How to Use Product Design Sprint to Overcome a Deadlock - Case Study

We established a really strong process to offer our clients a comprehensive tool that can solve many real problems.

Our challenge

Sometimes, already working processes cannot be replicated in some particularly specific situations. For this reason, we broke the rules, organising a version of our Design Sprint without the Client. This experiment brought some positive results.

Reasons that led us to adapt our process can be traced to the issues listed above.

• The Client could not be present. (they could do one hour a day maximum, remotely)

• The Client wanted fast solutions to many problems, but they had no time to sit with down and engage in lengthy discussions.

• The Client really trusted us. They gave us some freedom.

• The Client needed advice about their business and strategy.

• The situation was a deadlock due to the absence of feedback from the Client and lack of business knowledge on our part.

So, we redefined our method, which usually requires a Product Designer, the Client, and a PM. Instead, we created a team of two Product Designers and a PM.

The first designer was the one really familiar with the project and with great experience communicating with the client, while the other designer was totally new to the project. We can say in this case that the First Product Designer became the Product Owner, or better, the point of connection between the Client’s vision and the team.

The team was made up of:

• the Product Owner – the internal Product designer with a strong background in the project;

• the new Product Designer, providing a fresh eye and new ideas to the process;

• the Project Manager, coordinating and facilitating the sprint;

• the Client, even if not present, was working as a remote tester to validate our ideas at the end of the day.

The process

First Day.

We started with a series of exercises, in order to help the new Product Designer to understand the scope better. We analysed the list of competitors, trying to understand differences between the Client’s vision and those of their competitors. We mapped the project to have a full picture in front of our eyes. We analysed the business, UX, and strategy issues together.

We used the following tools:

• A Project Card template,

• A map of stakeholders,

• Personas cards,

• A Customer Problem Solution canvas.

Second Day.

We started with drawing some sketches on paper and setting up first wire-frames. We analysed the basic User Flow on a whiteboard and put together some ideas. We tried to focus on the most important features, trying to find the one that was the app’s core functionality. We shared with our findings with the Client, and they agreed that we chose the right functionality.

We finished with a clear and practical solution. We also created mockups and a working prototype. Nonetheless, it required changes later, because the team did not understand some details and requests correctly.

Third Day.

We adjusted the mockups and the prototype. We made a strong design iteration after the Client’s feedback. Still, the design required corrections and adjustments after the Client tested it. For this reason, we decided to onboard the new Product Designer for a longer period in order to get fast design iterations and speed up the design phase.

What went well

• We shaped ideas better and found weak points.

• Having another designer gave us better control over the details.

• The team set better priorities.

• We were able to organise our team better.

• Design iterations went really fast.

What went bad

• We didn’t have enough time to make a Hi-Fi prototype for testing. It was one of the main goals of the sprint. The three days we had turned out not to be enough.

• We also didn’t have enough time to fully understand the specific needs of the Client due to the lack of feedback from the Client before starting the sprint.

• The fact that the Client was not fully present increased the likelihood of misunderstanding.

Conclusion

Product Design Sprint can be easily adapted to many circumstances. A strong scoping session before the Sprint can be really useful to make it more effective. Product Design Sprint can also be a really powerful tool for brainstorming and hammering out common solutions within the team. Even without the Client participating actively, PDS can strongly affect the team’s motivation and make all members understand the product’s goals and core features better.