Application Form Redesign

This case study is part of a 13-month redesign of Postcard, the application portal for our cultural exchange programs. The application form is the primary touchpoint, where users spend the most time and where dropout risk is highest.

Over time, the application process accumulated features without a cohesive redesign. The result was an interface that felt heavy and overwhelming:

• •Bold but exhausting visual language: Large typography and strong colors made pages lengthy and hard to scan.
• •High information density: Content-heavy pages with no clear hierarchy.
• •Unclear interaction logic: Sometimes users couldn't easily understand where they were in the process or what was expected.
• •No support elements: Just forms. No guidance, no reassurance, no help.

For users already anxious about cost, safety, and whether they're "qualified enough," this interface added friction instead of reducing it.

Before jumping into solutions, I mapped out three hard constraints:

• •Limited dev resources: The team viewed this as a visual refresh, not a full rebuild. Every interaction change had to be negotiated.
• •Shipping in pieces: I couldn't redesign everything at once. Changes had to fit into existing sprints alongside other priorities.
• •The process itself was fixed: Users had to complete every step. I could change how steps felt, but not remove them.

These constraints shaped everything that followed, starting with understanding who we were designing for.

Our applicants are mostly university students: young, financially stretched, and inexperienced with formal applications. Through an internal survey, our sales team surfaced the concerns they hear most often:

• •"Is this a scam?"
• •"I've never traveled alone, is it safe?"
• •"I don't think I'm qualified enough."
• •"The overall cost is too high."

These aren't just UX problems. They're emotional barriers. And that raised a question: could the system even address them?

I had a hunch early on that the system wasn't where the emotional weight lived. Conversations with my manager, sales, support, and operations confirmed it.

Users don't just interact with a system. They connect with real people.

Our sales and support teams are there throughout: personal calls, direct guidance, someone to thank when they get their placement. The system is just one part of a larger experience.

So instead of asking "how do we make this system more reassuring?", the real question became "what role should the system play?"

Sales & Support: Personal suggestions, emotional support, answering concerns

Official Website: General program information and marketing

Postcard: The portal to submit information. Efficient, not emotional

The system didn't need to be warm and encouraging. It needed to be invisible. Smooth enough that users could focus on the task at hand, not fighting the interface. That insight shaped everything from process to design.

This wasn't a single launch. It was a gradual transformation across 13 months, redesigning the system while users were actively applying.

Prioritization approach:

1. Start simple: I explored "friendly" elements like progress celebrations early on, but they were expensive to scale. Since sales and support already carried the emotional weight, I dropped the decorations, focused on function, and established patterns on basic pages first.

2. Follow the business cycle: Our programs run on a yearly cycle, so I started from foundational pages and prioritized based on where users currently were in their journey. We refreshed the pages they'd hit next.

3. Negotiate constantly: Not every UX improvement was worth the dev cost. I balanced cost against benefit, proposed options to the team, and focused on changes that served both the product and the user.

Shipping in pieces meant every decision had to hold up across dozens of pages, including ones I hadn't designed yet. I needed a scalable foundation before jumping into interactions.

For consistency, I carved out time early to build a minimal design system, a shared language that reduced back-and-forth on every new page.

For the building blocks, I optimized for flexibility over perfection:

1. Mobile-first, less adaptation for desktop

One layout to maintain instead of two. Sacrifice a bit of desktop polish to ship faster.

2. Minimal component variety

Avoid specialized components early. Fewer types means faster development now and room for purposeful variation later.

3. Tolerant of future complexity

Every visual choice needed to survive content we hadn't planned yet.

The underlying trade-off: this system plays a support role in the user's journey, not the starring one. Speed and resource efficiency over pixel-perfect polish. Build solid, then refine.

With the foundation in place, I established three principles to guide the interaction design:

• •Be easy, smooth, invisible: Don't try to delight. Try to disappear. Reduce cognitive load so users can focus on what matters.
• •Okay to leave now: Users are in this process for months. Let them pause, leave, and return without friction.
• •Be kind, don't trigger anxiety: No unnecessary alerts, no blocking errors, no making users feel like they're doing something wrong.

Be Easy, Smooth, Invisible

The goal was to make the interface feel effortless, something users move through without noticing.

Okay to Leave Now

The application process takes months. Users shouldn't feel trapped or pressured to finish everything in one session.

1. Homepage "Continue" section: When users return, the homepage shows their current stage with a clear "Continue" button. No hunting for where they left off.

2. Step-as-tabs pattern: What looks like a multi-step form is actually a tab system. Users can leave anytime, jump back to any section, or switch between people without losing progress. It doesn't need to be linear.

3. "Save and Continue" buttons: Long sections are broken into shorter chunks with explicit save points. Users know their progress is safe and it's okay to leave.

Provide In-time Support

Invisible doesn't mean absent. The system still needs to help when users are stuck.

We also started bringing AI into the process. For example, users often struggled to describe their abilities in the Skills section, so we added an AI checker that reviews their responses and suggests improvements in real time.

Be Scannable

1. Separated guides: Instructional guides with videos moved from inline to a dedicated page that auto-skips on return visits. Pages stay focused.

2. Preview pages for complex items: Sections like work experience and references have a summary page before editing. Scannable without sacrificing detail.

Be Kind, Don't Trigger Anxiety

Our users are already anxious. The system shouldn't add to that.

1. No blocking between tabs: Users can visit any tab even if the current one isn't complete. Preview what's coming without feeling stuck.

2. No backend validation alerts: Validation happens inline as users type instead of error alerts after submission. No surprises, no punishment.

We don't have dedicated product analytics, but the signals we do have are encouraging:

NPS Score: 85 → 89

Our Net Promoter Score increased 4 points year-over-year. This reflects the entire program experience, but the application process is a significant touchpoint.

4% Explicit Mentions

Around 4% of NPS respondents specifically described the application as "easy" and "efficient." That sounds small, but users rarely comment on frictionless experiences. When something works, it's invisible. The fact that some users noticed suggests the redesign made a real difference.

The product isn't always the main character. Sales and support carry the emotional weight. The system just needs to stay out of the way. Understanding the ecosystem first saved me from solving the wrong problems.

Value isn't just UX. Scalability, dev cost, maintainability, shipping speed all matter. A standardized form style over custom pages wasn't the most exciting UX choice, but it was the right product choice. More ground, fewer resources, a foundation to refine over time.

Next time, I'd sequence differently. If this were a focused three-month project, I'd stress-test patterns on complex pages first before building a design system around them. It held up, but testing edge cases earlier would have given me more confidence.