Summary of UX for lean startups

March 27th, 2018

What is Lean UX

It's all about validating what we think
We shouldn't ever assume we know what users want
Instead we do interviews and research to create hypothesis about and then test it
It isn't about always adding features to a product
It's about working out where the value is, what metrics drive a business and what problems we can solve to improve those metrics and then check that we actually were right
Lean UX is all about constant improvement, that includes features already built and trimming down weak features

Validation

You have markets, problems and products
Markets are the group you think will want to buy your product
Problems are the reason people are going to buy your product
Product is the way you'll solve the problem
You need to check that a problem actually exists in your target market
Sometimes a problem exists but isn't that much of a problem to bother solving
When you validate you much niche down to be as specific as possible. (See crossing the chasm)
If you really focus down you're more likely to find a group of similar people with a similar small problem you can solve
It's also far more likely this specific group will talk to each other about how they solve their problem
Be specific about who your target market is before speaking to people about whether your product solves their problem
One simple way to validate is landing page tests. Market what the product is and share it to gauge how many sign up. You'll need to drive some traffic there with ads
Once you've validated you can start to show prototypes, clickable ideally, of what the product is and see their reaction
Pain driven design PDD - basically before you design feature or product, figure out what is causing pain for your potential users
This applies to both current and potential new products. e.g Watch new people on your product to figure out the pain

Research

