"Design a link shortener." Four words, and then the interviewer stops talking and waits. What they're waiting for is your framing: the short stretch of work where you decide what problem you're actually solving, before a single box goes on the whiteboard.

Framing is the knowledge that turns an underspecified product prompt into a scoped one: which ambiguities are worth a question, what vocabulary you state requirements in, which of those requirements a first answer can honestly meet, and in what order you attack the rest. It decides what gets drawn. It never decides how any drawn thing works.

This is the opening five to ten minutes of a 45- to 60-minute round, and it's the only part of a system design interview that is guaranteed to happen. It's also the highest-variance part. If you skip the framing and draw immediately, you may design for the wrong problem, and good component choices twenty minutes later cannot repair that mismatch.

The expected depth depends on the level. A mid-level round mostly needs a clear scope. A senior round expects quantified quality requirements and explicit machinery for deferred work. Two habits cause the most trouble either way: leaving quality goals vague, and drawing before anyone has agreed what the system does.

The focus is framing: read what a prompt withholds, state both functional and non-functional requirements, decide which requirements a first pass can genuinely honor, and then run a reusable loop. Clarify, estimate, draw the request path, add the components justified by the requirements, and name what you are deferring. Each move depends on the output of the previous one. A link-shortening service provides one continuous example, but the goal is to frame the problem rather than finish its architecture.