Lean Design Review¶
Ritual — instantiates Parsimony Filter
A structured review that asks whether a design has unnecessary features, steps, dependencies, interfaces, or documentation burden.
A Lean Design Review is a recurring, structured ceremony a team runs on a design before or during build — walking its steps, dependencies, interfaces, and documentation and asking of each element, "does this earn its keep?" Its defining trait is that it is a group ritual with a protected-exception rule: a convened room, a challenge checklist, and an explicit list of categories — safety, compliance, accessibility — that are off-limits to cutting no matter how rarely they fire. That combination is what separates it from a solo pruning pass on a shipped product and from a review of a project's deliverable list. It interrogates the internal complexity of a design-in-progress, and it does so as a shared, repeated practice so that "keep it lean" becomes a team norm rather than one engineer's preference.
Example¶
A company is designing the onboarding flow for new hires: fourteen steps, six forms, four approvals, and a forty-page handbook. Nothing is built yet — it is a process on a whiteboard. Every quarter a Lean Design Review convenes HR, IT, a hiring manager, and someone who was onboarded recently.
They walk the design element by element, weighing each one's carrying cost: the coordination it demands, the training it needs, the new hire's cognitive load, the documentation someone must keep current. Three of the four approvals turn out to be rubber stamps that never catch anything; the handbook duplicates a wiki that is already maintained. But the exception rule fires twice and holds: the security-clearance step for finance-system access and the accessibility-accommodation intake stay in, regardless of how few hires trigger them, because they exist to protect exactly the rare case. Then the stakeholder impact check catches something the room nearly cut — the in-person buddy introduction looks like overhead until someone notes that remote hires depend on it most, so it is kept for them specifically. The flow lands at nine steps with the handbook folded into the wiki, and the safeguards untouched.
How it works¶
- Convene the standing review. Bring the defined roles into the room on a set cadence; the ritual's value is that it recurs and that the right perspectives are present.
- Challenge each element for its carrying cost. Walk the design part by part and make each one justify its coordination, maintenance, training, and cognitive burden — the default is "cut unless justified."
- Apply the exception rule. Hold protected categories — safety, legal, accessibility — exempt from the cut, so leanness cannot quietly strip a safeguard.
- Run the impact check on proposed cuts. Before removing an element, ask who relies on it, with attention to groups less visible in the headline design, and decide as a group.
Tuning parameters¶
- Cadence — how often the review runs. Too frequent and it becomes a bikeshed that stalls the design; too rare and complexity is baked in before anyone questions it.
- Challenge-question set — the standard prompts each element must survive. Sharp questions surface real bloat; vague ones let the ritual degrade into a nod-through.
- Exception categories — what is declared off-limits to cutting. Draw the list too wide and nothing gets simplified; too narrow and a real safeguard slips through as "overhead."
- Impact-check breadth — how far the review looks for who is affected by a cut. Broad looks protect quiet stakeholders but slow the review; narrow looks are fast but miss the group that isn't in the room.
When it helps, and when it misleads¶
Its strength is catching over-design before it is built in, when a step or dependency is still cheap to drop — the moment a complex system is most tempted to grow past the simple one that would have worked.[1] As a repeated ceremony it also makes simplification a shared expectation instead of a fight picked by one skeptic.
Its central failure mode is austerity masquerading as parsimony: "lean" becomes the language used to strip review steps, redundancy, or accessibility that exist precisely for the rare, high-stakes case — which is exactly why the exception rule is load-bearing rather than decorative. The classic misuse is the review that hardens into ritual theater: a standing meeting that rubber-stamps whatever is put in front of it, or one that burns its hour bikeshedding a trivial interface. The guarding discipline is the protected-exception list paired with the stakeholder impact check, which together keep leanness from sliding into recklessness.
How it implements the components¶
complexity_cost— its core lens: every design element is made to justify its standing burden — coordination, maintenance, training, cognitive load — or be cut.exception_rule— it holds declared categories (safety, compliance, accessibility) exempt from cutting, protecting the rare-but-critical element the burden lens would otherwise flag.stakeholder_impact_check— before a cut lands, it asks who relies on the element, with deliberate attention to groups underweighted in the main design.
It does not run a part-by-part necessity_test that deletes and files a removal_log on a shipped product — that surgical, logged removal is Feature Pruning. It stands up no simple_baseline for candidates to beat (that is Simple Baseline Model), and it does not defer whole deliverables behind a complexity_reintroduction_threshold — trimming a project's committed work is Scope Reduction Review.
Related¶
- Instantiates: Parsimony Filter — Lean Design Review is the filter run as a recurring ceremony over a design's internal complexity.
- Sibling mechanisms: Feature Pruning · Occam-Style Model Selection · Scope Reduction Review · Simple Baseline Model · Assumption Audit · Minimum Viable Explanation · Model Complexity Penalty
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Lean Design Review operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a structured review that asks whether a design has unnecessary features, steps, dependencies, interfaces, or documentation burden
Independent corroboration: The frozen evidence defines Lean Design Review as 'A structured review that asks whether a design has unnecessary features, steps, dependencies, interfaces, or documentation burden', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Universal
Rationale: Lean management supplies waste and value concepts, but applying them to remove unnecessary product features, interfaces, and dependencies is lean product and engineering design.
Related originating lineages:
- Computer Science & Software Engineering — Lean software and architecture practice contributed scrutiny of interfaces and documentation burden.
- Organizational & Management Science — Lean-management practice supplied waste categories and facilitated review rituals.
Review resolution: Lean management supplies waste and value concepts, but applying them to remove unnecessary product features, interfaces, and dependencies is lean product and engineering design. The source supports the selected provenance; the retained alternates record documented formative or independently established lineages, not downstream applicability alone. origin_mode=cross_disciplinary_synthesis because the mechanism joins contributions across those traditions. domain_reach=universal records application breadth separately from origin.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- https://www.lean.org/explore-lean/product-process-development/ — Lean Enterprise Institute overview of Lean Product and Process Development as a product and process design system.
References¶
[1] Gall, J. General Systemantics: An Essay on How Systems Work, and Especially How They Fail, Together with the Very First Annotated Compendium of Basic Systems Axioms: A Handbook and Ready Reference for Scientists, Engineers, Laboratory Workers, Administrators, Public Officials, Systems Analysts, Etc., Etc., Etc., and the General Public. General Systemantics Press (1975). States that working complex systems evolve from working simpler systems. registry ↩