What UI/UX Designer Interviews Actually Test in 2026

UX is the structure underneath, how a user moves through a task, what they need at each step, whether the flow makes sense at all. UI is the surface that structure gets expressed through, color, type, spacing, the specific visual language. A screen can be visually polished and still fail on UX if the flow itself doesn't match how a user actually thinks about the task.

The follow-up interviewers almost always ask: give an example where good UI couldn't save bad UX. A beautifully designed checkout form still fails if it asks for shipping address before the user has decided what they're buying.

Finished isn't "I ran out of ideas." It's when the design solves the defined problem within the agreed constraints and the remaining changes would be polish, not fixes. Tie it to a specific signal: usability testing stopped surfacing new issues, or the design meets the acceptance criteria the team agreed to upfront.

Candidates who say "when it feels right" without a concrete stopping condition tend to get pushed on this hard. Interviewers want to hear that you can ship something imperfect on purpose, not that you chase an undefined bar forever.

Diverge wide first, three to five genuinely different directions, not three variations of the same idea with the button moved. Then narrow using a stated criteria, feasibility, user feedback, alignment with the product's existing patterns, rather than picking whichever direction you personally like best.

Interviewers who've reviewed a lot of portfolios can usually tell when "exploration" was really one idea dressed up three different ways after the fact. Real divergence tends to include at least one direction the candidate ultimately rejects and can explain why.

A design sprint (the Google Ventures five-day format most people mean by this) compresses divergence, decision, prototyping, and testing into one tight, time-boxed week with a cross-functional team in the room the whole time. A normal process runs longer, involves more iteration, and usually doesn't have everyone blocked off from other work simultaneously.

Interviewers ask this to check whether a candidate treats "design sprint" as a buzzword or has actually run one. Vague answers that describe a regular project timeline and call it a sprint are an easy tell.

Anchor feedback to the problem the design is trying to solve, not personal taste. "I'd have made the button blue" isn't useful. "This doesn't address how a user would recover from an error mid-flow" is.

Interviewers at companies with a real critique culture want to see that a candidate can separate "different from what I'd do" from "actually doesn't work," since conflating the two is one of the fastest ways to make design reviews unproductive.

Interviews get you depth, the why behind a behavior, and they work well early when you don't yet know what questions matter. Surveys get you breadth, confirming a pattern across a larger group, and they work better once you already have a hypothesis worth testing at scale.

A common mistake: running a survey to explore an open-ended question, which mostly produces answers people think they should give rather than what they'd actually do. Interviews are slower but harder to fake your way through, for the participant and the researcher both.

A persona is a composite representation of a user segment, built from real research, not a stock photo with a made-up name and a coffee preference. They're useful for keeping a team aligned on who they're designing for when decisions get made without research present in the room.

They stop being useful the moment they calcify, when a team defends a decision by pointing at "what Sarah would want" instead of going back to actual users. Good candidates flag this tension unprompted, since a persona built from six-month-old research can quietly become fiction.

Five for a qualitative usability round, per the widely cited Nielsen Norman Group research, since the goal there is surfacing problems, not measuring frequency precisely. Quantitative studies where you need statistically meaningful numbers, like a survey measuring satisfaction across a segment, need a much larger sample, often 20 or more depending on the effect size you're trying to detect.

Candidates who answer "5" for every kind of research haven't fully absorbed why the number is 5 in the first place. It's specific to a particular research goal, not a universal constant.

Moderated testing, a researcher present live, gets you the ability to ask follow-up questions in the moment and probe confusion as it happens. Unmoderated testing, participants complete tasks on their own time through a tool, scales faster and cheaper but you lose the ability to dig into a surprising reaction.

Pick moderated for early-stage, exploratory research where the unknowns are still fuzzy. Pick unmoderated once you have a specific, well-defined task and want a larger sample without the time cost of running every session live.

Wireframes are low-fidelity structure, layout and hierarchy without visual polish, used to nail the flow before anyone argues about color. Mockups are high-fidelity static screens, the actual visual design applied to that structure. Prototypes are interactive, letting someone click or tap through a flow to feel how it behaves, not simply how it looks.

Interviewers use this question to check whether a candidate skips wireframes entirely and jumps straight to polished screens, a habit that tends to produce beautiful designs built on an unvalidated flow.

