User roles = collection of defining attributes that characterise a population of users and their intended interactions
Persona = imaginary representation of a user role. Describe sufficiently so the team feel like they know the person (e.g. job, family, likes, comfort with technology). Include a description and a picture.
Extreme characters = over-the-top characters like a drug dealer or the pope
Good Persona Guidance
What Info should a good persona provide (1, pg 31)
Quote that conveys what they most care about
Relevant motivations and attitudes
Related tasks and behaviours
Frustrations/ pain points with current solution
Level of expertise/ knowledge (in the relevant domain, e.g. level computer savvy)
Product usage context/ environment (e.g. laptop in a loud, bust office or tablet on the couch at home)
Technology adoption life cycle segment (for your product category) – according to Geoffrey Moore’s Crossing the Chasm
Keeping personas as a living document, rather than a one time activity
Create proto-personas at the start and then validate that the persona is correct, rather than upfront research by a third party. Team are disconnected from the personas
Then validate 3 things
Does the customer exist?
Do they have the needs and obstacles you think they do?
A scientific, systematic way to build better products inspired by ‘The Four Steps to the Improvement Kata’ from Toyota Kata Practice Guide by Mike Rother
Product Kata Overview
Product Kata at two levels: Company and Product. For the Product level the example relates to the imaginary case study in the book of an online course company where teachers upload course content and students pay to access them.
Product Kata Walkthrough
1) Understand the direction
Create or establish the direction metrics
Ensure they aren’t vanity metrics and that when they increase/ decrease it actually means something
See the metrics page for more on creating good metrics
'The more user effort required to take an action, the lower the percentage of users who will take that action. The less user effort required, the higher the percentage of users who will take that action.'
Gestalt principles (1, page 136)
Principle of proximity – the brain perceives objects that are closer together as more related than objects that are farther apart
Principle of similarity – the brain perceives objects that share similar characteristics as more related than objects that don’t share those characteristics
Visual Hierarchy Design Principle (1, page 136)
The brain assumes larger objects are more important and smaller objects are less important
Elements with high contrast (e.g. items that ‘pop’) are more important
Position also affects visual hierarchy (e.g. for people who speak English the top left is the most important as that is how we read)
To determine visual hierarchy squint at the page you will be able to identify the most important design elements
Principles of composition (1, page 137)
Unity – does the page or screen feel like a unified whole or a bunch of disparate elements?
Contrast – is there enough variation in colour, size, arrangement, and so forth to create visual interest?
Balance – have you equally distributed the visual weight (position, size, colour etc) of elements in your design?
Use of space – how cluttered or sparse does your design feel? Ensure there is enough white space so that it doesn’t feel crowded.
UX Design Iceberg (1, page 116)
Conceptual design (1, page 117)
This is the core concept you are using to design your product
E.g. uber’s is based around a map
Information Architecture (1, page 120)
How the information and functionality should be structured
Findability – how easy it is to find what the user needs (test this)
Sitemaps are tool used to define the structure
Interaction Design (1, page 123)
Specify user flows
What actions can the user take?
Including error messages and slow response flows
Flowcharts are a tool for mapping flows
Wireframes are tool for testing
Visual Design (1, page 129)
Colours/ font/ graphics have emotions for user
Style guide used to ensure consistent feel
Layout grids used to ensure consistent alignment of the design (e.g. divide the desktop screen by 12 sections which is then used to put all the nav options/ content boxes in line with) (page 133)
What do we want to be in 5-10 years? Value for customers, position in market, what our business looks like
What business challenges are standing in the way of reaching our vision
Senior leadership Business leads
What problems can we address to tackle the challenge from a product perspective?
Product leadership team
What are the different ways I can address those problems to reach my goals?
Product Dev teams
Strategy Deployment Levels
Business Value Types
Framework for thinking about value by Joshua Arnold (1, page 82)
Increase Revenue – Increasing sales to new or existing customers. Delighting or Disrupting to increase market share and size
Protect Revenue – Improvements and incremental innovation to sustain current market share and revenue figures
Reduce Costs – Costs that we are currently incurring, that can be reduced. More efficient, improved margin or contribution
Avoid Costs – Improvements to sustain current cost base. Costs we are not currently incurring but may do in the future
Type of Value (3)
Commercial Value: How much revenue or profit does this work result in?
Market Value: How many new customers will we be able to serve?
Efficiency Value: How much time or money will this save us?
Customer Value: To what extent will this decrease the likelihood that a customer leaves?
Future Value: How much will this save us in time or money in the future?
Project Rather than Product Management Smell
Build Trap (1, page 1)
Build Trap = organizations become stuck measuring their successes by outputs rather than outcomes. […] When companies stop producing real value for the users, they begin to lose market share, allowing them to be disrupted.
Progress Focus Powerful Questions (2, page 80)
For when a company is focusing on percent complete, status, or points rather than value
Could we achieve all of these measure and still be unsuccessful?
How are we validating assumptions about the user needs of the market demand?
What are we learning about value? How I this guiding our product decisions?
What has changed with our users or our competitive environment since we began this initiative?
‘Product Vision Box’ Exercise (4) (5)
Give your product team cardboard boxes and pens
Ask them to design the box for the product they would buy
Definition: Assumptions are our best guess based on what we know today. They are also filled with risk. Your goal as Lean UX practitioners is to reduce risk. (1, page 23)
Four Big Assumptions (1, page 24)
Assumptions Workshop (1, page 24-25)
Find out the following in reference to the problem statement
Analytics reports that show how the current product is being used
Usability reports that illustrate why customers are taking certain actions in your product
Information about past attempts to fix this issue and their successes and failures
Justification from the business as to how solving this problem will affect the company’s performance
Competitive analysis that show how your competition is tackling the same issue
I believe my customers have a need to:
These needs can be solved with:
My initial customers are (or will be):
The #1 value a customer wants to get our of my service is:
They can also get these additional benefits:
I will acquire the majority of my customers through:
I will make money by:
My primary competition in the market will be:
We will beat them due to:
My biggest product risk is:
We will solve this through:
We will know we are successful when we see the following changes in customer behaviour:
What other assumptions do we have that, if proven false, will cause our business/ project to fail:
Who is the user?
Where does our product fir in their work or 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?
Give everyone the worksheet and ask them to answer the assumption questions individually about the problem statement
Collect all the assumptions together
Use these assumptions to form hypotheses
Hypothesis Statement Format (1, page 30)
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]
Hypothesis Driven Development (2, page 87)
helps Scrum Teams to frame hypotheses and experiments with thinking about what they are trying to achieve and how they will measure it
helps teams to be mindful of assumptions
We believe [doing this feature] for [these personas] will achieve [this outcome]. We will know that this is true when we see [this measurement] changed.
Value and Growth Hypotheses (3, page 61)
Value hypothesis: tests whether product delivers value to a customer (experiment, not survey)
Growth hypothesis: tests how new customers will discover product/ service (find early adopters – people who need the product the most – they will be eager to feedback)
Experiment Stories (1, page 127)
Hypothesis you’re testing or the thing you’re trying to learn
Tactic(s) for learning (e.g. interviews/ a/b testing)
Who will do the work
A level of effort estimate (e.g. story points)
We believe that asking new users MORE questions during registration will increase complete profiles.
Tactic: landing page test & customer interviews
Assigned to: UX, PDM
Hypothesis Creation Workshop (1, page 32 – 43)
Must have a problem statement before this
Brainstorm small outcomes that will lead to the big outcome(s) in the problem statement (e.g. what behaviours will predict more downloads?)
Vote all together on priority (have a decider in the room if necessary)
Create a personas
Validate these personas
Create user outcome (assumption of what the user is trying to do)
E.g. How does our product or service get the user closer to a life goal or dream?
Brainstorm features to meet these user outcomes
Assemble what you have created in steps 1-4 into the hypothesis table (below)
Fill in the gaps in the table as you find them
Between 7 and 10 rows on the chart is a good starting point
Ensure that the hypothesis you create out of this focuses on 1 feature (multi-feature hypotheses are hard to test)