UX for Lean Startups

Notes for Laura Klein's book: UX for Lean Startups

These are my takes on Laura Klein's book. This is meant to be a quick reference on key concepts but by no means a replacement for the book itself. It's an amazing book for:

1. Designers
2. Software engineers
3. Product managers
4. Anyone wanting to learn how to find their market and cater great products for them.

Go buy Laura's book here --> https://www.amazon.com/UX-Lean-Startups-Experience-Research/dp/1449334911/ref=sr_1_2?ie=UTF8&qid=1520170438&sr=8-2&keywords=ux+for+lean+startups

P.S: I don't get anything if you buy from that link. It's a genuine recommendation

Index

Introduction Part one 1. Early Validation

Introduction

You need to validate things with your customers early and often in order tok eep learning.

Lean UX revolves around the idea of validating hypotheses rather than being the designer's purely creative endeavor. Use user interviews and reaserch to develop a hypothesis about what a customer might want and then test it to see you were right.

The problem of traditional approaches is that the process starts with the feature rather than the hypohesis. As an example, Laura uses a "Wall of comments" that the company wants to build for their product, however, the motivation behind it is shallow: we need to display comments. In a hypothesis based approach, the example turns into "we need to improve revenue and data/research has lead us to believe that allowing users to leave comments on product pages will cause them to become more negaged and buy more items. How can we figure out if that true?"

This approach creates a higher motivation, a bigger objective to tackle which can be achieved in multiple ways by different features.

Lean UX isnt' about adding features to a product. It's about figuring out which metrics drive a business, understanding what customer problems we can solve to improve those metrics, generating ideas for fixing those customer problems, and then validating wether or not we were correct.

Lean UX is Infomed by Data

Lean UX doesn't assume that a new design of feature is better than what came before it. Feature cycles don't end when the feature is relased to production. That just means it's ready to be tested and for its next iteration.

By testing every iteration of a feature's design, we help the designed learn more about real user behavior.

Part One: Validation

The important thing is that you validate your idea --all of your ideas, really -- before you jum pin and start building your product.

Chapter one: Early validation

Key concepts:

1. A market is a group of people you think might want to buy your product.

2. A problem is the reason those people are going to use your product.

3. A product is simply the way that you're going to solve the users's problem.

4. Problem validation is something you do to reduce the uncertainty of an idea. Early validation will help you refine your ideas and learn more about your users.

5. Market validation is narrowing down the specific people who might want a soluiton to the problem you've validated.

6. Validating the product is the most time consuming process.

Does this product really solve the identified problem for the specific market? You'll know you've validated your product when a large percentage of your target market offers to pay you money to solve their problem

Types of user research.

Etnographic studies

(Listening to your users)

Get to know the people for whom you're building a product.

1. Ask open-ended questions about their problems and their lifes. What's their current solution for the problem?
2. Don't ask (or don't get biased by) how a process is done. Ask about the situations that revolve around the process or, better yet, watch the people go through the process. You may find patters, or better yet, you may not find any (which cries for standarization)
3. Learn why they do things a certain way.
4. Learn about their current practices and patterns. You want to build products that fit seamlessly into people's exsisting processses.

How to

1. Find a good market segment

Good and bad segment examples

Segment
Women	Bad
People who process payroll for small businesses	Good!
Drivers	Bad
NASCAR drivers	Good!
Suburban driving grandmothers	Good!

2. Find 5 people who fit in the segment. If you can't easily find them, your segment might be too specific or too hard to reach.
3. Visit them or Skype/Facetime.
4. Ask them to show you the tasks they perform to solve the problem.
5. Ask them why they're doing things in a particular way.
6. Ask them which other things they have tried to solve the problem

*** What to look for ***

1. Get a good overview of their current practices
2. Spot patterns of behavior
3. Is there a specific problem encountered by each of the test participants?
4. Have they all complained about a paticular piece of software? Are they all performing tasks in specific way that could be made easier?

The single greatest mistake you can make at this point is to start off by telling the test subject what you're working on and how great it will be for him. Nothing will bias a session faster than you trying to sell him on your ideas. You're not there to talk. You're there to listen.

Here's the best possible way for you to try to figure out if your idea solves somebody's problem Show them something and observe their reactions.

Prototype testing

Rather than pitching your idea to poeple:

1. Show them a prototype and watch them react to it. It's very easy for people to imagine a solution after your pitch but it will be far off from your product.
2. Make it interactive enough so they can imagine they're using a real product

Even at high fidelity, an interactive prototype still takes far less time to build than an actual product.

Pain driven design

Clients can't predict the future and they're not the source of truth. Using User Centered Design doesn't mean the customer's always right and they have the solution to all of your problems. Making users talk about their problems and pain points can spark creativity in designers to develop better solutions.

Becoming a doctor

Pain driven design is like being a doctor. As a doctor, you don't ask people about their disease. You ask them about:

