Order the POS-terminal

Ok, let`s go step-by-step…

Goals

I framed the work around three outcomes the business and the customer both needed:

• Collapse time-to-terminal. Replace the 56-hour, call-centre-dependent process with a self-serve digital flow a merchant could complete unaided across both the web app for sole traders and the mobile banking app.

• Turn rejection into a route forward. Work with the security department to replace silent declines with a transparent path: tell merchants exactly what’s needed and let them prove their business activity in-flow — eliminating the dead end driving the 60% drop-off.

• Fix the last mile. Let merchants choose how they receive the terminal — branch collection at a location of their choice, or delivery — to stop the 20% no-collection leakage.

Process

1. Discovery

I opened discovery by mapping the stakeholders and running interviews to identify the key open questions we needed answered before designing any digital onboarding — framing the problem space before committing to solutions.

From there, I put together all existing data we already had on the order-and-collection experience: feedback from branches, the contact centre, and social media. Mining what the organisation already knew, cheaply, before commissioning new research, identify patterns fast and pointed us at where to dig deeper.

I then ran a competitor analysis, identifying the strengths and weaknesses that genuinely mattered to our users rather than cataloguing features for their own sake — which is where the branch-choice and delivery expectations came sharply into focus.

Finally, I built Personas and validated the picture with both an online survey (quantitative) and in-depth interviews (qualitative), to pin down the real pain points and the priority areas for the product to grow into.

2. Synthesis & definition

To turn the research into something we could build, I mapped the Customer Journey Map end-to-end and the Service Blueprint.

It was the Service Blueprint that exposed the real root cause:
the silent rejections and the manual security checks lived behind the interface, in back-stage processes the customer never saw but always felt. Making those steps visible turned an invisible operational problem into a designable one and gave me the concrete basis to sit down with the security department and co-define the additional in-flow verification steps, plus a year-long automation roadmap. The Blueprint didn’t just document the service; it became the tool for changing it across team boundaries.

I then prioritised features with product manager using a Kano-style framework — Hygiene (must-have) / Performance / Nice-to-have — to make scope decisions: what had to ship for the flow to work at all, what would move the metrics, and what could wait. That gave the team a shared, defensible basis for the first release versus the roadmap, before we moved into prototyping.

3. Prototyping & testing

I prototyped directly in high fidelity in Figma, built on our design system, so what we tested was close to the real product experience, not an abstract wireframe, and findings translated straight into shippable UI. The flow went through three design versions as it sharpened.

Testing was iterative, not a one-off check: five rounds of usability testing, five participants each, sampled to cover the different personas.
Five users per round kept each cycle fast; five successive rounds gave us a genuine test → refine → retest loop, with each version validated against real behaviour before it moved forward.

The clearest example of testing changing the design was the business-classification step.
Users had to select their business-activity code (KVED) and activity type, but the codes are defined in law, some of them almost identically, and the list couldn’t be simplified at the data level. So users was frustrated: they’d stop, dig out their documents, and re-read options trying to work out which one was theirs. It was the single biggest point of friction in the flow.

I couldn’t change the regulated data, so I redesigned the path through it:

• Smart search so users could find their code by typing, instead of scrolling a dense legal list;

• Most-likely codes surfaced to the top, so the common cases were reachable immediately;

• The list grouped into business categories, turning a flat legal register into something navigable by how people actually think about their work.

Together these turned the flow’s worst bottleneck into a step users could move through without leaving to hunt for paperwork.