Innovative problem-solving: Discovering by prototyping
As summer drew to a close last year, our Crisis and Emergency Response Product Team at the British Red Cross faced a challenge — our national and local partners lacked a centralised resource to discover the support we could offer during emergencies. Recognising this gap, we decided to take a Lean UX approach: skip the exploratory Discovery phase and jump straight into prototyping. This product was led by our Content Designer Juudit Breakey.
The decision to begin with a prototype might be controversial with traditional design thinkers, but it was grounded in our belief that Discovery is an ongoing process throughout a product’s lifecycle. We saw the prototype development as an opportunity not just to build a solution but to better define the problem and validate the proposed solution.
Our initial idea was a series of webpages to share with partners. However, assumptions began to surface. Did we collectively understand our offers? Was our offer standardised across regions? We quickly realised that nuances in offers, and regional differences needed attention. Starting from a prototype without a prior Discovery phase meant we had to adapt, collect insights, and validate them with our team, staff and partners.
Testing the prototype on Figma proved instrumental. Rapid feedback from users allowed us to iterate swiftly on UX, UI, and content presentation. Assumptions were tested, challenged, and refined in real time.
One assumption was that a single set of webpages would suffice. However, testing revealed that regional nuances, particularly in Northern Ireland, required individualised webpages for effective communication. Another crucial finding was the need for translation into Welsh to cater to our partners in Wales.
Starting with a prototype demanded more iteration than a Discovery phase might have, but it provided a tangible product for immediate user engagement and feedback. We showcased value quickly and learned if the solution met user needs; it was an efficient way to gauge feasibility.
While this approach may not suit every problem, it worked well for us due to a relatively low degree of ambiguity and uncertainty. We saved time, gained rich feedback, and navigated challenges by focusing on prototypes as tools to test hypotheses and uncover user needs.
In conclusion, our experience taught us when to opt for a prototype-first approach and when an exploratory Discovery phase is essential. It’s about keeping momentum and adapting to challenges in the prototyping phase. Starting with a minimal viable product allowed us to trial an idea quickly and adjust the course if needed.
Whether to start with a prototype or not depends on the problem at hand. For our team, it was a valuable lesson in innovation and problem-solving, paving the way for future products.