1. Their habits
2. What hurts
3. When does it hurt
4. Things that the patient about symptoms they may haven't noticed
5. Their likes and disliked
6. Their family and surroundings

That way you can diagnose a disease, develop a course of treatment and follow its evolution.

Chapter two: The right sort of research at the right time

If you don't have time to do user reserach, you'd better make time to fix your product once you've built it wrong, because I guarantee that is what's going to happen. The fact is, you don't have time not to do research.

If you're doing the right sort of research at the righ time, you will end up saving time and money.

Competitor testing

Go test what the competition does. No competition? Weird... but go find the next best thing. They must be screwing something up. Find it and fix it for your product.

How to do it Part 1:

1. Find 4 or 5 users that use your competitors product.
2. Schedule a meeting/skype call.
3. Watch them use their product.

Part 2: Ask them some questions. Here are some examples

1. What do you like about the product?
2. What do you hate about it?
3. What confuses you about it?
4. What do you find particularly annoying about it?
5. What's missing from it?
6. Where did you hear about it?
7. Have you tried anything else like it?
8. Why did you pick this particular product over other options?

Five Second tests

You'd be shocked by how many users have literally no idea who you are, what your product is, or why they should be using it. The horrifying thing is, they often feel this way after they've seen your actual product.

Ask your clients what it is they think you do. This is greatly influcenced by your landing page. It's your first and almost always your only chance to convert a visit into revenue.

The goal of your landing pages is to convert the right kind of visitors into users.

Ask these questions to potential clients or random people at a cafe:

1. What does the user think this product does? (Messaging) What does this product do?
2. Who does the user think the product is for? (Branding) Who is this product for?
3. Can the user figure out how to get the product? (CTA) What would you do if you came to this page on the recommendation of a friend or after clicking an ad?

Always follow up with WHY after each question. Always remember to buy them something in return ;)

Clickable prototype testing

When is this the best choice? When you're creating a confusing, frustrating or complicated interaction. When is it not? When an engineer can built it almost as fast or faster in code. Like a landing page.

There are many gray areas but here are some pointer as to when you should create an interactive prototype:

1. For some reason, it will be difficult to change it in production if you got it wrong --for example, you're shipping software ina box or building a physical product.
2. Your finished product could kill someone or otherwise have a terrible outcome if it's wrong--for example, you're building a medical device or an election ballot.
3. The expected user flow is more complicated than a single click or call-to-action--for example, the user has to move thorugh several states or input various pireces of information, each of which may affect later decisons.
4. You have engineers who will be upset if they have to throw all their work because you designed it wrong--for example, every enegneer I have ever met.

How to do it

1. Make an interavtive prototype. Use HTML & JS, Axure, Adobe XD, Invision. Pick something where you can create and iterate quickly. Use a tool built for the job, NOT POWERPOINT!
2. Decide who to interview and which tasks they should perform.

Things Laura Klein tests

1. Signup flows that have more than one step

2. Purchase flows

3. Searching and browsing experiences

4. Sharing experiences (taking a picture, leaving a comment)

5. File upload and editing

6. Navigation of the entire product

7. PHysical buttons on products that aren't entirely screen based

8. Installation for products that require any kind of setup.

9. Anything else that requires more than one or two steps

10. Make 3 to 5 people navigate and test it. Make them perform the tasks you listed.

Once you've identified a few major problems that users are having while completing the tasks, fix the prototype and do it all again. Keep iterating until users are able to complete most tasks themselves.

Pro tip: If you have multiple versions, ask your test users to complete all tasks in all prototypes but show them in random order.

Guerilla user tests

Cheap | Fast | Actionable. Excelente for finding major usability flows in they key parts of your product. Use it to test new user problems (onboarding, messaging, early conversion)

Load your prototype, actual product or competition's product in a laptop or tablet, go to the nearest coffee shop, offer someone a drink and let them look at it for 10 mins.

1. Give the subject just the data they would know if they arrived there on their own.
2. Give them one task to acomplish.
3. Don't give any context or explain your product.
4. Listen to the questions they pose but don't answer them
5. Ask how they think they did accomplishing the task.
6. Repeat!

By the 4th or 5th iteration, you should have enough data to identify major usability flaws. If there are, iterate the prototype and start over.

One word of caution: You can't actually learn wether people will like your product this way. You can only figure out if people understand your product. But, flankly, that's a pretty important thing to know.

Tips on getting useful user feedback

1. Shut the hell up! Listen! Give people enough time to figure things on their own.
2. Don't give a guided tour. Give as little information as possible. Present a scenario to give some context. I.E. You want to buy new pants and someone told you about this new cool app where you can buy them. What would you do to buy them?
3. After the user has finished, ask questions that spark a discusison. Do not use Yes or No questions. You want to get people talking.
4. Always ask followup questions. "Was it cool?" "yes" "WHAT WAS COOL ABOUT IT?!!" Ding ding ding!
5. Let the user fail.

