Building the case for a product discovery design sprint
Previously, the team poured all their resources into building an idea in 2 months, only to have it discarded due to a lack of product-market fit. I proposed doing a design sprint to validate ideas in 1/6 of the original time spent, and with much less engineering resources.
I invited different departments to participate and understand the context of the problems from a user’s perspective, co-create our ideal solution and prototyped a minimum viable product to be tested with real users.
Workshop Kickoff
Many participants were participating in a design sprint for the first time. To get past the inertia for sketching and "designing", I came up with a quick game to ease the worries about “not being able to draw” with a game called "blindfolded charades" which builds their confidence in sketching ideas with simple lines and shapes.
Lightning sessions
I invited industry experts to talk about the problems and challenges liquidity providers faced, while the team jotted down ‘How Might We’ (HMW) notes to identify solutions, challenges, opportunities as the speakers talked through their problems.
Themes discovered
We identified problems and opportunities in the market based on the expert sharing
Themes discovered include: dealing with compliance risks, time-sensitive booking workflow, settlement workflow and ledger keeping. The team discussed the unknowns and voted to tackle a problem that hinges on the biggest assumptions that should be validated, and got to prototyping our solutions:
User testing
A key part of the design sprint is also involving other stakeholders directly in interpreting the user's feedback of the prototype. This spreadsheet allows everyone to glance and identify the most important feedback we had to work on for our next iteration.
Workshop takeaways
Advocate and educate early
Part of being a designer is involving others to be part of the process of designing, and to reframe the notion that design is something that is only the responsibility of a designer. I would try this on a smaller and more frequent scale by involving different stakeholders in smaller design discussions to warm them up to the idea of having a multi-disciplinary team come together to solve problems through design.
Prepare and plan with your team
The more people are involved earlier, the better the buy-in and involvement. Be specific about what you need their help with. It can range from defining the problem space, getting and setting up the workshop materials, to timekeeping for the session.
Scope appropriately
Be clear about what's not within the scope. This removes ambiguity and helps the team prioritise, identify opportunities and sketch solutions accordingly. Enterprise software products have big and complex features which makes it challenging to scope down. Identify the largest assumptions and validate those first.