The role of software development is to produce software to solve a problem. The role of Agile software development is to learn as much about the solution as possible while developing, Agile does that mainly through ruthlessly begging for feedback, both on the product (e.g. sprint reviews, test-driven development and continuous delivery) and on the process (e.g. Scrum/Kanban boards, sprint retrospectives and standup). In between all these feedback sessions, you do ”normal” software development.
The role of user experience design (UX) is to produce a design to solve a problem (through user research and interaction design, of course). So, software development and user experience design go hand in hand, completing each other. Design and build.
The common misconception is that Lean UX also shall produce a design solution to a problem.
This is not the case. The role of Lean UX (and its progenitor Lean Startup) is to learn, but learn as much about the problem as possible. Lean UX does that through ruthlessly validating assumptions about the problem, the customer, their needs, the proposed solutions and the success metrics. Lean UX and Agile go hand in hand as well, learning about the problem and the solution, before, during and after development. In between all these validation sessions, you do ”normal” UX.
One situation where Lean UX is usually not used right due to the misconception is when you have had an ideation session and come up with possible solutions to a given problem. The Lean UX way of working would be to place those solutions in a risk vs. value matrix. For the solutions that end up in the high value and low risk corner, you do ”normal” UX since low risk means that you know enough about the assumptions around the solution. So you create a prototype and test that prototype with users to see if the workflow seems to solve the problem. For the solutions that end up in high value and high risk corner, you need to learn more and eliminate unknowns. In Lean UX, you create the smallest thing possible to mimic the intended experience of the solution (by creating a Riskiest Assumption Test, RAT, formerly known as MVP) to learn more about and (in)validate the solution. When you have learned enough, i.e. lowered the risk, you can do ”normal” UX again for that solution.
Here’s an example: There’s a problem that people do not really use Lean UX as intended. One possible solution that lands in the high value high risk corner of the matrix would be to create a course for learning Lean UX. Instead of creating a prototype of the full course, detailing out different sections and exercises, you can create a nugget of teaching such as a five minute long YouTube clip or a blog post, and then ask some questions to see if they’ve learned the content. This would (in)validate the assumption that people can learn Lean UX in a course setting and reduces the risk of actually delivering one, such as Lean UX at Crisp, and getting feedback on that solution in production. 😀
It’s all about learning…
