Agile UX and Lean UX put collaboration, iterative working, and user-centric, evidence-based research at the heart of their systems.
Why?
Well, what would happen if the design and development of a digital product were carried out in one fell swoop, built around the information provided in a single hypothesis, plan, or idea? There are far too many avenues for potential failure likely to occur by the time the finished product is produced.
Think about it; could you possibly uncover every angle of performance and user need in one set of rules and observations?
For example, technology moves incredibly quickly, so there’s a strong chance it won’t be too long before there’s a better way of performing necessary tasks in new ways. Or, it’s inevitable that people constantly evolve and change, so yesterday’s problem might not be as significant as one they discovered a week or two later. And, while you’re working on your solutions to the latest prevailing set of problems, your competitors may have dropped something superior in the meantime that makes your current project seem a little lackluster, behind the times, or just unnecessary.
In any such cases, having a one-shot plan with a single production phase is only likely to deliver a costly experience for developing something that’s no longer necessary.
Agile UX solved that particular set of problems
When Agile UX arrived in software development, its job was to ensure that those blinkered vision development systems became a thing of the past.
It introduced a method where different sections, stages, or functions were managed in smaller separate chunks, in shorter steps, and reviewed, typically over a couple of weeks. The idea of a design-build-test-launch system was upgraded to a design-build-test-review cycle, with as much iteration as required until a launch-worthy product came to fruition.
That all sounds great, right? A worthy solution.
But, as demands on resources of both time and money came into play, with more and more startups looking for a faster and more affordable way to market, the Lean UX approach became the most attractive for new operations with restricted budgets on time and money.
What is Lean UX?
When you add the term ‘lean’ to any system, you’d be forgiven for assuming that such streamlining, whether time or money-saving, was down to cutting corners. Not so.
Think of your Lean UX designers as racing drivers. They’re not cutting corners; but finding the most efficient way around them at the highest speed.
Lean UX methods rely heavily on the assumption that the first version will never be the best; in fact, it’s assumed that it won’t even work. Given that mindset, why would anyone spend more than they have to building a prototype just to discover what’s wrong with it? That’s where the MVP becomes so crucial to the process.
Using a minimums viable product to test Lean UX assumptions
Like Agile UX, Lean UX is collaborative, user-centric, and built in bite-size sections. But instead of separating functions, sections, or processes, iterations are typically a new or revised MVP built on what they found wrong with the previous prototype.
This process is known as the assumption and hypothesis method.
If we assume that each prototype will be wrong and require improvement, we derive a problem statement that can lead to a set of assumptions. How do we do that? By having a conversation, usually in the form of team brainstorming, where everyone on the project is involved. Bringing the entire team into the discussion helps to see the many problems their project could face in every part of the process. Teamwork makes the dream work, right? Well, in Lean UX, that’s precisely the point.
Working with a Lean UX problem statement
Assumptions are just problems without proof. By asking questions and holding discussions around those problems, we can create a hypothesis to test them.
If user testing proves successful, then you have your proof. If not, you can discard the idea and move on to the next one.
However, the same user testing may uncover other issues you couldn’t see without it, perhaps even forcing a complete remodel of your intentions, product, and next prototype. With an MVP, there’s little to lose if you have to scrap the entire model to start again from a better, more educated standpoint.
Problem statements allow you to keep discussing and testing. The goal is to explore and improve the product and your initial goals, learning more about customer needs to deliver the best possible outcome for your users and next-stage Lean UX personas.
The essentials of Lean UX
Agile and Lean UX are similar in performance, but the essential difference is that Lean UX uses learning loops dependent on each MVP.
Minimum viable products help UX designers and researchers validate ideas (or don’t) as quickly as possible. Therefore, the fewer features they have, the less noise there is, the quicker they are to build, and the sooner they can be dropped into the testing space.
As you can see, it’s not cutting a corner; it’s flying around it unhindered by unnecessary details.
Each learning loop delivers a monitored and measured MVP based on UX research and testing techniques.
So what’s the difference between Lean and Agile UX in their testing loops?
- Lean UX testing asks what the problems are and learns from them.
- Agile UX testing loops validate that their latest version works as it should.
Back to our original question: Is your Lean UX team proactive or reactive?
Lean UX should, in theory, ensure your process is proactive at each step, using research and design thinking to discover issues and needs built around user data.
However, there are times when stakeholders are just too close to their hypothesis to see the alternatives. So, leading their charge, they build and test their initial MVP without the appropriate amount of UX research or assumption-and-hypothesis conversations. This creates a reactive team, testing out the assumptions made by a single stakeholder and not those of their users.
Sadly, this is a typical situation that misses the target of Lean UX, with user testing reacting to the stakeholder’s ideas and not proactively exploring properly structured problem statements.
In such circumstances, product owners and stakeholders need to un-blinker themselves and open up to the bigger picture, ideally dropping back in on the basics of UX research, for example, using the Design Council Double Diamond approach. Engaging with the left-hand diamond, they’ll stand a far greater chance of discovering the real issues than their single, biased assumptions. It’s a standard tool that aids designers and researchers in fully exploring the problem space before any solution is uncovered or suggested.
For those who have yet to explore the Double Diamond approach or need a quick reminder of how it determines the actual problems to solve, it follows four simple stages through two ‘diamond’ stages that ensure we’re designing the right thing and designing things right.
- Stage 1 – Discovering the right thing through research
- Stage 2 – Defining the right thing through synthesis
- Stage 3 – Developing things the right way through ideation
- Stage 4 – Delivering things the right way through implementation
The framework promotes four key principles so that problem-solvers can work as efficiently as possible:
- Put people first – Understand their needs, strengths, and aspirations.
- Communicate visually and inclusively – Help everyone gain a shared understanding of problems and ideas.
- Collaborate and co-create – Working together promotes inspiration.
- Iterate – Continual testing uncovers errors earlier, lowers risk, and builds confidence.
If you think those key principles sound familiar—congratulations—we’re glad to hear you’ve been paying attention. Now all you have to do is ensure you remember them and stay on track during your Lean UX build.
Conclusion
Today, we considered a particular problem we regularly see by dropping it in place using a simple Lean UX summary. Following the program as intended is essential to make the most of any design or research tool. It’s far too easy to get swept up in the excitement of a new venture or feature, making it even more important to ensure we’re not chasing dreams but data.
If you’d like to understand a little more about Lean UX, feel free to explore our pages that look a little deeper into the differences between Agile and Lean UX and how Lean UX helps you overcome the fear of design failure. Finally, there’s also a page that discusses how the collaboration between all parties during Lean UX uncovers a broader, more informed and well-rounded set of problems and solutions.
If you would like to know more about how UX24/7 can help you with your Lean UX approach, email us at hello@ux247.com.
