A lean design sprint is a scaled-down design approach that involves delivering artefacts quickly in an iterative fashion to obtain user feedback with limited resources.

I have recently completed a design sprint and have found this approach especially useful for product designers/teams that want to build a quick and usable solution to prove value before proceeding with further commitments.

I’ll be sharing briefly on the approach. The lean design sprint consists of four broad steps:

1. Prototype: Establish initial sketches of user journeys
2. Define: Create a user feedback framework
3. Validate: Organise frequent meetings with users
4. Build: Align your sprint schedule with the development sprints

#1. Prototype: Establish initial sketches of user journeys

Based on your initial understanding of the product requirements, obtain inspiration from close competitors to develop an initial prototype. For example, if you’re building a customer relationship management (CRM) product, you can refer to products like Salesforce, Pega, HubSpot, etc.

Using a combination of reference designs, you can either sketch the design on a piece of paper or using design tools i.e. Sketch/Figma/PowerPoint.

This stage enables you to create a common understanding among the stakeholders (through visuals) of the desired product in mind based on the initial sketches and user journeys.

Don’t reinvent the wheel.

#2. Define: Create a user feedback framework

Once you have the initial sketch up, you can work with selected groups or individual end-users to evaluate your sketch and improve on it.

With the latest improved sketch, you can adopt an approach to disseminate it to a larger group of users to obtain feedback. This can be done via email and/or face to face interviews.

Do note that different groups of users may require a different approach depending on their profile, e.g. location, peak periods, roles, years of experience, etc. You’ll have to tailor your timeline to catch the users during the low periods and specific sets of questions to users in various roles and experiences.

For interviews, it would be good to first come up with an interview guide to structure and prepare the list of questions that you want to ask the users to achieve your outcome.

This stage focuses on defining a form of structure that allows you to obtain and consolidate feedback across various stakeholders in a consistent manner throughout the design sprints.

Tailor the solution to users.

#3. Validate: Organise frequent meetings

There are various stakeholders involved in the design sprint: end-users, business analysts, developers, product designers/owners, etc.

It’s important to maintain a good relationship with your stakeholders throughout the sprint – especially when you are designing for a large and diverse group of users. Involving the users frequently increases the chances of your solution buy-in and eventual adoption rate.

Book their schedules in advance and plan the agenda for the meetings, your users will appreciate the regard for their time.

Meeting agendas include understanding users’ pain points, validating the prototype, obtaining further requirements, aligning objectives, etc.

Listen, understand, and continuously improve the solution.

#4. Build: Align your sprint schedule with the development sprints

To ensure that your development efforts are worthwhile and solve the right problems, it should be based on the validated designs from stakeholders. Therefore, the design sprint should be approximately one sprint ahead of the development sprint.

Usually, while the developers are building, you will be socialising with the end-users and business analysts to establish design sketches for the subsequent sprints. In some projects, design sprints are completed before starting on the development sprints.

I personally prefer running design and development sprints in tandem because requirements tend to still change throughout the project during the development sprints.

The output (e.g. end-to-end functional prototype) for the development sprint will be further validated with end-users to obtain feedback, whereby updates and improvements would be documented and illustrated with sketches and updated journeys.

Build usable solutions from surgically validated designs.

Benefits

The above-mentioned approach has reaped the following benefits for my project:

• Provide developers with ample direction: with a visual sketch, developers can better visualise the outcome and intent of the product while bridging the communication gap between the users and builders
• Produce user-centric solutions: the solution is designed based on the consolidated inputs and involvement of various users — leading to increased user adoption and usage
• Establish a base product to improve on: users have a baseline product with basic features to tinker with and provide constructive feedback— reducing the need to recreate similar features and saves time

Takeaways

Start with an initial sketch so that end-users and developers have a common understanding of the deliverable and objectives; then improve on the design through a feedback framework that tailors to the relevant stakeholders. Organise frequent meetings to realign deliverables with stakeholders in a fashion that streamlines product delivery.