Design the smallest, most constrained viewport first, then expand, rather than designing desktop and shrinking it down afterward. Content and hierarchy decisions made under mobile's real constraints, limited space, thumb reach, tend to hold up well when scaled up. The reverse rarely works cleanly.

Interviewers listen for whether a candidate treats "responsive" as a checkbox at the end or a constraint baked into the design decisions from the start, since those produce visibly different results.

Start from function, not preference: what needs to communicate hierarchy, what needs to signal state (error, success, warning), what needs to stay legible at small sizes across devices. Accessibility constraints, contrast ratios especially, narrow the palette before aesthetics enter the conversation.

A palette chosen purely on taste tends to fall apart the first time it needs to express a state nobody planned for, an error red that doesn't actually meet contrast requirements against the background it ends up used on.

Catching the gap between what was designed and what actually got built. Spacing that's slightly off, a state that got skipped, a font weight that doesn't match, small individually, but they compound into a product that feels less polished than the design file promised.

Skipping design QA is a common corner cut under deadline pressure, and it's usually a false economy, since the fixes found late cost more engineering time than the same fixes caught before release.

Generic answers about "great culture" or "exciting mission" are transparent and forgettable. A specific product opinion, something you'd change, something you think they've gotten right that competitors haven't, shows you've actually used the product and formed a real point of view before the interview.

This is one of the most underprepared questions in every design loop, not because it's hard, but because candidates assume it doesn't matter as much as the portfolio review. Interviewers weight it more than candidates expect.

Pick the project with the most interesting trade-offs or the messiest middle, not necessarily the most visually polished final screens. Interviewers who ask this directly are signaling they want depth on process and decisions, not a tour of your best-looking case study.

A candidate who picks the project they're proudest of aesthetically, but can't go deep on the actual decisions behind it, usually gets found out within two or three follow-up questions.

Name the actual problem before the solution: who had it, how you knew it was real (a support ticket count, a research finding, a metric), and what constraint shaped the work, a deadline, an engineering limitation, a legal requirement. Then walk the decisions, not just the steps. "I did research, then wireframes, then hi-fi" tells an interviewer nothing about how you think.

The strongest answers name at least one thing that changed mid-project because of new information, and say what that information was. A process with zero course corrections either means the project was trivial or the story is polished past the point of being believable.

Rank by a real framework, impact against effort, or user reach against business urgency, and say it out loud instead of trusting gut feel silently. Then name which three you're not doing and why, since the interesting part of prioritization is what gets cut, not what gets picked.

Weak answers dodge the "no." Strong answers describe how they communicated the cut to whoever asked for it, and what happened when that person pushed back.

Separate what needs full research and iteration from what can ship as a smaller, well-scoped slice this sprint. A redesign of an entire settings page doesn't fit two weeks. One flow inside it, with a clear before-and-after, usually does.

Good answers mention negotiating scope with engineering and product early, not discovering the mismatch on day nine. That's not really a test of design skill. It asks whether you've actually shipped inside a real sprint cadence before.

Look at whether the problem is inside the existing structure or caused by the structure itself. A confusing button label is a quick fix. A flow that requires five screens for a task that should take one is a structural problem no amount of copy tweaking solves.

The honest answer includes cost. A structural change is more disruptive to ship and harder to sell to a roadmap. Candidates who name that trade-off explicitly, and who've actually had to make the case for a bigger change, tend to stand out here.

Bring evidence. An opinion alone rarely survives real pushback. A usability finding, a data point, a comparable pattern from a product both of you respect. Interviewers want to see that you can hold a position under pushback without becoming either a pushover or someone who digs in regardless of new information.

The strongest version of this answer includes a moment where the stakeholder was actually right about something, or where you both landed on a third option neither started with. A story where the designer is simply, cleanly correct the whole time reads as rehearsed.

Talk to people who do use it before opening a design tool. That's the honest, unglamorous answer, and interviewers are checking whether a candidate reaches for research reflexively or defaults to guessing based on their own habits.

A designer who's never used enterprise accounting software still needs to design a reconciliation flow sometimes. The gap gets closed with user interviews, existing analytics, or a subject-matter expert on the team, not by assuming the designer's own intuition transfers.

Cut scope, not quality, on whatever ships. Identify the smallest version of the flow that still solves the core problem, and be explicit with the team about what's getting deferred rather than quietly shipping something half-finished and hoping nobody notices the gaps.

