Responsive, Multi-Platform, and Localized Design Questions

Situation / Goal
I led UI across web and native apps for a product family where visual drift and inconsistent responsive behavior slowed releases and increased dev rework. My goal: preserve responsive integrity while letting designers iterate quickly.

Process & Governance

• Establish a living Design System in Figma with tokens (color, type, spacing, breakpoints) and component variants for web, iOS, Android.
• Define responsive rules tied to tokens: 4 breakpoint groups, fluid spacing scale, and accessibility thresholds.

Review Cycles

• Two-tier reviews:
  • Lightweight daily syncs / Figma comments for iterative work (designers own rapid exploration).
  • Weekly formal component review with lead + dev + QA for any new/changed components affecting responsiveness or tokens.
• Use a PR-like flow (PR stands for pull request, the code-review workflow developers use before merging a change): submit a "Design Change Request" in a lightweight template (what changed, affected tokens, screenshots across breakpoints, implementation notes).

Documentation Standards

• Component pages include: purpose, anatomy, props/variants, responsive behavior examples, token mappings, code snippets, and QA checklist.
• Maintain a changelog and migration notes for token changes.

Example & Outcome
By enforcing token-driven components and the two-tier review, we reduced CSS override bugs by 60% and sped up design iteration: designers could prototype freely while major changes passed the weekly gate for consistency.

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.

Approach (brief)
Define token families (spacing, type-size, line-height) with breakpoint suffixes. Keep semantic names where practical (e.g., spacing-sm) and raw scale tokens for flexibility. Map tokens to CSS custom properties and to Figma tokens (or tokens plugin) for one-to-one sync.

Naming conventions

• Spacing: spacing-<scale>-<bp> (bp: mobile | tablet | desktop)
• Typography size: type-<role>-<bp> (role: xs, sm, body, lead, h1..)
• Line-height: leading-<role>-<bp>

Example tokens

Spacing:

• spacing-1-mobile: 4px
• spacing-2-mobile: 8px
• spacing-3-mobile: 16px
• spacing-1-tablet: 6px
• spacing-2-tablet: 12px
• spacing-3-tablet: 20px
• spacing-1-desktop: 8px
• spacing-2-desktop: 16px
• spacing-3-desktop: 24px

Typography:

• type-body-mobile: 14px
• leading-body-mobile: 20px
• type-body-tablet: 16px
• leading-body-tablet: 24px
• type-body-desktop: 18px
• leading-body-desktop: 28px

Headings:

• type-h1-mobile: 28px / leading-h1-mobile: 36px
• type-h1-tablet: 36px / leading-h1-tablet: 44px
• type-h1-desktop: 48px / leading-h1-desktop: 56px

CSS implementation
Use root-level token objects and media queries. Example:

:root {
  --type-body: 14px;
  --leading-body: 20px;
  --spacing-2: 8px;
}

@media (min-width: 768px) {
  :root {
    --type-body: 16px;
    --leading-body: 24px;
    --spacing-2: 12px;
  }
}

@media (min-width: 1024px) {
  :root {
    --type-body: 18px;
    --leading-body: 28px;
    --spacing-2: 16px;
  }
}

.body-text {
  font-size: var(--type-body);
  line-height: var(--leading-body);
  margin-bottom: var(--spacing-2);
}

Benefits: single source of truth; components use same var names, responsive versions driven by media queries.

Figma / Design tool mapping

• Create token sets named same as CSS tokens (spacing-2, type-body). Use tokens plugin to assign values per breakpoint or set up variant pages (Mobile / Tablet / Desktop).
• Use Auto Layout with spacing tokens (e.g., padding = spacing-2) and Text Styles referencing type and leading tokens.
• Export JSON token file or use design-token tooling to sync with code.

Accessibility & best practices

• Prefer relative units (rem) in code for user zoom; convert px tokens to rem at build step.
• Keep consistent modular scale (e.g., 4px base) and document intended use (utility vs semantic).
• Test line-length and contrast across breakpoints.

Approach summary
As a UI Designer I weigh readability, consistency, and engineering cost. Fluid (continuous) scaling offers pixel-perfect responsiveness and smooth transitions across intermediate sizes; adaptive layouts (breakpoints) provide optimized, tested experiences at specific device classes. Each has trade-offs in complexity, maintenance, and QA.

Trade-offs

• Fluid scaling
  • Pros: seamless across sizes, fewer distinct designs, great for content-driven UIs
  • Cons: harder to control micro-layouts, edge-case spacing issues, more visual testing
