What Matters Most, Protected.
PROJECT OVERVIEW
Payment not confirmed
Designing the one state an insurance app is most tempted to lie about.
A life-insurance concept solving payment uncertainty: when a customer pays but receives no final bank status, neither the customer nor insurer knows whether funds were transferred. Presented to Standard Life in 2022, it became the foundation for the real application built on the same payment model.
Problem
An unresolved bank response can read as success, or invite a second payment. Either can cause serious, potentially irreversible harm.
Decision
Make the unresolved payment a first-class product state, and remove the repeat action rather than make it safer.
Evidence
Of six moderated participants, none read the revised pending state as success and none attempted a second payment.
Outcome
The concept opened an engagement with Standard Life; the application is being built on the same payment model.
Unresolved
Payment submitted, no final answer from the bank, policy not active. Right: bank confirmed, policy issued. The product is never allowed to blur these two. Everything below explains why the left screen was the hardest thing in the project — and what it took to carry that rule across ninety more screens.
What this is, and what it is not
SCOPERole
Product designer, sole designer on the concept: research design, product logic, interaction, visual, design system, prototype, engineering handoff. On the client engagement that followed: product design — states, content contract, payment model, developer handoff.
Decision
Forty-nine screens in English and Russian, a dependency-free functional prototype, a state and content matrix, a payment state machine, a token seed. Presented to Standard Life, an operating life insurer in Kazakhstan. The argument of this page is built here.
Evidence
What the concept opened: seven Kazakh-language flows, about ninety hi-fi screens, platform and accessibility variants, a Term Life product line with its own research rounds. The craft of this page is shown from here, with its own evidence and its own limits, and nothing from it is presented as launched.
Outcome
July – September 2022
Everything after this line separates observation, recovered signal, hypothesis and modelled effect rather than presenting them with the same confidence.
The quote exists. The purchase does not.
Digital calculators create confidence faster than they create commitment. A price appears, the customer treats it as final, and then a manager, a paper form and an office visit arrive to renegotiate it. Meanwhile exclusions — the part that determines whether a payout will ever happen — live inside documents the customer never opens before signing.
A customer can calculate a life-insurance premium online in minutes and then discover the journey ends with a phone call.
Three failures the category repeats
FAILURE
WHY IT MISLEADS
IN THIS PROJECT
The price looks final before it can be
An anonymous estimate is computed before identity and health are known. Presented in the visual language of a real offer, every later correction reads as a bait-and-switch.
Exclusions are structurally invisible
They are the mechanism by which a claim gets refused, and they usually appear as a link inside a signing step where nobody reads anything.
An unresolved payment looks like a completed one
Render "processing" with the vocabulary of success and the customer leaves believing they are covered. Offer "try again" and the customer pays twice. This is the failure with an irreversible cost.
ESTIMATE → OFFER
The verified offer states the delta from the estimate next to the verified price instead of replacing it silently.
EXCLUSIONS IN THE OPEN
The coverage summary is deliberately not a form: nothing on it can be tapped by mistake, and real exclusions never sit in the same list as illustrative examples.
Certainty about a price grows faster than the reliability of that price.
Designing against unanswered questions
The interesting constraint was not complexity. It was that the people who could resolve the ambiguity were not available to resolve it.
01
NO OWNERNo owner of the truth
Asked which systems hold the contract’s status, the answer was “all of them” — no single API contract, no synchronicity guarantee, no named owner of the record. Until one exists, elegant status synchronisation is fiction, so the design had to assume the status could be wrong and stay safe anyway.
02
NO BASELINENo price on the problem
Preventing a duplicate charge has a computable value — blocked repeat attempts × probability of a second debit × average premium, plus avoided support contacts × their cost. Every input was empty. So I specified how it would be measured instead: twenty-one named events, ten outcome metrics, five guardrails, and a failure condition written before build.
03
NO COMPLIANCE OWNERTen steps stayed ten steps
The flow is longer than I would want to ship, and every step carries either a regulatory obligation or a comprehension risk I could not merge away without someone empowered to say what may legally be combined. I preferred an extra step to an assumption about the law.
04
OPEN QUESTIONNo horizon for a multi-day pending
The specification names a reconciliation expiry; the interface shows only the next automatic check. What a customer should be told at hour 72 is written down and not answered — one of six questions in the technical review now out with a payments engineer, tracked in the appendix.
An invented percentage would make this case weaker, not stronger. A named measurement plan with empty cells is the honest version of business impact for unlaunched work.
03 · THE CORE OF THE PROJECT Pending is not a slow success. It is an unknown.
The simplest interface would show a spinner and a “try again” button. Both are wrong, and one of them is expensive.
When a bank response does not arrive, the interface still has to say something. Optimism is cheap — show a checkmark, keep the flow moving — and so is helpfulness: offer to retry. The first creates a customer who believes they are insured and is not. The second creates a second debit.
I removed the repeat action rather than making it safer. Visual simplicity does not justify the risk of a second charge. From an unresolved state the customer may only read the status of the attempt that already exists. A new attempt becomes available after a terminal failure or an explicit expiry — never on the customer’s guess.
What removing one button actually cost
To make that refusal safe, the state had to be specified at the level of write authority.
PAYMENT STATE MACHINE
no answer
Terminal states · who writes them
01
WRITE AUTHORITY
The app never writes the outcome
SUCCESS and FAILED are written only by the callback handler, after signature verification, merchant binding and matching intent, amount, currency and bank reference.
02
REMOVED BY DESIGN
The customer may read, not retry
From PENDING the customer may only read the attempt that already exists. Try again was removed — a guess must never create a second debit.
GUARANTEES
Three guarantees the state machine has to keep
Read only
Core rule“Check status” is a read and a reconciliation trigger. It cannot write success, and pressing it can never produce a policy.
One attempt
Concurrency CREATED, SUBMITTED and PENDING
all block creation of another attempt for the same payment
intent. A timeout or transport retry reuses the same idempotency key and
returns the existing attempt.
One verified success
Write authority SUCCESS may only be written by the callback handler,
after signature verification, merchant binding and matching intent,
amount, currency and bank reference. Event IDs are unique, replay is a
no-op, and a late callback cannot downgrade a success. Policy
activation consumes exactly one verified success event.
What survives an interruption
Every attempt carries a stable record — payment intent, idempotency key, attempt ID, application ID, amount, created time, status, bank reference, last check and next check. Closing the app and returning restores the same attempt with the same identity, never an inferred success.
What the customer keeps
Reading the status of the attempt that exists, contacting support with its identifier, and leaving. Agency was not removed; one irreversible action was.
Four states that test the system
The main path is the easy part. A product is judged on the states around it. Each of these keeps the same header, the same column and the same dock as the screen it stands in for, so nobody is dropped into a different-looking product at the worst moment. Colour follows meaning: amber while an outcome is still open, forest once it is confirmed, and no state colour at all when the outcome is known and nothing has gone wrong.
EXPIRED
Expired offer — selections kept, signature and payment refused on a stale price. The outcome is settled, so no state colour is warranted; the forest panel here is the same confirmed surface named in the anatomy above.
CLIENT-SIDE
Document load error — the policy context survives the failure.
EMPTY
No policies yet — one action, no decoration.
CONFIRMED
Active policies — status, cover and next payment on every row.
Expired, failed, empty and active, from the concept set. The payment states of the same product — checking, refreshing, unchanged after a check, no connection, escalated to support, confirmed, failed — are seven more screens on the same grid.
Twelve screens,one grammar
Individual screens can be made to look good. A flow shows whether the system holds. The purchase path as built for the engagement, in Kazakh, on a 393-point frame. Every screen shares the same header with step and progress, a 24-point margin, a 345-point content column and a 56-point action dock. Nothing is centred that does not need to be.
06 · The flow, whole
01 Entry · saved application offered first
03 Preliminary · named as such
05 Participants · beneficiary is a person
02 Calculate · age and cover only
04 Coverage · exclusions separate
06 Health · nothing preselected
07 Verified offer · documents before signature
08A SMS code · one document, one code
10 Under check · the screen from the top of the page
08 Review · signing does not pay
09 Payment · submit once
11 Issued · forest, at last
Quote Application Signature Payment7
flows at hi-fi: purchase, manual underwriting, payment unknown, grace and restoration, death claim, maturity payout, appeal
engagement design file
≈90
hi-fi screens on one 393 × 852 frame, plus 14 platform and accessibility variants
Figma, seven flow pages
49
concept screens in the earlier English/Russian set, including the seven payment states above
concept screen inventory
The purchase path in Kazakh. Eleven more states sit beside these twelve in the same file — saved draft, delete draft, delete confirmed, guarantees and surrender amounts, full terms before signature, bank transfer as an alternative rail, support.
Why the unresolved screen is built the way it is
Measured from the source frame, not described from memory. Including the places where it is not yet right.
grid
393 × 852, 24-point margins, 345-point column. Every hi-fi screen in the file sits on this; the earlier low-fi generation used 390 × 844 with 32-point margins, and the two are never mixed on one page.
order
Header → status → record → recovery → action. The reading order is the argument: what step you are on, what is unknown, which attempt this is, what survived the relaunch, and the only thing you can do. The localized screen-reader announcements are drafted in the same sequence; they have not been tested in a native build, and the page says so below.
colour
Amber border, amber wash, ink text. The panel deliberately does not resemble the forest confirmation two screens later. Status is never colour alone — the headline says “not confirmed” and the panel says “unknown whether the money was debited”. Defect, being fixed in Figma: the icon plates in the attempt record and the restored-attempt note are forest — the colour that means confirmed.
type
Headline 30/38 semibold, −1.5 tracking. Panel title 20/28. Secondary and subhead 14/20. Caption 12/16. Four sizes, one family, all from the file’s named text styles (Display, Section, Secondary, Subhead, Caption Strong) — nothing on this screen is a detached size.
rhythm
Section gaps 24 · 15 · 15 · 12; inner gaps 13 · 59 · 9 · 29 · 6. Measured, not designed: the screen holds together because its containers are strong, not because its vertical rhythm is systematic. The spacing pass against the declared scale is in the backlog.
targets
Back and help 48 × 48; the list rows 52; icon plates 42 inside them; the dock action 56. The 44-point minimum holds for every control that carries the flow. It does not hold for the two text actions at the foot — “Get support” and “Return home” are drawn at 32 and 16 points and need their tap areas extended in build.
progress
“Step 9 of 10” — the label carries the data. The bar does not: its fill is drawn in a lighter colour than the track beneath it, so it reads as an empty bar with a dark end, whatever the step. A decorative indicator dressed as a data one. The fix is a fill tied to the step value in the header component’s fifty variants; it is open in the audit, not done.
A screen is not finished when it looks right. It is finished when the measurements agree with the rules it claims to follow. This one is close, and the gap is written down.
Components know meanings, not colours
Tokens are structured in three layers — primitive, semantic, component — in the W3C design-token format, with a CSS handoff. Product components are not permitted to reference primitives. They consume semantic or component tokens, which is what makes the state contract survive a rebrand: change the amber, and every unresolved state in the product moves with it, correctly.
PRIMITIVE · holds the value
SEMANTIC · holds the meaning
COMPONENT · consumes the meaning
Status panel
One component, three semantic variants — warning, confirmed, terminal. The warning variant may never borrow the confirmed variant’s surface, which is the whole rule the product is built on.
Action dock
One 345-point primary, or 112 + 225 when a secondary is present. The 112-point secondary clips the Kazakh “Қолдау”: a Latin-width assumption that survived into a Kazakh-first product.
Journey header
Fifty variants for step-of-total across seven flow lengths, so the step is never typed by hand. The label carries the number; the bar beside it does not, which is the defect named above.
Dark theme: a primitive swap, checked honestly
The coverage summary in both themes exposed an inconsistency: the dark frame had lost the step number and “illustrative examples” disclaimer, proving it was repainted rather than token-swapped. The pair is now re-exported from one source using two primitive sets and shown as a system test, not proof of success. It also revealed that white text on the lighter dark-theme green has only 2.57:1 contrast, so primary-action text became a semantic on-action token instead of hardcoded white.
Kazakh is the stress test the layout has to pass first
Kazakh runs twenty to forty percent longer than Russian for the same idea, and the words do not break where Latin words break. Every layout in this project was drafted against the longest string in the set, not the shortest one.
The three screens below are the Kazakh originals. Nothing was shortened to make them fit — the rules changed instead.
04 · ҚАМТУ
Six coverage rows, each with a Kazakh label longer than its Russian equivalent. The row height is set by the label, never the other way round.
07 · РАСТАЛҒАН ОФЕРТА
The premium is a token on its own line, so the sentence around it can grow without pushing the number out of view.
08B · ШАРТТАР ОҚЫЛДЫ
The consent block is the longest string in the product. It sets the minimum width of every card in the flow.
STRING UNDER TEST
CONTENT
RULE IT FORCED
Payment recovery body · KZ
Төлем расталмады. Банк жауабын күтіп тұрмыз — бұл 30 минутқа дейін созылуы мүмкін.
Status body wraps to three lines. The card height is never fixed, and the action never moves up to meet it.
Claim start title · KZ
Сақтандыру жағдайы бойынша өтініш беру
Titles are two lines by design at 28/34. Nothing is truncated, and nothing is abbreviated to fit.
Upload action · KZ / RU / EN
Құжаттарды жүктеу · Загрузить документы · Upload documents
Buttons hug their label and stack vertically below 360 pt instead of shrinking the type.
Calculator disclosure · RU
Расчёт носит иллюстративный характер и не является офертой.
Disclosure sits above the action, not under it, at 13/18 — read before the tap, not after.
None of these rules came from a style guide. Each one came from a string that broke a screen.
Accessibility as craft, not as a checklist
Two hundred percent type and a 320-point screen are not edge cases in this market — they are an ordinary Tuesday. Every variant below is built from the same primitives as the default screen. No separate layout, no shortened copy, no second source of truth.
IOS · DYNAMIC TYPE 200 %
At 200 % the offer card stops behaving like a card. It becomes a scrolling document with the amount pinned as the first line, because the amount is a token, not a phrase.
IOS · 320 COMPACT
At 320 pt the two-column premium summary collapses to one column. The order of information is identical — only the number of columns is allowed to change.
ANDROID · LARGE TEXT 200 %
Android large text plus a system font swap. The money line survives on one line because it was never part of the sentence around it.
SEVEN SCREENS · ONE GRAMMAR · KAZAKH THROUGHOUT
The design contract is short. Nothing is a fixed height, nothing is centred by pixel, and no number ever lives inside a sentence. Those three rules survive translation, they survive 200 % type, and they survive a 320-point screen. Everything else in the system is negotiable.
54
STRINGS
tested at their longest Kazakh form before any screen was called finished
320
POINTS
the narrowest supported width — the layout is drafted here first, not last
1
SEPARATE LAYOUT
the number of screens that needed one. It is the claim flow, and it is documented
Four levels of confidence, kept apart
Not every claim in this case study carries the same weight. Mixing them together would be the easiest way to overstate the work, so each one is labelled by where it came from — and the labels are never merged.
LEVEL
WHAT IT COVERS
HOW IT MAY BE STATED
Eleven participants across Kazakh and Russian, working on their own devices, on tasks they were not coached through.
Stated as a finding, always with the number of people it came from attached to it.
Screen order, field order, validation rules and error copy taken from the live product as it exists today.
Stated as fact about the current product, with the date it was read.
Server guarantees, state names, retry windows, idempotency keys and what the client is never allowed to assume.
Stated as a contract the client design depends on — not as something I verified in production.
Everything else: hierarchy, tone of voice, motion, the shape of the dark theme, the anatomy of a card.
Stated as an argument, in the first person, and open to being disagreed with.
KNOWN BIAS
I recruited through my own network, so the sample skews urban and skews toward people who already hold a policy of some kind. Nobody in it failed to read at all. What follows is true of the people I sat with — it is not a claim about the market.
FINDING
DESIGN RESPONSE
RESULT
F-01
Eight of eleven read “pending” as “failed” and moved to pay a second time.
Pending became a named state with its own screen, an explicit wait window, and no retry button anywhere on it.
Zero duplicate payment attempts in the retest.
F-02
The indicative premium was read as the final one.
The indicative amount is separated from the confirmed amount and carries its own label and its own colour.
All seven retest participants named the amount correctly.
F-03
Kazakh consent copy overflowed the sign card on three devices.
The consent block now sets the minimum card width for the whole flow, rather than being fitted into it.
No overflow across the tested device set.
F-04
Nobody found the saved application after leaving the flow.
The saved application is offered first on the entry screen, with the date it was left.
Six of six resumed without help in the retest.
What the engagement added: the second half of the life cycle
The original brief ended at the signature. Everything after it had no screens, no copy and no failure modes — the product simply assumed it worked. Half of this project is that missing half: what the app says while money is in flight, what it says when a bank goes quiet, and what it says on the day the policy is finally live.
11
PARTICIPANTS
Moderated sessions in Kazakh and Russian, on the participants’ own phones.
8
SESSIONS RE-RUN
The same tasks repeated against the revised flow after the changes landed.
27 · 21 · 6 · 0
SCREENS · STATES · ERRORS · SHIPPED
What the file contains, and what it has not yet become.
HOW TO READ THESE THREE NUMBERS
Eleven is a sample, not a study. Eight is a retest, not a control group. And the last row counts artefacts, not outcomes — nothing here has shipped, so no number in this case study describes a product in the market.
The most useful thing testing gave me was not a list of fixes. It was permission to stop guessing which half of the flow mattered.
A concept is an argument. This one was accepted — and here is what it does not prove.
The concept was reviewed by the product team and accepted as the direction for the mobile purchase and service flow. That is a real outcome, and it is also a limited one: an accepted concept is a decision to build, not evidence that the thing works. What follows is the honest boundary of what this case study can claim.
Evidence
Eleven moderated sessions and one retest. That is enough to find where a flow breaks. It is not enough to say how often it breaks, for whom, or by how much. There is no conversion number anywhere in this case study, because none has been measured.
Server guarantees
The payment states, retry windows and idempotency rules were agreed with engineering and designed against. They were not observed under production load. If the server behaves differently, several screens here are wrong in a way I would only learn from real traffic.
Review
Accepted as a direction is not accepted as a release. Legal wording, actuarial disclosure and regulatory copy sit in the file as placeholders of the correct shape and length. All of it will change before anything ships.
APPENDIX · FULL SESSION NOTES, THE UNTRANSLATED KAZAKH STRINGS AND THE STATE-MACHINE CONTRACT ARE AVAILABLE ON REQUEST
Three things I would do differently
01
TEST THE SECOND HALF FIRST
I designed the purchase flow before I tested the waiting states — and the waiting states turned out to be where the trust was actually lost.
02
WRITE THE FAILURE COPY FIRST
Every screen I had to retrofit an error message into was a screen I had designed slightly too tightly for the message it needed.
03
BUILD DARK FROM THE TOKENS
Repainting the dark theme afterwards hid an inconsistency for two weeks. It is the one documented earlier in this study.
The screen is not the product. The promise is. The screen is only the part of the promise you can look at.