Ask an agent for an "appointments page" and you will usually get a layout first: a sidebar, a table, maybe a calendar. The questions that decide whether that layout works come later, if at all. What is an appointment connected to? Where else can people reach it? What can they do with it?
Design Decision Method puts those questions before layout, but only when they matter. It calls this the object-map gate.
What the gate checks
Before wireframes, mockups, or code, the method asks whether the change you are making has structure that depends on relationships. It looks for four signals, scoped to the requested change:
- two or more object types that people move between in that change
- an object reachable from more than one place in the structure being designed or changed
- top-level navigation that is new or changing
- a form or screen that creates or edits a record relating to objects elsewhere in the product, when that relationship affects the structure being changed
If any of these apply, produce a short object map (or reuse a verified one) before layout. If none apply, skip it.
When to skip
The gate is deliberately narrow. A copy-only fix, a purely visual restyle, or a component-level fix with unchanged structure does not need a map. Existing product complexity alone does not require one for an unrelated copy or styling fix.
That matters when you work with an agent all day. A rule that fires on every edit gets ignored. A rule that fires when structure is actually changing is one you can keep.
What the map looks like
The map covers objects people recognize, how they relate, the attributes that matter for decisions, and what people can do. It follows the user's mental model, not the database schema. The design record template in the repo uses this row as its example:
| Object | Relationships | Decision-relevant attributes | Actions |
|---|---|---|---|
| Appointment | belongs to Patient; with Clinician | date, status, location | book, move, cancel |
Screens and routes are then derived from the map, instead of backfilling a map after the layout is done. The outcome is recorded in one line: Map: produced / reused / skipped, with a short reason.
The map is a short working note. It is not a claim that the full ORCA method was completed.
A short example
Say you are building a small booking site at example.com, and you ask your agent to add a "My appointments" page that also lets people move a booking.
Signals present: appointments relate to a clinician and a location, and a booking can be reached from a confirmation email and from the new page. So the gate applies. The agent writes the map above, then decides where moving a booking lives and what someone must see before confirming the change (the new date, the clinician, the location).
Now say you only want the button label changed from "Reschedule" to "Move appointment". No signal applies. The record says Map: skipped — copy-only change, and the agent edits the label.
Where this fits in the method
The gate is step 3 of six: establish context, choose the visual system, map objects before layout, write a decision record, structure each view, then deliver and validate with an honest evidence label. Whether the method saves time has not been measured.
Try it
Design Decision Method follows the open Agent Skills format and is MIT licensed. Install paths for Claude Code, Cursor, Gemini CLI, and Codex are in the README.
Top comments (0)