Strategy ⚡ Low

Law of Similarity

Things that look alike are assumed to work alike — design visual consistency on purpose.

Visual hierarchy Design systems Navigation states Interactive elements Data visualisation Pattern consistency

01 — TL;DR

Two sentences.

The Law of Similarity is a Gestalt perceptual principle establishing that the human visual system automatically groups elements sharing visual properties — colour, shape, size, texture, orientation, pattern — into the same perceptual category, assuming they are functionally equivalent regardless of their spatial position. For interface designers, this means visual consistency is not an aesthetic preference but a functional communication: when all interactive buttons share the same visual treatment, users can identify new buttons by similarity to known ones; when interactive and non-interactive elements are visually indistinguishable, users cannot determine what is clickable through visual scanning alone.

Similarity creates functional expectation — not just visual grouping

When two elements look the same, users don't merely perceive them as belonging to the same category — they expect them to behave the same way. A button that looks like every other button but doesn't respond to a click violates the functional expectation that similarity established. Applying the same visual treatment to functionally different elements does not merely create visual confusion — it creates interaction prediction failures.

Trigger phrase

When users are failing to recognise interactive elements as clickable, treating non-interactive elements as interactive, or not perceiving a set of functionally related items as belonging to the same category — and the root cause is visual inconsistency rather than missing labels.

02 — When to Use

Apply this when…

→ A design system is being built and you need a principled basis for deciding which visual properties should be shared across which element categories — interactive elements, status indicators, navigation items, data categories

→ A data visualisation uses multiple data series and you need to encode categorical membership visually — consistent colour across one category, consistent shape across another series

→ Users are reported clicking on non-interactive elements or failing to identify interactive elements — the cause is almost always similarity (or lack of it) between interactive and non-interactive treatments

→ Navigation items have multiple states (active, inactive, hover, disabled) and transitions need to maintain categorical identity while communicating state difference

→ A product is adding new features and new interactive patterns need to look similar enough to established ones that users can identify them by similarity without explicit instruction

→ A design audit reveals that multiple teams have independently created visually different versions of the same functional element — buttons with different border radii, inputs with different backgrounds, cards with different shadows

When NOT to apply it

Skip similarity enforcement when elements must appear similar for layout or aesthetic reasons despite being functionally different — spatial position, label size, or explicit category text must then override the automatic categorical inference the visual system creates. Skip it when the context is explicitly art direction rather than functional interface — decorative, illustrative, and brand elements may deliberately use visual similarity as an expressive technique rather than as categorical communication.

03 — How It Works

The mechanism

The visual system uses appearance as a proxy for category membership. In the natural world, things with the same appearance typically have the same properties — red berries on a bush are the same type, leaves on a tree have the same function. The visual system's automatic grouping by similarity is an efficient categorical inference engine: if things look the same, they probably are the same. Wertheimer's original demonstrations showed participants involuntarily grouping arrays of shapes by shared property rather than by position — and Anne Treisman's feature integration theory established that similarity grouping occurs within approximately 50 milliseconds, pre-attentively.

Establish a clear visual vocabulary for interactive vs non-interactive

Every interface implicitly uses similarity to communicate interactivity: buttons look like buttons because they share visual properties (border, fill, padding, radius); links look like links because they share colour and underline; inputs look like inputs because they share border and background. Make the shared vocabulary explicit and maintain it. The rule: everything interactive should share a visible affordance signal; everything non-interactive should lack it.

Assign visual properties to functional roles, not to individual components

Material Design assigns the "primary" colour to all interactive actions across all components — so any element in that colour is interactive, regardless of which component it lives in. This is similarity functioning as a categorical code. Define what each colour, weight, or shape means at the functional level, then apply it consistently — so users can infer new elements' function from their appearance.

Differentiate functionally opposite actions visually, not just through labels

A "Confirm" and a "Cancel" button with identical visual weight communicate through similarity that the two actions are equivalent — creating real probability of accidental destructive action. Functionally opposite actions require visual distinction beyond labels: position, colour, weight, or other properties must differentiate them. "Delete" should not look like "Save"; "Approve" should not look like "Reject".

Manage similarity and proximity together as grouping signals

Visually similar elements that are spatially separated will still be grouped by similarity across the gap. Dissimilar elements that are spatially proximate will be grouped by proximity despite the visual difference. When the two signals conflict, the stronger one dominates — but the outcome depends on their magnitudes. Decide explicitly which principle should govern each grouping and ensure its signal is strong enough to override the other.

Validate with category identification and interaction-error testing

Show users an interface element in isolation (without labels) and ask: "Is this interactive? Which category does this belong to?" If they can answer reliably, similarity is carrying categorical information correctly. Also measure similarity-based interaction errors — users clicking non-interactive elements that resemble interactive ones, or failing to click interactive elements that don't conform to the established vocabulary. Error patterns reveal which similarity links are missing or broken.

Similarity and Proximity work together — and can conflict

Similarity groups by shared visual properties; Proximity groups by spatial closeness. In well-designed interfaces they reinforce each other — related elements are both close and look alike. When they conflict — proximate elements that look different, or visually identical elements that are spread apart — the stronger signal wins, but the result depends on magnitude. Complex layouts can produce ambiguous perception when proximity and similarity suggest different groupings; resolve this by deciding explicitly which principle should dominate and strengthening its signal accordingly.

04 — Real Example

Material Design's colour-role assignment and the similarity-based interactive vocabulary

