A booking and ledger settlement system for Liquidity Providers

A booking and ledger settlement system for Liquidity Providers

Tags
Design sprint
User testing
Enterprise design
Web app
Product design
Public
Public

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.

My role

Facilitator, Designer, Researcher

The outcome

  • Building the culture of validating with users before building
  • Advocate for better research practices
  • Create shorter feedback loops to bring to the next iteration of the product idea

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.
Blindfold charades
Blindfold charades

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.
Questions to facilitate a lightning talk
Questions to facilitate a lightning talk
'How might we' post its
'How might we' post its

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:
Sketching ideas
Sketching ideas

User testing

User testing session
User testing session
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.
Collaborative user research insights and prioritisation matrix
Collaborative user research insights and prioritisation matrix

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.