DesOps : the Next Wave in Design (Part 9) Lean Methodologies & Hypothesis-Driven Design

I believe that any hypothesis statement can be cultivated from the bare-bones model of causeand effect being rendered as a formalized statement of ” if …. then” or ” when … then”kind of format. At least this gives a more practical approach to build a real-world Hypothesis-Driven Design based system which is technically feasible and is the essence of any DesOps system .

The second life-line as pointed out in the dimension of ‘Culture’ is “Cultural Shift towards Lean Philosophies” (Refer the part 5 of the current series here https://www.linkedin.com/pulse/desops-next-wave-design-part-5-definition-3-dimensions-samir-dash/ ). In this part of the series, we will be deep diving for the same.

Typically any lean methodologies are based two basic goals:

  1. Helping the organization understanding customer value
  2. Using the key processes of the organization to continuously increase it and work towards delivering a perfect value to the customer through a perfect value creation process with zero waste.

In the context of Design and User Experience(UX), in the seminal book Lean UX by Jeff Gothelf, provides some lean methodologies break the stalemate between the speed of Agile and the need for design in product development lifecycle” [Jeff Gothelf and Josh Seidenjeff, The Lean UX]. If we observe closely, the basic foundations of Lean UX prescribed are common to the core Lean philosophies, namely:

  1. Remove Wastage from Design Process — Moving away from heavy documentation to a process that creates artefacts which can be directly used in the design and development lifecycle itself.
  2. Cross-functional Collaboration — All the stakeholders from any parts of the product lifecycle including the designer, developers, quality experts, analysts, marketers and end-users all collaborate in a transparent and productive way.
  3. Experimentation Based Iterative Execution — So fundamentally it alludes to the UCD core principles, that assumes that the designer (or the team) learns from the execution of the prototypes in an iterative cycle that starts early in the product lifecycle, from which the learning is used as an input to improve the product along the way. If you notice this is the very basis of what we talked about the continuous and integrated feedback loop.

The use of Agile and Design Thinking practices can be seen alluding to the philosophies above. However, regarding the third philosophy — to ensure that the designer has the right approach to conduct the experimentation so that the feedback can be used in a productive way to take informative decision making along the way across the design process requires some non-ambiguous methodologies that can help the designer making some assumption and validate that through experimentation. This is the basis of one of the core foundations of Lean UX and related lean methodologies, which is popularly known as Hypothesis-Driven Design (HDD). As any design that we produce is based on certain assumption and HDD provides the non-ambiguous approach to the same, that follows the third philosophy i.e. Experimentation Based Iterative Execution.

“Declaring assumptions is the first step, in Lean UX process” [Jeff Gothelf and Josh Seidenjeff, The Lean UX] . This statement reflects how the assumptions or the hypothesis is the core the Lean UX principles. Basically, the four steps in the Lean UX approach is the same blocks that appear while in HDD, and can be mapped to the following blocks:

  1. Making Assumption / Formation of Hypothesis
  2. Build a Prototype / Minimum Viable Product (MVP)
  3. Execute / Run the Prototype
  4. Get Feedback / Observation

Now step 4 is the feedback loop that connects to step 1 making a cycle, thereby using the feedback from current iteration as the input to form the assumption for the next iteration.

Interestingly this means the HDD process always depends on outcomes rather than traditional outputs of any traditional process. The outcomes are kind of hints from the segment that can give direction to the design along the way and help in getting incremental validation of the vision by acting as “evidence” or the and more precisely they are the factors that help in “course correction” for the design. As the outcomes of the assumption act as pieces of evidence, it helps in making data-driven decisions.

You may ask, does that mean the design is reduced to quantitative factors which will act as evidence to support some of the designs? Now, here is the interesting aspect that helps to understand the approach — the feedback or the evidence can be either quantitative or qualitative in nature. And to avoid the risk of being limited to measurement-driven design, the qualitative perspective is provided equal footing in HDD approach. This makes a fit case for DesOps that can help in converging the technology with this philosophy to form required service design solution powered by machine learning, artificial intelligence and automation. The aspect of the actual implementation using technology is what we will be exploring in coming articles of this series, mostly while discussing the third dimension i.e. technology.

The very first step in HDD, i.e. “Making Assumption / Formation of Hypothesis” involves articulation of the assumption or the hypothesis. And this is the most important aspect of HDD, as the other steps depend on this. Typical hypothesis statement can be framed as per the following simplest form —

I think doing [this] will result in [that ].

There multiple variations to this that many professionals use in their area for HDD based research and design /development activities. Some add the factors such as the segment or the persona or the end user of the product, something like the following —

For [user / him/her ] I think doing [this] will result in [that ].

If you see the above keeps segment in a context that helps it keep focused on to specific persona, which thereby can lead to the user-centred design process. This is essentially labelled by many as a design hypothesis.

Some use additional factors of forming negation of the hypothesis by adding an attribute like whether this hypothesis is believed by him as true or false. To formulate a null hypothesis and thereby move on to define an alternate hypothesis (which is essentially a negation to the null hypothesis one craves to validate, but due to nature and structure or any metrics associated with that, it may not practically be possible to achieve that. So in such kind of cases the implicitly the state of belief is presented as another factor to take part in the validation process —

Because I think [this] is true, I think doing [this] will result in [that ].

I believe that any hypothesis statement can be cultivated from the bare-bones model of cause and effect being rendered as a formalized statement of “if …. then” or “when … then” kind of format. At least this gives a more practical approach to build a real-world HDD based system which is technically feasible and is the essence of any DesOps system.

The next important aspect in this regard is how to ensure that we are considering the qualitative aspect of the evidence, as discussed above. If we look at irrespective of the fact that there is a crowd of applications out there which claims to support the business through a data-informed approached, they are primarily a set of some variation between the extremes like A/B testing tools and data-driven analytics and data modelling based prediction systems. But if we notice with care at the core of HDD we found that the essence of HDD lies in making sense of the data and treat it as evidence so as to inject it to a UCD based process to fuel design or business decisions. Though coming up with a real-world HDD system would require similar tools and technologies of data-driven systems, but they will be supporting components to HDD based system. In this regard, the real HDD based full fledged system is literally non-existent as of today, while I am writing this article. In regards to DesOps, this makes a lot of difference, as most of the HDD frameworks out there are not 100% autonomous. Most of the implementation of HDD is mostly based on the work practices and methodologies, which is implemented depending on the need and feasibility. However, these are good enough when we use these, in context to the tools we gain from UCD, Lean models and the Design Thinking principles. But, it is interesting that the philosophies of DesOps, take it to the next level, making it autonomous and integrated with the over-arching feedback loop we have been referring many times.

To be continued… Keep tuned in.

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

Advertisements

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

How UX Fits in Different Models of SDLC?

In my last post “Challenges in UX integration with different SDLC models” we explored about the challenges of fitting UX into different SDLC models. I would like to extend that discussion in the current post.

 

he pre-agile era saw many attempts of UX getting fitted into the waterfall and it’s derivative models of SDLCs. Such attempts by the many developers were natural outcome of the post-projects disasters, where ‘design’ was never the personality of “software product engineering” and the lack of usability doomed the products even after the initial set of requirements check list was fulfilled.

More demands for Graphic User Interfaces (GUI) in software application (due to GUI’s power to offer better visibility and power to the end users) tempted the developers to follow emerging UX practices which included a task to add “design phase” to existing SDLCs. Waterfall model was good enough to accommodate a notion of design in its phases and become popular despite its limitations (which later pave paths for Agile era). Most of the design approaches and techniques created during this era were having mostly a goal “to eliminate any deviation during the development process, by telling the developers exactly what we expect of them”.

Let’s see how different models of SDLC accommodated UX differently in the following:

 

Waterfall model

In this process the developers follow the different phases described in the previous section in order.


 

 

 

UCD components in Waterfall model:

Historically the waterfall model of SDLC can use the UCD components in its engineering process and the product to translate the “set of requirements into something beautiful”. It is relatively simpler and easy to spot the to spot the areas within different phases where UX can be easily fits in as each phases are clearly

 

 

 

 

 

 

 

 

 

 

 

 

 

In this model once one phase is finished, it proceeds to the next one. Reviews may occur before moving to the next phase which allows for the possibility of changes. Reviews may also be employed to ensure that the phase is indeed complete; the phase completion criteria are often referred to as a “gate” that the project must pass through to move to the next phase. Waterfall discourages revisiting and revising any prior phase once it’s complete.

 

Spiral model:

In this model deliberate iterative risk analysis, particularly suited to large-scale complex systems happens at a predefined frequency. It emphasizes risk analysis, and thereby requires customers to accept this analysis and act on it. So the developers typically spend more to fix the issues and are therefore often used for large-scale internal software development.

The Spiral is visualized as a process passing through some number of iterations, with the four quadrant diagram representative of the following activities:

  1. Formulate plans to: identify software targets, implement the program, clarify the project development restrictions
  2. Risk analysis: an analytical assessment of selected programs, to consider how to identify and eliminate risk
  3. Implementation of the project: the implementation of software development and verification

 

 

 

Because of frequent risk analysis and more effort spent by the developer to analyze the risks accurately, the cost factor goes up in the project.

 

UCD components in Spiral model:

In Spiral model, the UCD design can work across different quadrants of activities. The first quadrant where the objectives are determined, the usability and user research can happen as this is where requirements are planned. In the second quadrant the activities involving risk identification can best use UX activities involving IA and prototyping. The third quadrant of development and testing can utilize consultation and usability testing. The final fourth quadrant of activities can be used for feasibility evaluation and setting up usability metrics and bench marking for the next release.

..

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Iterative development model

This method helps to develop a system through repeated cycles and in smaller chunks at a time, allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system.

Incremental development divides the system functionality into increments (portions). In each increment, a portion of functionality is delivered through cross-discipline work, from the requirements to the deployment. The unified process groups increments/iterations into phases: inception, elaboration, construction, and transition. It identifies scope, functional and non-functional requirements and risks at a high level which can be estimated. 

Applying this model to multidisciplinary complex project with large volume can come with a risk as inability in the developers part to uncover important issues early before problems can spoil the project.


 

 

 

 

 

 

 

 

 

 

 

 

 

 

UCD components in Iterative development model

In this model each iteration cycle can be divided into different activities phases to incorporate UCD methodologies for UX integration. Each iteration activities block that are mostly split across concept, design, build and test phases can be used for different UCD activities.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Agile development

This is perhaps today’s the most widely used SDLC model. It uses iterative development as a basis ,but uses people-centric viewpoint through user feedbacks rather than planning as the primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

There are many variations of agile processes “:

  1. Agile Data (AD)
  2. Agile Microsoft Solutions Framework (MSF)
  3. Agile Modeling (AM)
  4. Agile Unified Process (AUP)
  5. Dynamic System Development Method (DSDM)
  6. Extreme Programming (XP)
  7. Feature Driven Development (FDD)
  8. Scrum
  9. Usage-Centered Design (UCD)

 

 

UCD components in Agile development

This 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.

(c) 2013-14, Samir Dash

The ABCs of UX: The Diverse Disciplines (Part 1/3)

“To understand what the user is looking for in the things he is looking at.”

 

The current post is the first one in the series of 3 posts, where I would like to clarify the definitions and concepts that are core to our context covering User Experience (UX),Information Architecture(IA) and Interaction Design (IxD).

 

User Experience (UX)

User experience (UX) is a convergence of several disciplines. There is no final fool-proof list of disciplines which come together to form it. But yes, there are many popular explanations by social scientists, industrial designers and information architects which describe it as a combination of a verity of disciplines.

 

 Fig: 1

 The most popular and accepted compilation of disciplines is shown in Fig 1 where it is represented as a combination of :

 

  1. Information Architecture (IA)
  2. Visual Design
  3. Industrial Design
  4. Human Factors
  5. Interaction Design (IxD)
  6. Human – Computer Interaction (HCI)
  7. Architecture

 

There are variations available to this where commercial aspects are added to it . Fig 2 represents such a case.

 

Fig: 2

 

 In Fig:2, you can see the UX definition has been seen as all those disciplines which can work together to provide a solution that can deliver “customer with a harmonious and consistent experience”.

If you notice all the aspects such as “branding” and “customer service” are related with emotional aspect of human behavior. So user experience is also about emotions and psychological dimensions of customer’s perceptions about the product. Wikipedia also defines “User Experience” as :

User experience (UX or UE) involves a person’s emotions about using a particular product, system or service. User experience highlights the experiential, affective, meaningful and valuable aspects of human-computer interaction and product ownership. Additionally, it includes a person’s perceptions of the practical aspects such as utility, ease of use and efficiency of the system. User experience is subjective in nature because it is about individual perception and thought with respect to the system. User experience is dynamic as it is constantly modified over time due to changing circumstances and new innovations.”

Similarly ISO 9241-210 defines user experience as:

a person’s perceptions and responses that result from the use or anticipated use of a product, system or service”. According to the ISO definition user experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use. The ISO also list three factors that influence user experience: system, user and the context of use.

 

So basically, “User Experience” deals with the “How” factor of the product or system rather than it’s “What” factor. Most of the customers buy the product not because simply “what it does”, rather the “how” factor takes priority when it comes to choose from a several similar products.

We will dive deep throughout this series, but before that let’s see clear similar jargons.

 

Information Architecture (IA)

 

While exploring UX in previous section, we saw that Information Architecture (IA) is one of the contributing disciplines which form the total User Experience. During 1960’s ,Richard Saul Wurman, an architect by profession having skills of a graphic designer, author and an editor of numerous fine graphics related books, coined the term “Information Architecture”. He mostly developed concepts “ in the ways in which information about urban environments could be gathered, organized, and presented in meaningful ways to architects, to urban planners, to utility and transport engineers, and especially to people living in or visiting cities”. Later these impacted a set of disciplines such as library- and information-science (LIS) , graphic design and in recent years the world wide web (www). During 1990’s , with the evolution of the Web, there rose the need to rethink the presentation of library-catalog information as this information has been moved into online public-access catalogs, and in part to the proliferation of information on the Web itself. So during 90’s IA has taken on something of a connotation of applying especially to the organization of information on the World-Wide Web.

Basically Information Architecture (IA), all about organizing information in a meaningful way so that the user can easily find it when needed through proper organizationnavigation,labelingandsearchingsystems.IA also takes care of the process that ensures that there is no information breakdown or explosion with the scaling of information overtime.

 

Fig: 3

 Fig:3 represents the 3 basic ingredients of IA, namely:

Users: This represents those who will use the product or system, their “information seeking behaviour” and their needs. Any of the following roles/skills/features can be applied to them:

  1. Personas
  2. Ethnography
  3. Usability Testing
  4. Expressing User Needs

 

Content: This is what is presented to the users through the product or system. This includes the data or information that is offered, along with its aspects such as volume, metadata, structure and organization. Sample skills/roles/features/concepts revolving around content are:

  1. Indexing
  2. Cataloguing
  3. Site Architecture
  4. Writing
  5. Content management
  6. Navigation
  7. Labeling
  8. Search mechanism

 

Context: This is what gives meaning to the content that is being served to the user. This can have the attributes like business model, business value, resource, resource constraints, culture etc. The following features/roles/skills are associated with context:

  1. Defining business requirements
  2. Project management
  3. Business model analysis
  4. ROI calculation
  5. Client management
  6. Technical constraints

 

(To be continued…)

 

(c) Samir Dash , 2013 -14