How to Prepare an HLD
That Different People Can Actually Review

Most High-Level Design documents fail for ordinary reasons. Too much technical detail appears too early. Diagrams arrive without an explanation of the decision behind them. Scope is implied rather than stated. Assumptions stay in someone's head instead of on the page. Risks are missing, or buried in an appendix nobody opens. There is no visible link between what was asked for and what was chosen. And often, the document reads as if it were written for the author's own clarity, not for the people who have to review it.

None of this is about writing skill. It is about purpose. A good HLD does not try to impress. It tries to make architecture decisions reviewable — by people who do not all need the same information, at the same depth, in the same order.

What an HLD is really for

A High-Level Design is a bridge between intent and delivery. It sits after the problem has been understood and before the detailed build begins. Its job is to carry the reasoning forward — so that delivery teams, reviewers, and operations do not have to reconstruct the thinking from scratch later.

A useful HLD answers a small set of questions clearly:

• What problem are we solving?
• What is in scope?
• What is out of scope?
• What solution direction is proposed?
• What major decisions have been made?
• What options were considered?
• What risks and assumptions exist?
• How will this be operated?
• What needs approval or guidance?

An HLD is not the final build manual. It is the architecture-level explanation of the solution direction — detailed enough to be reviewed responsibly, and no more detailed than that.

Different people read the same HLD differently

One reason HLDs fail is that they are written as if every reader needs the same information in the same order. They do not. A security architect and a delivery lead can read the same document and be looking for almost entirely different things.

The practical implication is structural, not stylistic. The HLD needs to be layered, so each reviewer can find their section without reading the whole document like a novel from page one. A leader should be able to understand purpose and risk from the first page. A security architect should be able to find trust boundaries without searching through delivery timelines to get there.

Start with the decision, not the diagram

Many HLDs open with an architecture diagram and let the reader infer the reasoning behind it. This is backwards. A diagram without decision context is only a picture. It shows what was chosen, not why.

Before any diagram appears, an HLD should already have made clear why this solution direction was chosen, what alternatives were considered, what trade-offs were accepted, what constraints shaped the design, and which decisions are still open. Once that context exists, the same diagram becomes far easier to review — because the reader already knows what question it is answering.

This single change — explaining the decision before showing the picture — is one of the simplest ways to make an HLD more reviewable, and one of the most commonly skipped.

A practical HLD structure

There is no single correct template, but a recurring structure works well across most organisations and most types of change:

Not every HLD needs every section at the same depth. A small, low-risk change might cover most of these in a paragraph each. A strategic platform decision might need several pages per section. The depth should match the risk and impact of the change — not the size of the template.

The diagrams an HLD usually needs

Diagrams should reduce confusion, not decorate the document. The useful question for every diagram is simple: what decision does this help someone review? If a diagram cannot answer that, it probably does not need to be in the HLD.

Use fewer diagrams, but make each one explain a real decision. A document with three diagrams that each carry real meaning is more reviewable than one with twelve diagrams that mostly repeat each other from slightly different angles.

What ARB usually needs from an HLD

An architecture review board is not looking for a beautiful document. It is looking for decision confidence — enough clarity to know whether the solution direction is ready to proceed, and what conditions, if any, should come with that approval.

ARB reviewers usually need to understand why the change is needed, whether the architecture direction is appropriate, whether standards and principles have been followed, whether risks are visible rather than implied, whether alternatives were genuinely considered, whether security and operations were brought in early rather than added at the end, whether the organisation can actually run what is being proposed, and whether there are conditions attached to approval.

ARB review becomes considerably easier when the HLD keeps facts, decisions, assumptions, risks, and open questions clearly separated, rather than blending them into one continuous narrative. A reviewer should never have to guess whether a statement is something that has been decided, something that is assumed, or something that is still open.

How to present an HLD

Presenting an HLD is a different exercise from reading the document aloud. A presentation has limited time and a room with mixed expectations — it needs to guide attention, not narrate every section in order.

A presentation flow that tends to work well: open with the problem and context, state the scope boundary, describe the proposed architecture direction, walk through the key decisions and trade-offs, show the main diagrams, surface risks and assumptions, explain the operating model, list the open decisions, and close with exactly what guidance or approval is being asked for.

The presentation should not attempt to cover every section of the document. Its job is to guide reviewers toward the decisions that actually matter, and to leave enough time for the questions those decisions deserve.

Common HLD mistakes

• Starting with a diagram before explaining the problem
• Hiding assumptions instead of stating them
• Treating security as a separate, late section
• Ignoring operations and support until the end
• Not showing integration dependencies clearly
• Mixing current state and future state without distinction
• Adding too much low-level implementation detail
• Not explaining why alternatives were rejected
• Making the document long without making it reviewable
• Presenting every slide instead of guiding the decision
• Asking for approval when key decisions are still unclear

A simple HLD review checklist

• Is the problem clearly stated?
• Is the scope boundary clear?
• Are out-of-scope items listed?
• Are key decisions visible?
• Are assumptions documented?
• Are risks and mitigations included?
• Are integration dependencies clear?
• Is the data flow understood?
• Are security controls included early?
• Is the hosting and deployment model clear?
• Is resilience explained?
• Is the operating model realistic?
• Are open decisions listed?
• Is the approval ask clear?

Final thought

A good HLD does not remove the need for discussion. It makes the discussion better — because the right people can find the right information, the decisions are visible instead of buried, and the conversation in the review room is about judgement rather than excavation.

The best HLD is not the longest document. It is the clearest explanation of the architecture decisions, trade-offs, risks, and ownership that others need to review.