How do you design a cross-platform user experience system?

Long Answer

A production-grade user experience system balances usability, accessibility, and visual consistency without forcing every platform to look identical. Standardize interaction intent, semantics, and patterns, while letting native controls feel at home. The payoff is faster delivery, fewer regressions, and inclusive experiences that scale.

1) Strategy and principles
Define a north star (for example, complete top tasks in ≤3 steps) and a quality bar tied to WCAG 2.1 AA. Adopt heuristics and measure them through research. When clarity conflicts with ornamentation, legibility and operability win.

2) Design tokens and system library
Centralize color, spacing, typography, elevation, and motion as tokens. Build a cross-platform component library—buttons, inputs, nav, dialogs, tables—with stable APIs, clear states, and accessible defaults. Document purpose, keyboard behavior, and responsive rules.

3) Information architecture and navigation
Model navigation by user goals. Keep wayfinding consistent; use progressive disclosure. On mobile, focus flows; on web, enable shortcuts. Ensure landmarks and headings form a logical outline.

4) Accessibility by construction
Prefer semantic HTML and native controls. For custom widgets, follow ARIA patterns, manage focus, and honor prefers-reduced-motion and increased-contrast. Provide visible focus, sufficient contrast, error prevention, and contextual forms. Keep targets large and gestures operable by keyboard and switches.

5) Cross-platform component engineering
Abstract interaction logic into specs, then implement platform skins. Align states—hover, focus, pressed, disabled, busy—in naming and visuals. Package tokens, variants, and i18n. Share a motion dictionary so timing stays coherent across refresh rates.

6) Content, localization, and inclusivity
Use plain, action-first copy, descriptive links, and meaningful headings. Localize with ICU messages; support bi-directional text, plural rules, and RTL layouts. Provide clear errors, captions, transcripts, and meaningful alt text.

7) Tooling, QA, and measurement
Run a living catalog (Storybook) with interactive accessibility checks. Lint contrast, focus traps, and ARIA usage. In CI, run unit tests for states, visual regression for themes, and end-to-end tests for key journeys. Track Core Web Vitals, task success, time on task, and defects escaping.

8) Release governance and change management
Use RFCs for breaking changes; publish migration codemods and deprecation timelines. Version the design system semantically. Roll out via canaries and feature flags; watch dashboards for regressions.

9) Research and feedback loops
Run continuous research: quick unmoderated tests, deeper moderated studies, and sessions with assistive-tech users. Triage findings into backlog items with criteria referencing tokens and patterns.

Built this way, the system is a shared contract. Teams share one vocabulary and kit. Users get predictable, fast, inclusive UIs that feel native across web and mobile.

‍

Table

‍

Common Mistakes

Treating consistency as visual sameness across platforms; ignoring native expectations. Shipping custom widgets without semantic roles, focus, or keyboard support. Relying on color alone for meaning; weak contrast. Over-engineering tokens with near-identical values, then teams drift anyway. Components with unstable props/events, so reuse collapses. QA run only with automated scans; no manual a11y or task tests. Design debt parked in tickets without ownership or deadlines. Rolling breaking changes without RFCs, flags, or migration guides. Measuring only page views, not task success or Core Web Vitals. Localizing strings but not layouts, dates, and RTL, leading to clipped or confusing UIs. Forgetting prefers-reduced-motion and increased-contrast, causing discomfort. Libraries diverge, so tokens do not match shipped components. Overusing modals and patterns that trap focus or break history. No canary rollout or observability, so regressions reach all users before detection.

‍

Sample Answers (Junior / Mid / Senior)

Junior:
“I start with semantic HTML and native controls. I follow our tokens for color and spacing, use accessible components from the library, and test keyboard paths. I check copy for clarity and run Axe and Storybook a11y checks before PR.”

Mid:
“I structure work around the design system: tokens, components with stable props, and patterns for forms and dialogs. I plan flows from user goals, add i18n with ICU messages, and validate with unit, visual, and e2e tests in CI. I watch Web Vitals and fix contrast, focus, and motion issues early.”

Senior:
“I steward the UX system as a product: WCAG 2.1 AA baseline, RFCs for breaking changes, and codemods with versioned releases. I balance cross-platform consistency with native expectations, run research with assistive-tech users, and govern rollout via flags and canaries with dashboards tracking task success.”

‍

Evaluation Criteria

