With the requirements pinned down, the A step turns them into a picture: the major pieces of the system and the arrows between them. This is the box-and-line diagram everyone pictures when they hear “system design” — and it's mostly two sketches.
The map
Where we are in RADIO
Requirements feed straight into architecture. Now you draw the system — tap A to recall its job:
A · High-Level Design
Sketch the major components, their boundaries, and how data flows between them — the big-picture diagram.
The A in RADIO
What high-level design is
High-level design describes the system from above: what the key components and modules are, and how they depend on one another. A component here doesn't mean a React component — it's any encapsulated piece that owns some logic: a store, a controller, a server, a UI widget. We draw each as a box and each dependency as an arrow.
Two symbols, that's it
A rectangle is a component (something encapsulated that does a job). An arrow is a dependency — its direction shows who relies on, or sends data to, whom. Master those two and you can diagram any system.
The method
Two sketches: wireframe + graph
High-level design splits into two drawings. Depending on the problem you may need one or both:
A simple sketch of what the screen looks like and which components live on it. On the job this is often already done — the design team handed you a Figma. In an interview you usually sketch it yourself so you and the interviewer share the same mental picture before going deeper.
Sketch one
The wireframe
Break the screen into named regions. For our running Facebook-feed example, a single post decomposes into five components — the same five we'll wire together in the graph:
Post Composerinput · image · link
Post Headerauthor · date · ⋯ menu
Post Contenttext · image · video
Comments Listrendered comments
Comment Inputwrite a comment
Scope to the component
If you're designing the dropdown, wireframe the dropdown — not the whole page it sits on. Zoom in on the thing you were asked to build and ignore everything outside its boundary.
Sketch two
The dependency graph
Now connect the pieces. The controller talks to the server and writes results into the store; display components read from the store; inputs send their data up to the controller. Tap any box to trace its connections:
The controller is the hub: it talks to the server and owns the store. Tap a box.
It's not the only right answer
Maybe you don't split out a controller, or you slice the store differently. That's fine — the goal is to make the key components and their relationships clear, not to match one canonical diagram.
Keep it clean
Notes that keep the design honest
A few habits keep the diagram useful instead of a tangle. Tap each:
Practice
Check your understanding
Q1Multiple choice
In a high-level design diagram, a “component” means…
Q2Sort each scenario
Wireframe or dependency graph?
Where the post header and comment input sit on screen
The controller writes fetched posts into the store
Comments List reads from the store
A rough picture of what the screen looks like
Q3Multiple choice
You're asked to design just a dropdown. What should your wireframe cover?
Try it yourself
Design challenge
Pick a screen you know — a comment thread, a Kanban column, a chat window — and produce both sketches:
A wireframe naming 4–6 components.
A dependency graph: which fetches data, which holds state, which only renders.
Mark one computation and decide: frontend or backend?
Key takeaways
→High-level design describes the system from above as boxes (components) and arrows (dependencies).
→It splits into a wireframe (what's on screen) and a dependency graph (how pieces relate).
→A “component” is anything encapsulated with a job — store, controller, server, or widget — not just a UI component.
→Keep boxes modular with clear separation of concerns, and decide where each computation runs.
→Scope and zoom to the thing you were asked to design — ignore everything outside its boundary.