Overview
- The problem
- An application involves preparation, multiple form stages, corrections, and a final commitment. People need to know where they are, what is required, and how to review before submission.
- My contribution
- Product Designer. The Figma work covers the account overview, profile and photo preparation, staged passport application, review and declaration, and mobile adaptations.
- The outcome
- Documented responsive portal and application-flow designs. Example applications, people, progress, and statuses are interface content, not real service records or measured outcomes.
Problem
Overview, identity preparation, staged passport application, review, declaration, and mobile screens document the intended journey. Example identities and statuses are sample design content, not real consular records.
My Role
- Company / product context
- Saphyte · E-Afghan Citizen Portal
- Users
- People managing consular requests, identity information, documents, and application progress in an account-based workspace.
- My role & scope
- Product Designer. The Figma work covers the account overview, profile and photo preparation, staged passport application, review and declaration, and mobile adaptations.
- Evidence available
- Original project narrative and design artifacts retained in this case study.
Process
The archive connects an overview to staged input and section-level review. Desktop and mobile layouts show workflow adaptation; a tested before-and-after comparison is not included.
Break the passport application into stages
The passport flow uses a visible step list to separate application setup, documents and photo, identity details, contact and employment, passport history, and review. Completed, current, and not-started stages communicate position within the flow, while Save and Exit gives the design a clear pause point.
Document uploads and photo requirements sit beside the application steps.Key Decisions
Applications need preparation, correction, and pause points as well as submission. Visible progress and Save and Exit describe intended behavior, but persistence, uploads, permissions, and session recovery require implementation validation.
Key design decisions
Separate starting work from tracking work
Quick actions offer visible entry points, while existing applications and profile readiness remain separately scannable on the overview.
View the portal overviewMake a long application navigable and pausable
A visible stage list distinguishes completed, current, and not-started sections. Save and Exit supplies a designed pause point instead of treating the form as one uninterrupted task.
View the application stages and document stepGive review and declaration a deliberate boundary
Grouped summaries expose section-level edits before submission. Declaration and signature are separated from ordinary form entry to make the final confirmation distinct.
View the review and declaration design
Final Solution
Quick actions, readiness information, visible application stages, review edits, and a separate declaration boundary make the long task inspectable. Original designs show these details without claiming working submission.
An overview that surfaces useful actions
The overview separates quick actions from application status and profile completion. Passport applications, payments, and photo checks have visible entry points, while existing requests remain available below. A persistent navigation groups accounts, workspace, citizen services, and tools.
Quick actions, existing applications, and profile readiness share one overview.Prepare identity information and photos
The profile and photo-check screens give preparation tasks their own space. Photo guidance breaks requirements into specific checks, including file format, size, resolution, portrait shape, lighting, and face visibility. The interface distinguishes these requirements from the upload action itself.
A dedicated profile surface for identity and account information.
Photo preparation pairs an upload area with concrete requirements and visual examples.Make review a deliberate step
Before submission, a summary groups the supplied information by section and exposes edit actions. The declaration and signature area is separate from that summary, making the final confirmation a distinct part of the journey rather than another ordinary form field.
Section-level review, correction, and declaration before submission.Carry the workflow onto mobile
The mobile designs preserve the overview and application structure while stacking the denser desktop layouts. The examples below show the account overview and the start-application screen as separate, focused mobile surfaces.
Responsive designs from the same Citizen Portal file. Open a screen for a closer look.Outcomes
The outcome is the documented responsive portal and application-flow design. Application-success improvement, production release, security validation, and usability-study results are not established.
Evidence & limitations
Design evidence only. No production release, application-success improvement, security validation, or usability-study results are asserted.
A visible pause action does not establish reliable saved state or recovery in a real application.
What needs validation
The following is a proposed validation plan, not research already conducted:
- Test whether people understand the current stage, required documents, photo guidance, and route back after saving.
- Evaluate correction from review and comprehension of declaration/signature before submission.
- Validate persistence, upload failure, session expiry, permissions, and recovery with the implementation team, then test mobile and assistive-technology workflows.
Learnings
- What worked in the design
- Review is treated as a correction task before final confirmation.
- What I would change next
- Test interrupted applications, document failures, review corrections, and mobile or assistive-technology use with the implemented workflow.
Delivery and design takeaways
The design record connects overview, preparation, staged input, and final review in a responsive workspace. It demonstrates intended progress, correction, and pause affordances; it does not establish working persistence, document processing, payment, or application submission.
- A useful overview distinguishes the next action from the status of work already in progress.
- Visible stages and a pause route make a complex application legible, but saved-state behavior still needs implementation and testing.
- Review is a correction task before it is a confirmation task; section-level edit routes should remain close to the supplied information.
