Mastering the Design Sprint Process- Furo App

Design Sprints process have always been exciting to us! Even though we have completed several five-day design sprints previously (both on-site and remote) and experimented with a one-day activity (we do not recommend it :P), the process of validating ideas and solving challenges still thrill us. The enthusiasm is always high as if it’s our first design sprint. Since I am assuming that many of you have already read our previous design sprint blogs, I’ll not dive deep into all the tiny details and exercises, and will focus on the points that made this sprint different.

The Pre-Work

Competitor Research

At the start of the sprint, we looked for the apps in similar space and tried to map out the problems of the existing users of those apps through different methods; Read user reviews on App Stores and other forums about these apps. Played around with those apps and tried the features to have a better understanding of the user’s journey and user experience.

What Did We Find?

The existing apps are complex, and the users have to go through a lot of steps to perform desired actions in the app. Also, the users aren’t happy with the overall performance of the app. So we needed a superior UX in our app along with an engaging UI.

User Personas

We had multiple calls with David to understand the concept of their app and along with it the ‘Why’ behind it. Why did he want to build that application? Along with this, we tried to understand more about the users of the app, what is their motive behind using the app, what are their goals. Based on the inputs and our desk research, we created user personas for the project. The client and his partners verified user personas.

Feature List

As we were in continuous communication with the client, we had been discussing more on the idea and building a comprehensive feature list for the app. One thing we (all the stakeholders) had made clear to ourselves: whatever features we will put together, we have to make sure that it does not create clutter.

We need to create value for the users even with the least minimum features. Most of the time the app owners feel that building more features into the app means it will create more value for the users and the users will think that they are spending money on the right app. But that is not the case. More features bring more complexity, which means risking the user experience.

Remember “less is more.” We then built a complete draft of the feature list and then focused on only a few of those features for phase. In a way, we were now ready to dive into the five days face to face design sprint session with the client.

Day 1

A well-defined Design Sprint starts with a strong Problem-framing session. The process ensures the team enthusiastically tackles a clear problem instead of facing unknowns with anxiety. However, some uncertainty around solutions remains.

Therefore, the Design Sprint Team (often different from the Framing team) dedicates time to understanding the problem, its context, and all available information. We’ve enhanced the design sprint process by structuring morning discussions into “Lightning Talks” and integrating pre-sprint research directly into the mapping session for deeper user empathy. The sharpened focus allows the team to pinpoint the most impactful area for a solution by the end of Day 1.

Day 2

Pre-work streamlines Lightning Demos: By assigning research as homework on Monday, Tuesday starts with 30-45 minute presentations instead of a 3-hour session. The strategy frees up the remaining morning (around 2 hours) for Solution Sketching. The team tackles solutions with fresh minds, inspired by the demos, potentially leading to more creative ideas.

Faster solution review and storyboarding: Afternoon dedicates 1.5 hours to reviewing solutions and selecting the prototype. While storyboarding gets 1.5 hours, tight timelines encourage focused discussions, leading to similar outcomes as the book’s method. compressed schedules save valuable time, especially for senior management participating in critical decision-making throughout the two core days. We still recommend keeping the entire team involved for the full Sprint duration.

Day 3

Our revised Design Sprint process eliminates the Wednesday storyboard debates. With a fresh perspective, the team dedicates up to 1 hour to review and refine the storyboard (if necessary). They then seamlessly transition into assigning roles and planning the prototyping process.

Such a collaborative approach establishes team spirit and ownership. We encourage everyone, including senior executives, to participate actively in prototyping. This strengthens team bonds and creates a shared sense of ownership over the solution, leading to greater investment in its success compared to a prototype built by an external designer or agency.

Day 4

The Design Sprint process concludes on Day 4 with user testing to validate the prototype. The critical step involves real users, often called “design partners,” who help identify usability issues and provide valuable feedback. The team strategically engages a select group representing the target audience to gather diverse insights.

Following best practices, the team can focus on learning from a focused group. Collaborative learning ensures a balance between obtaining a variety of perspectives and avoiding diminishing returns from excessive testing. The Design Sprint ends with the team debriefing key takeaways and defining the next steps. With further steps of reviewing user research and stakeholder consultations, identifying areas for improvement, and outlining a clear action plan.

Day 5

The final stage of your sprint is crucial: user testing. Plan, especially if reaching your target audience is difficult. Record your sessions (with consent) and define your success criteria. Will users complete tasks quickly? Does the information make sense? Clear goals are essential to measure success.

Look for patterns, user behaviors, and common themes in the feedback. These will be your roadmap for prioritizing features in the next development cycle. Finally, document everything! Create a report summarizing the valuable insights you gathered during testing.

Key Points To Remember If You Run A Design Sprint Process At Client Location

Do Your Homework

Make sure that you work on the idea a few days before meeting the team for a design sprint. It will give you enough time to do the competitor research, and you can come up with useful discussion points for the meeting.

Make The Optimum Use Of Time With The Client

Ask all types of relevant questions and have answers to even your silliest concern or doubts about the project.

Form A Bond With The Client And The Stakeholder Team

It will help you in the long run of the project as these stakeholders are going to be the key people to provide feedback on the product sprints.

In The End, This Is What The Client Had To Say About The Design Sprint