Prepare before capture
The interface explains lighting, positioning, and privacy expectations before the camera opens, then removes competing information during capture.
Past client work · enterprise UX
Enterprise KYC Platform
I designed the customer verification journey and the tools for configuring checks and reviewing evidence.
Project snapshot
- Role
- Product Designer / UX Designer
- Scope
- Mobile KYC SDK, policy builder, compliance review
- Contribution
- User flows, interaction design, prototypes, UI, developer handoff
- Collaboration
- Product management and engineering
My contribution was the experience design: translating verification requirements into understandable steps, defining how choices and recovery affect the journey, and carrying those decisions into interface designs and prototypes for engineering handoff. This case study focuses on that design work, rather than the underlying identity-checking technology.
Completed product design work. The interactive walkthrough is a portfolio reconstruction of the browser-based flow, not the live verification service.
Design framework
Make every handoff visible.
The design brief: make the next action clear without hiding the requirements or the evidence behind it.
Customer
I made capture, review and retry visible so people know what to do next.
Policy owner
I separated required checks from the way they are presented to the customer.
Reviewer
I connected each result to the document and check history that support it.
Prepare people before asking them to capture.
The customer had to complete unfamiliar, high-stakes tasks on a mobile device. My design response was to move guidance before each capture moment, keep the active camera state focused, and make document requirements explicit before upload.
Make document quality visible
I placed guidance before the scan and a quality checkpoint before submission. The review screen presents readability and glare criteria so customers can inspect their document before continuing; it does not ask them to interpret an unexplained error after submission.
Bound the proof-of-address choice
I made the supported submission methods explicit. Camera capture suits a paper document; upload supports an existing file. Keeping both routes adds states to design and implement, but avoids forcing every customer through the camera regardless of what they already have.
Optional walkthrough / Browser-based verification
Explore the verification journey.
One process, different ways through it. Follow the original mobile screens, change the document route, and see how guidance, review and the return to desktop fit together.
Liveness
Set people up for a successful scan.
Before opening the camera, the screen explains lighting, background and what must remain visible: the head and neck.
Screen 1 of 17
Why this matters
Preparation turns an unfamiliar biometric task into a small set of understandable actions.
The source shows the control, but not its return connector. This replay illustrates a possible return to capture.
Meanwhile, on desktop
Read-only walkthrough. No camera access, file uploads or identity processing. Use the controls outside the source image to explore.
All screens on this route Passport / photo / address upload
The evidence changes the route.
A passport requires one capture sequence. A two-sided ID introduces a second instruction and camera step, or two upload fields.
Confirmation is a design decision.
Document data review offers rescan. The photographed address document offers retry. Both make correction visible before continuing.
The phone is not the whole service.
The desktop waits during mobile capture. The final instruction explicitly returns the person to that original context.
Source coverage and interpretation
A separate browser-based flow, shown with original design screens and an interactive portfolio presentation. The SDK examples above demonstrate the mobile interface approach; they are not consecutive screens in this route.
The PDF documents liveness, four first-document routes, two address routes and the mobile ending. It does not expand second/third documents, a driving-licence-specific route, rejection states, retry limits or skip rules. The rescan/retry replays illustrate return wiring; the controls themselves are present in the source. Some camera mockups reuse sample card imagery across document routes. Motion, navigation, chapter labels and desktop context are portfolio presentation layers, not claims of shipped behavior.
KYC means Know Your Customer. Liveness checks whether a live person is present; proof of address supports the stated address. Completing a capture or upload is not the same as approval.
Earlier prevention & recovery model Conceptual decision trees, separate from the PDF walkthrough
Prevention & recovery
From uncertainty to a next step.
Reconstructed from the January 2023 concept and mobile-flow overview. These trees explain design intent, not proof that every branch shipped. Select a step for its rationale.
Help people start with what they need.
A customer may be exploring, missing a document, or unfamiliar with the technology. Readiness determines the next step; motivation alone does not.
Scroll sideways to explore the tree, or use Fit. Select any step for an explanation.
Read the decision tree as text
- Explain the requirements. Explain what identity verification involves, which documents are accepted, and how to prepare for a scan. Use a short checklist before opening the camera.
- Then: Ready to begin?.
- Ready to begin?. Check whether the customer has the required identity document and suitable capture conditions. A customer who lacks either needs preparation, not a failed verification attempt.
- No: Explain what is missing.
- Yes: Can this method work?.
- Explain what is missing. Name the missing item and explain how to prepare it. Avoid a generic instruction to try again when the person cannot complete the task yet.
- Prepare first: Return when ready.
- Return when ready. Let the customer leave the preparation stage and return with the required items. Any saved session or expiry behavior would need to be defined with engineering.
- Can this method work?. Before a device-dependent check, establish whether the chosen method is available. For example, NFC means reading a compatible document chip using a supported phone.
- No: Alternative available?.
- Yes: Begin the capture journey.
- Alternative available?. Check whether another available capture or upload method meets the institution's requirements. If none does, offer guided help instead of inviting an impossible attempt.
- Yes / use alternative: Begin the capture journey.
- No / none available: Open guided recovery.
- Open guided recovery. Explain the compatibility limitation and offer help with available options. Do not ask the customer to repeat a method their device or document cannot support.
- Begin the capture journey. Move into the required identity steps once the customer understands what to do and has a usable method. The exact checks depend on the configured KYC policy.
Separate a poor capture from a failed identity check.
The journey can include a liveness test, an identity document and proof of address. A readable image is an input to verification; it is not an approval.
Scroll sideways to explore the tree, or use Fit. Select any step for an explanation.
Read the decision tree as text
- Guide the current check. Show instructions for the current task and then a focused capture or upload screen. For a two-sided document, explain which side is needed.
- Then: Is the capture usable?.
- Is the capture usable?. Explain capture-quality conditions, such as glare, framing or a covered face. Keep them distinct from later identity or document-validity checks.
- No: Show a specific correction.
- Yes: More inputs required?.
- Show a specific correction. Name the visible problem and offer a relevant instruction: improve lighting, remove glare, reveal the whole document, or uncover the face.
- Then: Can the user fix it?.
- Can the user fix it?. Offer another attempt when the customer has a concrete correction to make. Repeated failure or an unavailable capability needs a different response.
- Yes / recapture: Guide the current check.
- No: Open guided recovery.
- Open guided recovery. Help diagnose the issue, identify an allowed alternative, or reach support when the customer cannot resolve it through recapture.
- More inputs required?. Check whether the journey still needs another document side, another required identity check, or proof of address.
- Yes: Explain the next input.
- No: Submit for verification.
- Explain the next input. Name the next required task and show relevant guidance. Repeat the capture-and-quality sequence for that input.
- Next required check: Guide the current check.
- Submit for verification. Confirm that required inputs have been submitted and communicate the actual verification status. Identity decisions follow the institution's checks and review rules.
Every failure needs an understandable next step.
Recovery starts by explaining the issue. It then distinguishes something the customer can correct from a method limitation or an issue that needs help.
Scroll sideways to explore the tree, or use Fit. Select any step for an explanation.
Read the decision tree as text
- Explain the failed step. Use the failing check as context for an informative review screen or diagnostic wizard. Explain what the customer can do next in plain language.
- Then: Can this be corrected?.
- Can this be corrected?. Distinguish a correctable issue, such as poor lighting, from a limitation that repeating the same action cannot fix.
- Yes: Guide the correction.
- No / still failing: Alternative permitted?.
- Guide the correction. Give focused instructions and let the customer retry the relevant check. Explain any session limitations instead of promising that all progress will be preserved.
- Apply correction: Retry the affected check.
- Retry the affected check. Return to the relevant capture with the corrective guidance available. Evaluate the new attempt through the same quality checks.
- Alternative permitted?. Check whether an available upload or capture method meets the institution's policy. The existence of an upload screen does not make it a substitute for every check.
- Yes: Use the allowed alternative.
- No: Contact support.
- Use the allowed alternative. Explain the alternative method and any new requirements before proceeding. Do not silently weaken the identity checks.
- Contact support. Give the customer a clear support route when the issue is unresolved. Manual review may be available if the institution supports it; it is not an automatic approval.
- Support response: Show the actual status.
- Show the actual status. Communicate whether the case needs customer action, is waiting for review, or has a final outcome. Avoid a success message while a decision remains pending.
Readiness, capture quality and identity approval are separate questions. Repeating an unavailable method is not a recovery strategy.
Design decisions / Operational experience
Make policy understandable and every decision traceable.
Operational users needed to configure verification journeys and later explain the outcome of an individual case. I designed a progressive information model that carries intent from policy setup through to evidence review.
Desktop / Verification policy configuration
02
Expose the policy before it goes live
The builder surfaces each check, its requirements, its place in the journey, and its cost. A final confirmation turns configuration into a sequence that can be reviewed before publishing.
Constraints and trade-offs
- Constraint
- A configuration choice changes what customers must do. Document-chip reading, for example, introduces a device and document compatibility dependency.
- My decision
- Make checks, their order, and their cost visible together, with a confirmation step before publishing the configuration.
- Trade-off
- More configurable checks offer flexibility but make setup harder to understand. An ordered journey and final summary expose the consequences without hiding the available controls.
Desktop / Compliance case review
03
Layer the evidence around the reviewer's question
I organised the record around a practical question: what happened in this case, and what evidence supports it? The overview establishes the case context, the timeline exposes individual checks, and the document views allow closer inspection. These are complementary levels of the same review task, not separate dashboards.
Constraints and trade-offs
- Constraint
- A status alone cannot explain a case, but showing every technical detail at once makes the first read unnecessarily demanding.
- My decision
- Layer the information: case summary first, check history second, source evidence on demand. Preserve the connection between a result and the material behind it.
- Trade-off
- Progressive disclosure requires an extra action to inspect detail. The benefit is a focused overview, provided the deeper evidence remains clearly reachable and attached to the same case.
What this work demonstrates
A clear next step, at each level.
I designed the customer journey and the tools around it as parts of one service. Guidance helps a customer provide evidence; configuration defines the checks; review keeps the result connected to its source. The screens demonstrate those design decisions, without claiming a measured improvement in completion rates.
Let’s work together
What could be easier to use?
Tell me about the product and the part that needs fixing. A few sentences is enough.
Tell me about it