Responsive, Multi-Platform, and Localized Design Questions

Definition: what mobile-first means
Mobile-first is designing for the smallest, most constrained screens first, prioritizing essential content, interactions, and performance. It embraces progressive enhancement: start with a solid mobile baseline, then layer richer layouts and features for larger viewports.

Why use it

• Matches majority mobile usage and performance constraints
• Forces clarity: prioritize content and tasks
• Simplifies responsive implementation for devs (CSS mobile-first rules)
• Improves accessibility and load speed

Sequence for redesigning desktop-first → mobile-first (with deliverables)

1. Audit & priorities

   • Deliverables: content inventory, usage analytics summary, user task list.
   • Purpose: determine core actions and content to keep on mobile.

2. Core flows & information architecture

   • Deliverables: mobile user journeys, card-sorting results (from an exercise where users group and label content cards themselves, to reveal how they'd naturally organize the information architecture), simplified sitemap.
   • Purpose: reduce friction; identify primary CTAs.

3. Low-fidelity layouts (mobile first)

   • Deliverables: sketches, wireframes (mobile screens).
   • Purpose: establish hierarchy, spacing, and essential interactions.

4. Design tokens & pattern decisions

   • Deliverables: token set (spacing, type scale, colors), component list.
   • Purpose: ensure consistency and responsive scaling.

5. High-fidelity components & responsive rules

   • Deliverables: UI kit in Figma, components with states, breakpoint definitions (e.g., 360, 768, 1024px).
   • Purpose: scale patterns from mobile to tablet/desktop.

6. Interactive prototypes & usability testing

   • Deliverables: clickable mobile prototype, task-based test scripts, findings report.
   • Purpose: validate flow and interactions before wider rollout.

7. Developer handoff & implementation guidance

   • Deliverables: annotated specs, CSS/utility guidance (mobile-first breakpoints), asset exports, accessibility notes.
   • Purpose: smooth build, performance and progressive enhancement guidance.

Notes & best practices

• Define breakpoints by content, not device.
• Keep tokens atomic and scalable.
• Prioritize performance (images, fonts) and touch targets.

Approach / goals
Preserve discoverability, surface deep links quickly, keep touch targets comfortable, and maintain visual hierarchy on small screens. Aim for progressive disclosure, clear labeling, and fast access to top tasks.

Recommended pattern
Use a hybrid: prominent bottom navigation for 3–5 primary sections + a contextual “Browse” entry that opens a full-screen expandable mega menu (accordion-style within that panel). This gives one-tap access to main areas and an efficient way to surface deep links.

Why this works

• Bottom nav supports thumb reach and habit for primary tasks.
• Full-screen panel preserves mega-menu grouping and visual hierarchy.
• Inside-panel accordions enable scanning and deep-link access without overwhelming the main chrome.

Compare patterns

• Hamburger menu
  • Pros: Conserves space; can contain full IA.
  • Cons: Low discoverability; hidden affordance; slows access to deep links.
• Bottom navigation
  • Pros: High discoverability for top-level items; thumb-friendly.
  • Cons: Limited slots (3–5); not suitable alone for deep hierarchies.
• Expandable accordion (in-panel)
  • Pros: Preserves hierarchy, supports deep links, scannable; works well in full-screen modal.
  • Cons: Can require more taps; needs careful animation to avoid performance issues.

Design details / accessibility

• Use clear labels, icons + text, and persistent search at top of panel.
• Provide visible breadcrumbs and tap-to-copy deep links.
• Ensure 44–48px touch targets, keyboard navigation, and screen-reader announcements for expand/collapse.
• Prototype and test with tree testing (giving users a text-only version of the navigation hierarchy and asking them to find where a specific item lives, to check the structure before any visual design) and 5–8 mobile users to validate discoverability.

Final decision: a hybrid bottom nav plus modal mega menu with accordions, balancing discoverability and depth while meeting mobile ergonomics.

Approach summary

I design for RTL (right-to-left) languages and for text that grows when translated by treating direction and flexible sizing as first-class rules in the design system, not exceptions handled at the end. Concretely that means: mirror layout using direction-aware CSS instead of hard-coded left/right values, reserve extra space for languages that translate longer than English, and define different truncation rules for mobile versus desktop.

Layout & alignment

Use logical CSS properties (margin-inline-start/end instead of margin-left/right, text-align: start/end instead of left/right) so the whole layout flips automatically when the page's dir attribute is set to "rtl," instead of needing a second, hand-maintained set of RTL-specific styles. Build components on flex or grid so the reading direction can reverse the row order, rather than positioning elements at fixed pixel offsets. Keep spacing on a token scale (small, medium, large, defined once) so hit areas and gutters can grow without a designer re-measuring every screen.

Icons & imagery

Flip only icons whose meaning depends on direction, like a "back" arrow or a forward chevron; an icon like a play button or a checkmark should stay exactly as it is. Mirror direction-dependent icons with a CSS transform (scaleX(-1)), and keep a deliberately mirrored version of any illustration that has text baked into the image itself, since text inside an image doesn't flip automatically the way a CSS layout does.

Typography & spacing: why translated text needs a buffer

Translated UI text is very often longer than the English original, and how much longer depends on the language. As a concrete example: the English word "Settings" is 8 characters. Its German translation, "Einstellungen," is 13 characters, about 60% longer. A button or label sized to fit "Settings" exactly will clip or wrap awkwardly once translated.

As a widely used rule of thumb for planning space (not exact for every string, since shorter strings tend to expand more than longer ones), European languages commonly seen in software localization expand English UI text by roughly this much: German by around 30%, Russian by around 20%, and French by around 15%. Build in the biggest buffer for short labels and button text, since that's where expansion hurts most, not for paragraphs.

The practical response: don't set fixed-width buttons. Let a button grow to fit its label, or allow the label to wrap onto a second line, rather than clip or overflow.

Truncation and differential behavior

• Mobile: favor readability over density. Let long labels wrap onto a second line, use multi-line buttons, and put less-critical detail behind a tap (a modal or an expanded view) rather than cramming it into one line.
• Desktop: truncating with an ellipsis is more acceptable in compact lists because there's more room elsewhere on the page, but pair every truncated label with a hover tooltip or an accessible full-text alternative so no information is silently lost. For dense tables, let a row expand in place on click instead of truncating permanently.
• Never truncate the verb in a critical action, like the label on a "Delete" or "Submit" button. If a button needs to shrink, shrink something else on the screen first.

Responsive patterns

Define the width at which a layout switches from one line to a stacked layout. Where the same component can appear at different widths on the same page, for example a card in a narrow sidebar versus the same card in the main content column, use container queries (rules based on the size of the component's own box, not the whole screen) instead of a single global breakpoint, so the component adapts correctly wherever it's placed.

Validation & testing at scale

• Pseudo-locales: a fake locale used in design and QA reviews that accents every character and adds bidi markers and extra length to strings. "Bidi" is short for bidirectional text, meaning right-to-left and left-to-right text mixed on the same line, which happens whenever, for example, an English brand name sits inside an Arabic sentence. Pseudo-locales surface mirroring and overflow bugs before a single real translation exists.
• Automated visual comparisons: a check that takes a screenshot of each component before and after a change and flags anything that visually shifted, run across a matrix of locales and screen widths, including RTL screenshots, so a translation-triggered layout break gets caught in a pull request rather than after release.
• Automated interaction tests that explicitly set dir="rtl" and verify that alignment, focus order (the order the Tab key moves through elements), and keyboard navigation still work correctly in a mirrored layout.
• Track two ongoing numbers release over release: the percentage of components passing the visual comparison check, and the number of localization bugs reported, so the process measurably improves rather than just feeling better.
• For a final human check, batch up real translated screenshots for translators and native speakers to review in context, not just as a raw text list, watching specifically for mirrored icons pointing the wrong way, punctuation in the wrong place, and toolbar order.

Example

A primary action button uses flexible sizing rather than a fixed width, so it can grow to fit "Settings" in English or "Einstellungen" in German without clipping. Its icon only flips if it's a directional icon, like an arrow; a checkmark icon on the same button stays fixed.

This keeps the design resilient and testable across RTL and long-string locales, and across mobile and desktop, without needing a separate design per language.

Approach overview

I treat foldables and variable windows as an extension of responsive design with added continuity and spatial transitions. I design fluid layouts, flexible components, and explicit states for folded/unfolded and multi-window contexts.

Layout strategies

• Responsive grids that reflow (single-column → two-column) based on width thresholds.
• Adaptive components: cards that expand to show detail, navigation that switches between bottom nav and rail.
• Content prioritization: define primary/secondary content so essential actions remain visible in narrow windows.

State continuity across folds

• Preserve scroll position and form state when folding/unfolding; use progressive disclosure so expanded context isn’t lost.
• Define transition rules: split-to-merge content mapping (e.g., master/detail remains linked when moving from dual-pane to single-pane).

Breakpoint & logic

• Use semantic breakpoints (compact, medium, expanded) tied to functional changes, not just pixels.
• Include fold-aware breakpoints: hinge area, dual-pane threshold, and multi-window min widths.
• Map behaviors: if width < 600px, stack single column; between 600-1023px, two panes; 1024px and above, rail + content. That maps directly onto the compact / medium / expanded window classes named above.

Testing & prototyping

• Prototype in Figma using components and variants for states (folded/unfolded, multi-window). Create interactive flows preserving states with Smart Animate and overlays.
• Use device mockup frames (Figma's own foldable device templates, or vendor-provided kits like Samsung's Galaxy Fold frames) for the visual states, and test on real foldable hardware or a platform emulator (such as Android Studio's resizable/foldable emulator profiles) for actual hinge behavior and continuity, since a static mockup frame cannot show fold motion or dual-screen handoff.
• Define QA checklist: visual layout, state persistence, focus/keyboard behavior, accessibility, and performance on fold/unfold transitions.

This approach balances visual consistency, predictable behavior, and usable transitions across variable windows.

Direct answer

Prioritize by task urgency and by who is actually looking, not by "what fits on a small screen." On mobile, show the smallest set of numbers someone needs to make a go/no-go call right now; push comparison, breakdown, and export to tablet and desktop. Filters shrink from persistent multi-select panels to single-choice controls, and drilldowns move from in-place expansion to a full-screen, breadcrumbed stack.

A framework: content tiers, then a persona lens on top

Start by tagging every widget with a tier:

• Tier 1, always visible: the 3-5 headline KPI cards (value plus trend delta) and one sparkline (a small trend-line chart with no axes or labels, just the shape of the trend). These answer "is anything on fire."
• Tier 2, one tap away: the detailed chart, top-N table, and secondary filters. Collapsed behind a card tap or a drilldown.
• Tier 3, desktop-only by default: dense multi-series charts, cross-filtering, full tables, export.

That tiering alone assumes one audience. In practice a dashboard usually serves at least two personas, and the key point is that "what's Tier 1" changes with who's asking:

• An executive on mobile wants outcome-level KPIs (revenue, margin, pipeline) and nothing else. They will not drill down; they want a 5-second read.
• A power user/analyst wants the same screen real estate spent on operational KPIs (orders, conversion rate, error rate) because their job is to act on the detail, not summarize it.

The fix is a configurable Tier 1, not a single hard-coded one: let the dashboard's default widget set depend on role, and let users pin their own KPIs. A BI tool and a custom app both support this, just at different effort levels (see below).

Interaction changes as the screen shrinks

• Filters: multi-select dropdowns on desktop become single-select chips or a bottom-sheet filter panel on mobile, since fat-finger multi-select on a 375px-wide screen is unreliable.
• Drilldowns: desktop shows a side panel or in-place expansion; mobile pushes a full-screen overlay with a back button, because there usually is not enough vertical space to show summary and detail at once.
• Tooltips: hover-based detail becomes tap-to-reveal, since there is no hover on touch.
• Touch targets: interactive elements need at least 44x44 points (Apple's iOS guideline) or 48x48dp (Android's), both comfortably above WCAG's (Web Content Accessibility Guidelines) newer 24x24 CSS pixel minimum, because a KPI card that's tappable needs a bigger hit area than a mouse pointer ever required.

Worked example

A sales dashboard has six widgets: Revenue KPI, Orders KPI, 28-day trend, regional map, top-products table, and an alerts feed.

• Mobile (under 600px, one column): Revenue + Orders tiles, the trend sparkline, and the single highest-priority alert. Tapping Revenue opens a full-screen overlay with the regional breakdown.
• Tablet (600-1024px, two columns): KPI rail alongside the trend chart, with the map and table one tap away.
• Desktop (1024px+): all six widgets visible with cross-filtering between the map and table.

If the exec persona is viewing on mobile, Tier 1 swaps Orders for Margin. If the analyst persona is viewing the same mobile screen, Tier 1 keeps Orders and adds Conversion Rate instead of Revenue's raw trend.

Trade-offs and pitfalls

Off-the-shelf BI tools trade control for speed: Power BI requires you to hand-build a separate mobile layout per report page rather than deriving it automatically, and its mobile rendering rules for visuals are largely fixed. Tableau's Device Designer lets you define phone/tablet/desktop layout variants of the same dashboard with more flexibility, but you still can't hand-roll a custom interaction like a swipe-to-drill gesture the way you could in a React app. A custom app costs more engineering time but gives you full control: container-query-based component sizing, custom gesture handling, and truly configurable per-persona defaults. The most common pitfall is treating "responsive" as one static hide/show order for everyone; without a persona lens, you inevitably ship a mobile view that's perfect for executives and useless for the analysts who actually live in the tool day to day.