Interviewers listen for whether the candidate protected the user experience of the reduced scope or just crammed the original scope into less time and shipped something rougher across the board. Those are very different outcomes from the same constraint.

Qualitative research (interviews, usability tests, diary studies) tells you why something is happening and surfaces problems you didn't know to look for. Quantitative research (analytics, surveys at scale, A/B test results) tells you how often something is happening and at what magnitude.

Neither replaces the other. A funnel drop-off metric tells you something's wrong on a screen. It won't tell you what. A usability test on that same screen tells you what's wrong, but not how many users it actually affects. Strong candidates use both together, not one instead of the other.

Ask open, neutral prompts. "What would you do next" instead of "would you click this button here," which plants the answer inside the question. Resist the urge to explain or defend the design when a participant struggles, since that struggle is exactly the data you're there to collect.

The hardest version of this to actually do: staying quiet through an uncomfortable silence while a participant is stuck, instead of jumping in to help. Interviewers who've moderated a lot of sessions themselves can usually tell whether a candidate has genuinely sat through that discomfort or is describing it secondhand.

Test the underlying task or need, not the specific solution, since there's nothing built yet to click on. A low-fidelity prototype, a paper sketch, or even a concierge test where you manually do what the feature would automate can surface whether the need is real before any code gets written.

The mistake to avoid: skipping research entirely because "there's nothing to test," and instead asking stakeholders whether they'd use the feature. People are famously unreliable predictors of their own future behavior, which is a real and well-documented gap in self-reported intent research.

Affinity mapping is the standard move, clustering raw quotes and observations into themes, then naming what each cluster actually represents as a pattern rather than a single participant's opinion. A finding backed by three unrelated participants saying variations of the same thing carries more weight than one strongly worded quote.

Where candidates fall short: presenting a wall of quotes without synthesis and calling it a readout. A team can't act on raw data. They can act on "four out of six participants abandoned at this exact step, and here's why," stated plainly.

Lead with the finding and the evidence, not the methodology. Engineers and PMs skeptical of research usually aren't skeptical of users, they're skeptical of vague, unfalsifiable conclusions. "Users found this confusing" invites pushback. "Four of five participants missed the submit button entirely because it sat below the fold on a laptop screen" is much harder to argue with.

The candidates who handle this well come prepared to answer "how do you know that generalizes" honestly, including admitting the limits of a small sample, rather than overselling five interviews as proof of a company-wide pattern.

Adoption and governance, not component count. A design system works when teams actually use it by default instead of designing around it, and when there's a clear process for proposing, reviewing, and retiring components as the product changes. A beautiful library nobody references in production is a portfolio piece, not a system.

This is a harder problem industry-wide than most candidates assume going in. zeroheight's 2025 Design Systems Report, surveying 294 design, engineering, and product practitioners, found stakeholder buy-in satisfaction for design systems dropped from 42% to 32% year over year (zeroheight, Design Systems Report 2025). Candidates who cite that trend, or who've personally felt the gap between a system existing and a system being trusted, tend to give a more grounded answer than one that just lists Figma component features.

Build contrast, focus states, and semantic structure into the first draft, not a pass at the end. WCAG AA requires a 4.5:1 contrast ratio for body text and 3:1 for large text and UI components, and checking that early is far cheaper than discovering a whole color system fails it after engineering has already built against it (WCAG 2.1, Understanding SC 1.4.3).

Interviewers also ask about keyboard and screen reader behavior specifically, not just color. A custom toggle or dropdown needs the right ARIA role and keyboard handling, rather than visual styling that only looks like a native control.

<div role="switch" aria-checked="false" tabindex="0" class="toggle">
 <span class="toggle__track" aria-hidden="true"></span>
 <span class="toggle__label">Email notifications</span>
</div>
<!-- JS toggles aria-checked on click AND on Enter/Space keydown,
   never on click alone -->

Document the states a static screen can't show, hover, loading, error, empty, and the responsive behavior at each breakpoint, not just the happy-path desktop screen. A file with specs but no explanation of intent forces engineering to guess at edge cases, and they'll guess wrong more often than a designer expects.

The strongest handoffs include a short walkthrough, live or recorded, not merely an annotated Figma file. Candidates who've actually shipped through a real engineering team usually mention specific friction they hit, a component that didn't map cleanly to what the design system had, an edge case nobody specced.