Google's Material Design system is one of the most systematically documented applications of the Law of Similarity in a production design system. Material Design explicitly assigns visual properties — primarily colour — to functional roles rather than to individual components: the "primary" colour role is applied to all interactive actions and CTAs across all components; the "secondary" colour role to all supporting interactive elements; the "surface" colour role to all non-interactive containers. The functional vocabulary emerges from the consistent assignment — any element sharing the primary colour is interactive; any element in the surface colour is not.

The strategic insight is that role-based colour assignment teaches users the interactive vocabulary of any product built on the system through similarity. Users who have learned that primary-colour elements are interactive in one Material Design application can apply that knowledge to any other Material Design application without explicit instruction. The visual property (primary colour) is consistently associated with the functional category (interactive action), so category membership of any new element is immediately inferable from its appearance.

Design system · Android / Web · Material Design

Role-based colour consistency builds a transferable interactive vocabulary through similarity

This is the Law of Similarity functioning as a cross-application design language rather than merely as within-application consistency. Because the same visual property (primary colour) is reliably associated with the same functional role (interactive action) across every Material-based product, users build a cross-product mental model that transfers. Similarity propagates functional knowledge at scale — and the design system is the infrastructure that keeps the signal consistent enough to be worth learning.

Colour-role = functional-role

05 — In the Wild

Test yourself & see real examples

No examples yet — be the first.

Spotted a product with such a consistent visual vocabulary that you could immediately identify every interactive element from its appearance — or one where interactive and non-interactive elements are so visually similar you have to click things to find out if they work? Submit a screenshot and annotate what you see. Every approved example gets attributed to you.

✓ Reviewed before publishing ✓ Your name on every example you submit ✓ Violation or fix — both welcome

Seen the Law of Similarity applied systematically or violated in a real product? Help grow the evidence base.

06 — Common Mistakes

Where teams go wrong

✗ Making interactive and non-interactive elements visually indistinguishable. Product cards that look identical whether or not they are clickable, informational text styled identically to linked text, form fields with the same treatment as display-only outputs — all require users to try-and-see instead of infer from appearance. The fix isn't to make every interactive element large and colourful — it's to ensure same-type elements share enough properties to form a category, and different types differ on at least one property.

✗ Applying the same visual treatment to elements with opposite functions. A "Confirm" and a "Cancel" button with identical visual weight communicate through similarity that the two actions are equivalent — creating a real probability of accidental destructive action. "Add to cart" and "Remove from cart" with matching icon style, "Approve" and "Reject" with matching typography, "Active" and "Inactive" toggles that look identical — all create functional-expectation ambiguity that labels alone cannot fix.

✗ Allowing design debt to accumulate multiple treatments for the same element type. Buttons designed at different times with slightly different border radii, input fields from different product areas with different backgrounds, icon styles with different stroke weights — users who learned the visual vocabulary of one part of the product cannot reliably apply it to others because functionally equivalent elements aren't visually consistent. Not an aesthetic problem — a functional one that compounds with every inconsistency added.

✗ Creating similarity groups that conflict with the interaction model. A settings page where toggles and checkboxes share the same visual treatment communicates they are the same kind of control — but toggles apply immediately while checkboxes require submission. A pricing page where included and excluded features are styled identically obscures a critical distinction. Applying similarity requires intentional decisions about which visual properties encode which categorical distinctions, not just visual coherence.

✗ Ignoring that similarity creates functional expectation, not just visual grouping. A disabled button that looks like every other button but does nothing when clicked violates the functional expectation similarity has established — worse than a visibly distinct disabled state would be. Whenever you style something like an interactive element, users will expect it to behave like one; design the state signals (hover, active, disabled) deliberately so similarity maps cleanly onto the actual behaviour.

07 — Variations & Related Principles

Connected ideas

The Law of Similarity is the Gestalt principle governing categorical perception through shared visual properties. Its closest relationships are with the other perceptual and cognitive principles that govern how users form and apply categories in interface interactions.

The most important pairing is the Law of Similarity with design system component consistency. Similarity predicts that visual consistency across same-category elements enables categorical inference; design system component libraries are the structural mechanism for enforcing that consistency. A design system assigning consistent visual properties to component categories — buttons, inputs, navigation items, cards — is a systematic implementation of the Law of Similarity as design infrastructure. Without a system to enforce it, visual similarity degrades through iteration and the categorical inference mechanism breaks down, forcing users back onto labels and trial interaction rather than visual pattern recognition.

08 — 10-Min Exercise

Run it right now

⏱ 10 minutes · Solo · No prep

The Category Audit

Open your product and identify every interactive element type on your most important screen — buttons, links, icon buttons, card CTAs, navigation items, toggles, and any other elements users can click or tap. List them.

1. For each interactive element type, write down the specific visual properties that distinguish it: background colour, border, border radius, typography weight, icon presence, shadow. Be precise — "blue" is insufficient; "hex #2563EB background with white text and no border" is useful.

2. Compare the visual properties across your list. Are there two interactive element types that share enough properties for a new user to perceive them as the same category? Are there interactive elements that share more properties with non-interactive elements (text, containers, images) than with other interactive elements?

3. For any category ambiguity — interactive elements that look too similar to each other or too similar to non-interactive elements — write the minimum visual change that would create a clear similarity-based categorical distinction.

4. The minimum change is the starting point for the design conversation about visual vocabulary consistency in your product. The goal isn't a complete redesign — it's resolving the specific similarity conflicts that are forcing users to rely on labels and trial interaction instead of pre-attentive categorical inference.

10 minutes