Responsive, Multi-Platform, and Localized Design Questions

Priority viewports (quick validation set)

• Mobile narrow: 360×640 (small phones)
• Mobile tall: 375×812 (modern phones)
• Tablet: 768×1024 (portrait) and 1024×768 (landscape)
• Desktop breakpoint range: 1280×800 and 1440×900
  (Prototype highest-traffic breakpoints + one edge small and one large)

Checklist: interactions & scenarios to prototype and test

Mobile

• Tap targets (thumb reach, 44–48px): primary CTA, nav, form controls
• Gestures: swipe carousels, pull-to-refresh, long-press menus
• Keyboard behavior: input focus, auto-fill, numeric keypad, virtual keyboard overlap
• Loading states: skeletons, spinners, progressive reveal
• Edge cases: slow networks, one-handed reach (bottom vs top controls)

Tablet

• Touch + multi-column layout: drag/drop, split views
• Orientation switch: portrait ⇄ landscape layout stability
• Hover alternatives: discoverability when no hover available
• Multi-window / app-switching resilience

Desktop

• Hover states, tooltips, keyboard navigation, focus outlines
• Complex interactions: drag/drop, multi-select, contextual menus
• Resizing window: responsive breakpoint transitions, fluid grids
• Accessibility: tab order, screen-reader labels, contrast

Cross-device scenarios

• Authentication flow end-to-end (signup, error states)
• Form entry & validation (with autosave/recover)
• Responsive nav: expanding/collapsing, search behavior
• Error & empty states, success confirmations
• Performance: first meaningful paint, interaction latency

Test goals: discoverability, affordance, reachability, error recovery, performance. Capture video, task success, and time-to-complete; iterate rapidly.

Clarify goal & constraints

• Long-press triggers secondary actions (context menu, drag, preview) on touch; must be emulatable on desktop and keyboard-accessible, discoverable, and documented for engineers.

Interaction map (by platform)

• Touch: press > 600ms (configurable) + slight radius threshold → reveal contextual menu / preview. Visual affordance: subtle ripple + hold progress indicator.
• Mouse: right-click opens menu; left-click-and-hold (optional) opens same menu after 600ms; hover shows tooltip hint.
• Keyboard: focusable element + Space or Enter + hold 600ms OR dedicated keystroke (Shift+F10 or Context Menu key) opens menu immediately.
• Assistive Tech: expose an ARIA (Accessible Rich Internet Applications, a set of HTML attributes that describe interactive behavior to screen readers) menu/button with aria-haspopup (tells a screen reader this control opens a menu or dialog) and aria-controls (points to the id of the element it opens); provide role=“button” with a description exposing the long-press alternative (e.g., “Press Shift+F10 to open menu”).

Fallbacks & discoverability

• Always provide a visible affordance (ellipsis, kebab, caret) for discoverability.
• Tooltip on hover/focus: “Hold to open options” / show shortcut “Shift+F10”.
• Settings: allow users to toggle long-press sensitivity or disable long-press.

Edge cases

• Accidental long-press during scrolling: cancel if movement is more than 10px or exceeds a velocity threshold.
• Conflicts with native OS gestures (iOS text selection, for example): prefer an explicit, visible affordance to avoid unexpected behavior.
• Multiple pointers: ignore a secondary touch while the primary one is still active.

Spec & prototype documentation

• In spec: state timing (default 600ms), movement threshold, visual states (idle / holding / activated), keyboard mappings, ARIA attributes, analytics events.
• Provide Figma prototype (interactive component) demonstrating touch hold, mouse emulation, keyboard flows; include annotated states and developer handoff tokens (timing variables, CSS classes).
• Acceptance criteria: accessible via keyboard and AT, passes gesture tests (hold duration, cancel on move), and visual feedback present.

This mapping balances cross-platform parity, accessibility, and clear handoff for implementation.

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.

Situation: At my last company I led visual design for a dashboard used by field agents and desktop analysts. The product team wanted feature parity on mobile, but screens became cramped and interactions required lots of horizontal scrolling and tiny touch targets.

Task: I needed to decide which UI elements to hide or reprioritize on mobile while preserving efficiency for field agents. I also had to convince product and engineering of the trade-offs.

Action: I created two Figma prototypes: one with full parity (dense layout) and one optimized for mobile using progressive disclosure: primary actions visible, secondary actions in a contextual overflow, and compact cards with touch-friendly spacing. I ran quick remote moderated usability tests with 8 agents and measured task completion and time-on-task. I prepared a one-page decision brief summarizing accessibility, tap target sizes, error risk, development effort, and KPI impact. In a stakeholder meeting I presented test videos, quantitative results (task success: 92% optimized vs 60% parity), and proposed phased roll-out with feature flags.

Result: Stakeholders approved the optimized mobile design. Post-release, mobile task completion improved 25%, support tickets about mis-taps dropped 40%, and engineers delivered the changes within the planned sprint. The chosen trade-offs maintained critical functionality while improving usability and accessibility.

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.