Related optical clusters share a cadence while retaining deliberate differences.

Design

The Cost of Inconsistent Design

Small design differences create repeated work for users and teams.

MT BYTES6 min read
Read the perspective

The cost of decisions that keep returning

A business adding a new service page should be deciding what the service offers and what a buyer needs to understand. If the same project also reopens the choice of button styles, enquiry fields, heading sizes and confirmation messages, part of the effort is being spent on questions the organisation has answered before.

One repeated discussion is a minor inconvenience. Across a website, customer portal and growing set of campaign pages, it becomes a capacity issue. Designers recreate familiar elements, developers reconcile slightly different implementations, and reviewers have to distinguish intentional changes from accidental ones.

This is the practical business case for design consistency. It gives teams a dependable starting point for recurring work, leaving more attention available for the decisions that are specific to the customer or product.

The savings should not be assumed. Establishing shared patterns takes time, and maintaining them adds responsibility. A small, stable website may need only a modest set of conventions. A business producing frequent pages or operating several related interfaces may have a stronger reason to invest.

The question is therefore concrete: which decisions does the business keep paying to make again, and which of those could be settled once without reducing the quality of the result?

Consistency is an investment in repeatable work, so its value should be judged where that work actually happens.

Start with behaviour and meaning

Consistency is easy to recognise in colour and typography. It is just as relevant to the meaning of a label, the behaviour of an error message and the information required to complete a request.

If one interface uses “enquiry” for an initial question and another uses the same word for a confirmed order, a shared visual style will not resolve the ambiguity. If a form preserves entered information after an error on one page but discards it on another, customers face different experiences even when the fields look identical.

The UK Department for Work and Pensions describes a design system as reusable standards accompanied by guidance. That combination matters: a reusable element needs an explanation of when and how it should be used.

For an SME, the first useful standards may be unglamorous. Agree how services are named, which actions require confirmation, how required information is explained and what a completed request tells the customer. Resolve the visual expression around those decisions.

This also clarifies what the business is trying to achieve. A consistent appearance can support recognition, but consistency of meaning helps teams avoid contradictory information. Consistency of behaviour gives a returning user fewer interface rules to rediscover. Each is worth examining on its own terms.

Find the patterns in existing work

Before commissioning a large library, inspect the work the business already produces. Group together pages or screens that serve a similar purpose. Look for repeated enquiry forms, service introductions, product information, alerts and confirmation states.

For each group, ask why the versions differ. Some differences will be justified. A support request may need information that a sales enquiry does not. Others may reflect separate suppliers, an old experiment or a decision made under a deadline and never reconsidered.

Do not count every variation as waste. The useful finding is an unnecessary difference that creates further work or confusion. Record the consequence: an extra development task, a repeated content question, a conflicting interaction or an avoidable review cycle.

The GOV.UK Design System provides an established example of organising shared styles, components and patterns. An SME can learn from that separation without adopting government branding or recreating the scale of a public-sector system.

Choose one frequently used pattern with a clear problem and a manageable scope. Improve it, document it and use it in the next relevant piece of work. That gives the team a chance to learn whether the shared approach is useful before standardising more of the product.

An inventory earns its place by changing a decision. A catalogue of screenshots, with no priority or owner, simply adds another document to maintain.

Leave room for differences that matter

A common pattern should make suitable work easier. It should not force every customer, service or market into an identical interface.

For a business operating in several countries, a shared enquiry form may need different address fields, telephone formats or language support. A payment flow may vary because the available methods differ. These are functional requirements, not failures of brand discipline.

Decide which parts should remain stable and which are intended to vary. The purpose of a field, the clarity of its explanation and the treatment of an error may be shared even when the information collected changes. Document that boundary so each local adaptation does not become a fresh argument.

This is also relevant within one market. A transactional screen and an editorial page have different reading tasks. Requiring them to use the same density or layout could make both less effective. A coherent design language can accommodate different compositions.

IBM's Carbon introduction describes a system that includes working code, design resources and guidance. Its existence illustrates the breadth of a maintained system; it does not demonstrate that an SME should copy IBM's structure or investment.

Allow exceptions to be explained. A short note identifying the user need and the reason an existing pattern does not fit is more useful than either unrestricted variation or a rule that nothing can change.

Measure rework before claiming efficiency

The number of components in a library says little about whether the business is benefiting. Measure the work the system is intended to improve.

For a recurring page type, record the effort involved in preparing the content, designing the page, implementing it and reviewing it. Note how much of the review concerns recurring decisions rather than new material. After adopting a shared pattern, make the comparison on similar work.

Use the result cautiously. A simpler page, a more experienced team or a better brief could also explain a faster delivery. The aim is to understand whether the shared approach helps, not to attribute every improvement to the design system.

Other evidence can be useful without becoming an elaborate reporting exercise. Are teams finding the agreed pattern? Are they using the same version? Do the same avoidable issues return during review? Has a fix reached the places where it is needed?

Include maintenance in the calculation. A pattern that saves production time but creates an expensive upgrade burden may need a different implementation. Equally, a pattern used infrequently may still justify attention if a mistake would have serious consequences.

Consistency is an investment in repeatable work, so its value should be judged where that work actually happens. Avoid turning a useful operational discipline into a claim about a percentage saving the business has never measured.

Give shared decisions a home and owner

A common pattern is useful only if people can find it, understand its status and get an answer when it does not fit. Put the approved version in the tools the team uses, with a short explanation of its purpose and known limitations.

Assign responsibility for keeping design, content and implementation aligned. This does not necessarily require a new role. It requires someone with enough time and authority to resolve changes and identify when a decision affects other parts of the product.

Plan adoption around actual work. Updating a recurring page when it next changes may be more proportionate than rebuilding every existing page immediately. Where a shared error or accessibility problem affects important tasks, the need for a coordinated update may be stronger.

When commissioning design support, include the adoption work in the scope. Ask where the approved patterns will live, which existing pages will change and who will maintain them. More formal contribution rules can follow as the number of teams and dependencies grows.

The outcome to seek is straightforward. When the next page or feature arrives, the team should know which decisions are already dependable and where fresh design work is still necessary. That is how consistency earns a place in a growing business.

MT
MT BYTES

Perspectives on technology and business.

Explore perspectives

Find the design decisions worth sharing

Discuss the recurring pages, product interfaces and review problems your team wants to simplify with MT BYTES.

Discuss your project