Category: Product

Posted in Product

Personas

Posted on by beckycarter

What is a Persona?

Mike Cohn Definition (3, page 38)

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)

  • Name
  • Representative photograph
  • Quote that conveys what they most care about
  • Job title
  • Demographics
  • Needs/goals
  • 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

Creating Personas

Proto-personas (2)

  • 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?
    • Would they value a solution to this problem?

See Persona Creating Workshop

References

  1. Lean Product Playbook by Dan Olsen
  2. Lean UX by Jeff Gothelf
  3. User Stories Applied by Mike Cohn

Explore more


User Testing
User Interview
User Stories
Posted in Product

Product Kata

Posted on by beckycarter

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

Slide1

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

Overview

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
company

Example: To double revenue growth

Product

Example: To increase course content

2) Analyse the Current State

overview
  • Where do you stand in relation to your vision?
  • Reflect the current state of outcomes
  • Collect a baseline for your Product Metrics
company

Example: Current revenue growth is 15% Year on Year (YoY)

product

Example: Publish course rate is 25% and second course is 10%

3) Set the Next Goal

overview

Name outcomes that you need to achieve to make progress toward the direction. They can be learning outcomes.

company

Example: Retain existing users

product

Example: Learn what the problems are with users creating the courses

4) Experiment Toward the Target Condition

Experiment with the following techniques to systematically reach the goal:

Problem exploration
  • Understand the problem; what are we trying to solve?
  • Validating the problem
  • See more in User Interviews
Solution exploration
Solution optimization

References

  1. Escaping the Build Trap by Melissa Perri

Explore more


Metrics
Which direction
Prioritising
Posted in Product

Design Studio Workshop

Posted on by beckycarter

What

This workshop is a team activity to design the UX for a product/ feature with any team members regardless of design expertise.

Who

  • 5 – 8 people recommended 
  • Larger than 8 could be wise to run parallel sessions

Supplies

  • Pens 
  • Pencils
  • Felt-tip markers or similar
  • Highlighters (multiple colours) 
  • Sketching templates (can be blank sheets of A3 divided into 6 segments) 
  • A1 self-stick easel pads
  • Dot stickers 

Process

  1. Problem definition and constraints 
    • Ensure everyone is aware of the problem you are trying to solve
    • Everyone understands the assumptions 
    • Everyone knows the users you are serving
    • The hypotheses you’ve generated
    • Constraints in which you are working
  2. Individual idea generation (diverge) 
    • Give each person a sketching template
    • If people find prospect of a blank page daunting optionally add a step whereby everyone writes the name of a persona/ pain point in each one (can repeat) and spend 5 minutes doing this
    • Give everyone 5 minutes to generate 6 low-fidelity sketches of solutions
    • These should be visual articulations, not words
    • If you can draw a square, a circle, and a triangle you can draw any low-fidelity diagram
  3. Presentation and critique 
    • 3 minutes per person
    • Go around the table
    • Each person holds up their sketches and presents them to the team
    • Presenters should state who they were solving a problem for and which pain point they were addressing and then explain the sketch
    • Each member of the team should provide critique and feedback to the presenter
    • Feedback should be focused on clarifying the presenter’s intention – no opinions allowed as they get people defensive and provide little clarity
      • How does this address the persona’s problem?
      • I don’t understand that part. Can you elaborate?
  4. Iterate and refine in pairs (emerge) 
    • 10 minutes
    • Each pair has an A3 sheet
    • Pair up (it is a good idea to pair up with someone with similar ideas if there is someone)
    • Each pair will be working to refine their ideas
    • Goal is to pick ideas that have the most merit and develop a more evolved, more integrated version of those ideas
    • Get more specific here, more details
    • Once time is up do the Present and Critique section again
  5. Team idea generation (converge) 
    • 45 minutes 
    • The team must converge on one idea 
    • The goal for this idea is to be the best for success an to be the basis for forming an MVP and running experiments
    • Use the easel pads or a whiteboard for the idea
    • Sketch components and workflow
    • Will need to compromise and pare back features 
      • Any ideas that don’t make the cut this time go into a parking lot to make it easier to let go of ideas
    • Put the output of this in a visible central place 

