The design method: from a vague problem to a defended design

"Design a chat app" is deliberately vague. The skill isn't knowing the answer; it's turning vagueness into a working design in a fixed order, so you never stall and never forget a piece. The same steps structure a design document at work and a 45-minute interview. Every worked design on this site follows them.

1. The idea

A design moves from what to how, and from broad to deep:

1. Frame the problem. Ask the few questions whose answers change the design: who uses it, the biggest scale, what must never go wrong, what's out.
2. What it must do. The three things users or clients can do ("a reader can open a paste by its link"). List the rest as "not now", with a reason.
3. How well it must do it. Measured targets: scale, speed, consistency or availability, data safety, security. "A paste loads in under 200 ms at p99", not "fast".
4. Numbers that change the design, and only those: every estimate ends "→ so we…" (Module 03).
5. The nouns. The main things the system stores and moves: Paste, Link, User. A short list; fields come later.
6. The contract. The few endpoints that serve the features, usually REST, with the caller's identity from the auth token. Add a data flow for pipelines.
7. First working version. Boxes and arrows that make each endpoint work, one request at a time. Simple first; a working system before a clever one. Keep a "parked for later" list.
8. Make it hold up. Go back to your targets and the parked list, and harden the design: scale, hot spots, failures, consistency, edge cases.
9. Follow-ups and wrap-up. Answer the interviewer's "what if" questions, then summarise the trade-offs, what you'd monitor, and what you'd change at 10× scale.

The order matters because each step feeds the next: the features decide the contract, the contract decides the components, and the targets decide which deep dives matter. Skipping ahead is how designs end up solving the wrong problem. (Other guides often call steps 2 and 3 "functional" and "non-functional requirements"; it's the same idea.) The interview framework page turns these steps into a minute-by-minute playbook.

2. How it works

Press Play to watch the method produce a complete design for Pastebin: a service where users paste text and get a short link to share it. Each frame adds one section to the whiteboard.

What good looks like, step by step

3. Try it yourself

Requirements sorter

The prompt is "Design a ticket booking site for concerts." Sort each statement. Your choice locks in and the explanation appears.

Plan your 45 minutes

Interviews run 35 to 90 minutes. Pick a length to see a sensible time budget. Leave making it hold up the most room: that's where seniority shows. The framework page has the full nine-phase planner.

4. Trade-offs

5. In real work and interviews

At work, the same steps become a design document: context and goals, explicit non-goals, the proposed design, alternatives considered and why they lost, risks, and a rollout plan. The doc is reviewed before code is written, because changing a box on paper is cheap and changing it in production isn't. Important decisions are often recorded as short architecture decision records (ADRs) so the reasons survive after the people move on (Module 28).

In interviews, the problem is either a product ("design a ride-hailing app") or infrastructure ("design a rate limiter"), drawn on a shared virtual whiteboard. Practise on the same kind of tool beforehand. Whatever words a company's rubric uses, it scores the same four things:

Expectations rise with level. Mid-level: a complete, sound design with the interviewer guiding the deep dives (roughly 80% breadth, 20% depth). Senior: the basics done quickly, two or three deep dives you choose and lead (60/40). Staff and above: you shape the problem itself, anticipate failure modes and operations, and go deep on what matters most (40/60).

The interview up close

Non-functional checklist (pick the top 3–5 that matter for this system, each with a number): consistency vs availability (CAP) · environment limits (mobile, bandwidth, memory) · scalability (bursts, read:write ratio) · latency · durability · security · fault tolerance · compliance.

Expect probing. Interviewers doubt your answers and push on trade-offs to tell understanding from memorised solutions. "Why not X?" isn't a sign you're wrong; it's the test. Answer with the trade-off, and change your mind gracefully if they show you something you missed.

Deep dives: seniors find and lead them ("the hard part here is double-booking; let me go deep on that"); juniors can expect the interviewer to point. Leave room for their questions: talking over them misses the signals they want and costs you on communication.

6. Remember it

7. Common mistakes

8. Design exercise (45 minutes, timed)

1. Requirements drill (10 min). For each prompt, write the 3 things it must do and 3 measured targets: "design a photo-sharing app", "design a rate limiter", "design a leaderboard for an online game".
2. API drill (5 min). Write the REST endpoints for the photo app's three features.
3. Full design (25 min). Without looking at section 2, design Pastebin on paper with a timer, following all eight steps.
4. Compare (5 min). Step through the Pastebin player again. What did you miss? Write it on the "Missed" line of your design notebook.

9. Self-check quiz

10. Go deeper