Design Reasoning

Build the smallest model that helps someone understand, decide, or act. Connect purpose, structure, behavior, and evidence instead of choosing a diagram or solution before establishing the problem. Understanding an existing system is a valid outcome; do not redesign it unless the request calls for change.

Frame the problem

Identify the audience or actors, their question or goal, observable success, and the task boundary. Inspect the available implementation, examples, requirements, and research. Separate verified facts and fixed contracts from assumptions, proposals, and constraints open to change. Ask about unknowns only when they materially change the next decision; continue independent work.

Scale the method to the task. A terminology correction may need one definition and counterexample; a cross-team process may need handoffs and exception paths. Do not require a workshop, diagram, document, implementation, or every domain reference for each request. Preserve the requested deliverable and scope.