Walk into the Design Review Able to Restate What You're Signing Off

Workflow area: Solution Evaluation · Tier: Core · Hands-on time: ~30 minutes

The design review is where analysts traditionally go quiet. The sequence diagram flashes past, someone says "we handle that asynchronously via the event bus," heads nod, and three months later the business discovers that "asynchronously" meant confirmation emails can arrive before validation completes. Nobody lied — the analyst just approved a document they could not read. AI removes the excuse: any design doc can now be explained at whatever level you need, interrogated against your requirements, and mined for the questions that make engineers say "good catch."

When to use — and when not to

• Use it before any design or architecture review you attend as the business voicean hour of AI-assisted prep converts you from spectator to participant.
• Use it on API contracts that implement your requirementsthe mapping from spec behavior to acceptance criteria is exactly where silent scope drift happens.
• Use it when a design decision needs business sign-offeventual consistency, retention behavior, failure handling — translated until you can restate the trade-off to your sponsor.
• Skip it as a path to playing architectyour job is verifying the design serves the requirements and the business understands the trade-offs, not redesigning the event bus.
• Skip challenging technology choices on AI-generated groundsif the model says a different queueing pattern is better, that is a question for the architect, not a position for you.
• Skip it when the design doc is a stubtranslating three bullet points produces authoritative-sounding fiction; ask engineering for the real document first.

The recipe

1. 1.

   Collect the design artifacts and your requirements. Get the actual documents — design doc, API spec, sequence diagrams, ADRs — not a summary from the tech lead. Pair them with the requirements and acceptance criteria this design is supposed to implement. The pairing is what makes the prep analytical instead of educational.

2. 2.

   Get the plain-language explanation, layered. Attach the design doc:

   Copy

   You are helping a business analyst prepare for a design
   review. Attached: the design doc and our requirements pack.
   I am not an engineer. Explain the design in three layers:
   
   1. ONE PARAGRAPH — what this design does, in business terms.
   2. THE MOVING PARTS — each component: what it does, what it
      talks to, and the business events it handles, avoiding
      jargon or defining it inline on first use.
   3. THE DECISIONS — every design decision with business-
      visible consequences (timing, ordering, failure behavior,
      data location, retention), each as: decision → what the
      business will observe → the trade-off being made.
   
   Cite the doc section for every claim. If the doc is silent
   or ambiguous on something, say NOT STATED — do not fill in
   how systems like this usually work.
   

3. 3.

   Run the requirements-vs-design mapping. Second pass, same session: "For each requirement in the pack, state where the design addresses it (cite section), how the design's behavior could differ from the acceptance criterion, or NOT ADDRESSED." The interesting rows are never the clean fits:

   Copy

   REQ-018 (order confirmation within 2 min): design §4.2 uses
   async processing with retry; happy path ~seconds, but retry
   policy allows up to 15 min on downstream failure. Criterion
   says 2 min unconditionally. DIVERGENCE — clarify whether the
   SLA holds during downstream degradation.
   REQ-023 (audit trail of price overrides): NOT ADDRESSED —
   no logging of override events found in the design.
   

4. 4.

   Generate questions, then filter them yourself. Ask for review questions a business analyst should raise, grouped by requirement risk, edge cases and failure behavior, and data lifecycle. Then cut anything you do not understand well enough to handle the answer — asking a question whose answer you cannot parse is worse than silence. Six good questions you own beat twenty you borrowed.

5. 5.

   Apply the restatement test. For every element you will approve, write one sentence in your own words without looking at the AI output: what happens, when, and what the business sees when it fails. Where you cannot, that element goes on the review agenda — the inability to restate is the finding. This test is the playbook's spine; the AI exists to get you to the point where you pass it.

6. 6.

   In the review, verify rather than perform. Lead with the divergences and NOT ADDRESSED rows from step 3. Restate answers back: "So when the downstream is degraded, confirmations can take fifteen minutes and the 2-minute SLA doesn't hold — is that what the business is accepting?" Log what was confirmed, what changed, and what the design team took away. Your sign-off note lists what you verified — which is what makes it worth something.

Make it yours

• Copilot chat over the repo for living designs: where the design truth lives in code and READMEs rather than documents, repo-aware chat answers "what actually happens when X fails" against the implementation — flag divergences from the design doc as findings in themselves.
• Claude Project per system area: accumulate design docs, ADRs, and API specs; by the third review you can ask "does this new design contradict any earlier decision?" and get cited answers.
• Glossary side-channel: keep a running "translated terms" note per engagement (idempotency, backpressure, eventual consistency — each with the business consequence); it compounds, and new analysts inherit it.
• API-contract quick mode: for a single spec, collapse to one prompt — "explain each endpoint's business behavior, then map against these acceptance criteria and flag divergences" — fifteen minutes, same restatement test.

Quality check

• Every explained claim carries a doc citationand NOT STATED gaps were sent to engineering as questions, not papered over by the model's general knowledge.
• The requirements mapping existseach requirement is addressed, divergent, or NOT ADDRESSED, and divergences drove the review agenda.
• You passed the restatement testone hand-written sentence per approved element; the ones you couldn't write appeared in the review.
• Questions were yoursfiltered to those whose answers you could evaluate, grounded in requirement risk.
• Failure behavior was coveredfor each critical flow you can state what the business observes when it breaks, not just when it works.
• Sign-off is scoped in writingwhat you verified, what changed, what remains open with owners.