A design decision about whether a rare but consequential edge case was worth adding an extra step for every user

We Didn’t Have Time to Cover Every Country

Chaebee started as a hackathon project. Travel requirements vary by nationality and destination, but we couldn’t cover every possible combination within the time we had. We had to narrow the scope, so we designed the service specifically for Korean nationals. Focusing on Koreans traveling abroad significantly reduced the number of conditions we needed to account for.

Then we found an exception within the scope we had just defined. What if someone held Korean nationality along with another nationality? They were still within our target audience, but assuming they only held Korean nationality could make the travel information we provided incorrect.

It Turned Out to Be About 0.4%

We looked into how many people this might affect. Comparing the number of people with multiple nationalities reported in data submitted by the Ministry of Justice with South Korea’s total population at the time gave us an estimate of about 0.4%. It was a very small number. In a hackathon, we couldn’t account for every edge case, so our first thought was whether we could simply leave this one out.

But the impact of missing it was too significant to judge by the number alone. Consider someone who holds both Korean and U.S. nationality and is preparing for a trip to the United States. Based only on their Korean nationality, Chaebee could tell them they need ESTA. But U.S. citizens, including those with multiple nationalities, must use a U.S. passport to enter and leave the country and cannot apply for ESTA. This was rare, but getting it wrong meant more than an awkward screen. The travel information itself would be incorrect.

Did We Need to Ask Everyone About Their Nationality?

Accurately identifying people with multiple nationalities would require an additional question or input. But after deliberately narrowing the service to Korean nationals, we didn’t want to ask everyone for more nationality information just to identify a small subset of users.

Instead, we added a screen explaining that different rules may apply to people with multiple nationalities. Every user still had to pass through one additional screen, but no one had to enter another nationality or answer whether they held one. Rather than identifying the exception ourselves, we chose to make users aware of it so those affected could check their own situation.

We Didn’t Remove the Complexity. We Moved It.

This approach still had a cost. We avoided adding another input, but every user—including those with only Korean nationality—had to pass through an extra information screen. We had not removed the complexity so much as moved it. Instead of adding an input to identify a small subset of users, we asked everyone to acknowledge a short notice.

And 0.4% was never the threshold for the decision. It was an estimate based on the total population, and we had no basis for assuming the same proportion among the international travelers who would actually use Chaebee. What mattered more was what could go wrong if we missed the case, and what cost we were willing to add for everyone else to prevent it.

At the time, we chose one additional screen as that cost. But within the hackathon, we couldn’t test how the extra step affected drop-off or completion rates.

Looking Back Now

There were ways to avoid adding another screen altogether. We could have placed the notice about multiple nationalities within an existing screen, or shown it only after the destination was known and nationality would actually change the guidance.

Today, I would explore the first option before adding a separate screen. A dedicated notice interrupts everyone’s flow, while an inline notice could surface the exception without creating another step. Back then, we added a screen to avoid overlooking 0.4% of users. Now, I would first ask not whether to add another screen, but where the notice could live while disrupting the fewest people.