Map the main path
Show components, responsibilities and data movement at the level needed for the decision. Avoid detail that hides the important boundaries.
Make the reasoning behind the design visible.
Work through system boundaries, failure cases and delivery dependencies together. Keep the trade-offs beside the diagram that explains them.
Hosts sign up. Guests join with a name.
Draw the system. Challenge the assumptions.
Add the failure path
Mark what happens when a dependency is unavailable, a request repeats or a step completes only partially.
Record the decision
Write the chosen approach, the trade-off and the open questions that implementation or testing must resolve.
An example session
Review a background-processing design
Trace how a job is accepted, processed and reported to the user. Add questions about retries, partial results and visibility for the operator.
A shared design discussion that makes the next engineering checks explicit.
Engineering teamsExample board AcceptCheck the request
ProcessPerform the bounded work
VerifyCheck the result
RecoverHandle a failed attempt
Will Boards check the technical design?
No. The board is a place to model and discuss the system. Implementation, testing and operational validation remain engineering work.
Can we use MCP in this workflow?
Compatible assistants can create and edit real board objects through MCP. Review the resulting diagram and notes before relying on them.
Bring the next conversation
onto a board.
Start with 3 free live boards. Invite your participants through a link.
Start free