LEAN UX Excerpt

Reading notes of Lean UX: Designing Great Products with Agile Teams

Siyu's Newsletter
10 min readSep 14, 2019

Preface

  • Lean principles apply to Lean UX

First, they help us remove waste from our UX design process.

Second, they drive us to harmonize our “system” of designers, developers, product managers, quality assurance engineers, marketers, and others

Last, is the mindset shift we gain from adopting a model based on experimentation.

  • The designer’s role begins to evolve toward design facilitation, and with that we take on a new set of responsibilities.
  • Design Agile refocuses software development on value. It seeks to deliver working software to customers quickly and to adjust regularly to new learning along the way.
Lean UX By Jeff Gothelf, Josh Seiden

Section I

C1 Why Lean UX?

  • Three foundations of Lean UX: Lean Startup, Design Thinking and Agile development philosophies.

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 Startup processes reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible.
  • Each design is a proposed business solution — a hypothesis.

Design Thinking

  • Tim Brown described design thinking as “innovation powered by…direct observation of what people want and need in their lives and what they like or dislike…to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”

Agile software development

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

The practice of Lean UX is:

Lean UX is the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way that reduces the emphasis on thorough documentation while increasing the focus on building a shared understanding of the actual product experience being designed.

C2 Principles

  • Cross-Functional Teams
  • Small, Dedicated, Colocated
  • Progress = Outcomes, Not Output
  • Problem-Focused Teams
  • Removing Waste
  • Small Batch Size
  • Continuous Discovery (the ongoing process of engaging the customer during the design and development process)
  • The New User-Centricity (Ultimately, the success or failure of your product isn’t the team’s decision — it’s the customers)
  • Shared Understanding
  • Anti-Pattern: Rockstars, Gurus, and Ninjas
  • Externalizing Your Work (getting your work out of your head and out of your computer and into public view)
  • Making over Analysis
  • Learning over Growth
  • Permission to Fail
  • Getting Out of the Deliverables Business (Lean UX refocuses the design process away from the document)

The team is creating to the outcomes the team is achieving. The team’s focus should be on learning which features have the biggest impact on the their customers.

Section II

The day-to-day rhythm of Lean UX: a team working collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback.

C3 Vision, Framing, and Outcomes

We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes.

Assumption

  • The hypothesis statement is the starting point for a project. It states a clear vision for the work and shifts the conversation between team members and their managers from outputs (e.g., “we will create a single sign-on feature”) to outcomes (e.g., “we want to increase the number of new sign-ups to our service”).
  • The hypothesis statement is a way of expressing assumptions in testable form. It is composed of the following elements: Assumptions, Hypotheses, Outcomes, Personas, Features

Problem Statement

Problem statements are made up of three elements:

  1. The current goals of the product or system
  2. The problem the business stakeholder wants addressed (i.e., where the goals aren’t being met)
  3. An explicit request for improvement that doesn’t dictate a specific solution

Problem Statement Template

[Our service/product] was designed to achieve [these goals]. We have observed that the product/service isn’t meeting [these goals], which is causing [this adverse effect] to our business. How might we improve [service/product] so that our customers are more successful based on [these measurable criteria]?

Prioritize assumptions

The goal is to prioritize a set of assumptions to test based on their level of risk (i.e., how bad would it be if we were wrong about this?) and how much understanding we have of the issue. The higher the risk and the more unknowns involved, the higher the priority to test those assumptions.

Hypotheses

Hypothesis statement

We believe [this statement is true].

We will know we’re [right/wrong] when we see the following feedback from the market:

[qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change].

Sub-hypotheses: Breaking the Hypothesis Down into Smaller Parts

We believe that

[doing this/building this feature/creating this experience]

for [these people/personas]

will achieve [this outcome].

We will know this is true when we see

[this market feedback, quantitative measure, or qualitative insight].

Outcomes

