This document outlines Lean UX principles and processes. Some key points: - Lean UX follows principles of design thinking, agile development, and lean startup to improve user experience through cross-functional collaboration, continuous learning and iteration. - Teams are small, focused on solving one problem at a time through hypothesis-driven experiments rather than predefined features. The goal is to learn from users, not just produce outputs. - The process involves declaring assumptions, creating minimum viable products to test hypotheses, running experiments to get user feedback, and using insights to iterate quickly through small batches. - Personas, user stories and features are defined based on the problem statement and assumptions to guide collaborative design and rapid protot

1. Lean UX principles
1
Tristan Libersat - September 16 2015

2. Foundations
2

3. It’s all about…
IMPROVING USER
EXPERIENCE
3

4. Lean UX is a combination of
DESIGN THINK
AGILE
LEAN START-UP
4

5. Principles
5

6. Cross functional, small, dedicated,
colocated teams
• Cross-functional squads
• High level of collaboration
• Squads of 10 people maximum
• Focused on 1 project at once
• Seated together
6

7. Progress = outcomes, not output
✖ We will create a single sign-on feature
✓ We want to increase the number of new sign-
ups to our service
The objective is to solve one problem, not
implement a feature
7

8. • The ONLY objective is to solve one problem,
not implement a feature
• Anything else is a waste of time
Problem-Focused Teams
Removing waste
8

9. • The faster we ship, the
most we can learn
• Involve the customer
• Research, experiment…
Small Batch Size
Continuous Discovery
9

10. GOOB: The New User-Centricity
• Get Out Of the Building, meet people
• Don’t decide things in an office room
10

11. Shared Understanding
• Collective knowledge is the key
• Rockstars, Gurus, and Ninjas break the
team work
• Expose the work & progress to everyone
• Use whiteboards
11

12. • If an idea is worth taking a risk, do it, don’t try
to debate on assumptions
• Don’t scale too quick, make sure it’s the right
thing to do first
Making over Analysis
but Learning over Growth
12

13. Permission to Fail
• Most of the ideas will fail, but that’s OK, that’s
what we try to learn
13

14. Getting out of the Deliverables Business
NO SPECS
(or just the minimum)
Don’t care about specs, the outcomes are
more valuable
14

15. Process
15

16. Declare Assumptions
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
16

17. Problem Statement
• Who: Team exercise + external if necessary
(content managers, support team)
• Preparation:
• How the product is currently used?
• Why customer are using it this way?
• Previous attempts to fix the issue, successes & failures
• How solving this would affect the company’s perf?
• How competitors are tackling the same issue?
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
17

18. • Define the problem statement:
• [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 it so that
our customers are more successful based on [these
measurable criteria]?
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
Problem Statement
18

19. Declare the Assumptions
Business assumptions:
• What need(s)?
• How can we solve them?
• Who are/will be the users?
• What is the #1 value the users want from my service/
product?
• Other benefits?
• How will I acquire the customers?
• How will I make money?
• Who will the main competitors be for this?
• How will we beat them?
• What is the biggest project risk?
• How can we solve it?
• What other assumptions do we have that, if proven
false, will cause our business/project to fail?
User assumptions:
• Who is the user?
• Where does our product fit in his life?
• What problems does our product solve?
• When and how is our product used?
• What features are important?
• How should our product look and behave?
Technical assumptions:
• What devices are impacted?
• What constraints could block us from delivering the product?
• What dependancies could be required for the product?
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
19

20. Prioritize the Assumptions
Known Unknown
Low risk
High risk
Test those ones first
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
20

21. Define the Hypothesis
• Define how to test the assumption
=> outcomes / KPIs
• And maybe breakdown them if necessary
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
21

22. Define the Personas
Sketch & name
Behavioral demographic
information
Pain points & needs Potential solutions
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
22

23. 1. Problem definition and constraints (15-45min, together):
make sure everyone knows the assumptions, hypothesis,
personas
2. Individual idea generation (10min, individual): quickly sketch
6 solutions based on personas / problems / hypothesis…
3. Presentation and critique (3min each, together)
4. Iterate and refine (5-10min, individual): refine the work into 1
final idea
5. Team generation idea (45min, together): converge to the
idea that has the biggest chance of success (according to the
team)
Use a
style guide
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
Collaborative Design -
Design Studio
23

24. Finally, list the Features
We will for in order to achieve
[create this feature] [this persona] [this outcome].
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
24

26. Create an Minimum Viable Product
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
26

27. Try to learn something
“The MVP is the minimum features
that are required to learn what
customers want.”
- Eric Ries
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
27

28. • It doesn’t necessarily have to involve any
development, it can be a landing page
promoting a future feature, or a newsletter, or
a dead-end button…
• Either way, don’t stop wondering if you have
reached the minimum feature-set yet
Try to learn something
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
28

29. Prototyping & coding
• Who will be interacting with it?
• What do you hope to learn?
• How much time do you have to create it?
• A good toolkit / style guide allows both designers
& developers to focus on interactions and earn
much time
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
29

30. Run an Experiment & Get Feedback
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
30

31. • Usability testing, onsite surveys, design
research, released product, whatever you
choose, the whole point is collecting data to
be able to decide what to do next
• Test everything
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
Again, try to learn something
31

32. Making sense
• Look for patterns
• Park the outliers: you may discover a pattern later
• Verify with other sources
Declare
Assumptions
Create an
MVP
Run an
Experiment
Feedback and
Research
32

33. Lean UX in an Scrum process
33

34. Declare Assumptions
34

35. Scrum & Lean UX
• User stories, Product & Sprint Backlog, Sprint, Stand-ups,
Retrospectives, that doesn’t change
• but the Sprint Planning changes a bit and so does the Sprint
organization…
35

36. Scrum & Lean UX
Test #1
Sketching / Ideations Iteration planning meeting Usability / value testing
36
Iteration #1
Iteration #1
SPRINT SPRINT SPRINT SPRINT
Test #2
Iteration #2
Iteration #2
SPRINT SPRI
Iteration #3
Iteration #3
Design Development
1st cycle can be extended repeat this part

37. Thank you
37