Reusable identity verification

Opening a bank account, investing in a fund or buying property each require identity verification. The same documents, a different form each time. VerifiMe was built to make it happen once.

The product had two sides. A consumer wallet where people hold and control their verified identity, and an assessments portal where service providers request verification.

Infrastructure, not destination

The original hypothesis was that customers would set up a wallet, verify once, and log in to share from then on.

Each of those steps points away from what the customer came to do. Nobody sets out to verify their identity. They set out to get a mortgage, or buy a house, or invest in a fund.

The product's job was not to be memorable. It was to be invisible enough that a customer could complete what their provider needed and move on. If the consumer journey worked, the provider portal would largely run itself.

That reframe shaped every decision below. It took some convincing.

Why we launched instead of prototyping further

Prototypes tested well and told us less than we needed. Time lags, authentication flows and trust signals cannot be simulated honestly. A participant in a session knows the email is fake.

So we launched to 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.

Everything below came from that group.

The entry point

Customers were not completing verification. A generic VerifiMe email asking people to hand over identity documents was raising suspicion rather than confidence.

The team wanted to improve the email. I argued the email was the wrong mechanism. It arrives from a company the customer has never heard of, asks for a passport, and comes days after the transaction it relates to. No subject line fixes that.

We replaced it with provider-specific codes, issued inside channels customers already trusted. The provider's channel became the onboarding surface rather than ours.

A code arriving inside a channel the customer already trusts does not need to earn trust from cold. Suspicion at the entry point stopped being the thing holding completion back.

The sharing step

Most early customers completed verification and stopped. They were not waiting or trying to log back in. There was no signal that anything remained to be done.

Sharing is the entire point of the product, and it had become a separate task for later. Most cases needed individual follow-up.

Folding the permission grant into the verification confirmation screen fixed it. The value arrived at the moment of completion rather than afterwards. One interaction instead of two.

The follow-up went away with it. Customers stopped needing to be chased to finish something they had already effectively done.

Balancing friction

Two decisions where the obvious design answer was wrong, in opposite directions.

Authentication: operability over novelty

Passkeys are slicker. They are also close to undiagnosable over the phone. When a customer cannot log in and a support agent has to talk them through it, the elegant mechanism is the one nobody can see into. MFA became primary and passkeys optional.

Setup: assurance over a quick win

Requiring wallet setup before a first verification was front-loading friction, and removing it was an obvious immediate win. But VerifiMe's proposition lives in the second visit. Remove the account and there is no second visit, only a quieter version of the same problem.

Making it optional also raised real concerns about data security and re-engagement. I worked through those with the team rather than around them. Before setup became optional we established that customer data was secure without a login, and that an account could be created later without re-entering everything.

Then the confirmation screen became a soft prompt instead of a gate. Customers who saw the value opted in. Those who did not were not blocked.

Entity verification

Verifying a trust, an SMSF or a company was low volume and high value, and necessary for VerifiMe to serve more than one industry. These transactions involve several people in roles most customers did not fully understand.

I assumed entity verification was hard because entity verification is hard, and that the job was making the form clearer.

Several rounds followed. Updated labels. Restructured flows. Clearer guidance. Then a working theory that the role descriptions themselves were the confusing part, and another round on those.

95% of submissions still came back incorrect.

The customers had not set up these entities. A lawyer or an accountant had, often years earlier. They were being handed a trust deed they had never read and asked to assign roles they had never considered. Several asked whether we could just do it for them. That question was the answer.

The task was unsuitable for the person being asked to do it, and no interface change addresses that. Entity verification moved into staff tooling, where someone who understood trust structures could do it properly.

This opened the segments where trusts and SMSF structures are standard.

Outcome

Five problems with the same shape underneath. Each time the product was asking too much of the person in front of it, and the answer was to change what was being asked rather than how it was worded.

My title changed to Head of Product & Design partway through. On a team that size, the designer closest to the customer ends up responsible for the product as well.