Module 11: The Four Levels of Design — Deliverables Mapped to Altitude
Modules 1–10 teach how to classify and construct individual statements. This module addresses a different but related question: as an engagement moves from initial vision to finished build, what are the actual deliverables you produce, who are they for, and how do they relate to the altitude ladder underneath them?
Two Different Things Named “Level”
Worth being explicit about this before going further, since both frameworks use a 0–3 scale and that’s a genuine source of confusion left implicit: Altitude (Modules 1–10) classifies a single statement. A sentence in a transcript is L0, L1, L2, or L3. Design Level (this module) classifies a deliverable — an entire document or artifact, built for a specific audience, at a specific point in the engagement. A Level 2 design document isn’t “an L2 statement” — it’s a document whose primary job is to hold confirmed L2 requirements (with L0/L1 context still attached, per Module 10’s “don’t delete the lower levels” principle) at a scale far beyond one sentence.
The Four Design Levels
| Level | Audience | Purpose | Outcomes |
|---|---|---|---|
| 0 | Executive, Director | High-level visual of the approach; used for budget justification, investment case, and alignment | All systems and connections in scope; the full wishlist — what the client wants and how; everything the client knows they need, including content that may actually be Level 1 or Level 2 material, not yet sorted |
| 1 | Director, Manager | Defines and outlines the process a team executes; clarifies decision points and branches, captures key steps | All key business processes, plus the supporting processes that make the key ones succeed |
| 2 | Manager, Ops | Creates clarity on what needs to be built (AE/Consultant); shows how process parts interact and overlap; exposes gaps needing clarification | User, system, and technical actions; user stories, technical requirements; ERDs where helpful |
| 3 | Manager, End user, Ops, Admin, IT | Adds full build detail — custom actions, automation, integrations — with complete logic spelled out | Technical build and full logic detail |
Why Levels 1–3 Map Cleanly and Level 0 Doesn’t
Design Levels 1, 2, and 3 line up almost exactly with Altitude L1, L2, and L3:
- Design Level 1 ≈ Altitude L1. Both are process descriptions — decision points, branches, key steps — aimed at the person who owns or executes the process, not yet naming system-level mechanics.
- Design Level 2 ≈ Altitude L2. Both are the missing middle — the authored bridge between what a process needs and what gets built. Design Level 2’s own outcomes explicitly name user stories and technical requirements, which is exactly the L2-native territory Module 13 covers.
- Design Level 3 ≈ Altitude L3. Both are full mechanical detail — custom logic, automation, integration specifics. Design Level 0 is different on purpose, and that difference matters. Its own definition says it plainly: it includes “everything you know you need… [which] may be aspects of Level 1 or Level 2 design.” A Level 0 deliverable is not altitude-pure. It’s a client-facing, executive-oriented artifact whose job is alignment and budget justification — and doing that job well means capturing the full wishlist as the client understands it, altitude and all, rather than pre-sorting it. Forcing altitude purity onto a Level 0 document would work against its purpose: an executive doesn’t need “L0: reduce billing errors” cleanly separated from “L2: the system needs to sync automatically” — they need the whole picture in one visual, at whatever resolution the client happened to think in when they built the wishlist.
The Practical Consequence: Treat Level 0 Documents as a Written Source, Not a Confirmed Requirement
This is the single most important operational takeaway of this module. Because a Level 0 deliverable is intentionally mixed-altitude, it should be run through the Module 15 written-source pass, not taken at face value just because it’s executive-approved. A client wishlist that reads as confident and specific can still contain L0 pain statements sitting right next to unconfirmed L2-shaped language that nobody with standing has actually bridged yet. The fact that a Level 0 document got signed off at the executive level tells you it has the right authority — it does not tell you it has the right altitude. Those are separate questions, and Module 7’s standing test still applies even to content an executive has already approved: approval establishes standing to set direction, not necessarily standing to confirm a specific system-level mechanic buried in the wishlist.
Using the Levels Together Across an Engagement
- Level 0 gets built early, often before or during initial discovery — the artifact that wins the budget and sets executive alignment. Its content should be treated as raw material for the ladder (Modules 1–3), not as pre-confirmed requirements.
- Level 1 gets built as discovery proceeds — where Module 9’s discovery-call playbook and the stakeholder map (Module 7) do their work, converting the Level 0 wishlist into real, process-level clarity with the right manager-level stakeholders.
- Level 2 is the requirements document itself — Module 10’s output, exactly. This is where bridge statements (Module 5) live, tagged and status-flagged (confirmed/provisional/conflicted/advised).
- Level 3 is the build spec — where L3 detail (Module 2) finally gets attached, only once the Level 2 document has earned it.
A Note on the Stakeholder/User Column
The altitude table’s Stakeholder/User column already encodes this same gradient without naming it: L0 skews Executive/Director, L1 skews Director/Manager, L2 skews Manager/Ops, L3 skews Manager/End user/Ops/Admin/IT. That’s not a coincidence — the Design Levels and the Altitude Levels are two views of the same underlying gradient of specificity and audience. This module makes that gradient explicit at the deliverable scale instead of the sentence scale.