References

  1. Lean UX by Jeff Gothelf, pg 52 – 57

UX
Personas
User Interviews
Posted in Product

User Interviews

Posted on by beckycarter

Who to Interview

How many customers should I test with? (2, page 144)

  • Focus groups lead to participants not being fully honest 
  • Interview between 5 and 8 is a good balance

How to recruit in target market? (2, page 148)

  • Refer to personas created to help with writing screener questions 
  • Ensure to cover all of the segmentations you used forming your target market
  • Use conferences/ networking events

Starbucks User Testing (2, page 151) 

  • Low cost and immediate
  • Harder to screen for the customers that you actually want (demographic)
  • “Hi sir, do you have 10 minutes to share your feed back on a new website in exchange for a £20 Starbucks card?
  • More success found in shopping centres than Starbucks as people tend to have more time to kill

How to Interview

In-person, remote, and unmoderated user testing (2, page 145)

  • Moderated tests have the customer perform the test on their own, but recorded for the moderator to view afterwards
  • In-person allows richer data collection (body language)
  • Remote – be aware of technology issues of screen sharing 
  • Unmoderated can product a quick turn around as providers already have users lined up ready 

Question Guidance

Open vs Closed Questions (2, page 158)

  • Open usually begin with why, how and what 
  • Closed questions limit the customer’s possible responses (e.g. to yes or no)
  • Tip to write the questions down in advance to check they are open

Non-leading Questions (2, page 158 – 160)

  • Be careful not to tell the user how you would like them to respond, e.g. ‘how would you prefer it to be sorted? By date?’  
  • Be ok with long pauses and don’t help them as it will invalidate the test. Real users won’t have you to help them.
  • Don’t predict what the customer will say out loud and try to recede into the background to get the most honest feedback

Measuring Importance and Satisfaction (2, page 59)

  • A bipolar scale goes from negative to positive (i.e. satisfaction)
  • A unipolar scale is a matter of degree (i.e. importance)
  • More than 10 choices is overwhelming
  • Fewer that 5 will lack granularity
Unipolar Example
  1. Not at all important 
  2. Slightly important 
  3. Moderately important 
  4. Very important 
  5. Extremely important 

Bipolar example 
  1. Completely dissatisfied 
  2. Mostly dissatisfied 
  3. Somewhat dissatisfied 
  4. Neither satisfied nor dissatisfied
  5. Somewhat satisfied 
  6. Mostly satisfied
  7. Completely satisfied

Product Market Fit Question (Sean Ellis) (2, page 231)

  • Do not invest in trying to grow a business until after you have achieved product-market fit
  • This questions helps you assess if you have achieved product-market fit
  • Survey users and ask:
    • “How would you feel if you could no longer use product X?
      • Very disappointed
      • Somewhat disappointed 
      • Not disappointed (it isn’t really that useful)
      • N/A – I no longer user (product X)”

Follow-up Questions (2, page 157)

  • ‘Echoing back’ is a useful technique – e.g. ‘I see you clicked that button. Could you tell me why?’
  • If user asks question, ask another question rather than replying with yes or no

The Data

Make sense of the data (1, page 103) 

  • Look for patterns 
  • Place outliers in a parking lot (outliers could form their own pattern with more data collection so don’t bin them) 
  • Verify with other sources (do people inside the office agree/ customer support staff seeing the same trend) If not your sources could have been skewed 

Feedback Table (2, page 162)

Feedback Structure (2, page 162)
  • Group into feature set, UX design, and messaging
  • Ask valuable and easy to use questions
  • Get overall scores to compare to next wave when improvements have been made

Regular Cadence

TIP – randomly schedule users on a routine basis so that you always have some ready to test with, rather than panicking (2, page 150)

Continuous Learning in the Lab: Three, Twelve, One (1, page 99)

  • Three users, by Twelve noon, once a week
  • The regular cadence ensures that you ‘test what you’ve got’ so that there is no deadline pressure
MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAY
Start with the recruiting process
Decide what will be tested		Refine what will be testedRefine what will be tested
Write the test script
Finalise recruiting		Testing day
Review findings with the entire team		Plan the next steps based on findings
Three, Twelve, One Sequence (1, page 99)

References

  1. Lean UX by Jeff Gothelf
  2. Lean Product Playbook by Dan Olsen

Explore more


Personas
User Testing
User Stories
Posted in Product

UX

Posted on by beckycarter

UX Principles

Two Elements of UX Design (1, page 115)

  • Great UX design = Usability + delight
  • Usability = can customers use your product?
  • Delight = do customers enjoy using your product?

Olsen’s Law of Usability (1, page 113) 

'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 Components

UX Design Iceberg (1, page 116)

UX Design Iceberg (1, pg 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)
  • Mockups used to test this 

References

  1. Lean Product Playbook by Dan Olsen

Explore more


Personas
User Testing
User Interviews
Posted in Product

Business Value/ Vision

Posted on by beckycarter

Business Value Levels

Strategy Deployment Levels (1, page 75)

VisionWhat do we want to be in 5-10 years? Value for customers, position in market, what our business looks likeCEO/ Leadership
Strategic IntentWhat business challenges are standing in the way of reaching our visionSenior leadership
Business leads
Product InitiativeWhat problems can we address to tackle the challenge from a product perspective?Product leadership team
OptionsWhat 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?

Vision

‘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

Product Vision Venn Diagram

Balance multiple product attributes (6, page 172)

References

  1. Escaping the Build Trap by Melissa Perri
  2. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  3. What is This Thing Called ‘Value’? by Christiaan Verwijs (blog post)
  4. Fixing Your Scrum by Ryan Ripley and Todd Miller
  5. Product Box by Innovation Games
  6. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Explore more


Which direction?
Prioritising
Hypotheses
Posted in Product

Value Statements

Posted on by beckycarter

Communication Forms

Microdefinition (1)

  • Microdefinition = next critical business objective on the way to creating the whole product.
  • Everything must be checked against this

North Star Document (2, page 136)

  • Explains the product in a way that can be visualised by the whole team and company
  • Problem it is solving
  • Proposed solution
  • Solution factors that matter for success
  • Outcomes the product will result in
  • Should evolve over time

References

  1. Coaching Agile Teams by Lyssa Adkins
  2. Escaping the Build Trap by Melissa Perri

Explore more


Which direction?
Personas
Hypotheses
Posted in Product

Minimum Viable Product (MVP)

Posted on by beckycarter

MVP Definition

MVP Tests (2, page 89)

  • MVP tests are everything that tests the hypothesis
  • MVP is reserved for the actual product

MVP Prerequisites

Steps to take before building an MVP (2, page 87)

  1. Formed hypotheses about your target customers
  2. Formed hypotheses about their underserved needs
  3. Articulated the value proposition you plan to pursue so that your product is better and different 
  4. Identified the top feature ideas you believe will address those needs and broken them down into smaller chunks
  5. Prioritised those feature chunks based on ROI 
  6. Selected a set of those feature chunks for your MVP candidate, which you hypothesize customers will find valuable

MVP Guidance

MVP Questions (1, page 77)

  • Most important question is ‘What’s the most important thing we need to learn next about this hypothesis?’
  • Next question is ‘what is the least amount of work we can do to learn that?’

MVP Functionality (2, page 89)

An MVP should address all of the needs from Olsen’s hierarchy – it should not be just functional – it should be usable and delight the user 

References

  1. Lean UX by Jeff Gothelf
  2. Lean Product Playbook by Dan Olsen

Explore more


Refinement
User Stories
User Testing
Posted in Product

Prioritising Problems

Posted on by beckycarter

Guidance on Prioritising Problems

By Risk (1, page 45)

  • Highest risk: value ratio gets top priority
  • Work on the riskiest ones first
  • Keep all on a the backlog 

Prioritisation Techniques

Importance vs Satisfaction Framework (2, page 47)

This technique is used for evaluating potential product opportunities

