Rapid Design Exercises and Working Under Constraints Questions

Approach summary
When time is limited I use a risk-and-impact prioritization: run tests that reduce the biggest unknowns for launch and are fastest to execute.

Simple prioritization framework

1. Define top risks (1–3): e.g., "Can users complete signup?", "Do users understand core value?"
2. Prioritize tasks by business impact × user frequency × technical risk. Pick 2–3 top tasks for the MVP (happy path + one critical error path).
3. Select test subjects by funnel value: primary persona(s) first, then edge persona if time permits. Recruit 5–8 participants (5 often uncovers ~85% of major issues).
4. Choose metrics: one qualitative success metric (task completion + confidence) and two quantitative signals (time-on-task, error rate) plus one sentiment measure (Net Promoter or 5‑pt ease).

Rapid execution (days)

• Use guerrilla or remote moderated tests (30–45 min) and a clickable prototype.
• Script: 2 warm-up questions, 3 tasks, 3 post-test probes.
• Analyze with a quick affinity map and severity scoring; produce a 1‑page findings + prioritized fixes list within 24 hours of last session.

Why this works
Focuses limited time on the riskiest hypotheses, gives both quantitative signals and rich qualitative insight, and produces actionable fixes designers and engineers can implement before launch.

Seed-stage startup — prioritize speed with pragmatic depth

• Team capacity: small cross‑functional teams; I take full ownership of UX, research is lightweight (guerrilla tests, analytics).
• Stakeholder expectations: founders expect rapid validation and early revenue/traction signals.
• Risk tolerance: higher for iterations; acceptable to launch MVTs with known rough edges to learn.
• Decision tradeoff: focus deep design on core workflows that prove product‑market fit; ship thinner copy for peripheral features.
• Success criteria: activation rate, retention after 7–14 days, conversion lift from A/B tests, qualitative user feedback guiding next sprints.

Large enterprise — prioritize design depth for scale and compliance

• Team capacity: larger orgs with specialists and design system ownership; collaboration cycles longer.
• Stakeholder expectations: predictable timelines, accessibility, security, and extensibility.
• Risk tolerance: low for UX regressions and compliance issues.
• Decision tradeoff: invest up‑front in research, polished interactions, edge cases, and documentation; prototype thoroughly before dev handoff.
• Success criteria: NPS, task completion time, error rates, accessibility conformance, reduction in support tickets, long‑term adoption metrics.

I balance these by mapping impact vs. effort, aligning chosen fidelity to measurable outcomes, and communicating tradeoffs to stakeholders.

Concept 1 — "Quick Tiles" (grid of tappable task shortcuts)

• Primary interaction: 6 large, customizable tiles on a single screen; long-press to edit, single tap launches quick-action: mark done/ snooze/ open details.
• Main tradeoff: extremely fast for repeat tasks but limited discoverability for less-frequent items.
• Edge case to validate: how to surface new/one-off tasks without cluttering tiles (overflow behavior).

Concept 2 — "One-Flow" (focused single-card action)

• Primary interaction: center card shows the next most important task with one prominent CTA (complete / postpone) and small gestures to peek at others.
• Main tradeoff: maximizes speed for the immediate task but reduces multi-task scanning efficiency.
• Edge case to validate: algorithm confidence — what if priority prediction is wrong during back-to-back meetings?

Concept 3 — "Mini-Inbox + Quick Add" (compact list + always-visible add)

• Primary interaction: compact chronological list with inline swipe actions and a persistent quick-add FAB that supports voice/text snippets.
• Main tradeoff: balances speed and flexibility but requires more cognitive scrolling when list grows.
• Edge case to validate: voice capture accuracy in noisy meeting environments and quick-edit friction.

Overview / Goal
Refactor the legacy UI into a modern, component-based design system incrementally so teams can continue shipping features with minimal disruption while improving consistency, accessibility, and velocity long‑term.

Phased strategy

1. Discovery (2–4 weeks)

• Audit UI patterns, components, usage frequency, pain points, accessibility gaps.
• Map screens to business value, churn, and technical cost.
• Define design tokens, visual language, accessibility baseline, and governance.

2. Foundations (4–8 weeks)

