A system everyone uses.
A process no one can see.
Two years of public feedback, four channels, one failure loop. What is the process?

Requirements vary by destination, visa type, and applicant.
Applicants spend days to months preparing and validating documents before submitting.
Applicants book appointments, travel, wait, verify documents, and submit biometrics.
One application can take hours, even whole day to process in person.
They may not know the application's status, handler, or blockers for weeks or months.
The decision returns, often via documents and courier.
3 patterns I observed firsthand: application errors, Embassy delays, and applicant confusion.
From my experience working in visa operations at VFS Global, I observed hundreds of thousands of applications across document submission, verification, biometrics, and applicant support.
This revealed a recurring problem: applicants have the least control, but carry the most uncertainty.
The visa journey is a fragmented, low-visibility service. Applicants move between disconnected touchpoints while critical work happens behind the scenes. The result is manual handoffs, unclear ownership, physical dependencies, and long periods of uncertainty for the person with the least control.
Research & Synthesize
Public feedback analysis using multi-source review and social listening (LinkedIn, Google Maps, Facebook, news).


Archetypes from both sides
Nine personas merge into two archetypes, one per product. The applicant side uses 1,455 real feedback items; the embassy side is assumption-based until officer interviews occur.


The business case set the bar before any interface existed.
>90%
of applicants can correctly answer “where is my application, and what happens next?” at any point, which measure in usability testing.
Document requirements differ per embassy and change without notice
Checklist created from embassy requirements and validated at intake, not after submission.
Embassy headcount and SLA are fixed; automating the decision is off the table
Rule-based triage and missing-document alerts move the queue, never the verdict
No shared system of record between VFS and the embassy
One case ID, a named owner per stage, event-driven notifications
Biometric enrolment is sovereign and hardware-bound; data residency varies by jurisdiction
An orchestration layer over existing centres; digital categories only, partitioned storage
Six stakeholders. One blind spot.
Power and visibility run in opposite directions. The actors with the most authority are the least visible to the person waiting.

Unclear ownership of delays.
→ no accountability, poor applicant experience.
Low visibility and control
→ anxiety, repeat inquiries, mistrust.
Paper and courier dependency
→ slow, lossy, expensive.
Security requirements cap automation
→ longer turnaround, rigid rules.
Every embassy runs its own.
→ silos, re-entry, integration debt.
Five stages, front to back.
Service blueprint first, interface second — map front stage to back stage before screen.
Every pain point has a design decision.

Two swimlanes, one handoff.
The applicant app and the embassy console are one flow with a single crossing point:
a structured case arriving in the officer's queue.

Turn a black-box process into a clear, predictable, controllable journey
→ the user can always answer: where am I, what's happening, what do I do next, when will I know?
Dashboard → Application detail → Timeline → Stage detail → Action (if needed)
Baseline is the individual tourist happy path (60–70% of users).
Beyond it: minors with guardian consent, passport expired.
What are the designs?
A Government-Integrated Visa Platform that replaces fragmented outsourcing with one secure, automated system. That is a system of record, coordination, and management.


A government service has to
look like one.
The brand argues this is official infrastructure, not a travel app. Every choice, from name, mark, and colour, aims to earn institutional trust and stay clear to anxious first-time applicants.

One token set, two products.







3 patterns I observed firsthand: application errors, Embassy delays, and applicant confusion.
From my experience working in visa operations at VFS Global, I observed hundreds of thousands of applications across document submission, verification, biometrics, and applicant support.
This revealed a recurring problem: applicants have the least control, but carry the most uncertainty.


Why we have this stage after the Application stage?
This will be a layer to guarantee the quality and quantity of each application, so the system can categorize them into ‘Fast-review’ or ‘Full-review’ of Embassy side.
And this will give a hold, when applicants change their mind & pause/withdraw their application before they pay visa fee and we dont have to do refund.


Why payment comes before biometrics?
Once payment and biometrics are completed, the application package can be prepared for embassy review.
If an applicant pauses or withdraws before biometrics, the system can handle the payment/refund without having to process biometric data.






Why is the e-visa view-only?
The e-visa is linked to the applicant's verified application data and synchronized with the relevant government systems.
Keeping it within the platform helps maintain a single, up-to-date version of the visa and reduces the risk of using an outdated or altered copy.

What changes, for each side.
Applicant
- Reduced uncertainty
- Fewer support inquiries
- Higher trust
- No courier wait on the passport
embassies
- Reduced workload
- Better case prioritization
- SLA visibility
- Attention spent on complex cases
the system
- Faster processing
- Lower operational cost
- One auditable record
- Scalable infrastructure
How I'd know if it worked.
Each measure pairs with the failure it is meant to close, so a flat number would tell me which part of the thesis was wrong.
Calls and emails per application should fall as the timeline answers the question first.
−50% vs the current baseline
support-ticket volume per case, 90 days
High repeat visits with low support contact means people trust what they are reading.
≥4 of 5 on "I know what happens next"
2-item survey after a status view
Pre-submission validation should cut the share of cases rejected on paperwork technicalities.
≥85% complete unaided · error rate under 10%
moderated task test, 12 applicants per archetype
Per-stage dwell time exposes which handoff is actually the bottleneck.
every stage attributable to one owner
stage dwell-time instrumentation
If triage works, officer attention concentrates on complex cases, not paperwork checks.
−30% on low-risk cases
time-on-task in the embassy console
The e-visa path should shrink courier volume, stage by stage.
downward trend quarter on quarter
courier volume per 100 cases
AI belongs before the application, not inside the decision.
Choosing the wrong visa type initially is a comprehension issue, where a language model helps. A copilot in the intake flow, using embassy requirements, with human review for uncertainties.
suggests a category from a plain-language trip description.
reads the embassy’s published requirements before answering (RAG) — never generates from memory.
turns that into an ordered, category-specific document checklist.
low confidence or an edge case routes to an officer — human-in-the-loop by default.
no approval, no refusal, no risk score.

What stays open.
The clean version of this platform is the idealistic one. Here is what the diagram does not solve.
Government pace
Data ties to the Immigration Department and Ministry of Foreign Affairs are still undefined;
procurement and policy move slower than any roadmap.
Embassy resistance
Each embassy owns its internal system and its risk appetite.
Adoption is a change-management problem, not a UI one.
Officer personas unvalidated
The embassy side is built on assumptions. Testing with real visa officers is the next honest step.
Biometrics stay physical
Capture still needs a supervised site, so the platform orchestrates visa centres rather than removing them.
What I'd do differently
I built the design system before the flows. On a two-platform service that was the wrong order, which was slow, and it only ever covered the mobile app. Finishing the flows first and formalising the system from what survived worked far better.


