“Inspired by Lean Startup and Agile development theories, it’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way with less emphasis on deliverables and greater focus on a shared understanding of the actual experience being designed.” - Jeff Gothelf
Our cross-functional product development teams at DMI International, like many teams everywhere, have worked with traditional UX deliverables in the past. This works to a point, but we have all had the sense that perhaps we weren’t working as optimally as we could be. In 2015 we initiated a pilot program to explore how we might bring better mobile products and services to our customers quicker and at lower cost. The results of this pilot have been even more successful than we had hoped for and so now we are operationalising this way of working. So what are the changes?
Lean UX focuses on the experience under the design and is less concerned with deliverables than traditional UX. It operates within agile development projects and with high levels of collaboration among the entire team. Collaboration means we build a shared understanding of what we’re building and why, which eliminates the need for static documentation. Additionally, we focus on obtaining feedback as early as possible so that it can be used to make quick decisions. The nature of Agile development is to work in rapid, iterative cycles and Lean UX mimics these cycles to ensure that data generated can be used in each iteration. The data we generate within the UX team is both qualitative and quantitative and informs the entire product development team about what we’re building and why.
We answer three important questions for our clients:
How long do we wait before launch?
In Lean UX we are not focused on detailed deliverables, this is because the nature of the products we’re building are far too complex for anyone (product manager, designer, solution architect, business manager) to have all the answers up front. Product “requirements” are really “assumptions”: they are things we believe to be true. But until a customer actually has it in their hand and is using it, and is paying for it, we really don’t know whether we’re building the right “thing” or not. We want end users to interact with something as soon as possible in order for us to begin learning. This is often days after a project starts, not months (or even years!) in traditional projects.
How do we define the right requirements for our product?
Unless the product we’re building is very incremental, then what we call user requirements are simply assumptions. It’s better to acknowledge we don’t know all the answers up front to solve a business problem and shift to experimentation and learning, which is both a change in mindset and tactics. This is actually how, though, we do define the right requirements for a product. We can take opinions and guesswork largely off the table and instead use data anchored in an understanding of market fit to guide our decision making.
What signals are we looking for from the market?
By shifting our focus away from outputs (wireframes, user stories, delivered code) to outcomes (measurable customer value), we can build better and more satisfying experiences. When the entire team has a shared understanding of the problem they’re solving and a shared ownership of the outcome, the activities of design and software development can flow in a perfect balance with one another resulting in a superior customer offering.
The prototype is our documentation.
A lot of questions we get are some variation of: “How do the developers know what to build if you haven’t documented it?” and “What does the customer get if we’re not delivering the traditional UX deliverables?”
The answer to both of these questions begins with the prototype. In our process, the prototype is everything. It is how we externalise our thinking and ideas, it is how the team communicates around the project. It is how we perform user evaluations and usability tests. It’s also how we capture all of the really practical things necessary for creating software: the states of the entire system, the interactions, the flow, use cases, error messages, user onboarding, etc. We believe it’s the best way to communicate experience design because it reflects better the complexity of software; much better than static PDFs or other “documentation” that tries to describe it abstractly. With interactive prototypes at varying fidelities, we can describe it directly. Developers collaborate with designers, and customers, around prototypes, from very rough to very detailed, in order to build their understanding. It allows for a much clearer picture of what is to be created and potential technical pitfalls.
And as for the customer, they get better software faster.
Conclusion
We combine Lean UX with Design Thinking (1) as foundations for our Customer Experience (CX) teams so that we prioritise learning over delivering arbitrary software. Our ability to learn quickly, and apply those learnings systematically, is what allows us to unlock tremendous value for our customers in the form of mobile experiences, apps, and services.
We begin by identifying the problem we’re trying to solve. Starting with the solution is, in my experience, an extremely efficient method for getting rid of any excess money you may have lying around. By framing a really good problem, based on customer insights and understanding, we can ideate many possible solutions which may be a much better market fit. It also results in faster times to market because of the shared understanding we’ve created through the activity of framing the problem.
We then seek to understand how we will know if we’re successful or not. By already beginning to bring in the business goals and customer needs, we can make much better decisions with regards to roadmap, features, and how those features should be implemented. This is about having the holistic picture in mind amongst the whole team who is actually building it.
Finally, our measure of progress and success changes from output to outcome. Output: the stuff we make; aka, features; Outcome: a measurable change in customer behaviour attributable to specific output (and we focus here because we can tie our team’s work directly to something measurable). And since software is no longer sold in shrink-wrapped physical media, at a big box retail store, this approach enables us to work in way where we are continuously delivering software of value to the end user.
For a much deeper exploration of Lean UX, I highly recommend Jeff Gothelf’s “Lean UX: Applying Lean Principles to Improve User Experience”.
To start your own journey in creating exceptional mobile experiences for your customers, contact us at DMI International.
(1) “As a style of thinking , it is generally considered to combine empathy for the context of a problem, creativity in the generation of insights and solutions, and rationality to analyse and fit solutions to the context.” - Tim Brown, CEO IDEO
