Lean UX and Design sprints are two popular UX methods created to solve a design problem. There is some crossover and I'm experienced in both methodologies. I've have seen both positives and negatives to each approach. In this post, I am going to highlight what works well from each process and finally how I have designed my own workshop based on them.

Lean UX

This is the approach of validating product ideas in the leanest possible way. The idea comes from Jeff Gothelf book 'Lean UX'. It follows a Build > Test > Learn approach.

How does it work?

• Running Experiments to validate ideas.
• Learning and testing from your end user.
• Hypothesis-driven development.

Good points

• Get a solution in-front of users quickly and learn from that.
• Start to understand a backlog. As you create all the assumptions of what the product is these then help to prioritise the risky ones which you then test. It also maps out all the other things the product should be.
• Research is light and you use the idea of 'just enough testing'.
• Focusing on the crucial parts of the experience that will make or break the product. Then testing these assumptions and learning from them.
• Slots nicely into a SCRUM methodology.

Bad points

• The language you use can be intimidating.
• Within the methodology, the sketching and ideation approach is the weakest part.
• Metrics are required to validate if the hypothesis is true. These can be hard to create and sometimes they are dependant on user testing and become subjective.

Design Sprints

This is based on the book 'Design Sprints’ by Jake Knapp. Jake Knapp worked at Google Ventures where he created this approach. It follows the unpack > ideate > evaluate > test > refine pattern approach.

How does it work?

• The book breaks the approach into a 5-day Sprint.
• Day 1 unpack the problem > Day 2 idea solutions > Day 3 Decide the solution > Day 4 Prototype > Day 5 test the solution

Good points

• Clients love this approach, they are fully involved and get a say. -They also get an internal prototype that they can circulate for buy-in.
• Its a really fun week with a good output and great for team building.
• Research is light and you use the idea of 'just enough testing.'
• The structure of the week is very well defined.
• The sketching day is excellent and the exercises you do to get people out of their comfort zone.
• Really understand the problem from the client's point of view.

Bad Points

• The prototyping day is pretty intense.
• You don’t get a well-defined backlog.
• It does not fit into SCRUM and it can make the design process waterfall.🚿

Conclusion

I enjoy using both of these techniques and have used them at the start of projects to understand what to build. Lately, I've combined bits of both exercises into one with the focus on getting a prototype in front of users. This is my workshop approach and is something I continue to iterate and build upon.

• Unpacking problem: (adopted from Design sprints) I ask key stakeholders to speak about the problem and what they are trying to solve.
  
  
• Understand your users: get into their mindset. What they are trying to do and achieve? I usually use a version of the empathy map for this.
  
  
• Vision: why are we building this and how will it benefit the business? I usually use the vision board but I am starting to create my own version as there is an overlap with the empathy map which I have found clients find frustrating.
  
  
• Assumptions: (borrowed from Lean UX) I love this exercise its a great way of getting everyone's views on what the product should be. After that, I map out on a matrix to understand what is a high priority and a high risk.
  
  
• Sketch: I find the sketching framework of the design sprint the best approach to get the ideas out.
  
  
• Prototype: I usually look to have at least two days to build a lean prototype. We usually use Invsion and make it a simple click through but I have built HTML/CSS prototypes in the past.
  
  
• Test: Validating the prototype testing with actual users.