Strong answers start with principles (usability heuristics + WCAG 2.1 AA) and show how they become tokens, components, and patterns. Look for a design system with accessible defaults, semantic HTML first, ARIA only when needed, and clear keyboard and screen-reader behavior. Candidates should separate visual consistency from visual uniformity, keeping native expectations per platform. Expect plans for Storybook catalogs, a11y linting, unit/visual/e2e tests, and CI gates. Measurement must include Core Web Vitals and task success, not only page views. Governance signals seniority: RFCs for breaking changes, versioned releases, flags and canaries, and migration guides. Red flags: custom widgets lacking roles and focus, color-only meaning, no localization or RTL, and ‘scan at the end’ attitudes. Bonus points for research loops with assistive-tech users, dashboards tying issues to SLAs, and explicit rubrics for resolving conflicts between brand, usability, and accessibility. Evidence of i18n discipline (ICU messages, plural rules) and motion policies respecting user preferences is a plus.

‍

Preparation Tips

Create a small cross-platform design system: tokens in CSS variables and mobile equivalents; Button, Input, Dialog, Toast, and Card components in Storybook with a11y tests. Build a sample flow (search → detail → checkout) and define SLOs (task success ≥ 90%, time on task targets). Add Axe and ESLint a11y rules to CI; block merges on critical issues. Practice authoring ARIA for a custom combobox and trap focus in a modal. Localize with ICU messages, add RTL and pluralization, and verify mirrored layouts. Measure Web Vitals and interaction latency on mid-tier devices. Pilot a reduced-motion mode and a high-contrast theme. Draft an RFC that changes a component API and ship a codemod. Run two usability tests: one unmoderated for copy, one moderated with a screen reader. Summarize findings in a one-page report that maps issues to tokens, components, or patterns and proposes fixes with owners and dates. Add dashboards for task success and error rates, and schedule weekly triage. Rehearse a canary rollout with feature flags and a rollback, and capture before/after screenshots for review.

‍

Real-world Context

A fintech unified tokens and components across web and mobile; brand refreshes shipped in days, not weeks, and support tickets about inconsistent controls dropped. A streaming service added semantic HTML defaults and ARIA patterns to its player; keyboard access and captions raised completion rates for users with disabilities. A marketplace introduced Storybook with a11y linting and visual tests; regressions fell and velocity increased. A gov portal moved to task-first navigation and improved headings/landmarks; screen-reader users finished forms faster with fewer errors. A learning platform localized with ICU messages, RTL, and plural rules; trust improved as copy felt native. A productivity app codified motion tokens, added reduced-motion modes, and paused offscreen animations; battery life and comfort improved on mobile. Across all, UX systems tied to WCAG 2.1 and research loops delivered measurable gains in inclusivity, consistency, and release confidence. Executive confidence rose as dashboards linked task success to specific component and token changes.

‍

Key Takeaways

• Treat the user experience system as a shared contract across teams.
  
• Encode visual consistency with tokens; keep usability and accessibility first.
  
• Use platform-native patterns with common semantics and states.
  
• Shift-left with Storybook, linting, CI gates, and research loops.
  
• Govern change with RFCs, flags, canaries, and versioned releases.
  
  

Practice Exercise

Scenario:
You must stand up a cross-platform UX system for a commerce app spanning web and mobile. Leadership requires WCAG 2.1 AA, faster task completion, and consistent visuals without breaking native expectations. Beta launches in six weeks.

Tasks:

1. Define the north star (top three tasks) and write acceptance metrics (task success, time on task, Web Vitals). Publish a conflict rubric that prioritizes legibility and operability over ornamentation.
   
2. Create tokens (color, type, spacing, motion) and a component starter set (Button, Input, Dialog, Toast, Card). Document props, states, keyboard behavior, and responsive rules in Storybook.
   
3. Build flows for search → detail → checkout with semantic HTML and accessible patterns. Add copy guidelines and error messaging that explains next steps.
   
4. Localize with ICU messages; enable RTL and plural rules. Respect prefers-reduced-motion and increased-contrast. Set minimum target sizes.
   
5. Add CI checks (Axe, ESLint a11y) and tests (unit, visual, e2e). Establish dashboards for Core Web Vitals, task success, and defects escaping.
   
6. Propose governance: RFCs for breaking changes, flags and canaries for rollout, and versioned releases with migration notes.
   
7. Run two lightweight studies: unmoderated copy tests and a moderated screen-reader session. Triage findings into tickets linked to tokens or components.
   
   

Deliverable:
A one-page system overview, token table, component inventory, and dashboards proving improvements over baseline. Include a risk list, owners, and dates for the next iteration.