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, whether you're looking at building your first app, or you're a seasoned tech veteran.
A Recap on the methodology
Build
Means to create something that solves the problem that you’re trying to solve (for more information on how to make sure you're doing this correctly, read these articles on defining true problems and releasing the website you need, not the website you want).
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. You're looking for answers to the following questions:
Is it understandable?
Is the information easy to navigate?
Is it engaging and fun?
There’s a distinct difference between feedback and testing. Feedback is the act of getting opinions on a concept whereas Testing is putting the user tasks to the test and ensuring that we’ve solved the problem.
Both are important, but only testing will produce measurable evidence about how successful the design is.
This testing can happen in three main ways. Each has a different set of benefits, which vary depending on the level of testing required and the complexity of the product.
- 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 - For Example, here at Mudbath, we have a User Testing Lab and an Observation Room so our clients and the project team can observe and record the User Tests.
What makes an effective formal user test?
- The right number of Users (5-8),
- Testing the right Tasks (E.g. 'pay your bill', 'buy a phone', 'update your details'),
- A testable product or prototype, designs, or rough sketch,
- 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:
- 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 to 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 to improve what you have built, based primarily on the evidence and insights you have collected through testing, research or feedback.
Sometimes iterating means completely scrapping an idea that has been unsuccessfully tested, and moving in a closely-related or brand new direction. Alternatively, iterating can mean simple changes to improve clarity and usability.
What’s key is that these changes are based on user testing. And here is where we get into the meat of the article.
The Four Most-Commonly Overlooked Problems In Lean UX
After conducting countless Lean UX workshops in my career, if seen the following issues arise in almost every project. They originate in very driven, single-minded Founders or internal visionaries who (sometimes rightfully) believe they know everything there is to know about the product they have in mind.
- They make too many assumptions regarding who their users really are, and what they want and need. This is the fastest way to ensure you waste resources building something that nobody wants, but it is, unfortunately, one of the hardest things to test and measure prior to launching. Even if you conducted 100 interviews on people in your target market prior to launch, who is to say that they are ACTUALLY your users?
- They show a lack of empathy by making no effort to understand who the user is, and what they are looking for. For example, they believe that because they understand their idea, everybody will, and therefore they do not understand or prioritise accessibility.
- They put research in the “too hard basket” and not doing their homework in order to drive out dangerous assumptions. It can be exciting to have prototypes (or working products) in your hands ASAP, but I cannot say strongly enough just how crucial it is to do the legwork before breaking first ground with your product.
- They show a lack of continuity by failing to keep the User and their needs at the centre of the project for future releases.
Problems 1-3 need to be addressed in every project before moving into the build phase. As UX Designers, it’s our responsibility to tackle this head-on from the start.
So how do we fix these problems?
Two words: Diligent Research
You have to know who the people are who will use your products. Assumptions aren’t Users.
You must know who your Users are so you (or your Agency Partner) don’t build things that aren’t important to your Users. This wastes time (and money), adds confusion to any product and eats away any competitive advantage you may have.
Here's how to make sure you're creating a product that will delight your users and make sure they use it time and time again.
- Talk to the people who will be using your product. Find out how they think, how they make decisions, and what are the things that they need to understand while solving their problem.
- If you don’t know who they are, you can run online surveys and look at the data, or you could talk to the people who talk to Users and really understand them, have them point you in the right direction.
- Develop and Document Personas to capture this information to ensure we keep focused on your key user groups throughout the process.
Tip: This doesn’t have to be a huge, involved process - it can happen in minutes, hours or days - but it should be a continual cycle throughout the product.
Whether you’re at the start of a project, halfway through, or immediately pre-deployment, do your research! Go and talk to the people who will be using your product, drive out the assumptions, intimately know who the people you are designing for are, and keep them top-of-mind throughout the project.
This is hard, but it’s one of the most important steps to building a successful and useful product.
If you're looking to build a great Product based on user research and testing, contact us today.