DesOps: the Next Wave in Design (Part 7) The 10 Practices

A method, procedure, process, or rule used in a particular field is typically defined as practice for that field. In last article, we discovered about the 10 guiding principles that drive the DesOps. No wonder the practices involved in DesOps, loud the same principles to the core. Note that we are still discussing the culture driven by DesOps / DesignOps, that is typically fuelled by these practices.

Here are the broad practices that drive the DesOps philosophies:

1. Design Thinking

This practice ensures that we employ the creative problem solving, the typical methodologies and tools of Design thinking. Here are some quick notes and list of methodologies and tools used in IBM version of it which anyway follows the fundamental principles of Design Thinking https://medium.com/eunoia-i-o/quick-guide-notes-on-the-ibm-design-thinking-78490d7433dd.

The typical tools of Design Thinking, such as Stakeholders map, Experience maps (As Isand To Be), Personae, Roadmap, MVP, Kano Modelling, Story Boarding, Priority Grid etc. are coupled with continuous practices defined in the following to implement the Continuous Loop of the Design Thinking practice that holds the DesOps philosophies.

2. User-centred Design (UCD) and Usability Design

Users (both the typical user / persona from UX angle and the segment from marketing/business context ) are at the core of DesOps. Any design solution generated fundamentally is an advocacy of the user needs and tries to direct the business goals to build upon this. The business goals are also in such cases are market specific and are based on the pulse of the segments driven by the user needs. You can have a quick note on UCD and usability-design here https://www.linkedin.com/pulse/20140702070557-9377042-usability-design-and-user-centered-design-ucd/. As UCD or Usability design focuses on the Iterative Design approach of User Centered System Design (UCSD) process this fundamentally contributes to DesOps goals.

(Fig – Source: UX Simplified: Models & Methodologies, 2014, ISBN 1500499587 )

As UCD supports growing product through iterative design that is also fuelled by all 3 models of design which contribute to typical Design Thinking as well as Lean UX models, namely:

  • Cooperative Design: This involves designers and users on an equal footing.
  • Participatory Design (PD): Inspired by Cooperative Design, focusing on the participation of users
  • Contextual Design: “Customer-Centered Design” in the actual context, including some ideas from Participatory Design.

And here are the steps we use while implementing UCD , irrespective of the above models we follow: All these UCD models involve more or less a set of activities grouped into the following steps mentioned below:

  • STEP 1 – Planning: in this stage the UCD process is planned and if needed customized. It involves understanding the business needs and setting up the goals and objectives of the UX activities. Also forming the right team for the UX needs and if needed hiring specialties fall into this step.
  • STEP 2 – User data collection and analysis: This step involves data collection through different applicable methodologies such as user interviews, developing personas, conducting scenarios, use-cases and user stories analysis, setting up measurable goals.
  • STEP 3 – Designing and Prototyping: This involves activities like card sorting, conducting IA, wireframing and developing prototyping.
  • STEP 4 – Content writing: this involves content refinement and writing for web and similar activities.
  • STEP 5 – Usability testing: This involves is a set of activities of conducting tests and heuristic evaluations and reporting to allow refinement of the product. However, Usability Testing can have its set of steps involving similar activities such as planning , Team forming, testing, review and data analysis and reporting.

And you will see all these naturally fall into the places while any DesOps is implemented.

3. Hypothesis-Driven Design/Development (HDD) & Data-driven Decisions making

The DesOps story remains incomplete without referring to one of its key practices that are Hypothesis-driven – development (HDD), which certainly contributes to the service design like DesOps, that brings possibilities of changes to inculcate design thinking, innovation and organizational changes. It also promotes the lifecycle methods and adjusts them to ensure that integrated work-flow and work-culture is established that can make the best use of data-driven decision making by running multiple early-stage experiments (synonymous with what we are trying to achieve through continuous feedback loop and prototyping) and gathering insights from their outcomes (and not just output!). Another interesting thing is that this advocates the use of UCD approaches as it focuses on making an assumption, running experimenting and validating them with measurable data, and thereby taking some action based on the same.

Will elaborate on HDD driven methodologies in context to DesOps as we move in this series of articles.

4. Agile / Iterative Life Cycle

There are several challenges in integrating UX design and related activities into a typical agile software development lifecycle process. The most common problem is typically “ finding a balance between up-front interaction design and integrating interaction design with iterative coding with the aim of delivering working software instead of early design concepts”. This happens mostly because typical pure SDLC approaches primarily aim at “efficient coding tactics together with project management and team organization instead of usability engineering”.As Agile is more “a way of thinking about creating software products’ rather than being a specific process or methodology hints at the challenges of UX integration into it as integrating user research and UX design with agile, is itself an “agile antipattern”.The very idea of SDLC is a process for developing software, traditionally never kept the “user” into a focus, or event kept any scope for methodologies that try to bring any component that is not considered as a native ingredient of the process of creating a software product. The focus was always the “cost, scope, and schedule” that drive any traditional SDLC models including Agile. And sure enough, this typically gives rise to the challenges for UX integration into any SDLC as project managers never try to upset the balance of these three by reducing costs, tightening deadlines, and adding features in the specification. To know more about the typical challenges we face while implementing design / UX into Agile SDLC read my earlier article here: https://www.linkedin.com/pulse/20140706143027-9377042-challenges-in-ux-integration-with-different-sdlc-models/

