01
The context
B2POS is the tool a shop assistant opens when a customer says “can I pay for this in instalments?”. Cart, credit calculator, customer data, scoring, bank offers, SMS signing. The whole thing happens at the counter with a person standing on the other side of it, often with a queue behind them.
That changes what good design means here. The user is not the customer, it is a retail employee on shift, on a cheap Android device or PC from 2018, who runs this flow forty times a day after an hour of training. Every second of hesitation is a second the customer spends reconsidering the purchase.
02
The problem
The original platform was built for the back office and then pushed into the shop. Three things followed from that.
It was slow where it hurt.
Median time to complete an application was around nine minutes. Interviews told us where the minutes went, and it was rarely typing (but also is, we implemented an init on finding second-time buyers to pull data from base). It was hesitation, going back to check, and re-entering data after a validation error dumped the form.
Assistants could not answer the customer.
Each partner bank has its own terms, downpayment rules and restrictions, and none of that was in the product. So the assistant guessed, or called support while the customer waited. Roughly a fifth of all tickets were not bugs, they were someone not understanding the process they were asked to run.
Every retail chain wanted it to look like theirs.
The platform is deployed across brands, and the visual system had drifted into one-off overrides that broke every release.
03
What I owned
Framing the problem, running the interviews, the design direction, the design system and its handoff to both web and mobile engineering, and deciding what we measured next. I work with the developers directly rather than throwing files over the wall, and the token libraries we ship are checked by hand, so the product is genuinely on one page.
04
Four decisions
01
Four brands, light and dark: eight themes instead of one
This is the decision I fought hardest for. Eight themes looks like indulgence when the backlog is full of features. The argument that won was operational: shop lighting is not neutral, and every brand deployment was piling up hardcoded overrides that slowed each release. The themes became the mechanism that stopped brand variation leaking into the codebase. One semantic token layer, eight exports, and nothing in the product references a raw colour.
02
More steps, not fewer
The instinct with a nine-minute form is to compress it. Interviews said the opposite: people move faster and make fewer errors through a long flow of simple steps than through a short flow of dense ones. One decision per screen means the assistant always knows what is asked and never loses work to an error further down. We added steps and the flow got faster.
03
The bank’s terms belong in the product
Instead of writing better support docs, we put each partner bank’s conditions at the moment the question arises: choosing an offer. Support tickets dropped 40%, and tickets about not understanding the process dropped 19%. That second number means the product explains itself now.
04
Designing the measurement
The analytics taxonomy was designed with the screens: event names tied to the app’s own routes, and a session id minted when the cart opens, reconciled with the application id once the customer is identified. Without that stitch, the cart and calculator were invisible, and that is where much of the hesitation lived.
05
Shipping it
We did not cut over. The new version rolled out alongside the old one, and 40% of the fleet, about 32,000 devices, is on it now. It is at v2.0.4, iterated through A/B tests and interviews rather than one big launch.
Each measurement is either a win or an instruction. The tests that did not move a metric told us which parts of the flow assistants were not struggling with, which is how the four decisions got their priority order.
06
Where it is now
Handoff runs as a pipeline, not a document. The same semantic layer ships as a CSS variables library for web and a Flutter theme for mobile, generated with AI assistance and reviewed by hand with the engineers who use it, so web and app cannot drift apart.
In flight: a platform-wide onboarding flow, a dashboard and navigation layer, and a companion mobile app in closed test with 12,000 partner users.
