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


  • 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


  • 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, loop11 and TryMyUI. You can also watch users with tools like
  • 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


  • 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


  • 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)


  • 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.