UX Research - International Design
What happens when your usersdon't speak your language (literally)
I've spent 16+ years designing for users across Turkey, Germany, and a dozen countries in between. Aviation passengers booking in three different languages. Insurance clients navigating German bureaucracy in their second language. Health tourism patients trying to understand a price quote from a hospital in a country they've never visited.
Here's what I've learned: designing for international, multilingual audiences isn't just about translating the text. It's about questioning almost every assumption you made when you built the thing in the first place.
Localization is changing the words. Internationalization is changing the thinking. Most products do the first and skip the second entirely.
The date format that costs airlines money
During my time consulting for Turkish Airlines, one issue came up repeatedly in usability feedback: passengers booking international flights were selecting the wrong date. Not because the calendar was broken. Because 06/07 means June 7th in the US and July 6th in most of Europe and Turkey.
A passenger seeing "06/07" reads it through the lens of their own date format convention. Always. They don't stop to check which system the interface is using. Why would they? Every other date in their life works the way they expect.
The fix sounds simple: use unambiguous date formats. "7 Jun 2024" instead of "06/07/24". But here's the thing - this wasn't in the brief. Nobody asked us to fix date formatting. It surfaced through user research, through reading support tickets, through asking why people were calling customer service to change their bookings. The interface "worked". The users were just silently getting it wrong.
Names that don't fit your form
Airline booking forms have a particular obsession with name fields. First name. Last name. Middle name. Sometimes title. Sometimes suffix. The form is designed around a Western naming convention that doesn't apply to a huge portion of the world's population.
In Turkey, many people have names that don't map cleanly onto "first/last" - particularly older generations. In many East Asian cultures, the family name comes first, not last. In some cultures, people use a single name with no surname at all. In Germany, the concept of "Geburtsname" (birth name vs. current legal name) creates complexity that a single "Last name" field simply can't capture.
What happens when your form rejects a valid legal name because it's too long, contains characters outside the ASCII set, or doesn't fit the first/last structure? The user finds a workaround. They truncate their name. They transliterate characters incorrectly. And then their passport doesn't match their ticket. And then they miss their flight.
This is not a hypothetical. It happens. The form wasn't wrong in the developer's mental model. It was just built for one version of the world.
What "professional" looks like depends on where you're from
I'm now working on health tourism platform design with international users, I noticed something in our research that I hadn't anticipated: what users perceived as "trustworthy" and "professional" in an interface varied significantly by country.
German users tended to trust dense, information-heavy layouts - a page with lots of detail signalled thoroughness and reliability. Users from other markets sometimes perceived the same layout as overwhelming or bureaucratic, preferring cleaner, more visual interfaces with less text.
Turkish users - particularly older demographics - placed high trust in interfaces that used formal language and included explicit assurances. English-language interfaces often felt too casual. The same copy that felt warm and approachable to a British user felt informal and therefore less trustworthy to some Turkish users.
None of this is a rule. None of it is a stereotype. It's just the reality that visual language carries cultural meaning that designers often don't see because they're inside their own cultural context. The only way to see it is to do the research with real users from the actual markets you're designing for.
The invisible problem: text expansion
German UI copy is almost always longer than English UI copy. Sometimes significantly. "Settings" in English is 8 characters. "Einstellungen" in German is 13. "Submit" is 6. "Absenden" is 8. "Continue" is 8. "Weiter" is 6 - actually shorter that time. But "Forgot your password?" is 21 characters. "Haben Sie Ihr Passwort vergessen?" is 33.
When a UI is designed in English and then translated to German, buttons overflow. Navigation items wrap. Truncation kicks in at the wrong moment. The UI that looked balanced in English starts to feel cramped, misaligned, or broken in German. And then someone decides to just make the German text smaller. Which is how you end up with a WCAG contrast failure in every German language version of a product originally designed for English speakers.
The fix is to design for expansion from the start. Assume your UI copy will be 30-40% longer in German. Give buttons room to breathe. Don't hardcode container widths around English copy length. This is one of the places where designing mobile-first genuinely helps - constrained layouts designed for small screens tend to handle text expansion more gracefully than desktop-first layouts where space felt infinite.
Being multilingual makes you a better designer
I work in Turkish, German, and English. Switching between them daily has made me permanently aware that every word choice, every label, every piece of UI copy is a translation of an idea - and translations can fail.
When I write UI copy in English and then mentally translate it to Turkish to check it, I often catch problems the English version hid. A label that was clear in English becomes ambiguous in Turkish. A button that felt decisive in English feels abrupt in German. A confirmation message that was reassuring in English sounds bureaucratic in Turkish.
You don't have to be trilingual to do this. But you do have to get your UI copy in front of real users from your actual markets before you ship it. Not after. Not as a localization QA step. During the design process, when you can still change things without breaking a build.
Practical checklist
Before shipping any international-facing UI: check date formats are unambiguous, name fields accept long names and non-ASCII characters, UI copy has been reviewed by a native speaker in each language, buttons and labels have been tested with 30% longer text, and trust signals (security badges, certifications, formal language) match what your specific market expects.
more to discover
UX Analysis - Heuristics
Revamping Slack for Better Team Communication
I'm not picking on Slack. I'm a fan. But the best tools deserve honest critique - that's how they get better.
Read More
Personal - Creative - Music
Playing in a band made me a better
UX designer. I am serious.
Nobody in a band ever said "I think we should add more here." The best musicians are the ones who know when to stop.
Read More
UX Research - International Design
What happens when your usersdon't speak your language (literally)
I've spent 16+ years designing for users across Turkey, Germany, and a dozen countries in between. Aviation passengers booking in three different languages. Insurance clients navigating German bureaucracy in their second language. Health tourism patients trying to understand a price quote from a hospital in a country they've never visited.
Here's what I've learned: designing for international, multilingual audiences isn't just about translating the text. It's about questioning almost every assumption you made when you built the thing in the first place.
Localization is changing the words. Internationalization is changing the thinking. Most products do the first and skip the second entirely.
The date format that costs airlines money
During my time consulting for Turkish Airlines, one issue came up repeatedly in usability feedback: passengers booking international flights were selecting the wrong date. Not because the calendar was broken. Because 06/07 means June 7th in the US and July 6th in most of Europe and Turkey.
A passenger seeing "06/07" reads it through the lens of their own date format convention. Always. They don't stop to check which system the interface is using. Why would they? Every other date in their life works the way they expect.
The fix sounds simple: use unambiguous date formats. "7 Jun 2024" instead of "06/07/24". But here's the thing - this wasn't in the brief. Nobody asked us to fix date formatting. It surfaced through user research, through reading support tickets, through asking why people were calling customer service to change their bookings. The interface "worked". The users were just silently getting it wrong.
Names that don't fit your form
Airline booking forms have a particular obsession with name fields. First name. Last name. Middle name. Sometimes title. Sometimes suffix. The form is designed around a Western naming convention that doesn't apply to a huge portion of the world's population.
In Turkey, many people have names that don't map cleanly onto "first/last" - particularly older generations. In many East Asian cultures, the family name comes first, not last. In some cultures, people use a single name with no surname at all. In Germany, the concept of "Geburtsname" (birth name vs. current legal name) creates complexity that a single "Last name" field simply can't capture.
What happens when your form rejects a valid legal name because it's too long, contains characters outside the ASCII set, or doesn't fit the first/last structure? The user finds a workaround. They truncate their name. They transliterate characters incorrectly. And then their passport doesn't match their ticket. And then they miss their flight.
This is not a hypothetical. It happens. The form wasn't wrong in the developer's mental model. It was just built for one version of the world.
What "professional" looks like depends on where you're from
I'm now working on health tourism platform design with international users, I noticed something in our research that I hadn't anticipated: what users perceived as "trustworthy" and "professional" in an interface varied significantly by country.
German users tended to trust dense, information-heavy layouts - a page with lots of detail signalled thoroughness and reliability. Users from other markets sometimes perceived the same layout as overwhelming or bureaucratic, preferring cleaner, more visual interfaces with less text.
Turkish users - particularly older demographics - placed high trust in interfaces that used formal language and included explicit assurances. English-language interfaces often felt too casual. The same copy that felt warm and approachable to a British user felt informal and therefore less trustworthy to some Turkish users.
None of this is a rule. None of it is a stereotype. It's just the reality that visual language carries cultural meaning that designers often don't see because they're inside their own cultural context. The only way to see it is to do the research with real users from the actual markets you're designing for.
The invisible problem: text expansion
German UI copy is almost always longer than English UI copy. Sometimes significantly. "Settings" in English is 8 characters. "Einstellungen" in German is 13. "Submit" is 6. "Absenden" is 8. "Continue" is 8. "Weiter" is 6 - actually shorter that time. But "Forgot your password?" is 21 characters. "Haben Sie Ihr Passwort vergessen?" is 33.
When a UI is designed in English and then translated to German, buttons overflow. Navigation items wrap. Truncation kicks in at the wrong moment. The UI that looked balanced in English starts to feel cramped, misaligned, or broken in German. And then someone decides to just make the German text smaller. Which is how you end up with a WCAG contrast failure in every German language version of a product originally designed for English speakers.
The fix is to design for expansion from the start. Assume your UI copy will be 30-40% longer in German. Give buttons room to breathe. Don't hardcode container widths around English copy length. This is one of the places where designing mobile-first genuinely helps - constrained layouts designed for small screens tend to handle text expansion more gracefully than desktop-first layouts where space felt infinite.
Being multilingual makes you a better designer
I work in Turkish, German, and English. Switching between them daily has made me permanently aware that every word choice, every label, every piece of UI copy is a translation of an idea - and translations can fail.
When I write UI copy in English and then mentally translate it to Turkish to check it, I often catch problems the English version hid. A label that was clear in English becomes ambiguous in Turkish. A button that felt decisive in English feels abrupt in German. A confirmation message that was reassuring in English sounds bureaucratic in Turkish.
You don't have to be trilingual to do this. But you do have to get your UI copy in front of real users from your actual markets before you ship it. Not after. Not as a localization QA step. During the design process, when you can still change things without breaking a build.
Practical checklist
Before shipping any international-facing UI: check date formats are unambiguous, name fields accept long names and non-ASCII characters, UI copy has been reviewed by a native speaker in each language, buttons and labels have been tested with 30% longer text, and trust signals (security badges, certifications, formal language) match what your specific market expects.
more to discover
UX Analysis - Heuristics
Revamping Slack for Better Team Communication
I'm not picking on Slack. I'm a fan. But the best tools deserve honest critique - that's how they get better.
Read More
Personal - Creative - Music
Playing in a band made me a better
UX designer. I am serious.
Nobody in a band ever said "I think we should add more here." The best musicians are the ones who know when to stop.
Read More
UX Research - International Design
What happens when your usersdon't speak your language (literally)
I've spent 16+ years designing for users across Turkey, Germany, and a dozen countries in between. Aviation passengers booking in three different languages. Insurance clients navigating German bureaucracy in their second language. Health tourism patients trying to understand a price quote from a hospital in a country they've never visited.
Here's what I've learned: designing for international, multilingual audiences isn't just about translating the text. It's about questioning almost every assumption you made when you built the thing in the first place.
Localization is changing the words. Internationalization is changing the thinking. Most products do the first and skip the second entirely.
The date format that costs airlines money
During my time consulting for Turkish Airlines, one issue came up repeatedly in usability feedback: passengers booking international flights were selecting the wrong date. Not because the calendar was broken. Because 06/07 means June 7th in the US and July 6th in most of Europe and Turkey.
A passenger seeing "06/07" reads it through the lens of their own date format convention. Always. They don't stop to check which system the interface is using. Why would they? Every other date in their life works the way they expect.
The fix sounds simple: use unambiguous date formats. "7 Jun 2024" instead of "06/07/24". But here's the thing - this wasn't in the brief. Nobody asked us to fix date formatting. It surfaced through user research, through reading support tickets, through asking why people were calling customer service to change their bookings. The interface "worked". The users were just silently getting it wrong.
Names that don't fit your form
Airline booking forms have a particular obsession with name fields. First name. Last name. Middle name. Sometimes title. Sometimes suffix. The form is designed around a Western naming convention that doesn't apply to a huge portion of the world's population.
In Turkey, many people have names that don't map cleanly onto "first/last" - particularly older generations. In many East Asian cultures, the family name comes first, not last. In some cultures, people use a single name with no surname at all. In Germany, the concept of "Geburtsname" (birth name vs. current legal name) creates complexity that a single "Last name" field simply can't capture.
What happens when your form rejects a valid legal name because it's too long, contains characters outside the ASCII set, or doesn't fit the first/last structure? The user finds a workaround. They truncate their name. They transliterate characters incorrectly. And then their passport doesn't match their ticket. And then they miss their flight.
This is not a hypothetical. It happens. The form wasn't wrong in the developer's mental model. It was just built for one version of the world.
What "professional" looks like depends on where you're from
I'm now working on health tourism platform design with international users, I noticed something in our research that I hadn't anticipated: what users perceived as "trustworthy" and "professional" in an interface varied significantly by country.
German users tended to trust dense, information-heavy layouts - a page with lots of detail signalled thoroughness and reliability. Users from other markets sometimes perceived the same layout as overwhelming or bureaucratic, preferring cleaner, more visual interfaces with less text.
Turkish users - particularly older demographics - placed high trust in interfaces that used formal language and included explicit assurances. English-language interfaces often felt too casual. The same copy that felt warm and approachable to a British user felt informal and therefore less trustworthy to some Turkish users.
None of this is a rule. None of it is a stereotype. It's just the reality that visual language carries cultural meaning that designers often don't see because they're inside their own cultural context. The only way to see it is to do the research with real users from the actual markets you're designing for.
The invisible problem: text expansion
German UI copy is almost always longer than English UI copy. Sometimes significantly. "Settings" in English is 8 characters. "Einstellungen" in German is 13. "Submit" is 6. "Absenden" is 8. "Continue" is 8. "Weiter" is 6 - actually shorter that time. But "Forgot your password?" is 21 characters. "Haben Sie Ihr Passwort vergessen?" is 33.
When a UI is designed in English and then translated to German, buttons overflow. Navigation items wrap. Truncation kicks in at the wrong moment. The UI that looked balanced in English starts to feel cramped, misaligned, or broken in German. And then someone decides to just make the German text smaller. Which is how you end up with a WCAG contrast failure in every German language version of a product originally designed for English speakers.
The fix is to design for expansion from the start. Assume your UI copy will be 30-40% longer in German. Give buttons room to breathe. Don't hardcode container widths around English copy length. This is one of the places where designing mobile-first genuinely helps - constrained layouts designed for small screens tend to handle text expansion more gracefully than desktop-first layouts where space felt infinite.
Being multilingual makes you a better designer
I work in Turkish, German, and English. Switching between them daily has made me permanently aware that every word choice, every label, every piece of UI copy is a translation of an idea - and translations can fail.
When I write UI copy in English and then mentally translate it to Turkish to check it, I often catch problems the English version hid. A label that was clear in English becomes ambiguous in Turkish. A button that felt decisive in English feels abrupt in German. A confirmation message that was reassuring in English sounds bureaucratic in Turkish.
You don't have to be trilingual to do this. But you do have to get your UI copy in front of real users from your actual markets before you ship it. Not after. Not as a localization QA step. During the design process, when you can still change things without breaking a build.
Practical checklist
Before shipping any international-facing UI: check date formats are unambiguous, name fields accept long names and non-ASCII characters, UI copy has been reviewed by a native speaker in each language, buttons and labels have been tested with 30% longer text, and trust signals (security badges, certifications, formal language) match what your specific market expects.
more to discover
UX Analysis - Heuristics
Revamping Slack for Better Team Communication
I'm not picking on Slack. I'm a fan. But the best tools deserve honest critique - that's how they get better.
Read More
Personal - Creative - Music
Playing in a band made me a better
UX designer. I am serious.
Nobody in a band ever said "I think we should add more here." The best musicians are the ones who know when to stop.