• Adaptive layouts
  • Pros: tailored UX per form factor, predictable visuals, easier handoff for platform-specific interactions
  • Cons: more design/implementation effort, potential inconsistencies

Actionable hybrid approach

1. Define breakpoints for major form factors, for example: phone portrait under 480px, phone landscape 480-767px, tablet 768-1023px, and desktop/windowed 1024px and up.
2. Within each breakpoint, use fluid rules (relative units, constraints, flexible grids) to scale components smoothly.
3. Create responsive token set (spacing, type scales, breakpoint-aware tokens) in the design system.
4. Prototype transitions at midpoints to catch awkward states; document intended wrapping/overflow behaviors.
5. Prioritize performance: limit heavy reflows and platform-specific heavy assets.

Shared vs platform-specific components

• Use shared components for structure, typography, color, and common behaviors to ensure brand consistency.
• Create platform-specific variants when:
  • Native affordances differ (navigation patterns, gestures, system modals)
  • Performance/UI conventions require it (e.g., iOS tab bar vs Android bottom nav)
  • Accessibility behaviors diverge (keyboard, focus, large-text support)
    Document variants in the component library: base component + small, well-documented overrides for platform-specific rules.

When to choose which

• Choose primarily fluid+shared for content-rich apps with many form factors.
• Favor adaptive+platform-specific when interaction paradigms or constraints demand distinct UX (complex native workflows, heavy enterprise tools).

This hybrid balances developer effort, visual control, and a consistent cross-platform experience.

Situation & goal
As the UI Designer proposing a responsive layout + new CTAs, success = measurable lift in user engagement and business outcomes while maintaining UX quality across devices.

KPIs (primary + secondary)

• Primary: Conversion rate (CTA click → goal completion), Goal completion rate (sign-up, purchase).
• Secondary: CTA click-through rate (CTR), time-to-first-action, bounce rate, task success rate (usability), visual stability metrics (CLS).
• Qualitative: User feedback, usability test task completion, accessibility checks.

Segmentation

• By device: mobile portrait, mobile landscape, tablet, desktop.
• By platform/os: iOS vs Android vs Web.
• By user cohort: new vs returning, traffic source, screen resolution, high vs low network.
• Prioritize mobile-first if analytics show majority mobile traffic.

Experiment design (A/B)

• Two variants: Control (current) vs Treatment (redesign).
• Randomize at user-cookie or user-id level; persist assignment across sessions.
• Run parallel instrumentation for analytics and qualitative micro-surveys.
• Pre-register metrics and analysis plan; guard against peeking (repeatedly checking results early and stopping the test as soon as they look significant, which inflates the false-positive rate) with sequential testing rules, a statistical method designed to let you check results early without that inflation.

Sample size considerations

• Use baseline conversion p and desired minimum detectable effect (MDE) d.
• Approximate two-sample sample-size formula (per variant), since an A/B test compares two groups against each other rather than one group against a fixed target, so it needs both the significance level and the desired power, not significance alone:

n = (Z_alpha/2 + Z_beta)^2 * (p1 * (1 - p1) + p2 * (1 - p2)) / (p1 - p2)^2

• Choose alpha = 0.05 (Z_alpha/2 = 1.96) and power 80% (Z_beta = 0.84). A common mistake is dropping the power term and using only Z_alpha/2, which understates how many users you actually need. Worked instance: baseline conversion p1 = 5% (0.05), target conversion after the redesign p2 = 6% (0.06), a minimum detectable effect (MDE) of 1 percentage point. Plugging in: n = (1.96 + 0.84)^2 * (0.050.95 + 0.060.94) / 0.01^2 = 7.84 * 0.1039 / 0.0001 ≈ 8,146 users per variant. Inflate that number for segmentation and expected variance, and account for attrition. For low-conversion funnels, run longer or increase the MDE so the required sample size stays reachable.

Rollout criteria

• Rollout if: primary KPI lift is statistically significant, secondary metrics non-degrading, no major UX regressions, accessibility passed, and business stakeholders sign-off.
• Iterate if: marginal/no lift but improved qualitative feedback: run follow-up A/B variants (CTA copy, color, placement).
• Roll back if: negative impact on conversion, engagement, or accessibility.

Notes for execution

• Collaborate with PM/Analytics to instrument events; QA visual specs across breakpoints.
• Complement A/B with session replays and moderated usability on the treatment to explain why metrics moved.