Lean UX teams focus less on output (the documents, the drawings, even the products and features that we create) and more on the outcomes that these outputs create.

Personas

  • When creating personas in this approach, we start with assumptions and then do research to validate our assumptions.
  • Proto-personas. Proto-personas are our best guess as to who is using (or will use) our product and why.

C4 Collaborative Design

Lean UX is a collaborative process…The more the team collectively understands, the less it has to document in order to move forward.

Design Studio

  1. Problem definition and constraints
  2. Individual idea generation (diverge)
  3. Presentation and critique
  4. Iterate and refine (emerge)
  5. Team idea generation (converge)

Style Guide

A successful style guide has three important characteristics: it’s accessible, it’s continually improved (a.k.a. a living document), and it’s actionable.

C5 MVPs and Experiments

MVP: create the smallest thing you can to determine the validity of each of these hypothesis statements.

Sometimes teams create an MVP primarily to learn something.

  1. Is there a need for the solution I’m designing?
  2. Is there value in the solution and features I’m offering?
  3. Is my solution usable?

In digital product design, behavior trumps opinion.

Paper Prototypes

Pros

  • Can be created in an hour
  • Easily arranged and rearranged
  • Cheap
  • Can be assembled with materials already found in the office
  • Fun activity that many people enjoy

Cons

  • Rapid iteration and duplication of the prototype can become time consuming and tedious
  • The simulation is very artificial, because you’re not using the actual input mechanisms (mouse, trackpad, keyboard, touch screen, etc.)
  • Feedback is limited to the high-level structure and flow of the product

Clickable Wireframes

Pros

  • Provides a good sense of the length of workflow
  • Reveals major obstacles to primary task completion
  • Allows assessment of findability of core elements
  • Can be used to quickly create “something clickable” to get your team learning from your existing assets instead of forcing the creation of new ones

Cons

  • Most people who will interact with these assets are savvy enough to recognize an unfinished product
  • More attention than normal is paid to labeling and copy

Hi-fi Prototypes

Pros

  • Produces high-quality and realistic prototypes
  • Visual design and brand elements can be tested
  • Workflow and user interface interactions can be assessed

Cons

  • Interactivity is still more limited than fully native prototypes
  • Users typically can’t interact with real data, so there is a limit to the types of product interactions you can simulate
  • Depending on the tool, it can be time-consuming to create and maintain these prototypes; maintaining a high-fidelity prototype and keeping it in sync with the actual product often involves duplicate effort

Focus on the core workflows that illustrate your MVP.

C6 Feedback and Research

Research is formalized curiosity. It is poking and prying with a purpose. — Zora Neale Hurston

  • Lean UX research is continuous; this means that you build research activities into every sprint. Instead of a costly and disruptive big bang process, we make research bite-sized…
  • It’s essential that you and your team conduct research together; that’s why I call it collaborative discovery.
  1. Look for patterns
  2. Park your outliers
  3. Verify with other sources
  • Lean UX research puts a priority on being continuous…Instead of running big studies, you’ll see a small number of users every week.
  • In order to maintain a regular cadence of user testing, your team must adopt a “test everything” policy…set expectations properly for the type of feedback you’ll be able to generate with each type of artifact

Other tactics

  • Search logs: Search terms are clear indicators of what customers are seeking on your site.
  • Site usage analytics: Site usage logs and analytics packages — especially funnel analyses — show how customers are using the site
  • A/B testing: relatively straightforward once your hypotheses evolve into working code.

Section III

C7 Integrating Lean UX and Agile

Scrum

An agile methodology promoting time-boxed cycles, team self-organization, and high team accountability. Scrum is the most popular form of Agile.

User story

The smallest unit of work expressed as a benefit to the end user.

As a [user type]

I want to [accomplish something]

So that [some benefit happens]

Backlog: A prioritized list of user stories.

Sprint: A single team cycle.

Stand-up

Retrospective

