Case Study: Design a Mobile App From Scratch

This is the capstone of the UI/UX Design Interview track. Every earlier subject — JTBD framing, information architecture, wireframing fidelity, interaction-design laws, UX writing, accessibility, responsive design, HEART metrics — was taught as an isolated tool. A live "design X from scratch" prompt is where an interviewer checks whether you can pick up all of those tools in the right order, under a clock, without being told which one applies where. That's a different skill from knowing each one individually, and it's the one this subject exists to model.

The prompt below is given exactly as an interviewer would say it, cold, with no further detail volunteered. What follows is not a lecture about how to answer this kind of question — it's a full worked answer, the way a strong candidate would actually talk through 30-40 minutes at a whiteboard: asking questions before designing anything, narrowing scope out loud, sketching real screens, writing real copy, and stopping at a defensible point rather than trying to design forever. Every section below names which earlier subject in the track it's drawing on and why, because that traceability — not just producing a plausible-looking app — is what's actually being evaluated.

The prompt: "Design a mobile app that helps people find and book last-minute fitness classes (yoga, spin, HIIT) at studios near them. You have 30-40 minutes. Walk me through your approach from scratch."

Step 1 — Clarifying Questions First

The weakest opening move in this kind of interview is sketching a screen before asking a single question — it signals that requirements are assumed rather than gathered, which is exactly the Discover-phase mistake ux-vs-ui-and-the-design-process warns against: solutioning before the problem is understood. A strong candidate spends the first two or three minutes narrowing the problem out loud.

Questions worth asking, and why each one changes the design:

• "Who's the primary user — someone deciding right now they want a class in the next hour, or someone planning their week of workouts in advance?" These are genuinely different core flows: spontaneous "what's available near me right now" discovery versus a browsable weekly schedule. Given the prompt explicitly says "last-minute," assume the former is primary and state that assumption out loud rather than silently picking it.
• "Is this two-sided — do studios need a way to list and manage their own availability inside this product — or can I assume real-time inventory already exists via a backend or a partnership with studio booking software (Mindbody, etc.)?" A studio-facing management tool is a second, much bigger product; assume for this exercise that availability data is sourced from existing studio systems via partnership, and the scope here is the consumer-facing discovery and booking app only.
• "What's the business model — a per-booking fee, a subscription, or free to the user with studios paying for placement?" This mainly affects later monetization screens, not the core flow, so note it and move on rather than let it stall the exercise: assume a small per-booking fee charged to the user, similar to how last-minute travel and restaurant apps monetize spontaneous demand.
• "iOS, Android, or both?" Assume both, native-feel per platform — this is a direct callback to responsive-and-mobile-design's point that iOS and Android have different platform conventions (tab bar placement, back-navigation gestures, system font); design the structure platform-agnostically and note where a real build would diverge.

Stating these assumptions explicitly, rather than silently picking answers, is itself a signal wireframing-and-prototyping calls out directly: "I'm assuming X — tell me if that's wrong" surfaces Discover/Define-style judgment in real time instead of hiding it.