Lean UX is a fantastic way for a project team to operate when the engineering team also using Agile development in conjunction with Build Measure Learn canvases. Older UX design processes don’t necessarily work well when using rapid burst development, often there’s not enough time to deliver well thought out UX solutions. Lean UX uses similar techniques and they both have the same goal in mind; to deliver a fantastic user experience. The difference is the way you work on a project, let’s take a look at how it would work.
Lean UX focuses more on the experience under the design and less on providing UX deliverables. It requires a greater level of collaboration with the engineering and design teams. The nature of Lean UX is to obtain user feedback as early as possible, using it to make quick decisions about the end product. To align with Agile development who’s purpose is to work in rapid, iterative sprints. Lean UX follows these cycles to ensure that feedback generated can be used to define each iteration.
Why we use Assumptions
Traditionally in older forms of UX each project is built upon the capture of requirements and producing deliverables. The objective was to ensure that each of these deliverables were highly detailed and responded specifically to the requirements that are defined at the beginning of each project.
The Lean UX process is different, it’s not as focused on providing deliverables. Instead the team produces ongoing changes to the product based on real time feedback, to ensure the final outcome is meets the users needs.
This works by getting rid of ‘requirements’ and using a ‘problem statement’ instead, which leads to assumptions that are used to create hypotheses.
So what exactly is an assumption? It’s a statement of something which we think to be true. It’s designed to create an understanding towards an idea to enable the team to get started working. As assumptions, it’s understood that they might not be correct and therefore might change during the course of the sprint, as a better understanding develops within the team.
Assumptions are usually generated during a collaborative workshop. By first stating the hat the problem is, the team can then brainstorm ideas to try solve it. In this process the team generate a Build Measure Learn canvas that captures the assumptions.
The canvas might include:
- What is the product used for?
- What is the most important functionality?
- Who are the users?
- When will they use it?
- What situation will they use it?
- What’s the biggest risk to delivery?
Usually there is more than one answer to each of the questions defined within the canvas. This leaves the team with a greater number of assumptions than they can usually handle. When this is the case, the team prioritises the assumptions following their creation. Normally the team will prioritise their assumptions by the risk they represent. The more severe the consequence of uncertainty surrounding the assumption the higher the priority.
Creating a Hypothesis
The hypotheses created are designed to test the teams assumptions. There’s a simple format that they can use to create them, quickly and easily.
We believe that auto saving users progress during their experience is essential for smartphone users. This will achieve a higher level of sign up completions. We will prove this hypothesis if we increase the sign up completions from the current rate of 26%.
Firstly the team states the hypothesis belief, why it is important and who it is important to. Then they follow with what they expect to achieve by the hypothesis. Finally, they determine what evidence they would need to collect to prove that their belief is true.
The big advantage this method is that it removes the ‘I‘m not sure if this is a good idea’ and potential feature design debate from the design process. Every idea will be tested and the evidence criteria clearly determined. If there is no evidence, then it’s time to drop that idea and try something else.
Using an MVP with Lean UX
The Minimum Viable Product also know as the MVP is a core concept of Lean UX. By building basic versions of the product the team can test it and if there are no valuable results, abandon it. The MVP which shows the most promise can then be incorporated into future design and development rounds without any hassle.
This is a great way of maximising the resources and one of the reasons why it works so well within the Agile development framework , it also allows for the team to do a lot of experimentation.
User Testing and Research
The lean UX version of user testing and research uses the same principles as traditional UX environments. However, this new approach tends to be operated on the fly. The tests results need to be delivered before the next sprint, so there’s less focus on meticulous outputs and more focus on the raw data.
Responsibilities for research is spread across the whole team so that there’s less of a bottleneck created by having a single UX resource trying to get the whole job done by themselves. This often allows engineering resources to get involved in UX work and increases the level of understanding and support for UX work within the engineer team.