Iteration planning meeting

  • Agile: work in shorter cycles and to divide your work into sequential pieces.
  • Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication.
  • You waste time creating documentation to describe what happened during the design sprints. And if developers haven’t participated in the design sprint, they haven’t had a chance to assess the work for feasibility or scope. That conversation doesn’t happen until handoff.
  • For Lean UX to work in Agile, the entire team must participate in all activities — standups, retrospectives, IPMs, brainstorming sessions — they all require everyone’s attendance to be successful.
  • Besides negotiating the complexity of certain features, cross-functional participation allows designers and developers to create effective backlog prioritization.
  • The team could have selected a story card that needed less design preparation to work on first, which would have bought the designer the time necessary to complete the work.
  • An Agile framework (focus on the customer, continuous delivery, team sits together, lightweight documentation, team ownership of decisions, shared rituals like standups, retrospectives, etc.).

The challenge for outcome-focused teams is that their project plans are dependent on what they are learning. They are responsive, so their typical plan lays out only small batches of work at a time. At most, these teams plan an iteration or two ahead. This perceived “shortsightedness” tends not to satisfy most high-level managers. How then do you keep the check-ins at bay while maintaining the pace of your Lean UX and Scrum processes?

Two words: proactive communication.

  • Proactively reach out to your product owners and executives.
  • Let them know:

— How the project is going

— What you tried so far and learned

— What you’ll be trying next

  • Keep the conversations focused on outcomes
  • Ensure that dependent departments (customer service, marketing, ops, etc.) are aware of upcoming changes that can affect their work.
  • Provide them with plenty of time to update their workflows if necessary.

C8 Making Organizational Shifts

  • Shifting from output to outcomes

…teams must shift their conversation with leadership from one based on features to one centered on outcomes, and this conversational shift is a radical one. Product managers and product owners must determine which business metrics require the most attention.

teams build backlogs of hypotheses they’d like to test and prioritize them based on risk, feasibility, and potential success.

  • Moving from limited roles to collaborative capabilities
  • Embracing new skills

Plugging interaction designers into these existing workflows limits their effectiveness by limiting the scope of their work, which has a side effect of reinforcing a siloed team model.

Designers must open up the design process. The team — not the individual — must own the product design.

Designers must take a leadership role on their team.

  • Creating cross-functional teams
  • Creating small teams
  • Creating open, collaborative workspaces
  • Not relying on heroes

As a designer you must expect that many of the your ideas will fail in testing.

  • Eliminating “Big Design Up Front”
  • Placing speed first, aesthetics second
  • Valuing problem solving
  • Embracing UX debt

Teams need to make a commitment to continuous improvement, and that means not simply refactoring code and addressing technical debt but also reworking and improving user interfaces. Teams must embrace the concept of UX debt and make a commitment to continuous improvement of the user experience.

To use the concept of UX debt, write stories to capture a gap analysis between where the experience is today and where you’d like it to be.

…focus on maximizing two factors: increasing collaboration between client and agency, and working to change the focus from outputs to outcomes.

both agency and client benefit from the additional insight, feedback, and collaboration with one another.

  • Shifting agency culture
  • Working with third-party vendors
  • Navigating documentation standards

Use this documentation…to capture

decision history and inform future teams working on this product.

• Being realistic about your environment

Try out some ideas and prove their value via quantifiable successes. Whether you saved time and money on the project or put out a more successful update than ever before, these achievements can help make your case.

• Managing up and out

empowering teams to discover the features they think will best serve the business.

Two valuable lessons to ensure smoother validation cycles:

  1. There are always other departments that are affected by your work. Ignore them at your peril.
  2. Ensure that customers are aware of any significant upcoming changes and allow them to opt out (at least temporarily).

--

--

Siyu's Newsletter

I go by 思玉Siyu. UX Designer/Consultant at Thoughtworks. Former HCI student at University of Michigan-Ann Arbor. Blog: siyujia.net