(Fig – Source: UX Simplified: Models & Methodologies, 2014, ISBN 1500499587 )

However, there ways to mend this gaps between process driven life cycle models such as Agile model — one of such is to implement usability design model (we discussed that as a practice of DesOps above). Usability process supplements to any software development life cycle at various stages, as is not a complete product development process as it does not output the final product at the end of the process cycle. One such solution is reflected in below diagram :

(Fig – Source: UX Simplified: Models & Methodologies, 2014, ISBN 1500499587 )

And it is interesting to see that each cycle in such solution is actually contributing to a continuous cycle of Conceptualize – Design – Build – Test that aligns nicely with DesOpsprinciples and other practices.

5. Lean UX Approach

The Lean UX practice focuses on the Lean philosophies that focus primarily on reducing waste from the process and provide ways to simplify and expedite the delivery keeping the quality intact or enhanced. Interestingly the Lean UX is based on the 3 foundations which are also part of the DesOps practices list we are discussing:

  • Design Thinking: This foundation upholds the concept that “every aspect of a business can be approached with design methods” and gives “designers permission and precedent to work beyond their typical boundaries”.
  • Agile Software Development: Core values of Agile are the key to Lean UX.
  • Lean Startup method: Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets teams building quickly and learning quickly

No practice used in Lean UX is something new. Rather it is “built from well-understood UX practices”. Many of the techniques used over the time in various UX process and have the practical usability even today have been packaged properly in Lean UX. So the following foundation pillars of this also supports DesOps as inherited from this practice:

  • Cross-Functional Teams: Specialists from various disciplines come together to form a cross-functional team to create the product. Such a team typically consists of Software engineering, product management, interaction design, visual design, content strategy, marketing, and quality assurance (QA).
  • Small, Dedicated, Collocated: Keep your teams small—no more than 10 total core people as keeping small team has the benefit of small teams comes down to three words: communication, focus, and camaraderie. It is easier to manage the smaller team as keeping track of status report, change management and learning.
  • Progress = Outcomes, Not Output: The focus should be on business goals which are typically are the “outcomes”, rather than the output product/system or service.
  • Problem-Focused Teams:“A problem-focused team is one that has been assigned a business problem to solve, as opposed to a set of features to implement”.
  • Removing Waste: This is one of the key ingredients of Lean UX which is focused on “removal of anything that doesn’t lead to the ultimate goal” so that the team resource can be utilized properly.
  • Small Batch Size: Lean UX focuses on “notion to keep inventory low and quality high”.
  • Continuous Discovery: “Regular customer conversations provide frequent opportunities for validating new product ideas”
  • GOOB: The New User-Centricity: GOOB stands for “getting out of the building” — meeting-room debates about user needs won’t be settled conclusively within your office. Instead, the answers lie out in the marketplace, outside of your building.
  • Shared Understanding: The more a team collectively understands what it’s doing and why, the less it has to depend on secondhand reports and detailed documents to continue its work.
  • Anti-Pattern: Rock-stars, Gurus, and Ninjas: Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. So more efforts should on team collaboration.
  • Externalizing Your Work: “Externalizing gets ideas out of teammates’ heads and on to the wall, allowing everyone to see where the team stands”.
  • Making over Analysis: “There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room”.
  • Learning over Growth: “Lean UX favours a focus on learning first and scaling second”.
  • Permission to Fail: “Lean UX teams need to experiment with ideas. Most of these ideas will fail.The team must be safe to fail if they are to be successful”.
  • Getting Out of the Deliverables Business: “The team’s focus should be on learning which features have the biggest impact on the their customers. The artefacts the team uses to gain that knowledge are irrelevant.”

You can read more in one of my articles here:https://www.linkedin.com/pulse/20140710010240-9377042-lean-ux-another-agile-ux/?

6. Fail-Fast through Prototyping

Typically a Fail-Fast is about immediately reporting any condition that is likely to indicate a failure. Also, Fail-Fast allows gathering early stage feedback that serves as an input for the continuous UCD model which helps bring up solutions to the design issues using such input and thereby minimizes the risk of product failure in the hand of users or in the market. This is also a philosophy that aligns to the Lean Startup methodology and accelerates innovation as it encourages taking early stage risk. Typically the startup cultures undertake bold experiments to determine the long-term viability of a product or strategy, rather than proceeding cautiously and investing years in a doomed approach. In service design, this helps to improve the processes to make use of systems that support Lean methodologies and model. The great part is that this in DesOps while getting combined with UCD processes, provides options to run short and quick UCD iterative cycles of Think – Make – Break kind of model.

