A developer console for an insurance-verification API, designed so a first successful request takes minutes and a failed one explains itself.
This is a self-initiated concept. The product, organisations and data are fictional; the design problems are real.
Role
End-to-end product design
Type
Self-initiated concept
Platform
Web console, dark UI
Focus
Onboarding, debugging, error design
Context
The problem and the bet
The problem
Integrating with insurers is slow and opaque: every insurer has quirks, errors are cryptic and outages look like your own bug. Teams lose days before their first useful response — and support teams lose hours debugging failures for customers.
The bet
If the console explains every response — what happened, whose problem it is, and what to do — developers ship faster and need support less.
How I’d validate it
Time-to-first-request tests with 5 developers new to the domain, plus a review of real support tickets to rank which errors cause the most confusion.
SK
Sam, backend engineer
Proto-persona · assumption-based, to validate
Goals
Ship coverage checks in a sprint, not a quarter
Handle every insurer response without special-casing each one
Frustrations
Errors that don’t say whether the bug is theirs or the insurer’s
Testing edge cases that only happen with real patients
Journey
Where the product steps in
Sign up→Test key06→First request01→Learn the API02→Edge cases04→Async results05→Debug in production03
Numbers refer to the chapters below. The hardest moments — first request, edge cases and failures — get the most design attention.
01 · Onboard
Get started
Get a developer from sign-up to a real, useful response in minutes.
1
Progress measured to the first live request
The checklist ends at “Go live”, not at “account created”. Activation is the moment a real response arrives.
2
A sandbox member for every edge case
Inactive coverage, unknown members and timeouts break integrations. Deterministic test IDs let developers reproduce each one on demand.
Considered insteadRandom mock data — realistic, but bugs can’t be reproduced.
3
Go-live blockers visible from day one
Compliance steps are the slowest part of launching. Showing them early avoids a surprise at the end.
02 · Learn
Playground
Teach the API through use instead of documentation.
1
Form and code stay in sync
Every field edit updates the snippet, so the playground produces working code to paste.
Considered insteadA separate docs page with static examples.
2
Two views of one response
A human summary for product decisions, raw JSON for implementation — neither audience has to translate.
3
Important flags pulled out of the JSON
Booleans like authorization_required change what the app must do next, so they’re surfaced as callouts.
03 · Debug
Request logs
Diagnose a failed request in seconds, without a support ticket.
1
Errors shown inside the volume chart
Spikes in 5xx are visible at a glance and tied to a time — usually the first clue.
2
Error types written for humans
payer_unavailable says more than “502”. The status code stays, but the type and a one-line explanation lead.
3
Whose fault, and is retrying safe?
The two questions every developer asks after a failure are answered first, with the idempotency guarantee stated.
Considered insteadLinking to a generic error-codes page.
04 · Depend
Insurer directory
Make 214 different insurers feel like one reliable API.
1
Status lives in the directory
Health is shown where developers choose and debug insurers, not on a status page they’d never check.
2
History, not just the current state
A 30-day strip shows whether an issue is a blip or a pattern — useful when deciding to build a fallback.
3
Every quirk says who handles it
“Handled by Kestrel”, “you handle” or “heads-up”: developers know exactly which differences they still need to code for.
05 · Integrate
Webhooks
Make async results trustworthy, even when the developer’s server fails.
1
Failing endpoints flagged in the list
A red dot and “failing since 13:44” surface problems before customers notice missing results.
2
The retry schedule is visible
Each attempt, the response the server returned and the next try are shown — and can be resent manually.
Considered insteadA single “failed” status with no attempt history.
3
Secret rotation with an overlap window
The old secret stays valid for 24 h, so teams can rotate without downtime.
06 · Secure
API keys
Protect live credentials without slowing developers down.
1
Shown once, copy first
The full key appears only at creation, with copy as the primary action. It can be rotated, never recovered.
2
Friction exactly where it matters
“Done” unlocks only after confirming the key is stored — one click that prevents the most common support request.
Considered insteadA warning text only — easy to skip.
3
Proactive key hygiene
Unused keys are flagged with a one-click revoke, turning a best practice into a default.
Trust
States & edge cases
In a developer tool, errors are the product. Each one answers what happened, whose problem it is, and what to do next — in the UI and in the JSON.
System
Rules behind the interface
Small, explicit rules keep a dense interface consistent as it grows.
Colour encodes responsibility
Green = success. Amber = your request or account. Red = the insurer or our infrastructure.
2xx · 4xx · 5xx
Machine values are monospace
IDs, keys, codes and JSON can be scanned, compared and copied without ambiguity.
req_9Tz4Kp
Every summary has a raw twin
Summaries never replace the data: exact JSON, headers or attempts are always one step away.
Summary · JSON · Headers
Outcome
Measuring it, and what’s next
As a concept, this has no live numbers — so here is what I would measure and test first.
How I’d measure success
Time to first successful request
Test → live key conversion
Failed requests resolved without a support ticket
Webhook delivery success after 24 h
What I’d test next
Do developers copy code from the playground or from docs?
Comprehension of “whose fault” labels on real errors
Which insurer quirks cause the most integration bugs
Does the “I’ve stored this key” step reduce key resets?
