Design Sprint Blog- Furo App

Design Sprints 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

As we were meeting face-to-face for the first time, we kicked off the day with a round of introductions, some background stories, and knowing each others’ roles as stakeholders of the project. The client also had his other partner and investor in the meeting. Moreover, he explained the “why?” behind this app. The problem he is trying to solve, pain points of the current users and the shortcomings in the competitor apps. I then presented the competitor research report and gave a walkthrough of user personas to make sure that everyone in the meeting room was on the same page. I made sure to note down all the problems we were going to solve in the coming few days.

Day 2

The second day was more about the ‘Diverge’ approach of Design Sprint where we discussed various possible solutions to help solve the pain points addressed on the previous day. For each challenge, we brainstormed on all the possible solutions and zeroed in on one best approach for each of the issues.

Day 3

Our initial thought around design sprint was to make the most out of the five days we have for working together. As the client and our team are in separate countries, it was essential to cover all the detailed feature discussions with the client. So, on day three, for the first half, we finalized the feature list for the app along with details on each feature. We spent a couple of hours in the second half of the day to create Information Architecture (IA) to make sure that we have a proper flow of all the features and navigation between them.

Day 4

This day was more about wireframing all the significant screens of the app and creating a prototype for it. I usually use a tool called Figma for wireframing which makes it easy to collaborate with the clients and my internal team. I created the major screens by working with the client. After meeting the client, I went back to my hotel room and created a few more hand sketches and sent them over to my UI/UX designer back in India. We leveraged the benefits of different time zones – as my designer was in India (12.5 hours ahead of EST time zone), by the time I was sleeping, she created the wireframes based on the hand sketches I had provided and even completed the prototype for it.

Day 5

On the final day, I presented the prototype to the client. We discussed more on a couple of features from it. The client provided feedback on a few screens, and I made sure that they immediately reflect their inputs in the wireframes and the prototype. Besides, I validated the screens with other stakeholders of the app.

Key Points To Remember If You Run A Design Sprint 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