Chapter Three: Faster user research

Iteration

Patterns start to emerge in usability research after the first few tests. After five, you're really just hearing all the same stuff over and over again.

For most type of researches, you want to find the minimum number of people you can interview before you start to see a pattern --> 5 seems to be the magic number.

For some types of tests, you may need larger numbers. Like (5 second tests)[#five-second-tests] that may need around 10 to 15 people.

The key is to

1. Take data from those few tests
2. Analize it
3. Look for patterns
4. Refine your prototype
5. Rinse and repeat

In usability testing, keep doing this pattern until the user passes all the tests with relative ease and minimal confusion. For landing page tests, iterate until people actually understand what your product does.

Whatever type of research you're doing, keep it small and then iterating will always give you the best return in the least amount of time.

Remote testing

The only types of tests you really need to do in person are the ones where you need to understand the environment where the user will be using your product.

Use gotomeeting.com, skype etc. Be sure to test your platform beforehand to invest your time with the user wisely.

Unmoderated testing

These are great to validate usability issues and find out if a person with no context can use your product but do not give specific insights about your specific market (unless you recruit specific people to do the tests).

Resources: usertesting.com

Surveys

... they're not a replacement for listening to customers talk about their needs or watching people use your product.

... this sort of qualitative research isn't a statistically significant science experiment. It often doesn't have to be. All it has to do is present you with some likely hypotheses you can later test in a more thorough manner.

By using qualitative research to generate your hypotheses and realizing that surveys are only good at validating or invalidating those hypotheses, you can turn surveys into an incredibly powerful tool. Just don't try to use them to come up with new ideas. They're the wrong tool for that.

Excuses people use for not doing research

1. It's a design standard.

   Sometimes people think by using design standards they can skip testing. Wrong! This doesn't mean you have to research every minor change to your site but you should keep an eye on how changes affect user behavior.

2. Company X does it this way... You're not solving the same problems as Google/Apple/Facebook and your customers are very different to theirs. Get inspired by them but test your own ideas.

3. We don't have time or money You'll save time and money if you do research/testing on time. Even if your past your deadline, take time to test.

4. We're new. We'll fix it later. Great. Cut something else but not on UX research and testing. Cut cool looks or dashing features.

Take a few hours to show your ideas to users informally, and you will save your future self many hours of rework.

5. It's my vision, User will just screw it up.

Your goal is to solve a problem by using user feedback. This doesn't mean to sacrifice your vision.

Chapter four: Qualitative research is great...except when it's terrible

The truth is that qualitative research isn't right for every situation (it's what we've been talking about). It's fantastic for learning very specific types of things, and it is completely useless for other things. That's OK. The trick is to use it only in the right cricumstances.

On qualitative research

1. Interviewing
2. Watching humans to understand their behavior
3. It's NOT statistically significant

Examples:

1. Contextual inquiry
2. Usability studies
3. Customer development interviews

On quantitative research

1. Doesn't involve speaking with humans
2. It's about the data in aggregate
3. It should always be statistically significant.

Examples:

1. Funnel analytics
2. A/B testing
3. Cohort analysis

Quantitative research tells you what your problem is. Qualitative research tells you why you have that problem.

An easy choice If you want to change the copy or placement of a single element, use qualitative tests.

A multivariable or flow change You can ship it and do qualitative tests afterwards. It may succeed or fail but you won't know why.

When you're making a large, multivariable change or really rearranging a process flow for something that already exists on your site, you'll want to perform qualitative testing before you ever ship the product.

You'll do an A/B test afterwards, but give the feature the best possible chance to succeed by first making sure you're not building something impossible to use.

Deciding what to build next

... you can learn a huge ammount from both quantitative and qualitative research when you're deciding what to build next.

1. Qualitative approach

• Watch user use your product on a regular basis. Where do they struggle? Where are they dissappointed? Where do they complain?
• Talk to people who have stopped using your product.  - Watch new customers with your product and ask them what they expected from the first 15 minutes using the product. **Use this to fulfill a users's first-time experience's expectations.

What questions does qualitative research answer well?

1. Can your users do X?
2. Does the feature make sense to them?
3. Can the complete a given task successfully?
4. Are they likely to enjoy performing the task?
5. Do they hate the task?
6. Are users excited or not about the feature? (keep your eyes open on their reaction)

Will people buy my product/new feature?

It's a tough question to answer but you can rely on quantitative data for that. Create fake landing pages taunting the feature or fake buttons to meassure intent.

How to choose between qualitative and quantitative tests

Aks yourself whether you want to know WHAT is happening or WHY is it happening. Example questions:

1. Quantitative:

• Traffic
• Revenue
• Clicks

2. Qualitative

• Why are people leaving a funnel at certain stage?
• Why do people leave at a specific page?  - Why don't people click that button you want them to click?

2. Design

P63