(Fig – Source: UX Simplified: Models & Methodologies, 2014, ISBN 1500499587 )

Prototype plays a crucial role in UCD models to achieve Fail-Fast and thereby ensuring early feedback on the design is received that can contribute to the evolution of the product. Different fidelity of prototypes is used in order to ensure that the target experience can be tested.

7. Continuous Discovery

Continuous Discovery is primaily involved with the conceptualization stage of the product lifecycle. This practice mostly is driven factors like

  • User focus: The goals of the activity, the work domain or context of use, the users’ goals, tasks and needs should control the development.
  • Active user involvement: Representative users should actively participate, early and continuously throughout the entire development process and throughout the system life cycle.
  • Simple design representations: The design must be represented in such ways that it can be easily understood by users and all other stakeholders.
  • Explicit and conscious design activities: The development process should contain dedicated design activities.

This practice, however, is not just limited to conceptualization stage, but organically is part of the evaluation and build stages as the outcomes from such stages of life cycle, it gets the input of feedbacks and evaluation results which aid in the discovery of the solution through the design process.

8. Continuous builds and delivery

This practice focuses on continuous design delivery that ensures that the DesOps sustains the lifecycle and supports iterative UCD cycles. This involves the process that supports the design of the solution which thereby contributing to the system development that is iterative and incremental. The early part of life cycles involving such practice typically gains life from prototyping which is used to visualize and evaluate ideas and design solutions in cooperation with the users.

So the factors in this practices are :

  • Evolutionary systems development: The systems development should be both iterative and incremental.
  • Prototyping: Early and continuously, prototypes should be used to visualize and evaluate ideas and design solutions in cooperation with the users.

9. Integrated & incremental testing

Evaluation and getting the feedback from all stages of the lifecycle is key to any DesOpsimplementation, therefore integrated testing (including usability testing) in an incremental fashion is what that plays a stronger role among all the practices. This actually draws from the UCD models running a User Centered System Design (UCSD) approach. As UCD experts help in benchmarking usability tests popularly known as “summative evaluations” that evaluates the performance of the system /product developed on several grounds. The metrics of this test is typically based on the “error rate for users as they use the system”, the “time it takes to attain proficiency performing a task”, and the “time it takes to perform a task once proficiency has been attained”. So the factor that drives the practice is —

  1. Evaluate use in context: Baseline usability goals and design criteria should control the development.

Note that the key here is that all the testing should support evaluations in context. In the real context of use, getting the data is what makes this effective and thereby making DesOpsmore fruitful.

