Borrow the Form

Take a proven structure from an existing product instead of inventing from zero.

Users' habits were trained by other products. Designing along them takes far less effort—and works far better—than inventing a new set. It's almost a rule of interface design: users spend far less time on your product than on everything else, and their expectations were shaped by those other products. jakobs-law

What you'll run into:

• An interaction you think is clever leaves everyone lost on first use
• To be "distinctive," you rename something familiar and now nobody understands it
• You start designing the information architecture from scratch and spend three days revising it

Innovation in the wrong place has a cost. Users spend only a few minutes in your product and won't pay extra to learn a new set of rules. Differentiation should live in how you solve the problem, not in what the buttons are called or how the list is ordered.

A concrete example: say you're building "work through a batch of pending items one by one"—reviewing contracts, counting inventory, following up tickets. Email clients already perfected this pattern: list on the left, detail on the right, swipe to archive, "Archive" instead of "Done." Users don't need to learn it, because they've been doing it for a year in Gmail and WeChat. Design along that and your product feels familiar from the first launch.

What to borrow, what not to

The last row is the dividing line. Borrowing structure saves the user's learning cost; copying features saves your own thinking cost—and what you build that way has no reason to exist. So before borrowing anything, ask one question: whose cost does this save? Things that save the user's learning cost, borrow freely; things that only save your own thinking cost are usually just copying.

Where to borrow from

• Start with what your users use every day. The apps they open most on their phone are their default mental models.
• Then borrow from a mature product with the same structure, not necessarily the same industry. If you're building "work through a batch of pending items one by one," an email client's structure works, regardless of industry.
• Borrow the operating system's native conventions. Back, share, long-press menu—following the system is never wrong.
• After borrowing, be clear about where you differ. For a product with the same structure but different content, users will ask "then why use you?"—the answer has to live in core value.

Note for the AI

Giving the AI one concrete reference is far more effective than a pile of adjectives. When you give a reference, also say what not to borrow—the AI will tend to copy the whole thing, and feature lists are the easiest to sweep in by accident.

PROMPT · Borrow a structure

I'm building: [one-sentence description of your product]

For the structure, reference [a specific part] of [a mature product],
because my users are already used to how it works. Borrow these:
- Information hierarchy: [e.g. list → detail → archive]
- Primary navigation: [e.g. left-side top-level nav]
- Common interactions: [e.g. swipe to archive, drag to reorder]
- Naming conventions: [e.g. use "Archive" not "Done"]

Don't borrow:
- Its feature list. My features come from my own scenario.
- Its custom hierarchy for its own business.

First draw the information architecture and page map, noting which
parts are borrowed and which are specific to my scenario, then proceed.

How to check the borrowing worked. Record a new user's first-use path and watch whether they pause longer than three seconds before any action. Wherever they pause is where the borrowed mental model didn't cover—either add a hint, or accept that this step is particular to your scenario and needs an extra explanation. No pauses at all isn't entirely good either: you may have borrowed so completely that users ask "then why wouldn't I just use the original?"