VerifiMe

Every time someone opens a bank account, invests in a fund, or buys property — they verify their identity from scratch. Same documents, different forms, repeated friction. VerifiMe's premise: verify once, own that identity, share it when you need to.

The product had two sides — a consumer wallet where people store and control their verified identity, and an assessments portal for service providers requesting verification. I joined as the sole designer on a small founding team — CEO, a couple of engineers, and me — with no design process, no system, and product decisions being made daily.

The design philosophy that shaped everything

Early product focus was on the assessments portal — the B2B surface, the revenue driver. That made commercial sense. But it meant the consumer experience was being treated as secondary.

My view was different: VerifiMe needed to get out of customers' way. Most people would interact with the consumer side rarely — once to verify, occasionally to share. The product's job wasn't to be memorable. It was to be invisible enough that users could complete what their service provider needed, without friction or confusion, and move on. The portal would almost run itself if the consumer journey worked.

That reframe — from product as destination to product as infrastructure — shaped the three consumer-facing decisions below, and required some convincing to land.

The problems

1. The consumer journey had to get out of the way

Three connected problems, one underlying principle

The consumer side of VerifiMe had a straightforward job: let users verify and share their identity with as little friction as possible, then disappear. Time lags, authentication flows, and trust signals are impossible to simulate honestly in a prototype — so rather than polish a fiction, we launched with a small group of early customers who were willing to work through rough edges with us. Real signal, early, while it was still cheap to change.

The entry point wasn't trustworthy. A generic VerifiMe email asking users to hand over identity documents was raising suspicion, not confidence. The team's instinct was to improve the email. I argued it was the wrong mechanism entirely — and that we should replace it with provider-specific invite codes embedded in channels users already trusted. That was a bigger call than it sounds: it meant the service provider's channel, not VerifiMe's, became the onboarding surface. VerifiMe became infrastructure behind a familiar interaction rather than a brand asking for trust from cold.

Account creation was front-loading friction. Early customers made clear that requiring wallet setup before a first verification — before they'd experienced any reason to want one — was the wrong order. Making it optional raised legitimate concerns about data security and future re-engagement. I worked through those with the team, made the case, and once resolved the confirmation screen became a soft prompt rather than a gate. Users who saw the value opted in. Those who didn't, weren't blocked.

The sharing step was invisible. In a prototype, users can see what's coming — in the real product, context disappears. Users completed verification and stopped, waiting or trying to log back in, with no signal that there was still something to do. Sharing — the whole point of the product — felt like a separate task for later. Folding the permission grant into the verification confirmation screen fixed it: the product's value was present at the moment of completion, not surfaced afterward as a follow-up. One interaction instead of two. Drop-off and support requests both decreased significantly.

2. Entity verification couldn't be solved with better UX copy

95% error rate revealed a customer behaviour pattern, not a content problem

Verifying a trust, SMSF, or company — high value, lower volume, but essential for VerifiMe to serve a wider range of industries — involves multiple people across legal roles most users didn't fully understand.

Being new to the domain, I took the complexity at face value — this is just how entity verification works, and the job is to make the form clearer. That assumption was wrong, and it cost several rounds of iteration to find out. Each time I thought the updated labels or restructured flow would be the fix. Each time, 95% of submissions still came back incorrect.

It took setting aside the assumption entirely and asking a different question: not "how do we make this form better?" but "why are people failing at this regardless of how the form looks?"

The answer: most of these users hadn't set up the entity themselves — a lawyer or accountant had. They couldn't interpret the trust deed and weren't confident assigning roles they'd never had to think about. No interface change was going to bridge that gap. When they kept asking "can you just do it for me?" — that was both the problem and the answer.

I made the call to stop designing around a self-service assumption that didn't match how this customer type actually operated. Instead of another iteration on the form, we built internal tooling for VerifiMe staff to handle entity setup from source documents — absorbing the complexity where it could actually be managed, and removing it entirely from the customer experience.

That decision unlocked the financial services, legal, and property sectors — the industries where trust and SMSF structures are standard. It's why VerifiMe now serves customers across a wide range of industries.

Design system

On a small team shipping fast, a fragmented design system creates hidden costs — inconsistent components slow down engineers, and design decisions made in isolation compound quickly. A system that only a designer can interpret is a liability, not an asset. With the dev team already on Material Design, building on top was faster and kept the engineers in familiar territory. I owned the design tokens to carry the VerifiMe brand while keeping MUI component behaviours the team already knew. Documentation was written only for custom components; the Figma library was structured so wireframe and mockup files drew from the same token foundation — one source of truth, not two.

As the product grew, components drifted — status badges were the first to fragment across portals. Once identified, I audited and consolidated rather than let it accumulate. Consistency isn't just aesthetic; on a product built around trust, visual incoherence has a cost.

What the work added up to

The consumer journey, the entity verification pivot, the design system — these were separate problems that shared the same underlying logic: find where the product was asking too much of people, and change what was being asked rather than just how it was asked.

By the time my title changed to Head of Product & Design, that way of working had become the job. Roadmap decisions, backlog prioritisation, customer feedback synthesis — I'd been doing it for a while before it was formalised. On a small team, the designer closest to the customer and the product tends to become responsible for both. The title caught up.

Figma · Miro · Material UI · Maze