Importance vs Satisfaction (2, page 47)
  • Competitive example is Excel. High important to users and it is the leading example. So product in this space to compete needs to be something like the online sheet tools for collaboration
  • Opportunity example is Uber where user satisfaction was low with taxi service but their need for a solution is very important to them
Measuring Customer Value
  • When importance and satisfaction are both percentages:
Customer value delivered = importance x satisfaction

Opportunity to add value = importance x (1-satisfaction)
Customer Value Example
  • For orange it is:
    • Customer value delivered: 0.9 x (0.35-0.2) = 0.135 
  • For blue it is:
    • Customer value delivered: 0.6 x (0.9-0.6) = 0.18 
  • So blue created marginally more value than orange. 

The Kano Model (2, page 64)

  • Performance needs – adding more will increase satisfaction. For example fuel efficiency on a car. Increasing this will always increase satisfaction.
  • Must-Have needs – they never increase satisfaction. They only decrease it if they are missing 
  • Delighter needs – the customer is not dissatisfied at all if they are missing as they are unexpected and result in very high satisfaction if they are included
Using the kano model to compare with competitors
FeatureCompetitor ACompetitor BYour Product
Must Have Feature 1Yes/ NoYes/ NoYes/ No
Must Have Feature 2Yes/ NoYes/ NoYes/ No
Must Have Feature 3Yes/ NoYes/ NoYes/ No
Performance Feature 1High/ Med/ LowHigh/ Med/ LowHigh/ Med/ Low
Performance Feature 2High/ Med/ LowHigh/ Med/ LowHigh/ Med/ Low
Performance Feature 3High/ Med/ LowHigh/ Med/ LowHigh/ Med/ Low
Delighter Feature 1Yes/ NoYes/ NoYes/ No
Delighter Feature 2Yes/ NoYes/ NoYes/ No
Kano Table

Return on Investment

Approximating ROI (2, pg 84)

References

  1. Lean UX by Jeff Gothelf
  2. Lean Product Playbook by Dan Olsen

Explore more


Which direction?
Metrics
Hypotheses
Posted in Product

Value Proposition/ Hypothesis

Posted on by beckycarter

Assumptions

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)

  • Business outcomes
  • Users
  • User outcomes 
  • Features 

Assumptions Workshop (1, page 24-25)

Who

Whole Team

Preparation

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 
WOrksheet Questions

Business Assumptions

  1. I believe my customers have a need to: 
  2. These needs can be solved with: 
  3. My initial customers are (or will be):
  4. The #1 value a customer wants to get our of my service is:
  5. They can also get these additional benefits:
  6. I will acquire the majority of my customers through:
  7. I will make money by:
  8. My primary competition in the market will be:
  9. We will beat them due to:
  10. My biggest product risk is:
  11. We will solve this through:
  12. We will know we are successful when we see the following changes in customer behaviour:
  13. What other assumptions do we have that, if proven false, will cause our business/ project to fail:

User Assumptions

  1. Who is the user?
  2. Where does our product fir in their work or life?
  3. What problems does our product solve?
  4. When and how is our product used?
  5. What features are important?
  6. How should our product look and behave?
Process
  1. Give everyone the worksheet and ask them to answer the assumption questions individually about the problem statement
  2. Collect all the assumptions together
  3. Use these assumptions to form hypotheses

Hypotheses Creation

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)

Contains
  • 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) 
Example
We believe that asking new users MORE questions during registration will increase complete profiles. 
Tactic: landing page test & customer interviews 
Assigned to: UX, PDM
2pts

Hypothesis Creation Workshop (1, page 32 – 43)

WHO

Whole Team

preparation

Must have a problem statement before this

process
  1. 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) 
  2. Create a personas
    • Validate these personas
  3. 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?
  4. Brainstorm features to meet these user outcomes
  5. 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)
We will achieve…if this user……can achieve……with this feature
[business outcome][persona][user outcome][feature]

References

  1. Lean UX by Jeff Gothelf
  2. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  3. The Lean Startup by Eric Ries

Explore more


Which direction?
Prioritising
Metrics