Overview
- The problem
- Clients could not connect their overall KYC status to the document or corrective action that required attention. Administrators lacked enough context to triage and review submissions efficiently.
- My contribution
- I redesigned the client and administrator verification flows, from interface review and synthesis through wireframes, high-fidelity screens, and linked Figma prototypes.
- What I delivered
- A documented design response covering document requirements, per-file status and recovery, contextual administrator review, and a separate third-party verification path.
Verification is a connected workflow. A client needs to know which document is required and what to fix; a reviewer needs the submission context to make and communicate a decision. My response to this design challenge treats those two perspectives as one system.
Problem
The published review began with interface recordings of the existing client and admin flows. The central issue was a gap between an overall status and the document-level information needed to act on it.
- Required and optional documents were difficult to distinguish.
- A global KYC status did not explain which document needed attention.
- Rejected documents lacked a clear reason and recovery path.
- Multiple files within one document category were poorly presented.
- Administrators needed stronger triage controls and more context during review.
The design goals were clearer status, easier submission and re-upload, and more contextual review. Lower support demand and operational effort were intended benefits, not measured results of the published challenge.
My Role
- Company / product context
- Saphyte CRM - KYC verification design challenge
- Users
- Clients submitting identity documents and administrators reviewing them in Saphyte CRM.
- Timeline
- 3 days, as reported in the article
- My role & scope
- I redesigned the client and administrator verification flows, from interface review and synthesis through wireframes, high-fidelity screens, and linked Figma prototypes.
- Evidence available
- My published article, original analysis and interface exports, and two linked Figma prototypes.
I worked across the client portal and admin back office. My scope was UX/UI design and prototyping: organizing document requirements, feedback, file actions, review context, and the distinction between manual and third-party verification.
Process
I used Nielsen's ten usability heuristics to structure the review of the recorded interface. The article then compares Binance and Wise against the same verification concerns: requirements, status transparency, error feedback, re-upload, review visibility, and contextual help.
Affinity mapping and ideation grouped the observations into clarity, error recovery, navigation, document management, and inline guidance. I translated those themes into client and administrator wireframes, then high-fidelity screens and prototypes. The persona artifact is part of this design synthesis; the article does not describe an interview sample or completed usability study.
Inspect the analysis and wireframes7 original artifacts
Open any image to inspect it at its published resolution.
Heuristic Analysis: Saphyte KYC UI (Current Design and Flow) Full size 
Published comparison of Saphyte, Binance, and Wise verification experiences Full size 
Affinity Mapping Full size 
Ideation Full size 
Design-persona artifact in the original KYC article Full size 
Sketch My Profile & KYC Page Full size 
Sketch KYC Management & Document Verification Details Page Full size Key Decisions
Make rejection actionable at the file
A global Rejected badge is insufficient. Keep the affected document, reason, and replacement action together so the user can identify a corrective step.
Inspect rejection recoveryBring evidence into the review context
The review queue exposes submission state; the detail view combines applicant context, document metadata, file status, and decision controls.
Inspect the admin workflowKeep provider results distinct from manual decisions
Third-party results use a separate, read-only presentation. This separates inspecting provider evidence from editing a manually reviewed submission.
Inspect the provider boundary
The trade-off is between a compact summary and enough detail to resolve an exception. Required and optional groups, per-category progress, and expandable document sections keep the overview manageable while preserving a route into file-level context.
Final Solution
Client recovery
The client sees Pending, Rejected, or Approved profile states with a next action. The KYC page separates required and optional documents, explains how required-document review affects the overall status, and makes file status and rejection reasons visible beside View, Replace, and Delete actions.
The rejected identity file has a specific reason and a Replace action beside it. The approved back document remains separately visible. Published in the original Medium article on 6 May 2025.The upload flow exposes document type, required inputs, file feedback, and an optional comment. Instructions and examples are placed near submission so a client can inspect expectations before retrying.
Two source upload states, not a simulated upload service.Administrator review
The queue distinguishes client status, required-document completion, and verification method before the reviewer opens a submission. The detail screen keeps the applicant, required-document progress, file metadata, version history, and decision actions in the same context.
Original review-detail design with file-level evidence, history, and separate decision controls. Names, IDs, document data, validation messages, and dates are sample interface content.Reject and approve actions have different confirmation contexts. Rejection offers consistent reasons and an optional comment, with an applicant-facing warning. Approval asks the reviewer to confirm the specific document before continuing.
Original decision dialogs. The case study documents interaction design, not the execution of a verification decision.Third-party verification
The design offers a Sumsub verification entry point and a separate provider-result page. Provider-supplied document results are marked read-only, with viewing and download controls. These screens establish the intended distinction between verification methods; they do not verify a working vendor integration or the accuracy of its checks.
Read-only third-party verification result in the original design. Risk and validation labels are illustrative interface content.Compare the remaining client and admin states8 original artifacts
Open any image to inspect it at its published resolution.
My Profile - Pending Full size 
My Profile - Rejected Full size 
My Profile - Approved Full size 
KYC - Required Docs - Pending Full size 
KYC - Optional Docs - Pending Full size 
KYC - Required Docs - Approved Full size 
Document Approved Successfully Full size 
Rejected Global Status Full size Outcomes
The documented result is a connected design set for client verification and administrator review, supported by wireframes, explicit exception states, and two linked Figma prototypes. The article was published on 6 May 2025 and describes a three-day challenge.
The article proposes future usability testing with people recovering from rejection. It does not report completed task testing, successful-KYC conversion, production review speed, or reduced support volume.
Evidence & limitations
The source is a three-day product design challenge published on 6 May 2025. It documents designs and prototypes, not a verified production rollout, compliance certification, completed usability tests, or measured improvements in KYC completion and review time. The later implementation result below is separately attributed to my resume and subsequent confirmation, without original analytics.
The published article contains no measured completion-rate, support-volume, or review-speed result.
After publication, this design was implemented in the same KYC workflow. I reported the later Accept-button interaction figures in my resume and confirmed that association when preparing this portfolio. The comparison measures interactions, not completed verification, and does not isolate the redesign from other changes.
What supports these numbers
- Verification status
- Owner-reported result; not independently verified
- Measurement period
- May to June 2026
- My contribution
- Client submission, rejection recovery, and administrator review workflow design
- Evidence available
- Owner-supplied resume and Insan’s confirmation that the reported result concerns implementation of this same design. The May 2025 Medium article documents the design process, not this later metric. No original analytics export or isolated experiment is available.
KYC Accept-button interactions
- Reported result
- +347%
- Baseline & comparison
- 507 interactions in May 2026; 2,265 in June 2026. Rounded relative increase: (2,265 - 507) / 507 × 100.
- Source & scope
- Reported by Insan for implementation of the same redesign. Button interactions are not unique users, completed verifications, or proof of design as the sole cause.
Learnings
- What worked in the design
- Client recovery and administrator decisions use the same document-level context.
- What I would change next
- Test rejection recovery with clients and review tasks with administrators; resolve progress-label inconsistencies before establishing a live baseline.
- Keep document counts, status, and numeric progress consistent: the published rejected-state screen shows one of two required documents approved beside a 100% label. That mismatch needs correction before implementation.
- Validate the rules for replacing or deleting approved documents with the review team rather than assuming every visible file action is appropriate in every state.
- Test whether clients can identify what to fix and whether reviewers can explain a decision from the available context before defining live completion and review-effort measures.
