A Design System is not perfect (and it doesn't have to be)

In this blog, I share my experience with setting up a Design System within a government institution. How I quickly came to the realization that achieving overall uniformity of User Interface (UI) and User Experience (UX) is more challenging than it seems, and how I adjusted my goal.
Robert Roose
Door Robert Roose

A Design System is not perfect (and it doesn't have to be)

Setting up a Design System? Easy, right?

Almost two years ago, I started with a challenging assignment at the Netherlands Enterprise Agency (Rijksdienst voor Ondernemend Nederland - RVO).

My task: ensure that the customer has a consistent User Interface (UI) and User Experience (UX) when using RVO's various applications and websites.

The Utopia of a Design System

The solution: A design system. This design system defines how components within the applications and websites should look. A component within our Design System must adhere to the government's visual style, user-friendliness (based on internal and external research results), and accessibility. In addition, the Design System includes patterns that show how the various components can best be used together.

Naïvely, I thought this wouldn't be too complex. You design about 30 components, a few patterns, and sample pages, and the applications could start using the Design System. Within a few months, maybe a year, all applications and channels would have a uniform appearance.

The Reality of a Design System

Reality is different. Setting up the design system and designing the components and patterns progressed well. However, integrating the applications is a challenge. You have to deal with dozens of different applications from internal and external suppliers, each with varying levels of technical knowledge. Additionally, factors like time and budget play a role in the prioritization of integrating with a design system.

I quickly realized that I had to adjust my goal of achieving uniformity quickly. I need to start small.

Technical Integration Is the Most Important

That means applications should load the so-called libraries of the Design System. The libraries include CSS files that determine the styling. When correct HTML is used, a component, like a button, looks the same in the application as in the design system. If another application does the same, you have two identical buttons in two applications. This is already a great advantage, but the power of the Design System becomes apparent when the button needs to be modified.

Currently, within our organization, there's a modified government visual style. The button, still the best example, receives a subtle modification. The corners are rounded, where they used to be sharp. Every application and website that must adhere to the government visual style needs to round the corners of the button. This means digging into the CSS to find where the buttons are called and adding a rule (border-radius: 3px).

When applications or websites use our Design System ROOS, it's much simpler. The modification is made centrally in one of the CSS libraries and sent to the connected applications. They can then bring the new CSS file into a development environment to see if the modification doesn't break anything. This is not the case with rounding the corners of the buttons. After a quick check, the modifications can be implemented in the production environment, and voilà, the button has rounded corners. I'm talking about a relatively small modification to a single component. But the time saved when dealing with multiple modifications across multiple components is enormous.

Therefore, the goal is as follows: as many applications as possible should share as many components and patterns as possible. The more, the better.

Don't Cram Everything into Your Design System

It's important to note that this doesn't mean you should include every component you encounter in an application directly into your Design System. This would make your Design System unwieldy and, in the long term, unusable.

Currently, I'm working on an application where users can edit topographic maps. Many commonly used components are reusable, such as an editing screen with form fields or an overview screen with cards. However, a map that can be edited by users is unique to this application. Therefore, it is not included as a component in the Design System. The rule is that it must be used by at least one other application.

However, it's essential that components not included in the Design System are designed in the spirit of the Design System. Therefore, it's more important that designers are connected to the development team who know what the Design System is and can design in the style of the Design System to maintain a uniform user experience.

Finally

Designing, creating, managing, and promoting a Design System is a messy process. And that's challenging for someone like me, who, despite my creativity, always likes to stay within the lines. I have to accept that not all applications or channels can follow the Design System to the letter. It's about celebrating small victories where the Design System helps development teams create usable and visually appealing applications or websites.

What's your experience with Design Systems? And what does your implementation look like? I'm curious, so please share it with me by leaving a comment below.

The content of this field is kept private and will not be shown publicly.

Beperkte HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.