Design tokens are named values, colors, spacing, radii, that get defined once and referenced everywhere instead of hardcoded per screen. Change the token, and every component using it updates, in design and in code, without a manual find-and-replace across dozens of files.

They matter most at scale, when a rebrand or a dark mode rollout needs to touch hundreds of components consistently. A team without tokens ends up with a dozen near-identical grays scattered through the codebase, none of them technically wrong, all of them slightly different.

{
 "color": {
  "brand": { "primary": "#2954FF", "primary-hover": "#1F3FCC" },
  "text": { "default": "#0F172A", "muted": "#64748B" }
 },
 "spacing": { "xs": "4px", "sm": "8px", "md": "16px", "lg": "24px" },
 "radius": { "sm": "4px", "md": "8px", "pill": "999px" }
}

Check whether the new use case is actually a different pattern or just a styling preference in disguise. A button that needs to be slightly bigger for one screen probably doesn't need a new variant. A button that needs to communicate a destructive action, delete, probably does, since that's a meaningfully different user intent, not a simple size difference.

Teams that add a variant for every one-off request end up with a system that's technically thorough and practically unusable, since nobody can tell which of fifteen button variants is the right default anymore.

This is where tokens earn their keep. If color decisions already route through semantic tokens (background, text, border) rather than hardcoded hex values, swapping the token values for a dark theme touches the system in one place instead of every screen individually.

The part candidates miss most: contrast ratios don't automatically hold when you flip a palette. A gray that passes AA on a white background can fail against a dark background, so dark mode needs its own contrast pass, not an assumption that inverting values preserves accessibility.

Name a specific decision, not a vague "I'd make it better." What would you change, and what do you know now that you didn't know then, a research method you'd trust less, a stakeholder conversation you'd have earlier, a technical constraint you'd have checked upfront.

Interviewers use this to check for growth and honest self-assessment. A candidate who can't name a single thing they'd do differently on any past project either hasn't shipped much or isn't being straight with the interviewer, and both read as red flags.

Bring a specific disagreement, what the stakeholder wanted, what you thought was wrong, and what evidence you used to make the case. The outcome matters less than whether the story shows you engaging with their reasoning rather than just digging in on preference.

A story where you were simply right the whole time and they simply came around reads as too clean. The more credible version usually includes some genuine back and forth, maybe a compromise neither side started with.

Frame the presentation around the problem and the constraints first, so the room is evaluating whether the design solves the right thing, not just reacting to whether they personally like the aesthetic. Ask specific questions ("does this handle the edge case where a user has no saved payment method") instead of the open-ended "thoughts?" that invites surface-level opinions.

Candidates who've run a lot of design reviews usually have a specific technique here, presenting two or three options instead of one final answer, walking through the problem before showing any screens, something concrete rather than a general philosophy about "being open to feedback."

Constraints worth talking about: a hard technical limitation, a legal or compliance requirement, an extremely compressed timeline, a legacy system you couldn't redesign around. The interesting part isn't the constraint itself, it's what you actually did because of it, not despite it.

Weak answers treat the constraint as an obstacle to complain about. Strong answers show a decision that only makes sense because of that specific constraint, proof the constraint genuinely shaped the design rather than sitting in the background of an otherwise generic story.

The idea being good is the point, this isn't about shooting down bad ideas, which is easy. It's about explaining why a genuinely reasonable idea didn't fit the current priority, timeline, or user need, and how you communicated that without dismissing the person who proposed it.

Strong answers name a specific trade-off, not a vague "we didn't have time." What got prioritized instead, and why that call held up in retrospect (or didn't, which is also an acceptable answer if you're honest about it).

Ask for the specific reasoning before reacting, since "wrong" from a senior person usually means "doesn't account for X," and X is worth understanding fully before agreeing or pushing back. Pure deference without engaging the reasoning is a weak answer. So is defending the original direction reflexively without genuinely considering the feedback.

The strongest version of this story includes a moment where you changed your mind because the feedback held up, or where you respectfully held your ground with evidence and the senior person came around. Either outcome works if the reasoning behind it is real.

Check the problem against evidence from more than one source, a support ticket pattern that matches a usability finding that matches a metric drop, rather than trusting a single stakeholder's framing of what's wrong. A problem stated as a solution ("we need a filter feature") is usually a symptom of a problem nobody's actually named yet.

