Lean UX cycle

Lean UX cycle

Lean UX = applying Lean and Lean Startup principles to User eXperience.

 

Remove waste from the UxD process.

Too often, product (software) design and development are document-driven. With the agile manifesto and principles in mind, we want to focus on creating great and valuable products (software) and releasing these early and often to get valuable end-user feedback to improve our products (software) iteratively and incrementally.

Forget about the overload of UxD deliverables created to communicate “specifications” to “developers.” Re-consider and only create those deliverables that genuinely serve a purpose. We value “making” over “analysis“; we value “building” over “specification.” Lean helps us focus on flow and reduce non-value creation (waste).

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and style guide (by preference a living style guide, to minimize maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mockups, designs, etc

Overhead deliverables:

  • Detailed User Interface specifications (for example, including annotations of every screen)
  • Wireframes of every screen, every screen size
  • Visual designs of every screen
  • High-fidelity mockups (not reused in development)

Try to minimize the “upfront” creation of large UxD deliverables to be handed over to developers; instead rely on true cross-functional collaboration.

Cross-functional collaboration

True cross-functional collaboration (including designers, UX people, usability engineers, developers, product owners, business stakeholders, marketers, etc). True agile cross-functional collaboration is the foundation and the catalyst for collaboration and short development/release cycles—agile re-focuses product (software) development on value creation and working products (software).

The whole team is involved in every step of the cycle from the very beginning. The entire team approach aims to create a shared understanding with everyone all the time. Knowledge user feedback can be quickly spread and shared, and the team minimizes the need for handovers (in any form: documents + interpretation, pass-through communication, re-discussions, etc).

Apply the scientific method.

BUILD > MEASURE > LEARN

or

MAKE > CHECK > THINK

The scientific method has existed for centuries, and we apply it to modern product (software) development.

"The Scientific Method as an Ongoing Process" by ArchonMagnus - Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons - https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg
“The Scientific Method as an Ongoing Process” by ArchonMagnus – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:The_Scientific_Method_as_an_Ongoing_Process.svg

In Lean Startup, this is known as the build > measure > learn cycle. This is an ongoing process that obviously doesn’t stop with 1 iteration. We also call this make > check > think.

Lean UX cycle basic
Lean UX cycle basic

The only way to create products (software) that matter for your end-users, which means a difference, that serves their needs is:

  • by first focusing on outcomes (objectives) and following on features (solutions)
  • by getting in touch with your end-users, observe and measure how they use your products
  • by focusing on creating valuable experiments to expose risks and uncertainty
  • by improving whatever you’re making based on that feedback
  • by building upon collective knowledge and wisdom and letting the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimizing the total time going through this process
  • by creating an environment of continuous learning

Learn more about Lean, Lean UX, and product development with experiments in follow-up posts!

  • Techniques to bring UxD and development closer together, why collaboration matters.
  • The scientific method and product development with experiments
  • How to organize user testing
  • How to incorporate validated learnings

Resources

Lean UX book

Materials in this post are based upon readings on Lean UX.

Lean UX book by Jeff Gothelf.
Lean UX (Jeff Gothelf)

A few articles

True cross-functional product development

Cross-functional” collaboration in (agile) product development means that the whole (complete) product “development” team is participating. Scrum talks about a “development” team without distinction of role. As such, “developer” means any competence or skill required to create the product or service, not limited to “programming” (writing code).

Lean UX heavily promotes the whole product development team participating during the complete product development cycle from the very beginning. The entire team approach aims to create a shared understanding with everyone (all team roles) from the start and to minimize any waste originating from working in sub-teams or silos (hand-overs, intermediate deliverables, re-discussing the same topic with people who didn’t participate, etc.).

Shared understanding
Shared understanding

True agile teams (feature teams) are product-oriented and can implement product features end to end, creating value pieces with every item done. Collaboration with all team members is an excellent source of creativity, new ideas, and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, participate in work outside their main domain, and help create that necessary shared understanding to deliver value within an iteration.

Teams working in a phased approach (the so-called staggered sprints) face several worries – this should not be accepted as standard, and such teams should strive for a better working method. A phased approach is some work done in a sprint before the “development” sprint (or, even worse, acceptance or testing after the” development” sprint).

Staggered sprints
Staggered sprints

The challenges with this phased approach are:

  • Sprints become out of sync
  • Iteration without agility
  • Lack of ownership among the developers
  • Groupthink
  • Waste (hand-overs, intermediate deliverables, etc.)

The (single) (proper) Scrum team approach has numerous benefits:

  • Understanding of concepts and users’ needs among all team members
  • Improved time to deliver (precondition is to provide chunks of value you are able to implement within a sprint)
  • Less re-work, less waste
  • Improved definition of done
  • Sense of ownership amongst all team members

And so, we urge you to reconsider any extensive upfront work (before “construction”) and try to create a shared understanding with the whole team. That shared understanding will lead to a willingness to collaborate within the same sprint. You foresee a regular cadence of user tests in the Lean UX approach. The aim is to create a “test everything” culture: we test what’s available, and given the users’ feedback, we improve (we iterate).

Real sprints
Real sprints

Sources: