The design process
From a one-line request to a working plan.
Real work rarely arrives as a specification. It arrives as a sentence: "Let people book appointments online." The design process turns that sentence into something a team can build. Designers who skip it usually build the wrong thing quickly, or the right thing for the wrong amount of traffic.
A repeatable process
Step 1 of 5
Clarify
Ask who the users are, what they need first, and what is out of scope. Do patients book for themselves or for family? Can a booking be cancelled?
The process is a loop, not a line. A surprising answer during estimation sends you back to clarify. A bottleneck found during stress sends you back to the sketch. Experienced designers go around the loop several times in the first hour, each time with a clearer picture.
Notice the verb on the middle arrow: measure. Guessing which part is slow is how teams add a cache nobody needed. Even before launch you can measure on paper: if a database handles about 6,000 queries per second and you expect 30,000, you know the database is the bottleneck without building anything.
Your turn
A friend says: build an app so neighbours can lend each other tools. Write three clarifying questions you would ask before sketching.
Stuck? Ask about users, scale and what is out of scope.
What to remember
Turn a vague request into questions first.
Estimate numbers before choosing parts.
Begin simple, then fix the first bottleneck.
Measure rather than guess.
Record the tradeoffs you accept.