• Build tokens, typography, color, spacing, and a small core component library (button, input, modal) as source of truth.
• Create documentation, Figma library, and engineering starter kit (storybook + auto-tests).
• Pilot one low-risk screen end‑to‑end.

3. Incremental rollout (ongoing)

• Use the strangler pattern: route new/updated screens to use the design system; wrap legacy screens with adapters to keep UX consistent.
• Prioritize by impact: high-traffic or frequently changed screens first; leave stable, rarely touched screens until necessary.
• Implement components in a parallel library and expose them via incremental package releases.

4. Stabilize & Optimize

• Iterate on patterns from usage data, expand components, remove duplicated legacy CSS.

Migration tactics

• Strangler pattern for screen-level migration.
• Facade/adapters to map legacy classes to tokens.
• “New component first” rule: feature work should prefer design system components; allow fallbacks when blockers exist.
• Feature flags and A/B tests for risky changes.

Risk mitigation

• Preserve feature cadence by limiting scope per sprint (~1–2 screens/components).
• Cross-functional “shiproom” weekly sync: designers, engineers, PMs.
• Rollback paths via feature flags.
• Maintain backward compatibility and semantic versioning for component packages.

Testing strategy

• Visual regression tests (Chromatic/Screenshot diff).
• Unit tests for component behavior and accessibility (axe).
• Integration tests for screen flows.
• Usability testing on migrated screens and telemetry monitoring for errors & performance.

Criteria: refactor vs leave-as‑is

• Refactor when: screen is frequently changed, high user traffic, accessibility/conversion issues, or re-use potential > 2 times.
• Leave as-is when: stable, low traffic, no UX issues, and cost > benefit now.
• Re-evaluate every quarter; use telemetry and product priorities to trigger refactor.

Outcome measures

• Reduced UI debt score, component reuse rate, decreased time-to-deliver new screens, improved accessibility compliance, and lower visual regressions.

Goal: deliver a polished, clickable investor demo in one week from an ambiguous brief. I’d treat this as a rapid product sprint focused on clarity, riskiest assumptions, and storytelling.

Day-by-day plan

• Day 1: Clarify scope with PM/Founder (30–60 min): target user, success metric for demo, non-negotiable flows. Align on tech constraints. Decide MVP scope.
• Days 2–3: Design & storyboarding: sketch end-to-end user journey and 3–5 key screens per flow.
• Day 4: High-fidelity UI and clickable prototype (Figma/Framer).
• Day 5: Rehearse demo script, run lightweight validation, iterate.
• Day 6: Polish visuals, interactions, accessibility checks.
• Day 7: Final rehearsal and handoff assets.

Flows to prioritize (risk-first)

• Core value flow (the single “wow” moment investors must see) — primary.
• Onboarding / first-time-use (sets context quickly).
• Conversion / commitment step (signup, purchase, connect) — shows monetization/traction.
• Failure/path edge case (to show robustness and thinking).

Artifacts I’ll produce

• One-page scope & assumptions doc (decision log).
• Storyboards for the core flow + onboarding (visual sequence).
• Clickable prototype (Figma/Framer) with polished UI and micro-interactions.
• Demo script with cues, timings, and expected investor questions.
• Quick slide “tech constraints & open risks” for pre-demo alignment.

Lightweight validation (before investor demo)

• 5-minute usability checks with 5 target-like users (remote moderated) to confirm core flow completes in <2 minutes.
• 3 internal walkthroughs with PM/engineer to catch feasibility gaps.
• Heuristic review checklist (consistency, affordance, CTA clarity).
• One “concierge” run: designer or PM plays the backend to prove flow works end-to-end.

What I’ll communicate to stakeholders after the demo

• Concrete outcomes: investor reactions, asked-for features, objections, next asks.
• What validated vs. what remains assumption-based (decision log).
• Immediate next steps: prioritized roadmap items, quick experiments, production handoff needs.
• Risks and resource asks (engineering time, analytics, user research).
• Proposed timeline for turning prototype into an MVP and metrics to track.

Why this works

• Focuses week on the highest-impact narrative and risk mitigation.
• Uses low-friction validation to reduce surprises.
• Communicates clear next steps so stakeholders can act immediately.