There is no excuse for not doing research. You don't have the time not to do research!
Some options include, competitor testing. Find users already using competitors and ask them questions (Likes, hates, confusion, annoying, missing, how easy to learn, where from, why this product over others
Five-second tests - Show a screen and ask what do you think the product does, what is the product for, test your messaging, branding clarity of offering
Five-second tests help highlight the fact that everyone internally knows what you do but externally it's probably not so clear!
Prototype testing - basically whenever you're building an interaction that could be frustating or difficult for the user and you could get easily get it wrong then you need to prototype
Some tools include axure and marvelapp (clickable screenshots)
When interviewing users, use open ended questions, shut up and ask follow-up questions. Why, why, why, that's interesting why is that!
Don't explain and don't help users when you're testing. Let them struggle, that's the whole point so you can feel their pain

Faster user research

To start with you don't need to do more than 5 usability tests before you'll start seeing common patterns and hearing the same stuff
Generally you'll find a few major issues that you'll need to solve first before you do anymore tests
Then you can uncover all the other things that need fixing that were blocked by these major problems
Couple of tools to make this easy are usertesting.com, loop11 and TryMyUI. You can also watch users with tools like hotjar.com
Ideally get the whole team to watch these videos and feel the pain
Avoid long surveys if possible. People hate writing. But they are great for following up on patterns you've spotted and confiring your aassumptions
There really isn't any excuse not to do user research.
Whilst you might not have to do a full blown usability test for every feature you introduce, you do want to have a clear view of your key metrics and testing how your design/changes impacts those metrics
Quantitative research tells you what your problem is
Qualitative research tells you why you have that problem.
Examples of quantitative research include funnels, a/b testing and cohort analysis

Quantitative approaches

Talk to people who have stopped using your product
Watch new customers use your product. Ask them about their first impressions
Look at most used features
Test fake changes by adding a link to a feature that isn't ready just yet. See how many people click it

Design

Truly understand the problem! Most of the time people talk about solutions rather than problems. e.g I want to add x
Should be constantly thinking about what it is users want to do rather than what feature you want to add. e.g
To understand the problem talk to users, talk to stake holders, talk to the sales guys and talk to the support agents
Decide how you'll measure a design before you design it. Have to do this so that you know if the changes you've made have actually improved things
a/b testing is always a good way to test design changes
Write some design stories to help identify with what problems you're trying to solve
Talk to the team about possible solutions. If you know the problem then getting input helps come up with lots of different solutions
If you're doing a brainstorming session on features, it's good to group them up by the metric they will impact. e.g Increase engagement, low hanging fruit, improve revenue, help users connect
Making a decision is hard. Sometimes you have to use some simple 2x2 with things like Expected return & expected cost to see how different features stack up against each other
Don't start sketching as your first step, you should do the things mentioned above first.
Sketching is a great way to come up with ideas but you end up getting caught up in the details early on
The most important thing is that sketching is super fast and you can use tools like balsamiq and omnigraffle
If an engineer can buid and release a feature quicker than building the prototype then generally you can skip building a prototype
Testing and iterating - Get things in front of users as early as possible to find out what they like and dislike then iterate and show them again
Learn what users really want as they often ask for things they are familiar with and have seen on other sites rather than things they genuinely need

Just enough design

Wizard of oz feature.
Instead of building everything a user might need dynamically, there might be times that you can offer some kind of concierge service which means you offer the service but do it manually. An example might be an integration a user wants with another platform. You could offer it by saying your tech team will work with their tech team to set it up manually for now.
Wizard of oz concept is great for complicated features you're not sure if you'll build
Focus on only solving important problems. Find something you would like to fix and ask yourself who is it affecting, how often does it happen and which metric is it damaging
Your design solution has to solve the problem and be the best solution that takes the least amount of time. (i.e doesn't have to be the perfect solution)

Diagrams, sketches, wireframes and prototypes

Flow diagrams are great for visualising how users will move through your product
Not something you would normally share with users so don't waste time making them look good
Sketching is a great way to communicate your design with other people
Just start by throwing things together, don't judge too much. More sketching means better sketches!
Sketches vs wireframes - wireframes are essentially somewhere between a sketch and prototype
Wireframes usually include all the important aspects such as navigation, copy, buttons but doesn't have visual design
Real content is very important for wireframes

Prototypes

Create an interactive prototype to figure out all the things that are wrong with your design before spending a lot of time and resources building the real thing
Changing designs is cheap compared to changing code
Anytime you're creating something that can't easily be fixed after releasing, interactive prototypes are crucial
Don't worry about making them pretty. If you do this, you end up making compromises to suit the design before you've full thought about the UX
Paper prototypes should only be used in certain scenarios. People interact with paper very differently than they do screens
People have a very different mindset when they see paper
Paper prototyping is more acceptable for mobile designs because it's closer to something you interact directly with your hands (rather than a mouse and keyboard)

MVPs

Idea behind MVP is to launch something smaller and faster that solves a specific problem rather than trying to solve everything and taking months to do so
Think about it as a fairy cake vs a wedding cake
Once people start trying out your MVP they are going to give you feedback and requests. Don't act on these requests yet even in the early days. You need to do some research to see how many people are actually asking for it and why
Again at this stage, observe users, listen to them and see how they respond to new features/functionality
What impact are new features having on your metrics? Are people using the new features etc
Important difference between "limited products and crappy products".
Limited product is a product that might not do much but does what it does well
Crappy products try to do too many things without doing any of them very well
Basically don't try to cram in lots of features and spread your resources. Better off starting small and doing specific tings really well

Visual diesgn

Visual design is how something looks. Interaction design is how it works
Visual design can be an essential part of the UX but you shouldn't do it first.
Form follows function for a reason
Often it's good to ignore visual design to do things faster and ensure people don't get bogged down in the design when they should be focussing on the interaction
If you can get the interactions correct first, in an agile environment it means that you can start to share it with the developers whilst the visual design is worked on in parrallel
Don't let visual design impact interactive negative. i.e sometimes a button needs to go in a certain place even if it looks better somewhere else
Your visual design should reflect your target market rather than your own desires. You are not your users
Try having a conversation with users about other products they really like and why

Measuring design

A/B testing. You always need a control test so you know what would happen if you didn't make the change
A/B testing is great for getting statistically significant data. e.g does this new change significantly increase metrics
NPS is a great way to measure how happy users are with your product.Try setting one up with current users and track over several weeks
Engagement is an interesting metric to study as you can see how often users are returning to your product

Go faster

Cross-functional team. Possibly the mot important thing is that the whole team is involved in monitoring and responding to user behaviour.
Sharing metrics with the entire team helps everyone become more flexible and able to respond to changes in strategy
Avoid enginerring where possible simply because this is when it becomes expensive and time consuming
Just ship! Sometimes you just have to ship and stop worrying that you'll suddenly lose all your customers or some other bad thing
If you've prototyped, putting it in front of users and learned from it then that's the most important thing. You have to show something to real users in order to improve things
Opt in method of when you release new features. Give users to option to see new features but don't force them to use them

By Jonathan Clift, a UX Desginer based in the UK.