4 problems with Lean UX that are often overlooked
Build Test Iterate
The Build, Test, Iterate (or Build, Measure, Learn) methodology encourages you to develop digital products in lean cycles. It’s a continual process which should happen throughout every stage of project, from the start, to the launch of the product, continuing through to improvements after the product is launched.
While this framework can be applied to a range of disciplines and industries, it is super useful in digital product development and specifically User Experience (UX) design. I’ve personally used the model throughout my career, and there are definite pitfalls to this methodology when not executed effectively (i.e. when the concerns of the user take a backseat from the outset).
In this article we take a closer look where the BTI methodology often falls over, and how we address these critical aspects here at Mudbath.
While UX designers will no doubt relate to many of the concepts below, if you’re working in digital or product design team read on… there are takeaways here that Engineers, Developers, Project Managers and Account Managers will all hopefully benefit from.
A Recap on the methodology
Already across it? Skip to the problem
Means to create something that solves the problem that you’re trying to solve. This happens at every stage of the design process, sketching, prototyping and visual design through to the build.
Test / Measure
Success or fail, testing is about making sure something works. How do you measure if design works? Is it understandable is it east to easy is it engaging and fun. There’s a distinct difference between feedback and testing. Feedback is the act of getting opinions on a concept. Testing is putting the user tasks to the test and ensuring that we’ve solved the problem. Both are important but only testing will reveal evidence about how successful the design is.
This testing can happen in many ways, each have different benefits depending on the level of testing required and the complexity.
- Casual testing - test someone in the office, a family member or anyone for quick validation.
- Online testing - Use a platform like optimal workshop or askable and recruit multiple people to complete the testing for a fee.
- Formal lab based testing (mudbath have a user testing lab and an observation room so clients and the project team can observe the testing results.)
What makes an effective formal user test:
- Users (5-8)
- Tasks (E.g. pay your bill, buy a phone, update your details)
- Something built (A sketch, prototype, design, code, live website)
- A facilitator - to ask questions and set the tasks
- An observer to record notes
How to record the test results
A good method to use is the ORID method to record the results and to address them in these areas.
- Objective - What did the user do, what did you see, what did they say?
- Reflective - How did this affect the user?
- Interpretative - What was the significance or the implication of this happening?, E.g. Did it mean they missed a crucial element?
- Decisional - How are we going improve or fix this problem from occurring again.
Tip: When recording observations you can use post-it notes to quickly write down what happened, where it happened and which user it was. Keeping it on post it notes allows you to group the common observations together when testing multiple participants.
Iterate / Learn
Iterating means let’s improve what we have built based on the evidence and insights we have collected through testing, research or feedback.
Sometimes iterating means scrapping an idea that we’ve tried and moving in a new direction, other times it’s simple changes to improve clarity and usability. What’s key is that these changes are based on user testing.
- Too many assumptions - around who the users really are and what they want and need
- Lack of empathy - making no effort to understand who the user is e.g. thinking people will be alright, not addressing accessibility and prioritising it.
- Laziness - putting research in the “too hard basket” and not conducting the research required to drive out assumptions
- Continuity - failing to keep the user at the centre of the project.
These are common problems that need to be addressed in all projects before moving into the build phase and as UX designers it’s our responsibility to tackle this head on from the start.
So how do we fix these problems, what’s the missing step in this methodology?
We have to know who the people are who will use your products. You must know. Assumptions aren’t real people. We must know who our users are so we don’t build things that aren’t important to them. This wastes time, adds confusion to any product and keeps you away from any competitive advantage.
- Talk to the people who will be using your product, find out how they think, how they decide and what are the things that they need to understand.
- If you don’t know who they are then run online surveys, look at your data, talk to the people who talk to users and really understand them, have them point you in the right direction.
- Develop personas to capture this information to ensure we keep personas throughout the process.
Tip: This doesn’t have to be a huge involved process it can happen in minutes, hours or days and it should be a continual cycle throughout the product.
So when you’re starting a project, halfway through or at the end, research! Go and talk to the people who will be using your product, drive out the assumptions, know who the people you are designing for are and keep them with you throughout the project. This is hard, but it’s one of the most important steps to building a successful and useful product.
If you are looking to build a great product based on user research and testing, contact us today.