SPUN
Designing multi-applicant visa requirements across two products
SPUN
Designing multi-applicant visa requirements across two products
Role
Role
Product Designer
Product Designer
About SPUN
About SPUN
SPUN Global is a technology company (startup) that operates an AI-powered infrastructure platform for visa processing services and cross-border travel support.
SPUN Global is a technology company (startup) that operates an AI-powered infrastructure platform for visa processing services and cross-border travel support.
Executive Summary
Executive Summary
I designed a multi-applicant capability that lets families and travel consultants see visa requirements for every applicant in one place, instead of one profile at a time. Designed within a two-week sprint, it shipped across SPANVISA and SPUN on desktop and mobile.
I designed a multi-applicant capability that lets families and travel consultants see visa requirements for every applicant in one place, instead of one profile at a time. Designed within a two-week sprint, it shipped across SPANVISA and SPUN on desktop and mobile.
When the CPO extended the request from travel consultants to consumers, I used storyboards of both journeys to decide what stays shared and what adapts. The result was one capability with entry points fitted to each context, built from existing components.
When the CPO extended the request from travel consultants to consumers, I used storyboards of both journeys to decide what stays shared and what adapts. The result was one capability with entry points fitted to each context, built from existing components.
Problem: One applicant at a time
Problem: One applicant at a time
Visa requirements change with the applicant. An adult and a child applying for the same visa can need different documents, yet the service detail page showed requirements for only one profile.
Visa requirements change with the applicant. An adult and a child applying for the same visa can need different documents, yet the service detail page showed requirements for only one profile.
A family of two adults and two children applying for a UK Standard Visitor Visa had to edit the profile and switch back and forth to check each person. They could never see all four together.
A family of two adults and two children applying for a UK Standard Visitor Visa had to edit the profile and switch back and forth to check each person. They could never see all four together.
The Shift: From one request to a shared capability
The Shift: From one request to a shared capability
The request came from SPANVISA, a joint venture between SPUN and Panorama JTB. Travel consultants needed to generate requirements for a group and pass them on to customers.
The request came from SPANVISA, a joint venture between SPUN and Panorama JTB. Travel consultants needed to generate requirements for a group and pass them on to customers.
Before designing, I mapped both journeys in storyboards: Travel consultants preparing requirements while serving a customer, and consumers exploring requirements before buying.
I sketched the scenarios on paper and used AI to turn them into clearer storyboard visuals. The storyboards served as a design exploration tool, helping me reason about possible workflows rather than validate them through formal user research.
Scenario exploration, not direct user observation.
Scenario exploration, not direct user observation.
When the CPO proposed bringing the capability to SPUN’s consumer side as well, the storyboards showed what the two journeys shared and where they had to differ.
When the CPO proposed bringing the capability to SPUN’s consumer side as well, the storyboards showed what the two journeys shared and where they had to differ.
The work moved through a two-week design sprint, with two design reviews each week. This cadence made it important to communicate design rationale clearly, resolve trade-offs quickly, and align with Engineering and stakeholders throughout the process.
The team had a two-week sprint, with two design reviews a week, so each decision had to hold up the first time.
How might we let people add applicants and move between their requirements easily, across two products used for different jobs?
How might we let people add applicants and move between their requirements easily, across two products used for different jobs?
Key Decision: Fit the entry point to the job
Key Decision: Fit the entry point to the job
Travel consultants add or remove applicants in the checkout pane, inside the flow they are already completing, so each applicant’s document checklist is visible at first sight.
Travel consultants add or remove applicants in the checkout pane, inside the flow they are already completing, so each applicant’s document checklist is visible at first sight.
Consumers see an outline banner on the service detail page. It opens a pop-up for applicant details that shows the number of applicants alongside the price, so people can see how group size affects what they pay.
Consumers see an outline banner on the service detail page. It opens a pop-up for applicant details that shows the number of applicants alongside the price, so people can see how group size affects what they pay.
Both entry points were built from components already on the service detail page, so the new capability didn’t introduce a new component and customers already knew the flow.
Both entry points were built from components already on the service detail page, so the new capability didn’t introduce a new component and customers already knew the flow.
Key Decision: Keep many applicants navigable
Key Decision: Keep many applicants navigable
Once a group had several applicants, the next problem was moving from one person’s requirements to another.
Once a group had several applicants, the next problem was moving from one person’s requirements to another.
On desktop, I added a side navigation on the right in both SPANVISA and SPUN that lists every applicant. Travel consultants and customers can jump between requirement lists without leaving the page.
On desktop, I added a side navigation on the right in both SPANVISA and SPUN that lists every applicant. Travel consultants and customers can jump between requirement lists without leaving the page.
The same panel holds an Add action and lets users edit each applicant’s details. Managing the group and reading the requirements happen in one place.
The same panel holds an Add action and lets users edit each applicant’s details. Managing the group and reading the requirements happen in one place.
On mobile, the applicant list moves into a dropdown under the Documents tab. Selecting an applicant takes users straight to that person’s requirements, so they don’t have to scroll past everyone else’s to find them. The Add more applicants action sits at the bottom of the same list.
On mobile, the applicant list moves into a dropdown under the Documents tab. Selecting an applicant takes users straight to that person’s requirements, so they don’t have to scroll past everyone else’s to find them. The Add more applicants action sits at the bottom of the same list.
Key Decision: Let requirements leave the product the way people share them
Key Decision: Let requirements leave the product the way people share them
A customer often needs only one person’s list, so each applicant has its own download action in a familiar button group, with download-all for the full set.
A customer often needs only one person’s list, so each applicant has its own download action in a familiar button group, with download-all for the full set.
To share with others, users copy formatted text for one applicant or for everyone. I structured it into header, subheader and body, using WhatsApp asterisks for emphasis so it scans inside a chat bubble. Copying happens in the product; sending stays manual in WhatsApp.
The only difference between SPANVISA and SPUN is the text header.
To share with others, users copy formatted text for one applicant or for everyone. I structured it into header, subheader and body, using WhatsApp asterisks for emphasis so it scans inside a chat bubble. Copying happens in the product; sending stays manual in WhatsApp.
The only difference between SPANVISA and SPUN is the text header.
Constraints & Edge Cases
Constraints & Edge Cases
Shipping now vs reusing customer data
Ideally, travel consultants could reuse details from customers already registered with Panorama JTB. That data was not available through the API, so we agreed to use the first-name and last-name pattern from other flows. The team shipped without waiting on the integration, and applicant reuse remains a future opportunity.
Shipping now vs reusing customer data
Ideally, travel consultants could reuse details from customers already registered with Panorama JTB. That data was not available through the API, so we agreed to use the first-name and last-name pattern from other flows. The team shipped without waiting on the integration, and applicant reuse remains a future opportunity.
Preventing lost work
Refreshing the browser mid-flow could wipe several documents. With Engineering, I designed a pop-up that asks whether to start over or keep the saved documents, so the consequence is the user’s choice.
Preventing lost work
Refreshing the browser mid-flow could wipe several documents. With Engineering, I designed a pop-up that asks whether to start over or keep the saved documents, so the consequence is the user’s choice.
The sprint left room for only one of two options: ship the pop-up and delay the release, or ship a simpler safeguard on time. We chose the second. The system now saves every generated document, so users who return to the service detail page find their list waiting for them.
The sprint left room for only one of two options: ship the pop-up and delay the release, or ship a simpler safeguard on time. We chose the second. The system now saves every generated document, so users who return to the service detail page find their list waiting for them.
We gained a release on schedule with no lost work. We gave up the option to start fresh, a gap worth revisiting.
We gained a release on schedule with no lost work. We gave up the option to start fresh, a gap worth revisiting.
Outcomes: Shipped across both products
Outcomes: Shipped across both products
Consultants got the capability first; consumer desktop and mobile followed one sprint later. Users can now:
Consultants got the capability first; consumer desktop and mobile followed one sprint later. Users can now:
Add applicants and get requirements tailored to each one
Download one applicant’s list or the full set
Copy ready-to-paste text for one applicant or everyone
Add applicants and get requirements tailored to each one
Download one applicant’s list or the full set
Copy ready-to-paste text for one applicant or everyone
Evidence: release and stakeholder acceptance.
What’s next
What’s next
Carry applicant details into checkout to remove duplicate entry, then measure task success, time on task and checkout progression.
Carry applicant details into checkout to remove duplicate entry, then measure task success, time on task and checkout progression.
Reflection
Reflection
This project sharpened how I look at a feature: not just what it does, but where else it lands. If multi-applicant requirements ship in one product, does that affect the other? If so, how should the feature adapt there? This case study is my answer to both questions.
This project sharpened how I look at a feature: not just what it does, but where else it lands. If multi-applicant requirements ship in one product, does that affect the other? If so, how should the feature adapt there? This case study is my answer to both questions.
It also taught me that seamless navigation doesn’t come from a single pattern. Each flow raised its own cases, from one applicant to a large group, and each one needed to be thought through on its own.
It also taught me that seamless navigation doesn’t come from a single pattern. Each flow raised its own cases, from one applicant to a large group, and each one needed to be thought through on its own.
Design ideas got stronger once they went through the team first. The PM and Engineering each saw the problem from their own angle. I treated their feedback, and the stakeholders’, as input to shape the design rather than a box to tick, and every iteration got sharper because of it.
Design ideas got stronger once they went through the team first. The PM and Engineering each saw the problem from their own angle. I treated their feedback, and the stakeholders’, as input to shape the design rather than a box to tick, and every iteration got sharper because of it.
Despite a tight sprint and several rounds of design review, the capability shipped across both products.
Despite a tight sprint and several rounds of design review, the capability shipped across both products.