This is genuinely hard to answer well without a real example, and interviewers know it. The candidates who struggle most here aren't bad designers, they just haven't had to defend problem framing against a confident stakeholder who's already decided on the solution.

Present the finding plainly, with the evidence, and don't soften it into something ambiguous just to keep the room comfortable. A finding that gets diluted to avoid conflict stops being useful research and starts being decoration.

The harder skill here is pairing the uncomfortable finding with a path forward, rather than only delivering bad news and leaving the room to sort it out. Candidates who can describe a specific instance where a stakeholder initially pushed back and then came around, with what actually changed their mind, give a far more credible answer than a generic "I present the data honestly."

When more than one team is contributing components and nobody owns deciding what gets added, changed, or deprecated. Without governance, a system drifts fast, duplicate components solving the same problem slightly differently, because two teams didn't know the other had already built something close.

The honest, slightly uncomfortable answer here: governance is often unpopular because it slows individual teams down in the short term to keep the system coherent long term. Candidates who acknowledge that trade-off directly, instead of pretending governance is purely upside, tend to have actually lived through a system at real scale.

Treat the system as a living contract between design and engineering, not a one-time deliverable. That means a defined process for updating the source of truth, in Figma and in code, whenever a component changes, plus periodic audits comparing what's actually shipped against what the system claims exists.

Drift happens fastest when engineering ships a quick fix directly in code without updating the design file, or when design updates a component without checking whether engineering actually implemented the change identically. Neither side is usually at fault alone. It's a process gap, and naming it as one signals real experience with a system at scale.

Start by asking where in the funnel the drop actually happens, not by guessing at a redesign. A metric-improvement question is really a diagnostic question wearing a design costume, if you can't name where users are dropping off, any proposed fix is a guess dressed up as a solution.

Once you've narrowed the funnel step, propose a hypothesis for why users drop there and a specific design change tied to that hypothesis, plus how you'd validate it worked, an A/B test, a follow-up usability round. Vague answers like "make it simpler" without a specific mechanism rarely land well here.

First I separate the two very different environments the design has now lived in. A usability test recruits five to eight people who agreed to sit down and complete a task with a facilitator watching. That controls for motivation, device, connection speed, and prior familiarity in ways production traffic never does. So the first question isn't "was the design wrong," it's "what does production have that the test didn't."

I start in analytics at the funnel step level, not the top line metric. If conversion dropped, I want to know exactly which step lost people compared to the old version, because a redesign usually doesn't fail everywhere, it fails at one specific point, like a new field ordering that trips up returning users who had the old layout memorized, or a CTA that moved below the fold on smaller viewports that weren't represented in the test rig. I also check whether the drop is uniform across segments or concentrated in one, because a change that helps new users and hurts power users will show up as flat or negative in an aggregate that hides both effects.

Then I rule out the boring explanations before blaming the design: did the metric definition or tracking event change in the same release, did another team ship something in the same window that touches the same funnel, is there a performance regression, is this the first three weeks of a novelty dip where returning users are relearning a flow they had memorized. Session recordings are useful here because they show real friction, hesitation, rage clicks, backing out, in a way a five person usability test with a script can't surface at scale.

If none of that explains it, the honest conclusion is that the test missed something, usually because the test measured task completion and comprehension, not the emotional cost of change for people who already had a mental model of the old version. That's a real failure mode of usability testing, and the fix isn't to distrust research, it's to add a cohort comparison of new versus returning users next time and to test with people who've used the current product, not just fresh recruits.

The baseline for a single modal is well understood: trap focus inside it, move focus to the modal (usually its heading or first interactive element) when it opens, set aria-modal="true" and make the background inert so a screen reader user can't accidentally tab or arrow into content behind it, handle Escape to close, and return focus to the exact element that triggered the modal when it closes. That last part gets skipped constantly, and it's the difference between a user picking up where they left off and a user getting dropped back at the top of the page with no idea where they are.

Stacked modals are where most implementations fall apart, because a naive focus trap only knows about one layer. If modal B opens on top of modal A, closing B needs to return focus into A, not to A's original trigger, and A's trap needs to still be intact underneath. The reliable way to handle this is a focus stack, not a single trapped-element reference: pushing a context when a modal opens and popping back to the previous context when it closes, so each layer owns its own return target.

