UX for lean Startups
### UX for Lean startups, Laura Klein ###
### Notes and extracts ###
### Comments ###
- Very good introduction to UX related concepts.
- I am not entirely convinced that the lean UX is the best approach to develop user-centred HMI. I can see benefits for the consumer electronics software development, but I am not sure how we can extent to other sectors like automotive, aviation, etc.
- The author suggest to avoid complex methodologies with many participants and not to worry about statistical significance. I completely disagree with this over-simplified approach. According to my view, an evidence based product development should use rigorous methodology in order to reduce uncertainty. Since, we are dealing with human participants, and individual variability, we should strengthen our methods and testing. A small sample of participants could be ok for initial iterations when you create a new interface, but we need statistical power to understand any fundamental differences and user preferences.
- User stories and testimonials have their purpose and it is a great way to communicate our message, human brain has a soft spot for stories. However, testimonials must support the data not used as data, that is not always the case.
-Why is it important: When we create user experience interfaces, we have to understand the advantages and disadvantages of different user testing and development methods.
-Reading time: ~10 minutes
Enjoy, share, comment
### Introduction ###
-If you have a question about how your product should work or what feature you should build next, the answer is not in that airless conference room youíre trapped in. Itís not on the whiteboard. Itís not the result of an endless brainstorming session with other people at your company. Even your CEO does not have the answer. Your answer is somewhere in the world outside the building, and your customers can help you find it. You just need to know how to learn from them. This is one of the most important concepts of Lean Startup. You need to validate things with your customers early and often in order to keep learning.
-Instead of thinking of a product as a series of features to be built, Lean UX looks at a product as a set of hypotheses to be validated. In other words, we donít assume that we know what the user wants. We do customer interviews and research in order to develop a hypothesis about what a customer might want, and then we test that hypothesis in various ways to see if we were right. And we keep doing that every time we make a change to the product.
-Agile Design includes cross-functional teams where designers and developers work directly together on a project rather than treating the design department as an external agency. The cross-functional team is critical to Lean UX. By including developers, designers, and product owners in the majority of decisions, it makes the entire design process faster and easier to change when things arenít going well.
-Like Agile, Lean focuses on working quickly and in short cycles in order to reduce the amount of time until the team gets feedback on the product.
-Instead of building before you validate, imagine that you start with a few lightweight experiments to test your product hypothesis, realise that itís absolutely wrong and that nobody will pay for it, and keep iterating and pivoting until you find something that people are interested in buying.
-A huge part of Lean UX involves something called the Minimum Viable Product (MVP) ÖThe short version of the MVP definition is that youíre going to build the smallest possible thing you can in order to conclusively validate or invalidate a hypothesis.
-With Lean UX, you need to constantly be improving your product, not just by adding new features, but also by improving the experience of the features you have already built and killing underperforming features.
### Chapter 1 ###
-Products donít spring fully formed from your brain. Before your product, you have an idea. Sometimes itís a great idea. More often, itís a terrible idea. The important thing is that you validate your ideaóall of your ideas, reallyóbefore you jump in and start building your product.
-Most startups begin with an idea for a fabulous new product. Most startups also fail. These two things may be more connected than you think. The problem is that the vast majority of startup ideas are based on things that somebody thought sounded cool or interesting, rather than something that solves a real problem for real people. This is why companies need to spend time validating their key hypotheses as early as possible.
-Letís imagine that, instead of spending time brainstorming brilliant ideas of products that nobodyís ever thought of, youíre going to go about finding a product idea in a totally different way. You are going to discover a problem that exists within your target market that you are capable of solving.
-If you agree with Eric Riesóthat ìa startup is a human institution designed to deliver a new product or service under conditions of extreme uncertaintyîóthen think of early problem validation as something you do to reduce that uncertainty.
-The most effective way to better understand the problems of your potential users is to go out and observe a few of them in person. Ö you do have to spend some time getting to know the people for whom you are building a product. This is your chance to ask open-ended questions about their problems and their lives. Itís an opportunity to observe their behaviours and to learn what sorts of solutions theyíre currently using to solve their problem.
-The most important thing is that whatever youíre showing people has to be interactive enough that people can imagine theyíre using a real product. People have to be able to poke around the prototype by themselves and learn about what it might do for them without any interference from you. They have to be able to discover features and understand what the product is offering without you constantly chiming in and telling them what should be happening. The more you have to explain or describe what happens, the more youíre going to bias the experiment.
### Chapter 2 ###
-A clickable prototype can be as simple as hooking up a few wireframes together so that when users click on a button they move to another static mockup. It can be as complicated as building a whole user interface that behaves almost identically to what a user would see in a real product but doesnít do anything on the backend. The closer you can get to the end prod- uct, the better the feedback youíll get.
-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 without crying.
-This is the single most important lesson to learn when interviewing people about anything. You are interviewing them. You are not talking. You are listening. You want their opinions, not your own. To get those, you have to shut the hell up and let them give you their opinions without becoming hostile or defensive or explanatory.
### Chapter 3 ###
-for maximum efficiency in any type of user research, you want to find the minimum number of people you can interview before you start to see a pattern. Then you want to interview that many people over and over, leaving plenty of time between sets to make changes to your product, mockup, prototype, discussion guide, or whatever else youíre testing.
-Just make sure when youíre testing a prototype that itís accessible to the other user, either through the screen-share or on a server somewhere. You need to have a setup that allows the test participant to manipulate the prototype. This isnít a demo; itís a test.
- Once youíve determined your question, recruit around five of the right sort of person to answer that question. If itís a question about power users, recruit power users. If itís a question about your productís first-time user experience, recruit people who are in your persona group but who have never seen your product before.
### Chapter 5 ###
-For example, you need to figure out your user base: What sort of people are using your product? How familiar with technology are they? Are you mainly trying to help new users or existing users? Are they paying you or using your product for free?
-A lot of times when we think of stories, we think of the very specific Agile engineering stories that we write and track. These are not the sort of stories youíre going to write. You need to write down design stories. Think of these as a way to break down your problem into manageable steps. Also, think of these as a way to evaluate the design once itís finished.
-When I say interactive prototypes, I donít mean something created in PowerPoint that somebody could kind of click through. I mean a full-scale, working prototype that allows users to explore and feel like theyíre accomplishing tasks.
-Build things, prototype things, and get things in front of users as quickly as possible to find out what they like and what they hate and what they find horribly confusing. Then fix the problems and add things you think theyíll like and keep doing that until youíve got a feature that people are excited about.
### Chapter 6 ###
-Whether youíre a trained designer or somebody who just needs to know enough design to get your product in front of users, youíre going to have to stop thinking about design primarily as a way to make things beautiful or cool or interesting. Your goal for this type of design is to make things easy, obvious, and useful.
-When you donít have enough resources, prioritisation becomes even more important. You donít have the luxury to execute every single great idea you have. You need to pick and choose, and the life of your company depends on choosing wisely.
-Visual design can be incredibly important, but 9 times out of 10, itís a cup holder. Obviously colors, fonts, and layout can affect things like conversion, but itís typically an optimization of conversion rather than a conversion driver.
### Chapter 7 ###
-Inconsistency also makes your product feel less finished and professional, which can be a serious problem for companies who are hoping that people will give them money.
### Chapter 8 ###
-Use a flow diagram or a site map when youíre trying to figure out how users will move around your product and complete common tasks. It can also be extremely helpful for estimating how much time something will take to build and for communicating the design to engineers.
-Paper prototypes, because of their complete lack of interactivity, are totally unsuited to allowing users to explore a product.
### Chapter 9 ###
-The idea behind a Minimum Viable Product is that, instead of taking months and months building a huge product with dozens of features and all sorts of bells and whistles before finally launching a giant thing that nobody wants, maybe it would be a better idea to launch something smaller and start learning earlier.
### Chapter 10 ###
- Ö visual design doesnít just make things pretty. Itís instrumental in a lot of ways, including the following: Enhancing your information design Reinforcing desired user actions Setting the tone for your product.
-It is much faster for me to iterate on something if I donít have to worry about making it pixel perfect. When I get feedback from a user test or a beta customer, simple grayscale wireframes can be changed quickly and without too much regard for things like margins and font sizes, while fully designed visual mockups can take much longer to fix.
-Many people think that the right answer is to have a grand vision of everything that will eventually go on the page, but things change far too rapidly for this. Imagine that youíve carefully designed a tabbed interface with just enough room for four tabs. Now imagine that you need to add a fifth tab. I hope you didnít spend too many hours getting all that spacing exactly right.
-How about spending time on the basics that wonít have to change every time you add a feature? For example, you could establish standards for things like the following: An attractive colour palette Font sizes and colour standards for headers, subheaders, and body text Column sizes in grid layouts A simple and appealing icon set Standards for things like boxes, gradients, backgrounds, and separators A flexible header and footer design.
-Make a visual standards guide: Try going through your product and listing things like fonts, colours, and button treatments that youíre currently using. Now put this list where everybody who codes can easily access it and ask them to try to reuse visual styles whenever possible.
-Prioritise function over form: The next time you find yourself tempted to make something more difficult to use just because it looks better, try stopping and thinking about what thatís really going to do to your key metrics. Will you lose customers because of it? Will you lose money? Is it really worth it?