What is Lean UX in SAFe?

Ever since Lean UX has appeared on the big picture of SAFe, everyone is curious to know what is Lean UX and how does it fit into SAFe framework ?

Definition of Lean UX (as defined by Jeff Gothelf and Josh Seiden)

  • Inspired by Lean Startup and Agile Development, it’s the practice of bringing the true nature of a product to light faster, in a collaboration, cross-functional way.
  • We work to build a shared understanding of the customer, their needs, our proposed solutions, and our definitions of success.
  • We prioritize learning over delivery to build evidence for our decisions.

Foundations of Lean UX

  • UX Design/Design Thinking
  • Agile
  • Lean Startup

Principles of Lean UX

 Principles to guide Team Organization

  • Cross-functional Team
  • Small, dedicated, collocated
  • Self-sufficient and empowered
  • Problem-focused team

 Principles to guide Process

  • Work in small batches to mitigate risk
  • Continuous discovery
  • GOOB: the new user-centricity (Get Out Of the Building)
  • Externalizing your work
  • Making over analysis
  • Getting out of the deliverable business

 Principles to guide Culture

  • Moving from doubt to certainty
  • Outcomes, not output
  • Removing waste
  • Shared understanding
  • No rock stars, gurus or ninja
  • Permission to fail

Lean UX Process


In Agile, standard user story template goes like this:

As a <user role…who>

I want <some goal…what>

So that <business value…why>

User role: we are not really worried about the segments of users, type of persona or this is just the experiment, and once we test , we learn about users or segments.

Some goal : most team replace with “some feature” and start implementing the feature, however in really again, this is just a hypothesis, which may be right or wrong.

Acceptance Criteria : System allows the user to complete a task. We are not sure  if the solution is usable or feasible or simply does any one wants this.

That is why, it makes sense to change the tune to “hypothesis based” (instead of fixed requirement), as this is just beginning of the conversation. Once we develop, test with user, and we know yes, this is what was needed.

Step 1: Outcomes, Assumption, Hypothesis

How might we ensure that these statements are true as quickly (and cheaply) as possible so that future decisions stand a better chance of succeeding?

Four types of assumptions:

  • Business outcomes: describe a measurable change we want to see in the world  or in customer behavior.

Can we make it easier for people to log in to our site?

Can we encourage more people to sign up?

Can we encourage greater collaboration among system users?

  • Users: The people for whom we believe we are solving a problem, often modeled as Persona.

We create Personas and we start with assumption and then do research to validate our assumption.

Proto-personas are our best guess as to who is using (or will use) our product and why.

  • User outcomes: Emotional or experience goal of user

What is the user trying to accomplish?

How does the user want to feel during and after this process?

How does our product or service get the user closer to a life goal or dream?

  • Features: Product changes, additions or improvements, we believe will help out customers achieve the goals.

We like to create feature list by brainstorming them as a team.

We are looking for features we think will help users achieve the user outcomes they seek.

In Lean UX, “Problem statement template”, looks like this

LeanUX_Problem _statement _template.png

Step 2: Collaborative Design

In this step, we need to design, so that we can build something that will help test hypothesis

  • Lean UX brings designers and non-designers together in co-creation.
  • Everybody gets to design
  • Low-fidelity artifacts (Ex: wireframe) increases collaboration
  • Build Shared understanding
  • Sketching exercise like Design Studio, Design Sprint

Design Studio Flow (Author: Jeff Gothelf) – 5 steps

  • Problem definition and constraints (15-45 minutes)
  • Individual Idea generation (diverge) (10 minutes)
  • Presentation and critique (3 minutes per person)
  • Iterate and refine in pairs (emerge) (10 minutes)
  • Team idea generation (converge) (45 minutes)

Similar to Design Studio, there are other flavors like design sprints, sprints etc

Design Sprint –GV (Google Venture)

Design sprints are a framework for teams of any size to solve and test design problems in 2-5 days.  Here are the steps, as reflected in the book “Sprint”, Author (Jake Knapp),

  • Map- map out the problem and pick an important place to focus
  • Sketch- sketch competing solutions on paper
  • Decide- make difficult decisions and turn your ideas into a testable hypothesis.
  • Prototype
  • Learn - test it with real live humans

Design Sprint (Author: Richard Banfield)- explains 5 steps in his book

  • Understand
  • Diverge
  • Converge
  • Prototype
  • Test

Step 3: Create an MVP

Lean UX makes heavy use of the notion of MVP. MVPs help us test our assumptions-will this tactic achieve the desired outcome?

Purpose of MVP

  • Learn something
  • start delivering value to the market as quickly as possible

Guidelines for creating MVP

  • Be clear about your learning goals
  • Go small
  • You don’t necessarily need code
  • Truth curve- amount of effort should be proportional to the amount of evidence
  • Example: Landing page test, feature fake, wizard of oz etc

Step 4: Research & Learning

It’s now time to put your MVP to the test. All of our work up to this point has been based on assumptions; now we must begin the validation process.

As you and your team collect feedback from various sources and try to synthesize your finding.

  • Look for pattern
  • Place your outliers in a “Parking lot”
  • Verify with other sources

Test what you have got

  • Sketches – great conversations
  • Static wireframe
  • High fidelity visual mockup (not clickable)
  • Clickable mockup
  • Coded Prototype


So where exactly ‘Lean UX’ fits in ‘Agile’ or vice versa.
As per model “Sy and Miller” defined in 2007, design activity takes place one sprint ahead of development. Work is designed and validated during the “design sprint” and then passed off into the development stream to be implemented during the development sprint, as shown in below diagram. This is called ‘sprint zero’ or sometimes “staggered sprints”.



Like this post? Share it with friends