A Guide to the Law of Similarity in Web Development

The Law of Similarity is one of the Gestalt principles of perception. It means that people naturally group elements that look alike. If two things share the same color, shape, size, typography, spacing, icon style, or visual treatment, users will assume those things are related.

In UX terms, similarity is how users build meaning before they read. A row of identical buttons feels like a set of related actions. Cards with the same structure feel like items from the same collection. Status badges with matching styles feel like part of a single system.

This matters because web apps are full of repeated objects like navigation links, buttons, filters, cards, charts, tables, alerts, menus, and form fields. If those elements are styled randomly, the interface becomes harder to scan. Nothing may be technically broken, but the page still feels confusing because the visual language keeps changing.

In this blog, we will discuss:

• Applying the Law of Similarity in UI/UX
• Examples of the Law of Similarity in Web Development
• Examples Using Wijmo Components

Ready to check it out? Download Wijmo Today!

Applying the Law of Similarity in UI/UX

Make Related Elements Look Related

If elements do the same kind of work, they should look like they belong to the same family. Primary buttons should share a style. Secondary buttons should share a style. Form fields should have consistent labels, borders, spacing, and validation patterns. Table statuses should use the same badge system across the product.

Similarity reduces the amount of interpretation users have to do. Once they learn one pattern, they can recognize it everywhere else.

Bad UI says, "Figure out what each thing means."
Good UI says, "You have seen this pattern before."

Keep Repeated Components Consistent

Modern web apps are built from reusable components, but reusable code does not automatically create a consistent experience. Developers can still break similarity by mixing button sizes, icon styles, column formats, label placement, menu behavior, and spacing rules.

A dashboard should not use three different card styles unless those differences mean something. A toolbar should not mix icons, text links, pill buttons, and dropdowns just because each feature was added in a different sprint. Users notice that inconsistency, even if they cannot name it.

Similarity helps the interface feel organized instead of assembled from leftovers.

Use Difference to Signal Difference

The Law of Similarity also works in reverse. If two things look different, users assume they are different.

That is useful when the difference is meaningful. A destructive action should not look exactly like a standard save button. A warning should not look like a neutral note. A selected navigation item should not disappear into the rest of the menu.

The trick is to be intentional. Similar things should look similar. Different things should look different. Random variation is not personality. It is noise.

Do Not Rely on Color Alone

Color is one of the strongest similarity signals, but it should not carry the entire interface on its own. Users with color vision deficiencies, low-quality displays, or high-contrast settings may not see the difference you intended.

If status matters, pair color with text, shape, position, or iconography. A green "Approved" badge and a red "Rejected" badge are better than unlabeled green and red dots. Similarity should support recognition, not create an accessibility guessing game.

Examples of the Law of Similarity in Web Development

Designing Consistent Cards and Lists

Cards are a clear place to apply the Law of Similarity. Product cards, article previews, user profiles, report tiles, and task cards should use a consistent structure when they represent the same type of object.

For example, an e-commerce product grid may use the same pattern for every product:

• Product image
• Product name
• Rating
• Price
• Availability
• Add to Cart button

That repetition lets users scan quickly. They do not need to relearn each card. Their eyes know where the price lives, where the button lives, and how to compare one product against another.

Making Navigation Easier to Understand

Navigation depends heavily on similarity. Links in the same navigation group should share the same visual treatment. Active states should be consistent. Dropdowns should behave consistently across sections. Icons should come from the same visual system.

If one navigation link is bold, another is underlined, another uses an icon-only button, and another opens a modal, users have to slow down. The menu no longer feels like a system. It feels like a scavenger hunt.

A similarity-driven navigation design gives users stable patterns:

• Main sections use the same link style
• Utility actions use the same compact style
• Current page state is visually distinct
• Nested items are indented and styled consistently

That consistency helps users move through the app with less hesitation.

Building Forms That Feel Predictable

Forms become easier when similar fields behave similarly. Text inputs, dropdowns, date pickers, number inputs, and validation messages should follow a clear visual language.

For example, a billing form might group fields like this:

• Customer Information
• Billing Address
• Payment Terms
• Tax Details

Inside each section, labels should appear in the same position. Required fields should be marked the same way. Error messages should use the same tone, color, and placement. Buttons should follow the same hierarchy.

When a form is visually consistent, users can focus on the information they need to provide instead of decoding the form itself.

Clarifying Data Tables

Data tables are one of the easiest places to damage similarity. Developers often add badges, icons, links, buttons, chips, inline menus, and custom formatting one feature at a time. Eventually, the table has six visual systems fighting within a single grid.

The Law of Similarity pushes developers to create a predictable table language. Similar values should be formatted similarly. Currency columns should align and use the same number format. Dates should follow one format. Statuses should use one badge system. Row actions should appear in the same place.

