You ask your AI agent for a small change: let someone snooze a reminder on example.com. Without a shared procedure, the reply can grow into controls nobody asked for.
Design Decision Method is six steps. For a small change, the notes can stay short. This walkthrough takes one fictional feature through all six as light notes — not a case study, not a measured result, and not a claim about every agent.
The product details below are invented for the illustration.
The brief
example.com already has reminders with a title, a due time, and a done action. You want snooze on the existing reminder detail view: one hour, tomorrow morning, or a time the person picks. No new navigation. No new object types.
1. Establish context
Audience: People who already use reminders on their phone.
Task / frequency: Snooze an upcoming reminder; occasional.
Cost of a mistake: Medium — a bad snooze can make someone miss a follow-up.
Device: Phone first.
Known: Title, due time, and done already exist. There is no calendar product.
Assumed (marked): Quiet hours were not requested, so none are designed.
Enough for establish context: who it is for, how often it happens, what a mistake costs, and what the product already has.
2. Choose the visual system
Keep the project's existing components and tokens. This change adds snooze actions; it does not introduce a new visual identity.
One line is enough when a system already exists. Choose the visual system starts there.
3. Object map — run the gate
The docs ask for a map when relationships would change the navigation, the routes, or the structure of the screen. Skip the map when the change does not depend on those relationships, such as a copy edit or a restyle that leaves the structure alone.
The agent procedure records the gate in one line:
Map: skipped — snooze adds actions on an existing reminder detail view. No new object types, no new routes, and navigation is unchanged.
When relationships would reshape the screen, map objects before layout. When they would not, do not invent a map for theatre.
4. Decision record
One consequential choice:
Decision: Three snooze presets (1 hour, tomorrow morning, pick a time). Presets first; custom time secondary.
Frequency / familiarity: Occasional; snooze is already familiar elsewhere.
Error cost: Medium if the new time is unclear.
Device: Phone.
Why: Presets cover common cases with less entry effort than opening a full picker every time.
Assumption: "Tomorrow morning" means 09:00 in the person's local timezone — marked, not smuggled in as an unmarked product rule.
A decision record is for choices that are costly to undo, not for every spacing tweak.
5. Structure each view
Purpose: Delay one reminder without opening a separate settings flow.
Information to decide: Reminder title, current due time, and the new time.
Actions: Snooze 1 hour; until tomorrow morning; pick a time; cancel.
States: Loading while saving; error if save fails (keep the reminder identity visible); success shows the new time on the detail view.
Device: Presets and cancel stay available on a narrow screen.
Structure each view before the chrome.
6. Deliver and validate
Delivered: Snooze actions on reminder detail (code), plus the notes above.
Acceptance / evidence:
- Choosing "1 hour" updates the due time. Manual test on one phone-sized viewport.
- Custom time rejects empty input and keeps the previous due time visible. Heuristic review of the flow only.
- Contrast on the snooze actions. Automated check on the colours used — not a claim about the whole product.
- People finish snooze without help. Proposed. Not tested. No user research. Not tested: screen reader pass, offline behaviour, other timezones beyond the marked assumption.
Deliver and validate labels what each result rests on and says what was not tested. Nothing above invents a measurement.
Keep it light
Six steps, still light: short context, a one-line visual keep, a skipped map with a reason, one decision, a compact view note, and an honest handoff. The method is a shared procedure, not mandatory for every small edit. It does not claim this saves time — that has not been measured. What it gives you is a trail of decisions the next prompt can reuse.
Try it
Design Decision Method is a lightweight design decision workflow for developers building interfaces with AI agents. It 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)