Insights

Writing on complex product design.

Articles on product design, UX architecture, design systems, and complex enterprise systems - organized by persona and topic, drawn from real projects.

12 articles

Menora Insurance

Engineering LeadersInternationalization (i18n)

i18n Starts in the Layout, Not the String Table

i18n is not a string table. Designing Hebrew-first, RTL interfaces for Menora taught me the expensive part is structural — label placement, filter alignment, data tables, which way affordances point. None of that is fixed by a translation layer. To CTOs: bake direction-neutrality into your components, not into late patches. The teams that internationalize cheaply designed the skeleton to flex from day one.

Read

Ministry of Defense

Engineering LeadersInternationalization (i18n)

Designing a Portal That Doesn't Assume One Direction

For an Israeli government portal, i18n isn't just a translation table - it's a direction problem. The Ministry of Defense site had to hold its institutional authority in Hebrew's right-to-left layout, not just the left-to-right conventions designers default to. So I described spacing and alignment in logical start/end terms rather than fixed left/right, so the visual system doesn't quietly break when direction flips. The lesson for any R&D team: make direction-awareness a property of the design system from the first screen, because retrofitting it later is expensive and visible.

Read

Academic & Research Systems

Engineering LeadersInternationalization (i18n)

i18n for Research Platforms Is a Data Problem, Not a String Problem

For research software, i18n is not a string problem — it's a data problem. Decimal separators, units, date formats, collation: get them wrong in a data-heavy tool and you don't have a cosmetic glitch, you have a corrupted dataset. Separate display formatting from canonical stored values, centralize it, and budget it as core infrastructure. For scientists, data integrity IS the product.

Read

Hacker U

Engineering LeadersInternationalization (i18n)

Designing the HackerU Site So i18n Wasn't a Rewrite

Most i18n pain isn't linguistic — it's structural, and it lands on engineering. The HackerU site is Hebrew-first, so RTL is the native direction, not a retrofit. That forces real discipline in the design system: direction-aware spacing tokens, mirrored navigation, components that handle variable string length — especially on dense surfaces like the course page. Build components that assume direction and text length early, and internationalization stops being a migration. It becomes a setting.

Read

Government & Public Sector

Engineering LeadersInternationalization (i18n)

i18n Is an Architecture Decision, Not a Translation Task

The i18n wall every public-sector CTO eventually hits: it was treated as a translation pass at the end, and now half the UI breaks in the second language. Serving citizens in their own language is often a legal obligation, not a nice-to-have — so i18n has to be a load-bearing architecture decision from commit one. No concatenated strings. No text in images. Layouts that survive a much longer label. RTL designed in, not patched on. And language attributes correct, because screen readers depend on them. Done right, i18n is invisible and cheap. Done late, it's a tax on every feature you ship after. Pay it early.

Read

Shomrat Hazorea

Engineering LeadersInternationalization (i18n)

Designing the Furniture Platform So i18n Isn't a Rewrite

i18n on an Israeli furniture platform doesn't start with 'maybe we expand later.' It starts with Hebrew being right-to-left. Our guided selling flow — conversational cards, a live results feed, a deep configuration drill-down from fabric to foam — is precisely the UI that breaks ugly when direction and strings are bolted on after the fact. The concern I kept raising with engineering wasn't translation cost. It was structural debt: are we hard-coding layout direction into components, or letting the design system resolve it as an input? The cheapest internationalization is the architecture that never assumed one language in the first place.

Read

Marketing & Campaign Analytics

Engineering LeadersInternationalization (i18n)

Designing MarTech Dashboards for Internationalization

i18n in an analytics product is not a translation layer you bolt on later. Interpreted insights are full sentences — and sentences expand, contract, and flip direction across languages. If your insight cards have fixed widths or truncate, every new market becomes a layout bug. For engineering leaders: treat locale as part of the data contract, not a presentation afterthought. Get it right early and i18n becomes configuration instead of a rewrite.

Read

Beehive

Engineering LeadersInternationalization (i18n)

Designing Beehive So i18n Wouldn't Be a Rebuild

i18n is rarely a launch requirement. It's almost always a future one — and CTOs pay when it's bolted on late. For Beehive, I designed the site and dashboard so internationalization stayed an option, not a rebuild: flexible containers that survive text expansion, no copy fused into imagery, strings separated from structure in the Design System. We didn't commit to multilingual on day one. We just made sure the day it's wanted, it's a content task — not a structural one.

Read

Movement

Engineering LeadersInternationalization (i18n)

Designing So i18n Stays a Constraint, Not a Retrofit

For an app like Movement (Ichilov's patient checkup product), i18n is never far off — Hebrew means RTL, and a working-population patient base isn't single-language for long. I won't pretend localization was the headline here, but the design discipline matters: think in logical start/end instead of hard-coded left/right, leave room for text expansion (translations rarely match source length), and keep meaning out of icons. The riskiest surface is the dense, status-driven dashboard — mirrored layouts break alignment there first. The takeaway for engineering leaders: i18n debt is cheapest to prevent at the design-system level. Direction-aware, text-tolerant components turn 'add a language' into a content task, not a re-architecture.

Read

Enterprise Mobile

Engineering LeadersInternationalization (i18n)

i18n for Frontline Apps Is a Field Problem, Not a String Table

For frontline B2E apps, i18n is the easiest thing to underestimate. Your most linguistically diverse users are often on the shop floor — multiple languages per shift, mixed literacy, RTL layouts nobody tested. Treat it as architecture, not a pre-launch string pass. Flow your layouts (German runs long, Arabic runs right-to-left). Prefer camera/GPS/QR over text. Ship locale data inside the offline bundle — you can't download a language pack in a dead zone. Retrofitting i18n always costs more than designing for it.

Read

Shibolet & Co.

Engineering LeadersInternationalization (i18n)

Hebrew-First, Built to Bend

i18n isn't a translation pass — it's a structural posture. For Shibolet's internal hub, Hebrew was the native experience, so RTL had to be first-class, not a mirrored afterthought. The hard part: a feed mixing warm social posts with formal firm notices, plus inline English terms, all reading naturally in both directions. Localize the structure, not just the strings. Then the foundation bends instead of breaking when scope grows.

Read

Zammit

Engineering LeadersInternationalization (i18n)

i18n Inside a Configurator Engine's Constraints

i18n in a configurator platform isn't a translation problem. It's an architecture problem. On Zammit, much of the user-facing language and option logic lived inside the DriveWorks configurator engine — not a tidy front-end string table. That changes everything: option labels, units, edge-profile terminology, manufacturing validation messages, and the checkout/OTP/tracking flows all cross that boundary. For CTOs: decide early what is localizable vs engine-bound. Retrofitting that split is brutal. Plan for string expansion reflow on mobile. And keep domain terms consistent across the configurator and the commerce surface. Localization fails quietly when one product ends up speaking two languages.

Read