A good table lets users compare rows quickly because each row follows the same visual pattern.

Examples Using Wijmo Components

Grouping Similar States with Wijmo FlexGrid

Wijmo's FlexGrid is a strong fit for the Law of Similarity because it gives developers control over columns, formatting, and cell presentation. Instead of letting every field appear with default styling, you can create a consistent visual system for similar values.

This example uses similar badge styles for similar ticket statuses, making the table easier to scan.

import * as wjGrid from '@mescius/wijmo.grid';

const tickets = [
  {
    id: 301,
    customer: 'Apex Supply',
    type: 'Billing',
    status: 'Open',
    owner: 'Mia Chen',
    updated: new Date(2026, 6, 18)
  },
  {
    id: 302,
    customer: 'Northline Co.',
    type: 'Support',
    status: 'Pending',
    owner: 'Sam Rivera',
    updated: new Date(2026, 6, 19)
  },
  {
    id: 303,
    customer: 'Summit Retail',
    type: 'Feature',
    status: 'Resolved',
    owner: 'Priya Shah',
    updated: new Date(2026, 6, 20)
  }
];

const grid = new wjGrid.FlexGrid('#ticketGrid', {
  autoGenerateColumns: false,
  columns: [
    { binding: 'id', header: 'Ticket', width: 90 },
    { binding: 'customer', header: 'Customer', width: '*' },
    { binding: 'type', header: 'Type', width: 120 },
    { binding: 'status', header: 'Status', width: 120 },
    { binding: 'owner', header: 'Owner', width: 140 },
    { binding: 'updated', header: 'Updated', format: 'MMM d', width: 110 }
  ],
  itemsSource: tickets
});

grid.formatItem.addHandler((s, e) => {
  if (e.panel !== s.cells) {
    return;
  }

  const col = s.columns[e.col];
  const item = s.rows[e.row].dataItem;

  e.cell.classList.remove(
    'status-open',
    'status-pending',
    'status-resolved',
    'ticket-type'
  );

  if (!item) {
    return;
  }

  if (col.binding === 'status') {
    const statusClass = `status-${item.status.toLowerCase()}`;
    e.cell.classList.add(statusClass);
  }

  if (col.binding === 'type') {
    e.cell.classList.add('ticket-type');
  }
});

.status-open,
.status-pending,
.status-resolved,
.ticket-type {
  font-weight: 600;
}

.status-open {
  color: #0f766e;
}

.status-pending {
  color: #b45309;
}

.status-resolved {
  color: #15803d;
}

.ticket-type {
  color: #475569;
}

The table now has a readable pattern. Status values feel related because they share weight and placement, while their color differences communicate state. Type values also receive consistent treatment, allowing users to distinguish the ticket category from its progress.

The point is not to decorate the grid. The point is to make repeated meaning recognizable.

Creating Consistent Data Categories with Wijmo FlexChart

Charts can also benefit from similarity. If the same category appears in multiple charts, it should use the same color and visual treatment. If "New Customers" is blue in one chart and orange in another, users have to stop and re-map the meaning.

Wijmo's FlexChart lets you clearly define series, including consistent names, bindings, chart types, and styles.

This example applies the Law of Similarity by keeping recurring customer categories visually consistent.

import * as wjChart from '@mescius/wijmo.chart';

const pipelineData = [
  { stage: 'Lead', newCustomers: 42, returningCustomers: 28 },
  { stage: 'Qualified', newCustomers: 31, returningCustomers: 24 },
  { stage: 'Proposal', newCustomers: 22, returningCustomers: 18 },
  { stage: 'Closed', newCustomers: 14, returningCustomers: 16 }
];

new wjChart.FlexChart('#pipelineChart', {
  itemsSource: pipelineData,
  bindingX: 'stage',
  chartType: 'Column',
  series: [
    {
      name: 'New Customers',
      binding: 'newCustomers',
      style: {
        fill: '#2563eb',
        stroke: '#2563eb'
      }
    },
    {
      name: 'Returning Customers',
      binding: 'returningCustomers',
      style: {
        fill: '#16a34a',
        stroke: '#16a34a'
      }
    }
  ],
  axisY: {
    title: 'Opportunities'
  },
  axisX: {
    title: 'Pipeline Stage'
  },
  legend: {
    position: 'Bottom'
  }
});

This chart provides a simple visual rule: blue indicates new customers, green indicates returning customers. If those same colors are used across other charts, users can compare views more quickly because the category language remains consistent.

Similarity makes the chart easier to understand because users do not have to learn a new visual system every time they change screens.

Building Similar Filter Controls with Wijmo Input Controls

