ID2GO
A self-serve identity channel, built in two weeks
When we got ambitious, the job was choosing what could wait.
YEAR
2026
COMPANY
Verimi
Status
Shipped - live 15 June 2026
0→1
B2B self-serve
Identity verification
KYC
Severity triage
MVP scoping
Measurement design
Two-week sprint
WHAT
Self-serve web shop: business partners buy identity-verification links and send them to end users — no sales call, no integration project
INDUSTRY
B2B identity verification · KYC
Role
Senior Product Designer — and the team's product memory: platform constraints, provider cost model, flow decisions
Team
Product lead, PO, architect, backend and frontend engineers, one designer (me) with working students supporting, legal counsel
TIMeline
Two-week sprint · live 15 June 2026
Key decisions
Reframed the sprint from "the right shop" to "the fastest path to feedback" · owned the pre-launch severity triage across four reviewers · forced a fix-or-accept binary on legal findings
result
Shipped in two weeks with every blocking legal finding fixed or formally risk-accepted · designed the 90-day success metric (repurchase intent, redemption rate) with kill criteria agreed before launch
Shipped on deadline with all blocking findings resolved · post-launch measurement frame with pre-committed kill criteria
Situation
A B2B identity company selling verification to business partners. The idea: a self-serve web shop where a partner buys verification links and sends them to end users — no sales call, no integration project. The sprint: two weeks, a hard deadline, a commodity e-commerce platform (Shopify) nobody on the team had used, and no validated assumptions behind any of it. Officially I was the designer. In practice I was the team’s product memory: I knew the platform constraints, the provider cost model, and the flow decisions from the wider identity programme, because I had worked on all three.
The idea in one line: a partner buys a verification link, sends it to their user, the user verifies, the partner gets the result.
Two weeks of assumptions, one goal: feedback
Mid-sprint, a planning session drifted into searching for the optimal solution — the right architecture, the right edge-case handling, the complete version. I stopped it. Everything we were building rested on assumptions, not validated needs. The goal was not the right shop. It was the fastest path to feedback that could tell us what the right shop would be. The product lead’s response: I even forget this myself sometimes. She repeated the point to the group, and it held for the rest of the sprint.
That reframe did more than any screen I designed. It is also why the sprint hit its date.
One example of the product memory at work: failed verifications carried a provider cost we could not pass on. That constraint — invisible to the sprint team — shaped how we priced the link validity window and what we accepted on our side.
ID2GO touched three actors and a full verification chain — I was the one person who held all of it.
Pre-launch feedback: transcribe it, or assess it
Before launch, feedback arrived from three managers plus legal counsel — UX, copy, legal, visual, technical, across the whole flow. Mixed severity, mixed quality. Two ways to handle it.
Transcribe — take reviewer labels as given, fix top-down. Fast and politically safe, but severity reflects the seniority of the reviewer, not the risk to the product.
Assess — apply my own severity model and own the prioritisation in writing. Slower, and exposed: if I downgraded a manager’s finding and it blew up, that was on me.
I took the second. I built a triage matrix organised by area and screen, rated every finding against three axes — impact on legal standing, product quality, and partner trust — and labelled the document explicitly as my professional assessment, not a comment log. When one page received a blanket blocker from a senior stakeholder, I added a priority flag on the page instead of upgrading every individual finding. Severity stayed consistent across the document, which is the only thing that makes a severity rating worth anything.
Part of the triage was separating severity from scope: some findings described defects, others described a bigger product. Both were legitimate — but only one category could block a two-week launch.
Legal findings: fix now, or accept in writing
Inside the triage, one pattern stood out: every legal finding carried the same middle rating. For a product handling identity data, a uniform middle rating is not a safe middle ground. It defers the decision without anyone owning it — neither fix now nor accepted risk.
I pushed for a binary per legal item: fixed before go-live, or accepted with written rationale and a documented mitigation plan. The binary happened. Legal items, copy, and graphics were resolved before the 15 June launch.
Triage matrix: areas (UX, Legal, Copy, Visual, Technical) by severity, findings as dots, legal findings accented on one middle row. Centerpiece.
Ownership on paper
The Head of Design confirmed I should lead the feedback response. I put the ownership on paper — the assessment note in the document said the prioritisation was mine — so that the accountability was explicit rather than implied. That mattered: a triage nobody owns is a list; a triage someone owns is a decision.
The triage wasn't a one-off for this launch. It's a reusable severity system — findings by area × risk, prioritisation owned in writing — that any team can run the next time mixed feedback has to become launch decisions. That's the pattern in my work: I don't just design the screen, I design the thing the team decides with.
What shipped — and how we would know it worked
ID2GO shipped on 15 June 2026, on the two-week deadline, with the pre-launch findings resolved. I also built hands-on: the front-end customisation (Shopify Liquid / CSS) for the cart and buy flow, working directly in the theme.
Post-launch, I set up the measurement frame rather than a verdict: repurchase intent as the north star, profit per order, and link redemption rate as the hidden killer — revenue can look healthy while partners get zero value because links never get redeemed. A 90-day review gate with pre-committed kill criteria, agreed before anyone’s reputation was attached to the numbers. I also redesigned the partner feedback survey around decision-relevant data: a rating grid per dimension instead of mirrored like/dislike lists, and a final demand-sensing question that turned a generic comment box into roadmap input from the exact people who would buy next.
What I can stand behind here isn't a conversion figure — it's delivery under a two-week constraint with every blocking legal finding resolved, and a measurement system installed to judge the shop honestly. A full post-launch read wasn't reached before the company wound down. Figures generalised for confidentiality.
Survey before/after, small, optional.
The cart and buy flow — front-end I built directly in the Shopify theme (Liquid/CSS).
What I’d do differently
My first brief to a working student supporting the sprint was: think it through yourself. The output was poor, and that was the brief’s fault, not hers. The second brief was structured — concrete feedback, specific instructions — and the work was strong. I lost a day learning that delegation under time pressure needs more structure, not less. I would write the first brief the way I wrote the second.
In one sentence
Under a two-week deadline, the value wasn't the shop — it was the judgment about what could wait, and the decision system I left the team to run.