(Fig – Source: Re-imagining Beta Testing in the Ever-Changing World of Automationhttps://medium.com/eunoia-i-o/re-imagining-beta-testing-in-the-ever-changing-world-of-automation-3579ac418007 )

The ISO standard also defines Quality process where context plays the major role. And interestingly Usability testing and HCI aspects are all driven by context. Read one of of my articles on how context plays a critical role in testing and usability, which also narrates an experiment named BetaStudio here – https://medium.com/eunoia-i-o/re-imagining-beta-testing-in-the-ever-changing-world-of-automation-3579ac418007 .

10. Service Design on an Integrated Feedback-Loop Model

The integrated feedback loop is actually more than getting testing reports. This practice ensures that the feedback flows from any point to any point as needed, may it be from stakeholder to Designers, or End-Users to Developer, Testers to Designers or in any path that flows from one persona to the other. Also, this includes the service design that helps to implement the DesOps which ensures the information, as well as the feedback, is flowing seamlessly even including from and to the systems and different roles. This certainly uses service design employing recent technologies like Automation, Machine Learning and Artificial Intelligence etc.

Hope this article was helpful. Keep tuning in for the next parts of this article series. Before moving on to next points on Culture of DesOps, we will be looking into a Business Model Canvas and try to see how DesOps fits in. Do share the words.

(c) 2018, Samir Dash. All rights reserved.

Advertisements

DesOps : the Next Wave in Design (Part 4) The 3C’s

The Living Design System is mostly perceived all about modular design. Mostly the patterns, being the referred to the “molecules” or “organisms” as a part of “atomic design process”, are made to allow the part of structure or group. This view of the living design system brings to focus, its two major aspects — first is, of course, the creation and maintenance of patterns. The later is about coming up with a process and ensuring that these fit into a workflow that both would touch both designer and developers and make the connections among their workflows. However, this latter aspect has remained challenging even for the experienced teams across the industry.

Historically and interestingly, DesOps at the beginning , without its formal name was focusing on the areas of creation and maintenance and sharing of its modular design systems.

Historically and interestingly, DesOps at the beginning, without its formal name was focusing on the areas of creation and maintenance and sharing of its modular design systems. At the very beginning phases in the last couple of years, it was more about the organisations having the design systems and making these socialised. Primarily these design systems have consisted of visual design languages and components and widgets. These design system had defined basic goals, principles, branding (for specific organisational identity) and a visual language that helped it maintain consistency in the creation of design artefacts and assets. Along with it the UI patterns and widget libraries included in them helped to bring consistency in terms of interactions across a wider scale of interfaces within the organisation or product portfolio.

Ensuring this became part of the strategic aspect of any UX or Design team, in the organisation that were responsible for driving this. Mostly this task became the primary share of the role of the Design Directors, Leads and Principals in the organisation as a part of their goal to ensure ringing the right maturity to their design team and practices.

This was definitely a low-hanging fruit in terms of what DesOps as principle is geared towards. The return from such low-hanging fruit was helpful in many ways. Apart from the consistency, it actually helped in reducing the friction among the teams regarding the design aspect. Also it helped reducing some aspect of operational inefficiencies in the design workflow to some extent and helped in reducing waste thereby helping the team to deliver at faster rate.

However the design work practices, unlike the development domain are more diverse and being the area with the most creative energy association in the whole lifecycle, the challenges to ensure the smooth amalgamation of the these design systems to the process blocks of the workflow was not easy. The fact is till the date writing this passage, it is still a challenge to fit the existing tools, to the design work-flows and then aligning it to the whole delivery track fuelled by the DevOps paradigm.

Recently the design team at AirBnB, came up with React Sketch App. Last year at RedHat UX team meet up Summit, as a part of a design challenge initiative I presented a concept Ditto, that was supposed to redefine the way the design can be integrated into a DevOpssupported environment. Will share the details of Ditto in coming articles of this series. ClearCleft also in recent times came up with Fractal that tried to reduce and even remove the distance between the design and development teams. Note that both the DevOps and DesOps are born out of similar drivers, however, the practices concerned with the two are very different.

From the example of Salesforce’s approach to design, the takeaway is the technological approach of use of “the single source of truth” can be a good starting point towards building a practical DesOps culture in the organisation. As the soul of DesOps based on the cultural shift and practices working towards Continuous Integration (CI) and Continuous Delivery(CD), it makes sense to use the living design systems as the foundation of the overarching concept of DesOps.

To understand the overarching structure of DesOps, we need to explore the various dimensions that give the concept its shape. From a framework point of view, if we look at it, the typical 3 pillars of any framework also fits here —

1. Consistency — in the context of DesOps  the consistency plays the major role both in approach and workflows as well as from the design perspective

2. Continuity — mostly it fuels the continuous design aspect that provides agility to the design process.

3. Complimentary – no doubt as DesOps completes the full-circle, it complements the vision of DevOps. 

In the next article, we will dive into the different models associated with the DesOps framework.

 

 

(c) 2018, Samir Dash. All rights reserved.

DesOps : the Next Wave in Design (Part 3) The Maturity of Design Systems

To understand where a DesignSystem  of an organisation stands in context of implementing a DesOps, first step is to evaluate the existing DesignSystem that is in place and contributes to the organisation’s design process. (We will explore the process aspect in details, in later articles in this series.) To evaluate any DesignSystems  in a broadway we can easily form a metrics that takes care of the following two perspectives on the system.

Designer System Types

Typically the Design Systems can be broadly categorised into 3 types, namely: StaticDynamic and Generative :

Static: Most of the attributes and elements that make this system is mostly static in nature. For example in a Static type Design System, the style guide may be pre-defined print ready reference, defining basic color standards and typography etc. The user has to read through and manually refer it to decide those related attributes in his work. This kind of System mainly prescribes guidelines, rules, principles which does not automatically change or created in a dynamic way either in the stages of creation or implementation by the developers etc. Typical organisational style guides, or UI pattern documentations where the system describes how and where to use the patterns with some sample code to refer are falling under this kind of categories.

Dynamic: This kind of DesignSystem  have the content as well as the principles of implementations are designed and developed in a way that can be directly used in the code. The creation and implementation of the content are dynamic and mostly geared towards the actual elements that can directly be used in the code. This kind of DesignSystem  is more than a reference system for the developer, rather as a part of the actual build of the actual products developed as a part of it. Most easily noticeable traits of this kind of DesignSystem  is that some special purpose frameworks, code libraries are part of it, which integrate into the actual builds of the products.

Generative: Generative DesignSystem  are the ones, which generate the actual build ready outputs that can directly go into the build of the product. For example, instead of a static style guide, a generative DesignSystem  can have the tool that will generate dev-ready HTML, CSS and Java Script based output from the designer/developer inputs. The output of such system, take care of the context for which the design outputs is needed. Let’s say if the developer needs to build a cross platform hybrid app, hen such system can generate the code that will take care of the scenarios for the interaction and behaviour for all target device resolutions, screen density as well as the behaviour for native wrappers as well as in-browser functionalities and restrictions. We will again journey into the details of the Generative Design Systems shortly.

Designer System Maturity 

The other angle to look at the Design Systems is to scale the maturity to measure how much the system has evolved. One of most important aspect of any Design System is to understand the maturity of it, as this helps to understand where it is in the overall DesOpsroadmap. Irrespective of the varied and complex categorisation of the same, we can still name the maturity as Low , Medium and High to get a quick and easy comprehension. And when we try to map the maturity, it takes care of the categorisation aspect.

Low Maturity: When the Design System has a low maturity, it mostly depends on the static attributes that we discussed above. The creation and maintenance of different attributes are mostly the result of manual effort and the most interesting point about this is that the designer and developers have the cognitive load to refer and comprehend and take decisions on what to use and not use in specific context of their work or product. It is also important, there may be some attributes which might have dynamic attributes , but most of them are out of the transition that the design system is having due to its evolution,

Medium Maturity: In the Design Systems  with medium maturity, the most elements and attributes are mainly dynamic in nature. These systems mostly depend on the frameworks, libraries etc. There may be some overlaps in static and well as generative attributes.

High Maturity: Similarly in Higher maturity, apart from the fact that it mostly contains generative attributes, it involves the aspects of automation, computer-vision and may deploy artificial intelligence (AI) to provide continuous pipelines that aspires to remove the human intervention form the process blocks. On ground reality it might require the human intervention to feed in the creative juices or decision power that impacts critical human needs or contexts.

When we map these 2 perspectives horizontally and vertically, we get the the right insight into the DesignSystem’s position in the graph that allows us to clearly understand where the gaps are for the DesignSystem to evolve on which dimensions.

Note that the metrics that govern the success of a DesOps implementation is almost synonymous to this metrics we explored about Design Systems. The factors that adds to this metric on Design Systems,  includes aspect where we measure how impactful the Design System is in touching the different design process lifecycle blocks where each role like an Information Architect or an Interaction Designer , Visual Designer or even the Developer are attached to, in the delivery track. This aspect is more figuratively termed as a Living Design System. 

The Living Design System

The scaling of design is a classic issue. Moreover in recent times the explosive growth of technology across different devices, platforms and ecosystems, it became an ever-growing monster that every designer faces sooner or later. Native (Windows, Android, iOS, Linux etc. ) Web (HTML, HTML5, CSS, CSS3, JavaScript and frameworks etc. ) Along with the combination – the Hybrid – make the scaling of the design language an unending challenge.

The Salesforce design team tried to solve the challenges of applying similar designs across cross-platform product families by introducing a dynamically configurable design asset system which viewed the individual entities of any design system as design tokens.

Technically it was a single JSON file that was the “Single Source of Truth” that contained a set of name-value pairs that defined the properties and their relationships under different categories like text colours, backgrounds, border sizes, font sizes, etc. This JSON was consumed by the framework (i.e. The Lightning Designing System link: https://www.lightningdesignsystem.com/downloads/) developed and templatized for different target platforms, devices, Operating Systems etc. The Lightning Designing System framework generated different formatted outputs for CSS via common CSS preprocessors like Sass, Less and Stylus. Also there was an output in XML format that is supported in Android and JSON for iOS specific development. The Salesforce Design Tokens open-sourced at https://github.com/salesforce-ux/design-system.

The second interesting aspect of this was the use of GitHub to host the design system. Unlike the design system of traditional organisation, where the design system was hosted as downloadable form (even in the cases where the version control like Git is used) these have to be either translated into desired formats for the target platform or hosted especially along with the code. But here the design tokens representing the styles definition and the properties, as hosted on GitHub, were directly integrated into the build process contributing to the Continuous Integration and Development approach of development. In this sense, it was more as a Living System acting a single source of truth, from which the required branch is pulled and be made as a part of the build.

Many other pattern library and/design systems like RedHat’s PatternFlyhttp://www.patternfly.org is also available in similar approach at GitHub (i.e. at https://github.com/patternfly )as that of this second aspect we discussed now. But the idea of making the style guide being available as a SingleSource of truth in combination of this second aspect is what makes the case of the Salesforce design system unique among similar attempts for an approach to deliver a consistent design across different platforms.

(c) 2018, Samir Dash. All rights reserved.

Rediscovering Accessibility for Future Tech!

This is a rediscovery of "Accessibility" in the world of touch-screens and other natural interfaces. With new technology innovation the lines between accessibility technology and Technology for Mass are getting blurred. What used to be a special need is becoming a general need for mass use.Situational Disabilities Use-cases are defining the new age devices, wearable & smart interfaces. High time we need to rediscover on "accessibility" what we think we have already discovered!

This is a rediscovery of “Accessibility” in the world of touch-screens and other natural interfaces. With new technology innovation the lines between accessibility technology and Technology for Mass are getting blurred. What used to be a special need is becoming a general need for mass use.Situational Disabilities Use-cases are defining the new age devices, wearable & smart interfaces.

High time we need to rediscover on “accessibility” what we think we have already discovered!

UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4

My  recent title is available on Kindle for download. This book covers basic models and methodologies that are revolved around User Experience (UX). The discussed topics include User Experience, Information Architecture, User Interface, Usability models, User Centered Design (UCD), User Centered Software Design (UCSD), different Software Lifecycles (SDLC) and how usability models fit into SDLC models.

The details of the book are as follows:

UX Simplified: Models & Methodologies: Digital Edition
by Samir Dash
ISBN: 978-1-3115-9110-4
ASIN: B00LPQ22O0

Kindle Price (US$):$1.87
Kindle Price (INR):Rs. 119.00 includes free international wireless delivery via Amazon Whispernet

http://www.amazon.com/dp/B00LPQ22O0/ref=r_soa_w_d

 

 

UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4
UX Simplified: Models & Methodologies: Digital Edition [Kindle Edition] ISBN: 978-1-3115-9110-4
Major topics included in this book are :

• Why “UX: Simplified”?
o The Diverse Disciplines: The ABCs of UX
o User Experience(UX)
o Information Architecture(IA)
o Interaction Design (IxD)
o User Interface Design (UI)
• Usability and Mental Models: Foundations of UX
o What is Usability?
o System Models
o What is a “Mental Model” exactly?
o Most-likely Mental Model
o Conceptual Model
o Challenges in Usability Measurement and Metrics
o A List of Factors for Generic and Consolidated Usability Model
o Heuristics:Measuring Usability
• Engineering and Design Processes: Usability and User Centric Approach
o Usability Engineering
o User-Centered Systems Design (UCSD)
o Usability Design
o User-Centered Design (UCD)
o Don’t get Confused: UCD vs UCSD
o UCD Models and Process
• Software Development Life Cycle (SDLC): Where and How User Experience Models fit in?
o Software Development Life Cycle (SDLC)
o Waterfall model
o Spiral model
o Iterative Development Model
o Agile development
o Challenges in UX Integration to Different SDLC Models
o Usability Designing Process
o How Usability Design Process Fits in Different Phases of SDLC?
o How UX Fits in Different Models of SDLC?
o Challenges with Agile model of SDLC to implement UX
o Lean UX and Agile Model
• Agile in Usability Design:Without Reference to SDLC
o Usability Designing Process
• Lean UX: Another Agile UX?
o The Beauty of Lean UX: Everything is familiar
o Foundation Stones of Lean UX:
o Lean Startup method: The concept of “Build-Measure-Learn”
o Minimum Viable Product (MVP) – Prototyping at it’s best in Lean Startup Method
o Principles of Lean UX

  • File Size: 1435 KB
  • Print Length: 86 pages
  • Simultaneous Device Usage: Unlimited
  • Sold by: Amazon Digital Services, Inc.
  • Language: English
  • ASIN: B00LPQ22O0

 

Lean UX : Another Agile UX?

Agile is the most popular and successful SDLC model as of today as it allows better scope in providing continuous and iterative refinement to the product. Historically when developers out of their frustrations with waterfall model turned to the growing Agile Movement to regain their control over the process, they found that “like its ancestors, Agile also didn’t take UX into account. Several of the Agile methods, such as Scrum and XP, recommended users sitting with the team during the development process, but that isn’t the same as design. Everyone who figured out how to get what they wanted from plugging UX into a phased waterfall approach was now struggling to work inside the Agile methods. The Agile principles, that focus more on communication and less on contracts, didn’t fit the status quo UX processes”.So efforts were made again to implement UX into Agile methods just like the way it was implemented into waterfall model . But it was not easy as , in waterfall model there are 2 things which helped implemented UX :

 

  1. The objectives of the project stays same from kickoff to the point where the finished product is launched.
  2. The designers created the set of design specifications as a contract which the developers had to implement into the final product.

 

And above two cannot be expected from Agile model as it is based on iterations and gradual exploration of what is best fit for the final product . On ejust simply cannot predict the final design from the start of the project. So many attempts were made to get the best agile SDLC practices that can incorporate the UX , before “Lean UX” was born.

 

As the above figure shows the documentation and guidelines are stripped to their bare minimum components, providing the minimum amount of information necessary to get started on implementation. Also Long detailed design cycles are discarded in favor of very short, iterative, low-fidelity cycles, with feedback coming from all members of the implementation team early and often.

 

 

Challenges with Agile model of SDLC to implement UX

There are several challenges in implementing UX in Agile model effectively and these challenges include:

  • Different approaches. Usability methodologies are centered on the user and holistic view of the user needs whereas agile methodologies take a broader view and focus on the stakeholder. Agile methods primarily focus on delivering working software early.
  • Different goals: Software engineers focus on the technical design, implementation the system where as UX practitioners focus on “developing systems so end-users can use them effectively”.
  • Organizational challenges: The agile methodologies focus on strategy where teams are self-organizing whereas UX focuses on a centralized UX groups within some organizations so that the needed practices, tools, and standards can be provided.
  • UX practitioners struggle to be heard: Many UX practitioners often complain that the results of their work are not considered in the design decisions and even if it is heard, there seems to be focus more on engineering decisions over the usability decisions.

Lean UX and Agile Model

 

Many of UX practitioners see “Lean UX” as the answers to the challenge we see in implementing UX into an Agile SDLC where it uses “taking the best parts of our current UX practices and redesigning them specifically for use in an agile world”. Lean UX, is about reducing waste in a process by removing it from the value chain of the usability process..

The proactive measures for border engagement in Agile model has paved path to a new and more practical implementation of UX discipline and methods called “Lean UX” Lean UX once blended with any exiting Agile SDLC, helps to “create a more productive team and a more collaborative process” .

 

The basic principles Lean UX uses to provide positive refinements to SDLC are through the following 3 foundation stones for it:

 

  1. Design Thinking:This foundation upholds the concept that “every aspect of a business can be approached with design methods” and gives “designers permission and precedent to work beyond their typical boundaries”.
  2. Agile Software Development: Core values of Agile are the key to Lean UX.
  3. Lean Startup method:Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets teams building quickly and learning quickly

 

Lean UX and UX in Agile SDLC

 

“Lean UX” is seen as the answers to the challenge we see in implementing UX into an Agile SDLC. As discussed in the earlier chapters, Lean UX principles use “taking the best parts of our current UX practices and redesigning them specifically for use in an agile world”.

Lean UX solved many issues were even there with the practices and usability process used in waterfall and different derivative iterative models. In Lean UX practices, there is no more requirements for the “objectives will stay the same and that you can design for a single solution throughout the project”. Also there no more need for the designers to create bulky guidelines and documentations for the developers to be used as a contract. Rather the Lean UX practice upholding agile approach, only focuses on each independent design iteration as a “hypothesis” which has to be validated from a “customer perspective” and from a “business perspective” . The beauty here is because of the Agile process being followed, fast iterations can happen to quickly test hypotheses and get to a great design in the end of the project.

In context of a real world situation the Lean UX is something like:

“The traditional paper work is discarded, while the focus is turned to making sketches of the idea. Then the sketch is presented and discussed with the team. The initial prototype effort is very small comparing to detailed documents, so it’s easy to make changes. After it’s agreed internally, rough prototype is made and tested with users. The learning from users help refine the idea and iteration starts over again”

And this makes case for “collaboration with the entire team” as it becomes critical to the success of the product and the whole project.

 

The Beauty of Lean UX: Everything is familiar

No practice used in Lean UX is something new. Rather it is “built from well-understood UX practices”. Many of the techniques used over the time in various UX process and have the practical usability even today, have been packaged properly in Lean UX.

 

Lean UX is not Same as Agile UX

Lean UX is a totally different term than Agile UX.Lean UX details methods and their practical application in dynamic environment of a Lean StartupIt is the converging point for product development and business, through constant measurement and so called “learning loops” (build – measure – learn).

Agile UX defines update of Agile Software Methodology with UX Design methods. It aims to unify developers and designers in the Agile process of product development.

However Lean UX uses Agile UX methodologies, tools to coordinate their software development.

Foundation Stones of Lean UX:

The key ingredients of Lean UX which act as foundation stones for it are:

 

  1. Design Thinking:
    This foundation upholds the concept that “every aspect of a business can be approached with design methods” and gives “designers permission and precedent to work beyond their typical boundaries”.

  2. Agile Software Development
    Core values of Agile are the key to Lean UX. It forces on 4 major principles of Agile development to product design:
    • Individuals and interactions over processes and tools: This principle louds the concept of exchange of ideas freely and frequently in a team. “The constraints of current processes and production tools are eschewed in favor of conversation with colleagues”
    • Working Software over Documentation:This focuses on bringing out solution quickly so that it can be “accessed for market and viability”.
    • Customer Collaboration over Contract Negotiation:Collaboration with teammates and customers builds consensus behind decisions which results in faster iterations and lessens heavy documentations.
    • Responding to change over following a plan: “The assumption in Lean UX is that the initial product designs will be wrong, so the goal should be to find out what’s wrong with them as soon as possible” and this helps in finding the right direction quickly.
  3. Lean Startup method: 
    Lean Startup uses a feedback loop called “build-measure-learn” to minimize project risk and gets teams building quickly and learning quickly. Typically startups are “free to build products in a manner which differentiate on quality”. Also startups can focus on “intrinsic value and usefulness of the product, rather than on a long list of mostly irrelevant features”. Startups have a distinguishable feature of reducing long product cycles into smaller, shorter chunks and validating these iterations with people that will use the products, actually opens the gate for important information needed to avoid expensive development cycles that come withsome kind of risk. ”The secret sauce of lean startup people is that they advocate for user experience research and design as one of the primary solutions to their business problems, and they do it using plain language”.

 

 

Lean Startup method: The concept of “Build-Measure-Learn”

The fundamental activity of a startup is to “turn ideas into products” at the first step. Next it has the aim to measure how customers respond and then to learn whether to pivot or persevere. So basically a startup’s success depends on this feedback loop. To be successful a startup has to accelerate that feedback loop. The feedback loop being employed here includes three primary activities: build the product, measure data and learn new ideas.

However the Lean Startup method employed in Lean UX , is slightly different – it’s basically about “Think-Make-Check”. The difference lies in the fact that in latter case the “feedback loop incorporates your own thoughts as a designer, not just ideas learned through measurement”.

 

Minimum Viable Product (MVP) – Prototyping at it’s best in Lean Startup Method

Minimum viable product is a version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The MVP is, in fact, an early prototype that serves as a tool to learn and test the team’s assumptions.

 

 

Lean UX is where prototyping is best promoted, focusing the prototype on major components of the experience. Once created, it will be immediately testable by any and all users to start the feedback loop. In most of the case the fidelity of the prototype is not a road block, rather the only mission is to get a quick prototype that can be tested quickly. However where the need for better visualization has priority, the best practices and tools are used to develop high fidelity prototypes in shortest time possible.

 

Principles of Lean UX

There are some guiding principles behind Lean UX which can be used to make sure the methodologies used in a Lean process is on track.

 

  1. Cross-Functional Teams: Specialists from various disciplines come together to form a cross functional team to create the product. Such a team typically consists of Software engineering, product management, interaction design, visual design, content strategy, marketing, and quality assurance (QA).
  2. Small, Dedicated, Collocated: Keep your teams small—no more than 10 total core people as keeping small team has the benefit of small teams comes down to three words: communication,focus, and camaraderie. It is easier to manage smaller team as keeping track of status report , change management and learning.
  3. Progress = Outcomes, Not Output: The focus should be on business goals which are typically are the “outcomes”, rather than the output product/system or service.
  4. Problem-Focused Teams:“A problem-focused team is one that has been assigned a business problem to solve, as opposed to a set of features to implement”.
  5. Removing Waste: This is one of the key ingredients of Lean UX which is focused on “removal of anything that doesn’t lead to the ultimate goal” so that the team resource can be utilized properly.
  6. Small Batch Size: Lean UX focuses on “notion to keep inventory low and quality high”.
  7. Continuous Discovery: “Regular customer conversations provide frequent opportunities for validating new product ideas”
  8. GOOB: The New User-Centricity: GOOB stands for “getting out of the building” — meeting-room debates about user needs won’t be settled conclusively within your office. Instead, the answers lie out in the marketplace, outside of your building.
  9. Shared Understanding: The more a team collectively understands what it’s doing and why, the less it has to depend on secondhand reports and detailed documents to continue its work.
  10. Anti-Pattern: Rock-stars, Gurus, and Ninjas:Team cohesion breaks down when you add individuals with large egos who are determined to stand out and be stars. So more efforts should on team collaboration.
  11. Externalizing Your Work:“Externalizing gets ideas out of teammates’ heads and on to the wall, allowing everyone to see where the team stands”.
  12. Making over Analysis: “There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room”.
  13. Learning over Growth: “Lean UX favors a focus on learning first and scaling second”.
  14. Permission to Fail: “Lean UX teams need to experiment with ideas. Most of these ideas will fail.The team must be safe to fail if they are to be successful”.
  15. Getting Out of the Deliverables Business: “The team’s focus should be on learning which features have the biggest impact on the their customers. The artifacts the team uses to gain that knowledge are irrelevant.”

 

 

 

 

 

 

(c)2013-14, Samir Dash

SIMPLE: Digital Content Distribution from Cloud (Proof of Concept)

This is one of my proof of concept application demo on how to prepare an eco-system for delivering protected digital content specially related to e-learning and m-learning context.

SIMPLE is an eco-system that allows tools such as

SimpleAuthor : That allows content authoring from common formats such as MS Office documents , PDFs and CBRs along with the options to author contents using cloud based WYSIWYG editor .

SimplePublisher: This allows you to import contents such as set of HTML files, ePubs, PDFs, text files, set of images, CBR files and the output from SimpleAuthor

SimplePlayer: This is a native course packaged with the required run-time that the end user will be using to view the content . This allows content activation and offline content tracking . In this current demo the Player is an EXE file that is being generated from the SimplePublisher. In the POC of the Publisher, each course is generated as an EXE file containing the content and the required runtime in it.

SimpleStore: In this POC you can see it as an online store that show cases different titles published using SimplePublisher. Basically it manages the catalog, and tracks activation of each offline course.

Note: the SIMPLE eco-system can be seen as an experiment based on the CUPID (Common Unified Programs for Instruction Delivery) guidelines. Check CUPID related info here:

OR at

http://cupid.mobilewish.com/