Comboboxes have a different failure mode: the visual listbox and the accessibility tree can get out of sync. The correct ARIA pattern keeps DOM focus on the text input the whole time and uses aria-activedescendant (or a roving tabindex within the listbox if you're not using a native input) to tell assistive tech which option is "active" without actually moving focus off the field. If a design system implements this by literally moving focus into the list on arrow-down, screen readers announce it as focus leaving the field, which breaks the typing flow and often causes duplicate or conflicting announcements.

The thing I don't skip anymore is testing this with an actual screen reader, VoiceOver or NVDA, on the real component, not just running axe or Lighthouse. Automated tools catch missing labels and contrast ratios well, but they can't tell you that focus silently escaped a modal, or that a live region announced the same message twice, because those are runtime state bugs, not static markup violations.

Don't start designing. Start asking what "ambiguous" actually means here, missing user, missing success metric, missing constraint. Then propose a scoped first step, a quick research pass, a stakeholder interview, that would remove the biggest unknown fastest, rather than guessing at a full solution and hoping it lands.

The trap candidates fall into: treating ambiguity as a green light to design whatever they personally find interesting. Interviewers notice when the "ambiguous brief" answer conveniently turns into a showcase of the candidate's favorite pattern instead of an actual response to the ambiguity.

Cover the setup: what task you gave participants, how you recruited them, and, just as important, what you were actually trying to learn before you started. A usability test without a stated hypothesis tends to produce a pile of observations nobody can act on.

Jakob Nielsen's classic finding still holds up as the industry default: testing with five users surfaces most of the major usability problems in an interface, and running more than five on the same round mostly produces diminishing returns rather than new insight (Nielsen Norman Group). Interviewers who know this research sometimes ask directly why five, and a candidate who can explain the reasoning behind it, not merely recite the number, stands out.

Design all three at the same time as the happy path, not after. A dashboard with a beautiful populated state and no defined empty state ships broken for every new user, since a brand-new account is empty by definition on day one.

Error states need more than "something went wrong." A useful error state tells the user what happened and what to do next, retry, contact support, go back, rather than leaving them stuck on a dead end with no path forward.

This is one of three common whiteboard formats, alongside designing a feature from scratch and improving a specific metric. Start by defining who you're redesigning for and what's actually broken today, don't skip straight to "here's what I'd change" without naming the problem first. Interviewers are watching your reasoning out loud more than the final sketch.

The failure mode that costs candidates the most: silently sketching for five minutes and presenting a finished idea, instead of narrating trade-offs as you go. Talk through what you're rejecting and why, not only what you're choosing.

Same discipline as the redesign format, user and problem before solution, but with less existing context to lean on. Ask clarifying questions upfront: who's the user, what platform, what's the business goal. Interviewers deliberately leave the brief vague to see whether you ask or assume.

Candidates who jump straight to sketching a solution without establishing who it's for usually produce something generic and defensible only on aesthetic grounds, not on user reasoning. That gap is exactly what this format is built to expose.

The mirroring part is the easy half. Anything that implies direction, like a back arrow, a forward chevron, a progress bar, or a timeline, has to flip. But not everything mirrors. A play button, a clock face, or a video scrubber stays put because those represent physical objects or time, not reading direction. Teams that mirror blindly end up with a clock running backwards in the Arabic build, and nobody catches it until a user reports it.

The part that actually breaks products is layout math done in left/right instead of logical direction. If your CSS or your spacing tokens are written as margin-left and padding-right, every one of those has to be manually overridden per locale. Logical properties fix this at the source:

.card {
 margin-inline-start: 16px;
 padding-inline-end: 12px;
 border-inline-start: 1px solid var(--border);
}

Beyond layout, the edge cases that get missed in design review are text expansion (German and Finnish routinely run 30 to 40 percent longer than English, so a button label that fits at 80px in English will wrap or truncate elsewhere), bidi handling for mixed content like a phone number or a price sitting inside an Arabic sentence (numerals stay left to right even inside RTL text, and if you don't test this you get scrambled digit order), and form fields where labels, helper text, and validation icons all need to flip their alignment together, not just the text.

My process is to design one flow in a pseudo-localized string set early, something that pads every string 30 percent and wraps it in brackets, so truncation and wrapping problems surface in the first review instead of during Arabic QA six weeks before launch. And I always get a native reader on a real device to review the RTL build, because things like icon-text spacing that read fine to me can look genuinely wrong to someone who reads the layout the other direction every day.