Insights
-
Why do design systems struggle?
Common barriers to successful design systems
Information architecture is often the hidden challenge in design systems. Here’s why teams struggle to implement them and how to fix it.
Three key methods used in this
insight
Why design systems are introduced
Large organisations, particularly in the public sector, rarely start from scratch. Services evolve over time. New teams add new pages. Different departments solve similar problems in slightly different ways. Urgent releases are prioritised over long-term consistency.
Over time, this leads to visible friction. Interfaces look inconsistent. Patterns vary between sections. Users encounter slightly different layouts for similar tasks. Internally, designers and developers repeat work because reusable foundations do not exist.
A design system is often positioned as the solution. It aims to create shared components, consistent interaction patterns, alignment on accessibility, and a common language across teams.
However, implementation is not simply a design task. It is a structural and organisational shift.
Information architecture challenges in design systems
Design systems are often introduced with confidence and optimism. They promise consistency, faster delivery, and a shared foundation for teams building digital services. Components are defined, patterns are documented, and libraries are created.
Yet many organisations still struggle to make them work in practice.
The issue is rarely about colours or typography. More often, the challenge lies in the structure, governance, and organisation of information across services. Without a strong foundation, even the most polished component library begins to fragment.
This is where information architecture becomes critical.
Where implementation breaks down
Structure is inconsistent beneath the surface
Many teams begin by auditing UI components. They catalogue buttons, forms, spacing, and typography. While this is useful, it does not address deeper structural variation.
Pages that look similar may be built on different content models. Sections may follow different naming conventions. Navigation hierarchies may vary between services that should feel connected.
When the structure differs, components cannot truly be reused. A card designed for one context behaves differently in another. A form pattern works in one service but not in another because the underlying content structure is different.
Without structural alignment, the system becomes a visual layer rather than a functional foundation.
Governance is unclear
A design system needs ownership. It needs clear decision-making pathways and documented contribution processes.
When governance is undefined, teams treat the system as optional. Designers adjust components locally to solve immediate needs. Developers modify patterns to meet technical constraints. Product teams request exceptions without a structured review.
Gradually, variations multiply. What began as a shared foundation becomes fragmented again.
Governance does not need to be heavy. It needs to be visible, understood, and consistent.
Collaboration gaps create drift
Design systems sit across disciplines. They touch design, development, content, accessibility, and product delivery.
When these roles operate in silos, misalignment grows. Developers may interpret components differently. Content teams may introduce patterns that do not align with layout rules. Accessibility checks may occur too late in the process.
The result is a subtle inconsistency that compounds over time.
Implementation requires structured collaboration, not just shared files.
Leadership underestimates the investment
There is often an assumption that once the system is built, the job is done.
In reality, systems require maintenance, documentation updates, accessibility reviews, and adoption measurement. Without sustained investment, documentation becomes outdated, and teams revert to local solutions.
Leadership support is essential not only at launch but throughout the system's lifecycle.
Culture resists standardisation
Some resistance is natural. Teams may feel that their service is unique. They may believe that standard patterns restrict creativity or prevent them from solving specific user needs.
However, consistency is not about limitation. It is about predictability for users.
When interaction patterns remain stable, users develop confidence. When confirmation messages behave consistently, trust increases. If you are interested in how predictable patterns build confidence, you may find this related article helpful: How do confirmation screens improve user trust?
Standardisation reduces cognitive load. It makes services easier to use and easier to maintain.
Building a foundation that lasts
Start with structure, not components
Before creating a polished component library, it is important to understand how services are organised. Mapping page types, identifying shared content models, and aligning naming conventions create a foundation for components to sit on confidently.
When structure is aligned, reuse becomes natural rather than forced.
Define ownership and contribution pathways
A clear governance model prevents ambiguity. Teams should understand who reviews changes, how updates are proposed, and how accessibility standards are maintained.
Transparency reduces friction. It also reinforces that the system is a shared asset rather than an optional resource.
Test patterns in real contexts
Components designed in isolation rarely survive contact with real service flows. Prototyping patterns within realistic scenarios reveals edge cases early.
Testing within complete journeys, such as a multi-step form, a content-heavy information page, or a mobile interaction, ensures patterns support real tasks rather than theoretical layouts.
This practical validation strengthens confidence across teams.
Invest in documentation people actually use
Documentation should not feel like a design manual. It should explain when to use a pattern, when not to use it, and how it supports accessibility and clarity.
Clear examples and realistic scenarios help teams apply patterns correctly without relying on central oversight for every decision.
When documentation reflects real use, adoption improves.
Measure adoption and refine
Successful systems evolve. Reviewing adoption rates, identifying unused components, and addressing repeated exceptions reveal where refinement is needed.
Regular review reinforces that the system is a living infrastructure, not a static deliverable.
A broader perspective
Design systems do not solve every structural issue. If users struggle to find information or navigate complex document lists, deeper structural work may be required.
For example, structural clarity is central when dealing with large document libraries. The article How do you make council documents easier to use? explores how improved organisation reduces confusion and improves findability across complex platforms.
The lesson is consistent: structure drives clarity.
Moving forward
Implementing a design system is not simply about visual consistency. It is about organisational alignment, structural clarity, and long-term governance.
When the foundation is strong, teams move faster. Accessibility improves. Duplication reduces. Users experience predictable, coherent services.
If your organisation is considering introducing or refining a system, begin by looking beneath the surface. Examine how information is structured, how decisions are made, and how teams collaborate.
When the foundation is right, the components will follow.
You might find these helpful
A few related articles that build on what you’ve just read.
