What this prompt does
This prompt makes the AI act as a senior product engineer specifying a regulated KYC onboarding flow, and it asks for working component code rather than pseudocode. It lays out five build steps plus a status screen: country and ID-type selection, ID front/back capture with glare and blur detection, a selfie liveness check, address details with proof-of-address upload, and a review-and-submit screen. The [id_types] placeholder constrains which documents the first step offers, and [provider] names the verification service the liveness step is wired to.
The structure works because KYC drop-off concentrates at failure points, and the prompt forces those into the design from the start. The status screen must handle pending, approved, and failed, with a clear reason and a retry path, so a rejection becomes recoverable instead of a dead end. The [stack] variable keeps the generated component files aligned with your framework, and the requested state-machine note documents how transitions between steps and statuses actually flow. Because each capture step carries its own guide frame, glare/blur detection, and retake affordance, the spec accounts for the messy real-world conditions, like poor lighting or a blurry document photo, that derail verification in production rather than in a clean demo.
When to use it
- Building KYC or identity verification for a regulated fintech product
- Integrating a provider like the one named in
[provider]and needing the UI around it - You need a clear failed-verification recovery path designed before styling
- Supporting a specific set of documents via
[id_types] - Mapping the step-to-step state machine for a multi-step onboarding flow
- Generating component files in a known
[stack]rather than abstract UX notes
Example output
You get step component files, one per onboarding step, plus a short state-machine note describing transitions between steps and between the pending, approved, and failed statuses. The capture steps include the live guide frame, glare/blur detection, and retake affordances; the status screen spells out each status with its reason and retry path. It is structured to drop into a real project rather than to be admired as a mockup.
Pro tips
- Fill
[id_types]with exactly the documents you accept; it drives the eligibility messaging in step one - Set
[provider]to your real liveness vendor so the selfie step is wired to the correct integration points - Push hardest on the failed status: ask the model to expand the reason copy and retry path, since that is where verified users are lost
- Keep
[stack]accurate so the component files match your framework's conventions - If the state-machine note is thin, ask for an explicit transition table covering every status
- Request that step five show exactly what data gets submitted; transparency at submit reduces abandonment