Filters are often repeated across dashboards, tables, and reports. That makes them a perfect place to apply the Law of Similarity. Similar filters should share label placement, control width, spacing, and interaction behavior.

Wijmo Input controls can help create a consistent filter panel using controls like ComboBox, InputDateRange, and InputNumber.

<div class="filter-panel">
  <div class="filter-field">
    <label for="statusFilter">Status</label>
    <input id="statusFilter" />
  </div>

  <div class="filter-field">
    <label for="dateFilter">Updated</label>
    <input id="dateFilter" />
  </div>

  <div class="filter-field">
    <label for="valueFilter">Minimum Value</label>
    <input id="valueFilter" />
  </div>
</div>

import {
  ComboBox,
  InputDateRange,
  InputNumber
} from '@mescius/wijmo.input';

const statuses = [
  { id: 'all', name: 'All Statuses' },
  { id: 'open', name: 'Open' },
  { id: 'pending', name: 'Pending' },
  { id: 'resolved', name: 'Resolved' }
];

new ComboBox('#statusFilter', {
  itemsSource: statuses,
  displayMemberPath: 'name',
  selectedValuePath: 'id',
  selectedValue: 'all'
});

new InputDateRange('#dateFilter', {
  monthCount: 2,
  closeOnSelection: true
});

new InputNumber('#valueFilter', {
  format: 'c0',
  min: 0,
  step: 500,
  placeholder: 'Minimum value'
});

.filter-panel {
  display: grid;
  grid-template-columns: repeat(3, minmax(180px, 1fr));
  gap: 16px;
  margin-bottom: 20px;
}

.filter-field label {
  display: block;
  margin-bottom: 6px;
  font-weight: 600;
}

.filter-field .wj-control {
  width: 100%;
}

The controls are different, but the pattern is similar. Each filter has a label, consistent width, and predictable spacing. Users understand that these controls belong to one filtering task.

That is the Law of Similarity doing real interface work.

Organizing Similar Navigation Groups with Wijmo TreeView

Wijmo's TreeView can help organize navigation, settings, or workflows into a recognizable hierarchy. Top-level items can share one style, nested items can share another, and related groups can use consistent category styling.

import * as wjNav from '@mescius/wijmo.nav';

const workflowNav = [
  {
    header: 'Sales',
    group: 'sales',
    items: [
      { header: 'Pipeline' },
      { header: 'Quotes' },
      { header: 'Orders' }
    ]
  },
  {
    header: 'Support',
    group: 'support',
    items: [
      { header: 'Tickets' },
      { header: 'Customers' },
      { header: 'Knowledge Base' }
    ]
  },
  {
    header: 'Admin',
    group: 'admin',
    items: [
      { header: 'Users' },
      { header: 'Roles' },
      { header: 'Integrations' }
    ]
  }
];

new wjNav.TreeView('#workflowTree', {
  itemsSource: workflowNav,
  displayMemberPath: 'header',
  childItemsPath: 'items',
  autoCollapse: true,
  formatItem: (s, e) => {
    e.element.classList.remove(
      'node-sales',
      'node-support',
      'node-admin',
      'node-leaf'
    );

    if (e.level === 0 && e.dataItem.group) {
      e.element.classList.add(`node-${e.dataItem.group}`);
    }

    if (e.level > 0) {
      e.element.classList.add('node-leaf');
    }
  }
});

.node-sales,
.node-support,
.node-admin {
  font-weight: 700;
}

.node-sales {
  color: #1d4ed8;
}

.node-support {
  color: #047857;
}

.node-admin {
  color: #7c2d12;
}

.node-leaf {
  color: #475569;
  font-weight: 400;
}

The top-level nodes share weight and structure, so users recognize them as major navigation categories. The nested nodes share a quieter treatment, so they read as secondary options.

TreeView gives the interface a repeated hierarchy. Users do not need to wonder whether "Pipeline," "Tickets," and "Users" are the same kind of object. The visual language tells them.

Conclusion

The Law of Similarity is simple, but it shows up everywhere in web development. Users group things that look alike. That means every repeated style in your UI is teaching users what belongs together, what behaves the same way, and what deserves the same kind of attention.

For web developers, similarity is not just a visual polish issue. It is a usability tool. Use consistent component patterns. Make repeated actions recognizable. Keep table formatting predictable. Use contrast only when the difference matters. And do not make users relearn your interface from one screen to the next.

With Wijmo's JavaScript UI components, you can apply the Law of Similarity directly in real applications: create recognizable status patterns with FlexGrid, keep chart categories consistent with FlexChart, build predictable filter panels with Wijmo Input controls, and organize navigation with TreeView.

The result is a web app that feels easier to scan, learn, and trust.

Ready to try it out? Download Wijmo Today!