Lean UX: A Shortcut to a Better MVP
There’s a pretty good chance that, if you’re reading this article, you are either in technology or in the startup field (perhaps both). So when I say “The Lean Loop” it almost certainiy jumps up in your mind’s eye: Learn, Build, Measure. It’s the foundation of Eric Ries’ book The Lean Startup, in which he stresses the importance of cycling through the loop as quickly as possible. So, when I say next that I’m about to tell you a way to make trips through the loop even faster, a way to keep the loop from ever stopping until you tell it to, I imagine that your virtual ears perk up a little. Let’s talk about Lean UX.
For those visual thinkers among us (hi!) here’s The Lean Loop:
It’s a loop so any point can be the beginning, but let’s say you start with some Ideas. You Build a Minimum Viable Product (MVP), resulting in Code that you Measure by showing it to your prospective customers. That gives you Data that you Learn from, refining your ideas that you Build into the next iteration of the MVP. And so on, so forth, forever after.
This model of work isn’t original to the Lean Startup. It’s the core of the scientific method, and of the creative process. Which makes it no surprise that the typical User Experience (UX) Design Workflow looks pretty similar to the Lean Loop:
UX Designers prototype ideas so that they can be tested against the target market, learn from the results of the test, and build a new prototype to test until the design is “done”. Then it gets handed off to the Developers to make it into functioning code.
It’s not a bad process, but it’s not especially small-a agile (and not big-A Agile either). Working this way you run the risk of getting way out ahead of your Developers and creating an unworkably large backlog. Cycling through the process without input from the Dev team also puts you at risk of designing something that will be too costly to build, or something that can’t be built at all.
A more fundamental drawback common to both the Lean Loop and the typical UX Workflow is that they are both serial processes: work on one phase can’t begin without the output from the previous phase. This means that a bottleneck in any one phase can gate the peformance of the entire system, slowing down the time it takes to cycle through the loop.
A loop can be managed carefully to keep bottlenecks at a minimum by capping iterations at a certain size or continuously re-balancing the staffing of each stage. In the hands of a capable manager this can certainly work — but I think there’s a simpler way.
UX + Lean Loop = Lean UX
Imagine adding the Prototype phase from the UX Workflow to the Lean Loop and giving it a twist. You end up with something like this:
The Build stage still gets fed Ideas and produces Code, but it now operates with its own semi-independent loop. Linked to this Build Loop is the Lean UX Loop, using Prototypes to test ideas in another semi-independent process. This results in two key advantages: more ideas can be tested and refined more quickly, and the Development team gets higher-quality output to base their work on.
Higher Speed
The two loops can operate as a figure-eight, constantly feeding each other in a similar manner as the standard Lean Loop. But they can also decouple for a period of time and operate independently. Say the team is working on an iteration that even in its maximally reduced state is more complex than usual, or an iteration where the UX work will take much longer than the Development work (or vice versa). Instead of staffing up or breaking the iteration up in an undesirable way, the two loops can split into a “staggered sprint” model, where the Development team and the UX team cycles through their work semi-independently. Once the teams reach their finishing points the loops can re-couple into the figure-eight process. What makes this possible is that the UX team can build their own Prototypes to fuel their Measure and Learn activities, instead of being bound to the Development team to Build everything the UX team tests.
The addition of the Prototype phase also enables the second advantage:
Higher Quality
The UX team can work in a self-contained loop when necessary through the use of Prototyping. Prototypes can be of any fidelity, built out of almost any material. Early in the process they can be actual sketches on actual napkins. As the ideas mature they become static wireframes, interactive mockups, and even coded mockups. Your UX team can build a Prototype using the actual presentation layer code that the Development team uses and hand it off to the Development team ready to be married to the back end code. In this process your Developers are only building ideas that have already been validated, leading to less re-work and a higher quality MVP.
Keep it Cross-Functional
Even when operating as two semi-independent loops, the UX team and the Development team should keep talking to each other. Having a Developer on the UX team can help to make sure that the Prototypes are built to be as useful as possible for the Development team. And if you add a UX Designer to your Development team, he or she can make dealing with gaps or inconsistencies in the Prototype quick and easy.
When do we Start?
For Lean organizations that already have a UX Team, adding Lean UX to your Lean Loop is simple in theory, though fine tuning the new process and getting everyone on board will of course take time.
If you’re running a Lean shop but don’t have any UX Designers on staff, or if you aren’t using Lean principles at all yet, you’ve got a little more work ahead of you. A good approach to take is to get in touch with an outside Lean UX Consultant (ahem) and have him or her help you start a UX team and get them integrated into your process or implement a Lean UX-based process from scratch.
If you’re interested in learning more about using the Lean UX process, sign up for the dbdc newsletter. This month’s issue will include a white paper diving deeper into implementing Lean UX so that you can start benefiting from Lean UX’s advantages at your organization. And as always, share your success stories or tell me what I’ve gotten completely, incredibly wrong by emailing me at info at dbdc dot us
