The first thing I noticed when I moved to Los Angeles was how American financial interfaces feel. I had opened a new bank account within two weeks of arriving, and the app was clean, friendly, almost cheerful about money. Big numbers, rounded corners, green everywhere. A far cry from the dense, serious layouts I had spent three years designing for institutional investors across Europe and the Middle East. That contrast stuck with me. Not as criticism, just as reminder that the way we design financial products is deeply shaped by where we are. And when your product has to work across fifteen countries simultaneously, that becomes real engineering problem. Not philosophical one. VALK served institutions across the UK, continental Europe, the Middle East, North America, and parts of Latin America. Seventy-plus investment banks, hedge funds, and asset managers, each operating under different regulators, using different conventions, carrying different cultural expectations about what a "serious" financial interface looks like. For most of my time there, I was the only designer. So I had to figure out how to handle all of this without creating fifteen separate products. Localization is not translation This is the thing people get wrong first. They think localization means you take your strings, send them to translator, and the job is done. That's barely twenty percent of the work. Real localization is about information hierarchy. What data a user expects to see first. How they read a table. Whether they trust a minimalist layout or find it suspicious. Languages change the shape of text, German financial terms are long, Arabic flows right to left, Russian uses completely different number grouping conventions. Each of these requires actual design decisions, not just string swaps. When I first approached this problem in 2020, I made the mistake of thinking about localization as a final step, something you handle after the real design is done. By 2022, after working with clients from Riyadh, Zurich, São Paulo, and London in the same quarter, I understood that localization has to be structural decision you make at the component level. The small things that are actually huge problems Let me be specific, because vague advice about "cultural sensitivity" is not useful. Date formats. This one caused an actual support incident. We had a data room where documents showed a signing date. In the UK, 06/07/2021 means the seventh of June. In the US, it means the sixth of July. In some of our middleware logging, we were getting ISO 8601 (YYYY-MM-DD), what the backend engineers defaulted to. Three different formats, one field, one very confused client in New York looking at what appeared to be backdated document. The solution sounds simple: always display dates with the month written out, or always use the locale-appropriate format explicitly. But that requires every date component in your design system to accept a locale parameter, which means you have to design for that from the start. If you bolt it on later, you end up with patchwork of inconsistent date displays across different parts of the product. Currency formatting. In the US: $1,000,000.00. In most of continental Europe: 1.000.000,00 €. In Russia, when I was still working from there: 1 000 000,00 ₽ with space as the thousands separator. Show European institutional investor a large number formatted the American way and they will pause. Small cognitive friction, but in product built around trust, you really cannot afford it. I built currency display as dedicated component in Figma, with variants for locale. Not because Figma renders these differently, it doesn't, but because it forced every screen that showed a financial number to explicitly declare its formatting intent. When the developer implements it, the decision is already made. No ambiguity in the handoff. Number density is harder to quantify but it's real. When we were working with clients from East Asian financial institutions, the feedback I got, through the CEO relaying conversations, was that the dashboards felt "light." Not enough information visible at once. These were users accustomed to dense terminal-style interfaces. Meanwhile, some of our Nordic clients felt the same dashboards were too busy. They wanted one key number and then progressive disclosure to get deeper. There is no layout that serves both of these users equally. What you can do is design flexible information architecture, modules that can be shown or hidden, table columns that can be configured, and then set sensible regional defaults. RTL, the one that changes everything Arabic is the case that forces you to actually think about your layout assumptions. We had client in the Middle East, and even though their internal interface language was English, we were anticipating growth in markets where Arabic support would matter. I started doing the mirroring exercise as thought experiment first. Take a screen, flip everything horizontally. Navigation goes from left to right. Tables align from right to left. Icons that imply direction, arrows, chevrons, progress indicators, all need to be reconsidered. The first time I mirrored one of our deal room layouts, I found about eight places where I had hardcoded directional assumptions that had nothing to do with text. A document progress bar that animated left-to-right. Sidebar visually anchored to the left. Tab navigation that opened to the right. None of these were text elements. All of them needed adjustment. RTL support is not just a CSS direction: rtl property. It requires designing bidirectional-aware components from the beginning, or going back and rebuilding. I have seen teams defer this until they have real paying client who needs it, then spend three months untangling assumptions that were baked in from day one. direction: rtl Regulatory differences that affect the actual UI This is the one that surprised me most when I first started working in fintech. I came from agency background where the client tells you what to show, and you show it. In regulated financial products, what you are allowed to show, and what you are required to show, differs by jurisdiction. In the UK, under FCA regulations, certain risk disclosures need to be visible at specific points in a transaction flow. The exact wording, placement, and visibility requirements are specified. You cannot tuck disclaimer in a footer and call it done. Switzerland has different norms around what performance data can be displayed before a user has been properly classified as qualified investor. Show the wrong number to the wrong user type, and it is compliance issue, not just a design decision. What this meant in practice: some UI elements existed in some regional configurations and were literally absent in others. Not hidden behind a click, not visually suppressed, structurally absent for certain jurisdictions. This pushed me toward configuration-driven design approach. Components needed to be built as if they could be switched on or off per region, per user type, per regulatory requirement. Designing for this is humbling. You realize the "clean, simple" interface you want to build is actually a series of conditional states, each driven by rules that live outside of your Figma file. Color and trust Red means "stop" or "bad" in most Western financial interfaces. Portfolio is down, you show red. Risk warning, red. Error state, red. In some East Asian financial cultures, red is traditionally associated with luck and positive outcomes. It's the color of profit in some markets, Hong Kong being the most-cited example, where red on a stock chart means the price went up. I am not saying you should redesign your entire color system for every regional market. But it is worth knowing when you are making cultural assumption versus universal one. If you are building for single market, your color conventions can be local. If you are building for fifteen, you should at least be intentional about which conventions you are defaulting to and why. We kept green/red as the primary gain/loss indicators because our primary market was UK and European institutions. But I flagged it as known limitation in the design documentation, noting that any future expansion into East Asian retail markets would need review of this system. How I organized Figma to not lose my mind The practical question: how do you manage this in real design file without duplicating everything six times? My approach was design tokens plus component configuration, not separate files per region. In Figma, I maintained core component library that was region-agnostic at the structural level. Number display components accepted format parameters. Date components had locale variants in their properties. Direction-sensitive icons had mirrored versions as separate component variants, selectable with one click. Then I had separate "regional configuration" page in the file, not a real design deliverable, more of a reference document. It mapped out which component variants were active in which configurations: UK flow, EU flow, MENA flow, US flow. Mostly for me, and for whoever was implementing. It made the conditional logic visible without needing to maintain fifteen separate design files. The danger of managing this in Figma is that you can accidentally create drift, the UK version gets a change that never propagates to the EU version. My solution was to treat the component library as source of truth for structure, and the regional configuration as source of truth for what gets used where. Any structural change to a component would automatically affect all regional variants because they all used the same component. Regional differences were expressed only through configuration choices, not through structural changes. Easier to say than to maintain, honestly. When you are moving fast and there is only one of you, shortcuts happen. But the principle held. What moving countries taught me about design I have been thinking about this more since arriving in Los Angeles. I grew up in Russia, worked from Saint Petersburg, spent time in Phuket, few months in Bali during the early pandemic, then Alanya and Istanbul. Each place had its own relationship to money, to what financial interfaces felt like, what felt trustworthy, what felt suspicious. In Turkey, during the inflation period in 2021, the relationship to currency was different. Numbers moved fast. People were accustomed to seeing prices change and tracking exchange rates closely. Dashboard that showed only today's value without historical context would have felt incomplete. In the US, I notice that financial products are built around optimism and simplicity. The UI encourages you to not look too closely, to trust the system, to feel good about investing. European and especially UK institutional products feel different, more serious, more disclosure-heavy, more skeptical of the user. Neither is wrong. They reflect real cultural differences in how people relate to financial institutions and financial risk. But understanding those differences, not as tourist, but as someone who has actually lived in different places and opened bank accounts and used local financial apps, has been useful in my design work in ways that reading about cultural UX differences in articles never fully was. The move to LA coincided with me starting to think more carefully about US market as design context in its own right. Americans are not Europeans who happen to speak English. Their expectations for financial interfaces, their trust patterns, their tolerance for risk and disclosure, these are different. And I am only starting to understand this from the inside. There is probably no final solution to designing for fifteen countries. Scope of difference is too large to fully systematize. What you can do is build systems that are honest about the variations, that encode the regional decisions explicitly rather than pretending there is universal interface that works everywhere. The day you stop treating localization as afterthought and start treating it as structural design requirement is the day your international product starts to actually work internationally. For me, that realization came late. But it came.

Dash

Figma

What Really Happens When You Stop Posting on X for 2 Months

Portfolio

Designing Fintech Across Fifteen Countries

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Accessible Data Visualization in Fintech: Why It Matters

A Breakdown of Software Development Types for Small Businesses

Applications of (pin)trace data

Building a RESTful API Service in Go Without Having Repetitive Boilerplate

Building a Scalable Node Abstract Repository for MongoDB

Building a Secure Web Chat With Redis, mTLS and GCP

Accessible Data Visualization in Fintech: Why It Matters

A Breakdown of Software Development Types for Small Businesses

Applications of (pin)trace data

Building a RESTful API Service in Go Without Having Repetitive Boilerplate

Building a Scalable Node Abstract Repository for MongoDB

Building a Secure Web Chat With Redis, mTLS and GCP

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps