| name | consistency-external |
| description | Apply external consistency — honoring conventions from outside your product (platform conventions, category conventions, established interaction patterns) so users can transfer their learning into your product. Use when designing for a specific platform (iOS, Android, web), entering an established product category (calendar, email, file manager), choosing icons or gestures, or deciding when to follow vs. lead a convention. External consistency reduces the learning cost for new users; deviating from it requires both a strong reason and explicit framing. |
Consistency — external
External consistency is honoring conventions that exist outside your product. The hamburger menu means "menu" because it means "menu" everywhere; the magnifying glass means "search"; pinch-to-zoom does what it does. Following these conventions lets users transfer their learning from other products directly into yours, with no onboarding cost.
External consistency is most powerful for new users — they're using accumulated learning from years of other products. As users mature in your product, internal consistency starts to dominate, because their learning becomes mostly product-specific. But the first session, where conversion happens or doesn't, is largely about external consistency.
What external consistency includes
Several distinct kinds of convention live "outside" your product.
Platform conventions. iOS, Android, macOS, Windows, web — each platform has accumulated conventions that users expect from native apps on that platform. The platform-native back gesture, the platform-native scrollbar, the platform-native form-input behavior, the platform-native keyboard shortcut for save. Apple's Human Interface Guidelines, Android's Material Design, and similar documents codify these.
Category conventions. Calendar apps look like calendars. Email apps look like email. File managers look like file managers. There's a strong, accumulated category-level expectation about layout, terminology, and interaction. Departing from category convention requires either a strong reason ("we're reimagining email") or accepting that users will have a steeper learning curve.
Web conventions. Underlined blue text is a link. The browser's back button works. Hover states reveal interactivity. Forms submit on Enter. Tab traverses focus. These are the conventions of the web as a platform.
Domain conventions. In specialized domains (medical software, financial software, design tools), there are conventions specific to the domain that users from that domain expect. A code editor uses certain symbols and color conventions; a CAD tool uses certain layouts; a music DAW uses certain interaction patterns. Domain conventions matter most for tools serving experts within the domain.
Cross-cultural conventions. Some conventions are global (color of red light, the magnifying glass for search); others are regional (the dollar sign for money is dominant in dollar-using countries; in others, currency symbols vary). Globally deployed products need to verify which conventions actually transfer to their audience.
When to honor external conventions
External conventions should be honored unless you have a strong reason not to. Specifically, honor conventions when:
Your audience comes to your product from many other products. Web apps, mobile apps, productivity tools — most users have encountered hundreds or thousands of similar products. Their accumulated learning is your asset.
The convention solves the problem reasonably well. The hamburger menu is fine. The magnifying glass for search is fine. They're not optimal in every case but they're widely understood, and the cost of teaching users a new pattern usually exceeds the gain from a slightly better one.
You're in an established category. Email, calendar, chat, file management, e-commerce — these categories have decades of accumulated convention. Reinventing what a "send" button looks like is rarely worth it.
Users are casual or first-time. Casual users have no patience for unfamiliar conventions; they'll abandon a product whose patterns they don't recognize within minutes.
When to break external conventions
Sometimes deviation is warranted. Specifically, consider breaking external conventions when:
The convention is genuinely bad. The floppy disk for "save" is increasingly anachronistic. The mailing-envelope for "email" is fine for now but won't be in twenty years. Following dying conventions just because they're conventional is sometimes wrong.
You have a fundamentally better pattern. If your new pattern is significantly easier or faster, the cost of teaching users the new pattern can be paid back over the lifetime of their use. But the bar is high — users have a lot of accumulated learning at stake.
The convention doesn't apply to your case. A convention that emerged in one context may not transfer cleanly to another. The "long-press for context menu" convention from desktop right-click doesn't translate well to all touch contexts.
You're explicitly reframing the category. "We're reimagining email" is a frame that gives users permission to expect new patterns. The frame has to actually be in the marketing — users won't infer it from the product alone.
In all these cases, the deviation should be deliberate, well-framed, and supported by onboarding. Sneaking in a non-conventional pattern without acknowledgment loses you users who don't know to expect it.
Worked examples
A web app that follows web conventions
A team building a web-based project-management tool follows web conventions: the browser's back button works, links look like links, forms submit on Enter, search is in the upper-right with a magnifying glass icon, settings are reachable from a gear icon. Users from other web tools find it immediately familiar.
The team's competitor reinvents some conventions: the back button doesn't work (it has its own in-app navigation history that overrides browser back), search uses a custom hexagon icon, settings are in a non-standard location. The competitor's product takes longer to learn, and users coming from elsewhere bounce more frequently.
The lesson: web conventions are extremely strong. Reinventing them is almost always net-negative.
A mobile app that follows platform conventions
An iOS app uses the system-native navigation bar (back button on the top-left, title in the center, action button on the top-right), the system-native swipe-back gesture, the system-native keyboard, the system-native share sheet, and the system-native modal presentation. iOS users find it familiar from the moment they open it.
The same app's Android version uses Android conventions (navigation drawer, system back button, system share intent, Material Design components). Android users find it equally familiar.
The product is consistent within itself in workflows and content but adapts its chrome to each platform. This is the right tradeoff for cross-platform mobile.
A category convention deliberately broken
A weather app departs from the standard "current temperature, hourly forecast, daily forecast" layout in favor of an ambient-light visualization. The departure is deliberate; the marketing frames it as "Weather, reimagined as ambient atmosphere." The first-launch screen briefly explains the metaphor.
Users who arrived via the framing accept the new pattern; users who arrived without the framing are confused. The framing is essential — it's what gives users permission to expect a new pattern instead of falling back on category expectations.
A domain convention used appropriately
A code editor uses syntax highlighting (color conventions for keywords, strings, comments) following the conventions of every other code editor. Programmers expect this; departing from it would be an unforced error. The product extends the domain conventions in some places (custom semantic highlighting for specific frameworks) but doesn't replace them.
A convention misapplied to a new context
A team building a smart-home app uses a "trash can" icon for "remove device from network." Users tap the icon expecting to delete the device's record; they're surprised to find that the device is now disconnected but the record remains. The trash-can convention misled them.
The fix: use a different icon (a "disconnect" symbol or "unlink" icon) and a different label ("Remove from network") to signal that this is not a deletion. The convention was strong but wrong for this case.
Anti-patterns
Reinventing for novelty's sake. A new icon for "search" because the magnifying glass feels overused. A new layout for the calendar because "we want to do something different." Novelty in convention costs the user; do it only when the new pattern is genuinely better, not for differentiation alone.
Following conventions that don't fit your audience. A B2B SaaS product following consumer-mobile conventions (a hamburger menu hiding the main nav on a desktop browser) when its users are at desktops with screen real estate to spare. The convention is for a different context.
Following dying conventions out of habit. The floppy disk for save when users no longer recognize it. The CD/DVD icon for media. Some conventions outlive their generation; reaching for them by reflex serves no one.
Half-following conventions. Using the standard icon but with non-standard behavior (the magnifying glass that opens a generic filter panel rather than a search box). Worse than either fully following or fully replacing the convention, because users have stronger expectations about behavior than about appearance.
Ignoring platform conventions on platform-native apps. Forcing iOS users to use Android-style navigation, or web users to use mobile-style chrome. Your product looks "out of place" on the platform and users feel the mismatch even if they can't articulate it.
Following one convention in some places, another in others, within the same product. Internal inconsistency cancels the benefit of either external convention. Pick one source of convention and follow it consistently.
Heuristic checklist
When designing a new pattern, ask: Is there an established convention for this case? If yes, default to it unless you have a strong reason. What platform am I on, and what does that platform expect? Honor platform conventions for the chrome of your app. What category am I in, and what does that category expect? Honor category conventions for the substance of your app. If I'm breaking a convention, do I have a strong reason and an explicit framing? Without both, reconsider.
Related sub-skills
consistency — parent principle on the four kinds of consistency.consistency-internal — sibling skill on internal consistency.mimicry — external consistency is a form of mimicking established patterns.recognition-over-recall — external conventions are recognized rather than recalled.mapping-cultural — cultural mappings are one specific form of external convention.iconic-representation — icon conventions are external consistency at the icon level.
See also
references/platform-conventions.md — survey of major platform conventions and how to honor them.
