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.

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.

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.

Layout strategy

• Mobile: use a visible menu button that opens a vertical drawer or accordion. Keep the interaction touch-first, avoid hover-only behavior, and surface the most important links near the top.
• Tablet: keep the main nav compact; if space is tight, move secondary items into a “More” overflow menu rather than squeezing everything.
• Desktop: use a horizontal nav bar, and for dense sections I’d switch to a flyout or mega menu. The key is that the same menu still works with click and keyboard, not just hover.

Accessibility details that matter most

• Use semantic <nav> and real <button> elements for toggles.
• Tie state to aria-expanded and aria-controls, two ARIA (Accessible Rich Internet Applications, a set of HTML attributes that describe interactive behavior to assistive technology) attributes: aria-expanded tells a screen reader whether the menu is currently open or closed, and aria-controls points to the id of the element the button opens, so the screen reader can announce what's about to happen.
• Make touch targets large enough and keep a clear visible focus style.
• Support Tab, Shift+Tab, Enter, Space, and Escape.
• If the menu opens as an overlay, move focus into it and return focus to the trigger when it closes.
• Don’t rely on hover as the only way to reveal content; screen readers and touch users need equivalent access.

Handling viewport changes
I’d keep layout in CSS and manage only interaction state in JavaScript. If the viewport crosses a breakpoint while the menu is open, I’d reconcile that state so the UI doesn’t get stuck in a mobile drawer on desktop. That keeps the navigation predictable, usable, and resilient across devices.

Direct answer

Run the migration as an incremental, evidence-ranked backlog rather than a rewrite: audit the existing product to find out what actually matters (traffic, business value, complexity), stand up the responsive foundation and a small pilot in parallel, then migrate component-by-component behind a compatibility layer so old and new UI coexist while feature teams keep shipping.

Phase 0: the audit, done in a way that also sequences the work

This is the tactical layer beneath the plan, and doing it in one pass avoids a second audit later:

1. Inventory every screen and component, tagging each with three scores: (a) traffic/usage volume from product analytics, (b) business value or revenue exposure, (c) technical complexity and coupling to other screens.
2. Rank into a migration backlog from that scoring: high-traffic, low-complexity screens go first (visible wins, builds momentum); high-value, high-complexity screens get scheduled with more runway and a named owner; low-traffic, high-complexity screens are candidates to freeze rather than migrate at all.
3. Extract real values before inventing new ones. Audit the colors, spacing, and type sizes actually in use today (not the ideal you'd like), consolidate them into a token set, and only then generate new component styles on top. This ordering matters: primitives (color, spacing) before typography scale, before component-level tokens (button, input), before layout grid and breakpoints, so downstream component work isn't blocked waiting on an upstream decision that hasn't been made yet.
4. Re-export image and icon assets for multi-density, responsive delivery in this same pass, so it doesn't become a rediscovered task mid-migration.

Phased milestones on top of that backlog

• Foundation and pilot: tokens, responsive grid, type scale, and the top 5-10 backlog components ship as a pilot on one or two high-traffic screens.
• Parallel rollout: remaining priority components migrate; a Storybook (or equivalent living component catalog) and a visual-regression baseline (a saved set of reference screenshots that an automated check compares every new screenshot against, flagging anything that visually changed) are in place so regressions are caught automatically, not by a human noticing.
• Completion and deprecation: remaining low-priority screens are migrated or explicitly frozen; legacy styles are removed once nothing references them, verified by a dependency check, not by memory.

Parallel design and engineering workflows

Design builds tokens, responsive component variants, and prototypes in a shared, versioned library; engineering implements the same components against those tokens in a component catalog. A weekly handoff review and a named "migration champion" per product squad keep the two tracks synced without either blocking the other's release cadence.

Automation, and communicating with stakeholders

Visual regression tests, interaction tests, and an accessibility scan run in CI on every component PR so migrated and legacy screens are both covered without manual re-checking. A weekly status view (percent migrated, current blockers) plus a monthly demo keeps stakeholders informed without turning every sync into a status meeting.

Trade-offs and pitfalls

Running two systems in parallel temporarily increases maintenance cost and shipped bundle size (the total amount of code sent to the browser, which grows while both the old and new systems ship side by side); that's the accepted cost of not freezing feature delivery, but it needs an explicit deprecation deadline or the "in-between" state quietly becomes permanent. The most common failure mode is treating the backlog ranking as a one-time exercise: usage patterns shift mid-migration, so re-score the backlog at each phase boundary rather than following the original ranking blindly six months in.