Implementation of discovery process in MyRaif

Built a discovery process from scratch at MyRaif.
Three phases — Discovery, Design, Usability Testing. Here's what we got wrong first, how co-design sessions changed everything, and why SUM became our single mandatory metric.

The Starting Point: Three Designers and a Clean Slate

At the outset, MyRaif was still finding its footing in terms of how design decisions should be made. Designers received tasks from PMs and focused on delivering the work. The questions why this task specifically and are we solving the right problem weren't really part of the conversation — not because anyone lacked the capability, but simply because the process hadn't yet made room for them.

I spent the first few weeks observing: what decisions were being made, and on what basis. The picture was fairly typical for an early-stage product — decisions shaped by assumptions, market benchmarks, and business intuition. That's a reasonable starting point. The question was how to build on it.

So the first decision I made was this: we build the discovery process in parallel with the very first feature work — not "later, once things settle down." The early-stage context gave us a rare advantage: the chance to establish the right habits from day one, rather than retraining a team after years of working differently.

Architecture: Three Phases of the Process

We explored various approaches and drew on double diamond and design sprint thinking. In the end, we arrived at a structure that matched our working rhythm — something the team could genuinely commit to, even under the pressures of a fast-moving product environment.

The process consists of three sequential phases, each with a clear input, output, and timebox.

Discovery

We understand the problem before touching a solution. The phase includes two types of interviews: with users and with stakeholders. The former give us a genuine understanding of real pain points and behaviour. The latter provide business context, constraints, and priorities — the sort of things you'd otherwise only discover halfway through the design work. In parallel, we analyse support data, behavioural analytics, and run quantitative reviews. The output of this phase is a clearly articulated problem statement, validated from both sides: the user's and the business's. We don't move forward until those two perspectives have been reconciled into a single problem statement.Optimize your UI with data-driven insights

AI tools like heatmaps and user session recordings can give you valuable insights into how users are interacting with your design. This allows you to refine your UI, improve usability, and make more data-informed decisions about layout, content placement, and navigation.

Design

We design solutions based on what we've learnt. One of the key tools of this phase is co-design sessions — we deliberately established them as a cultural norm within the team. Rather than a designer working in isolation to translate insights into solutions, co-design brings together designers, PMs, and occasionally business stakeholders: shared sketching, concept discussion, rapid direction-setting. This reduces the number of alignment iterations and significantly improves the quality of solutions — because different perspectives surface during the process rather than arriving as comments on a finished mockup. The output is a prototype ready for user testing.

Usability Testing

We validate the hypothesis with real people before handing anything over to development. Moderated sessions, think-aloud protocol, analysis of error patterns. Particularly important here is the evolution of our metrics: we started with a set of classic measures — time per task, error rate, task completion rate, and others. Over time, we realised that a large number of metrics made it harder to compare across sessions and diluted the focus. Today, the mandatory metric for every usability testing session is SUM — Single Usability Metric. It aggregates several dimensions into one figure and allows us to track progress clearly from iteration to iteration. The output is either a validated hypothesis or a return to the Design phase with concrete data. No task goes into development without completing this step.

That final condition — "no task goes into development without usability testing" — was non-negotiable. It was precisely what transformed the process from a recommendation into a genuine standard.

A process that only exists on a diagram isn't a process. A process is something the team has actually worked through at least once.

— what I tell anyone who asks me to help "design" a discovery process.

How It Played Out in Practice

In the first few months I personally led every phase alongside the team — not because I didn't trust the people, but because I wanted designers to see and feel the process from the inside. I moderated interviews together with them. I ran synthesis in pairs, thinking aloud about why some insights matter more than others. I tested prototypes and after each session we'd discuss what we'd observed and what it meant for the solution.

This was a deliberate strategy: to pass on understanding, not just a template. A template without the reasoning behind it tends to get applied mechanically — and that's when process stops serving the work.

In parallel, we built the infrastructure: a recruitment panel, standardised interview guides, a research readout format that PMs could read in ten minutes and grasp the essentials. Every designer needed to be capable of running the entire cycle independently — from recruitment through to synthesis.

Where we are now

The process is alive and continuing to change. We regularly review each phase together with the PMs — what's taking too long, where quality is being lost, where AI can help. Not "implemented and forgotten" — but constant, collaborative optimisation.