Reference, Not Recreate
Points at how another product behaves precisely enough to build from, without asking for a clone.
When to reach for it
When the clearest way to explain what you want is another app — "like the way Slack handles unread" — and you need the behavior extracted rather than the appearance copied.
What changes
- The reference gets restated as trigger, response, timing, and failure behavior, so you can see whether the right thing was understood before any code exists.
- You get a take list and a leave list, separating the mechanic from the other product's brand, copy, icons, and visual identity.
- Timings and dimensions recalled from memory are labeled as guesses with a defensible default, rather than quoted as if measured.
- The reference ends as an acceptance test — do X, expect Y within Z — that the finished work is checked against.
Pairs with
- Describe the FeelTurns "make it feel premium" into properties with numbers you can check when it comes back.
- Structure Before StyleDecides the shape of the screen before any colour is picked, because being recognisable on sight is the failure — not any one ingredient.
- Assumption CheckMakes the agent state what it is assuming — and verify it — before it writes a line.
Reference, Not Recreate
The request names another product. Extract the mechanic; leave the identity behind.
1. Locate the reference exactly
Name the product, the specific surface, the specific gesture, and where it was seen — which platform, roughly which version, desktop or mobile. "Linear" is not a reference. "The way Linear's issue list keeps the scroll position when you close an issue with Escape" is.
2. Describe the mechanic, not the skin
Write it as a sequence:
- Trigger — what the user does, precisely
- Response — what changes on screen, in what order
- Timing — what is instant, what is delayed, what is animated
- Persistence — what survives navigation, refresh, or a new session
- Interrupt — what happens if the user acts again mid-flight
- Failure — what is shown when the underlying action fails
The failure and interrupt rows are the ones that get skipped, and they are usually the reason the reference feels good.
3. Split into take and leave
- Take — the behavior, the state model, the ordering rules
- Leave — their name, logo, icon shapes, colour palette, wording, illustrations, and any distinctive visual signature
Write both lists. The leave list is what stops a reference becoming a knock-off.
4. Translate into this product's terms
Map their nouns onto ours before writing code: their "issue" is our "ticket", their "workspace" is our "project". If a concept has no counterpart here, say so — that is a design decision, not a detail.
5. Mark what is guessed
Any number recalled rather than measured gets labeled: "duration around 150ms — from memory, not measured; using 150ms as a defensible default." Then check whether the number actually matters.
6. Turn it into an acceptance test
One sentence per behavior: "With three items selected, pressing Escape clears the selection and leaves scroll position unchanged." That is what the finished work gets checked against.
Rules
- Do not reproduce the reference's trademarks, brand assets, icon artwork, or copy. Behavior is the thing being borrowed.
- Do not accept a bare product name as a specification. Ask which surface and which gesture, or state the assumption in writing.
- Do not quote remembered numbers as measurements.
- Do not copy an interaction whose prerequisites are missing here — a local index, a websocket, a different data model. Name the prerequisite instead of faking the result.
- Do not import the reference's flaws because they came with it. Say which parts are being deliberately left behind.