Lean UX cycle

Lean UX cycle

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

Remove waste from the UxD process

Too much too often product (software) design and development is 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, in order to improve our products (software) iteratively and incrementally.

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

What do I mean?

Useful deliverables (depending upon your context):

  • Branding and styleguide (by preference a living styleguide, to minimise maintenance effort)
  • Low-cost prototypes used in user testing
  • Low-cost sketches, mock-ups, 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 minimise 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, including UX people, including usability engineers, including developers, including product owners, including business stakeholders, marketeers, 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).

In every step of the cycle, and from the very beginning, the whole team is involved. The whole 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 minimises 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 exists for centuries and we are simply applying it to nowadays 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 on-going process, it 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) which matter for your end-users, which mean a difference, which serve their needs is:

  • by first focusing on outcomes (objectives) and next 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 upon that feedback
  • by building upon collective knowledge and wisdom and let the whole team flourish in creating the best experience
  • by creating products iteratively and not only incrementally
  • by minimising 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 organise user testing
  • How to incorporate validated learnings

Resources

Lean UX book

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

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

A few articles

Real sprints

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 whole team approach aims to create a shared understanding with everyone (all team roles) from the beginning 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 are able to implement product features end to end, creating pieces of value with every item done. Collaboration with all team members is a great source of creativity, new ideas and innovation. This kind of cross-functional collaboration is demanding: people are expected to think outside their box, to participate in work outside their main domain, and to help to create that necessary shared understanding to be able to deliver value within an iteration.

Teams working in a phased approach (the so-called staggered sprints) face a number of worries – this should not be accepted as common, and such teams should strive for a better way of working. A phased approach is basically 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 amongst the developers
  • Groupthink
  • Waste (hand-overs, intermediate deliverables, etc)

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

  • Understanding of concepts and users’ needs amongst all team members
  • Improved time to deliver (precondition is to deliver 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 re-consider any large upfront work (before “construction”), and try to create shared understandings with the whole team. That shared understanding will lead to willingness to truly collaborate together within the same sprint. In the Lean UX approach you foresee a regular cadence of user tests. 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: