What is a Design System?

“The official way in which a company designs and develops its digital products. A set of rules, processes and tools that help us make intelligent and coherent decisions.”
That’s my favourite way to describe it

If you prefer to read in Spanish, I originally posted this article en español aquí for anyone who has ever heard of “Components” and “UI kits” but does not quite understand the difference between these and more familiar concepts like “Style Guides” and “Brand Manuals.”

The most important word in this definition is not “design”, which is why I will avoid using the full term, opting instead for simply system and DS.

Common analogies and approaches

In recent years, three fantastic analogies have become popular in illustrating the different characteristics of a DS:

1 — A DS is like Lego: a set of predefined, reusable and modular pieces in which all the blocks fit together perfectly.

2 — A DS is a body of documentation that acts as a recipe that tells us the ingredients and how to mix them together to achieve consistent results.

3 — A DS is similar to a group of Atoms, Molecules and Organisms, a closed system in which elements can be combined in a logical fashion and according to their level of complexity.

While these three analogies are great in that they reflect the key elements of a DS, they alone fall short in explaining the complexity of digital product development. Indeed, it is that very complexity which a Design System decodes.

Is developing digital products really so complex?

In principle, it shouldn’t be, but there are several aspects which must be taken into account in understanding what lies behind the design and programming of a user interface.

To simplify and generalise by way of example, this is a superficial description of one of Adevinta’s companies, Fotocasa.

1 — Fotocasa has several real estate market products:

• Applications for professionals
• Applications for individual clients
• Applications for house hunters
• etc.

2 — Each of these products is present in various channels:

• Websites for mobile and desktop devices
• Native iOS and Android apps
• Social media, Merchandising, TV, Advertising
• etc.

3 — Fotocasa is divided into large general areas:

• Customer Service
• Marketing
• Product
• etc.

And each of these areas is then sub-divided into separate teams.

In the Product Area, which is where designers and programmers work together, each team is independent and usually responsible for just one part of the user experience, whether that be a section of the website or a cross-functional feature shared by several applications.

As an illustration of this autonomy, imagine team responsibilities being divided as follows:

• Team X is in charge of making life easier for users searching for a home who wish to refine (filter) their results.
• Team Y takes care of the experience of setting up an account.
• Team Z deals with everything that happens in the “my account” area for users who have already registered.

This distribution of tasks between teams has to be well coordinated because it is essentially a single product and a user may download the app on their iPhone to create an account, before continuing their search on the computer. The experience should be such that the user feels they are connected to the same product.

In a multi-device reality which must ensure browsing is consistent and natural regardless of the number of hands involved in its creation, visual consistency is especially crucial. That’s why any talk of systems tends to focus on tools which facilitate consistent design and programming by reusing symbols (UI-Kits) and pieces of code (Components).

In this regard, we may ask: If we already have the ability to reuse design symbols and code in order to manage consistency, what is the need for a broader system?

Can’t the other problems be solved with good old-fashioned Style Guides and Brand Manuals?

Essentially, yes, and we could say there is little difference between a DS and what large-scale production industries have been doing for decades:

• Car factories systematically design, manufacture and deliver high-quality products in line with each market’s legislation, even allowing each customer to customise the accessories.
• The packaging industry has also cracked high-quality consistency. The moment we walk into a supermarket, we can instantly tell which products belong to the same line or brand, regardless of the contents of the packaging or illustrations.
• Newspapers write, design, print and deliver thousands of copies every day. The editorial design follows a set of rules and processes, a well-oiled system and a precursor to the style of our modern-day websites (headers, paragraphs, bold font, images, etc.)

These and hundreds of other products existed long before any website, and the same analogies mentioned at the beginning of this article are equally valid for all of them.

• Manufacturing cars is a fine example of parts combining like LEGO.
• Packaging design uses constant yet variable “recipes” to make sure all the designs of different tea boxes breathe the same way.
• The columns and other features of a newspaper may be compared to chemical elements which, brought together, provide the style and identity of a particular editorial line.

Hold on… Are we reinventing the wheel? Are Design Systems just a trend? Are we simply renaming an existing concept?

Absolutely not.

Design Systems did not exist when the internet began to move towards what it is today, and they’re certainly not a fleeting trend. They are the natural and necessary evolution of the way we design and program digital products.

In order to understand this belief, we should emphasise that neither reusable symbols (UI Kits and Components) which have long existed, nor Style Guides and Brand Manuals constitute a DS on their own.

How were design and programming carried out prior to their existence and how have we got to this point?

From a design perspective

Now in my 40s, I began designing “for the web” right after finishing my bachelor’s degree in Graphic Design, a course full of rules on composition and technical limitations. “The web” appeared to be precisely the opposite: a new world, without rules, where you could encourage any interaction almost free of charge.

About 20 years ago html was taking its first tentative steps, it was not so rich in possibilities. We graphic designers who were starting to delve into the internet threw ourselves head-first into tools like Macromedia Flash, which allowed us to make interactive animations. We believed (wrongly) that the web would evolve towards audiovisual design, as our bread and butter was more akin to animation, poster design and advertising than to industrial or editorial design.

And clients weren’t demanding anything else. Brands saw the internet as a place for branding, not products.

Although not everything was Flash and many argued “making websites with html” was a better idea, these were still the glory days for those of us who could make “websites” and “micro-sites” which we distributed auto-executable CDs, designed for full-screen.

We should also remember that when we started, there was no legislation on the risks of running anything on the web, no codes of conduct, no good practice advice. We designers weren’t entirely sure whether something would run on the client’s computer or the server (and we didn’t know what that meant, either). Hardly anyone had any inkling as to what we would experience just a few years down the line. Smartphones didn’t exist, the concept of accessibility didn’t mean anything in particular to anyone I knew, etc.

And without really realising, screens and devices had already begun to sneak up on us. This was all driven by a tremendous increase in internet speeds, which gave free rein to increasingly innovative designs and developments.

The truth is, we reacted too late: until recently, design and programming schools were still teaching “websites” in terms of unlimited creative freedom without any clear risks or significant impact. And not entirely unfairly… after all, digital is not set in stone. Unlike a car or a newspaper, we can correct faults at any time, even if we have already delivered the product.

Oh! There lies one of the key elements to the inevitable complexity of digital work. The final version of a product is the result of iterations and decisions which do not necessarily need to be consistent with what came before.

While scalability, consistency and best practices remained central to all branches of design, we believed the web would be something else, with all the pros and cons that brought with it.

The ephemeral nature of the platform, the explosion of tools and the potential of technology… we could have fixed our course earlier but soon more screens, smartphones and tablets, native applications arrived (iOS and Android simplifying everything), etc.

Suddenly the concept of “multi-device” appeared — a whole range of variations to “paint” and an obsession with controlling every conceivable interaction, every design, of each and every one in every possible resolution and orientation for all devices.

This came with the new concept of “context”: A user does not browse the same on their home computer as they might while sitting on the subway. “We have to design different experiences for each case”.

Hey, I’m not saying that designing for context is bad, but it’s a relatively new idea.

Design tools

Although we would quickly learn that designing “for the web” was a very different kettle of fish to designing visuals, our tools would take a while to catch up. Flash was fiercely discouraged for a number of reasons and many of us replaced our traditional graphic design tools (such as Illustrator and Photoshop) with Fireworks. Even so, it was another few years before the launch of Sketch, arguably the first mass-use tool created specifically for interface design (UI Design).

And then all hell broke loose with an explosion of design, animation and prototype tools: A new one every year, a new one every month, every week, each one better than the last… I’m currently engaged in a rational and emotional debate between Sketch and Figma.

Writing about the evolution of tools would require a whole other article but the message I really want to get across is that the tools we used to design websites, banners and apps in the beginning were those designed for design without rules: retouching photos, logos, animation and advertising signage. We didn’t initially choose those that came with in-built style guides, editorial design tools like QuarkXpress and PageMaker.

Before getting into the code side of things, I’ll provide a quick definition of two concepts in case you’re not familiar with them (extremely simplified, sorry programmers): Backend is what happens in the code before delivering content to your computer for you to see, and the front-end is the part of the code you see and interact with.

So, let’s get to it.

The code side of things:

On the one hand, we should remember that websites were quite free in their composition back in the day. Whether or not it was technically incorrect, the truth is that each page could be “painted” separately without too much remorse and despite the initial existence of style sheets, one page could be completely different from the next on the same website without too much drama.

On the other hand, users didn’t expect websites to be dynamic, to follow any kind of logic. Our expectations didn’t imagine they would be smart, showing us different content depending on our interactions, our profile or position in the page flow. Nowadays, we’re completely used to seeing steps, interconnected screens and non-linear interaction, but when we started designing for the web we did it by “painting” each page in isolation. It sought to be coherent but independent from the rest, as if it were a magazine or a physical newspaper.

When it came to “dynamic” websites, the back end took on the bulk of the workload. Almost none of logic happened on your computer. Rather, every interaction produced a call to the server, which processed everything and returned another page. Each page was simply an html (template, if you don’t know code) that the front end could colour and animate. Clearly, very little of the design work was effected by what was happening in the back end, despite the fact much of what was happening in the design would impact the back end.

Things are very different now: The power of the frontend has grown at a phenomenal rate, with parallel advances in libraries and frameworks meaning it is now possible to do truly incredible things without having to send data to the server to be processed in the back end and returned. This means that both design and frontend have more freedom, as users’ interaction with the page is not limited to what they see. Rather, all the data we can “play” with is now at our disposal (filters, dynamic content, notifications, etc.) and the same piece of design and code can not only be reused but can also be modified in real time.

Another thing to keep in mind is that “traffic” (people visiting a site or an app) costs money; data that used to be stored on physical servers is now in “the cloud” and “the cloud” is a provider like Amazon or Google Cloud which charges to store and distribute this data.

This means we have to split apps up into small modules so a user only ever downloads what they need and we pay for low levels of traffic. And each of these modules should be viewed and interacted with in consistent fashion.

I’m aware I’m simplifying things and writing some atrocities, but I do so for informative purposes ;)

This bandwagon has also seen the proliferation of services that allow websites and apps to be enriched without a team having to program them. Things like payment gateways or chat services that integrates with our code but is not part of it.

Using these Lego pieces from different manufacturers requires us to pay attention to properties that are not always compatible with our design or programming rules.

This has a direct and not always positive impact on product uniformity as a single user will jump from one supplier to another in the same session.

In addition, the technically correct code for web is extremely open, flexible and permissive: The same result can be achieved in a thousand different ways: a blue box can be programmed with or without components, writing styles in the html itself or in any file extension type (.CSS, .JS, SCSS, etc.), with or without the need to use pre-processors, with or without javascript, etc. Almost anything can be “translated” for an explorer like Chrome to understand.

Oh, and we also started doing experiments to improve our applications: Today, we can compare variations of the same design in parallel by showing some users one version and others another. We can then measure the results and keep the best one (known as AB testing). This is a very powerful technique but, to follow our analogies, the fact it is such a free recipe leads to inconsistencies and spaghetti code.

As if that level of complexity and elements to bear in mind weren’t enough, the structure of our sites must also please Google to ensure we appear among its most relevant search results: The code should not be heavy, the HTML should be semantically correct, content must be high quality and the page must meet certain security parameters, include or exclude certain content, etc.

How has this increased complexity impacted the way we work?

On the bright side, it triggered the creation of new Design profiles (which we have also incorporated as part of our responsibilities -User research, data analysis, etc.) and led programmers to specialise as a result of the division of the Front-End code into pieces that have to be combined, made compatible, packaged and distributed.

And all this without even having touched on the world of Native Apps! My goodness.

On the slightly more negative side, things are no longer simple. On the one hand, it’s becoming increasingly easier to “put things” in an application, but on the other we’ve lost the ability to control everything. We’ve been forced to pay close attentions to things that, until recently, had very little relevance, such as accessibility, performance, privacy, traffic management, etc.

There are a lot of things (like Research) that I’m intentionally leaving out so as not to bore you with an article that’s getting longer by the minute.

How does the landscape look right now?

Pretty messy, but really exciting, as you can imagine.

Virtually every company now has what’s known as “Technical Debt” and “Design Debt”. Millions of web pages around the world have aged badly. We’ve long been stacking up tests and technology and over time, more than the odd design decision has been exposed as a victim of trends, with several coding languages linked up in a spaghetti that is often best left untangled.

Screens and touchpoints continue to appear and we’ve been forced to take a step back and reflect on the infeasibility of continuing to design each micro-interaction in granular fashion without putting everything at risk.

While adjusting each design “to the pixel” was well thought of until relatively recently, nowadays it’s very rare to hear things like, “raise it 2px so it looks better” in a design review session.

Looking on the bright side

A lot of water has gone under the bridge and we’re now well aware of the complexity of the digital ecosystem and its natural tendency to disruption and inconsistency.

Today, we have a system that helps us connect and orchestrate the different parts, and make design and programming decisions in a simple way. It gives us the ability to evolve our apps sustainably, incorporating inevitable advances in technology in controlled fashion.

What parts of this “System” link everything together?

A good Design System is made up of tools that allow agreements to be reached in a dynamic manner and ensure teams are aligned even if they’re not in the same room, in order to produce consistent, quality products in fast and efficient fashion.

It includes not only reusable symbols (UI Kits, Components, Tokens, etc.), but also a shared language and tools, guides and standardised processes.

But a Design System is far more than its isolated parts; I’ve heard many times, “a Design System does not exist unless the components are stitched together”, or quite the opposite, “the key lies in the UI-Kits!”.

I like to stress that every part of the system must be relevant to the person using it: Reusable symbols are great, but they’re useless if they’re in a technology you don’t use.

A designer does not use code-programmed components to build a design, they use symbols which are easy to drag into their design tool (a UI Kit).

Likewise, a programmer will rarely use a gallery of symbols that are within that design tool (UI Kit) if the components are already available and documented in a code library he or she works with on a regular basis.

The truth is, you can have all the parts and still not have a system and you can have a system that works perfectly well without design libraries or components.

You can still have positive development pace and dynamism without a unified technology platform. It’s perfectly feasible to make everything look and behave uniformly even if you have only migrated half the code to a new technology (React or Vue to give two examples).

On the Design side, you might be wasting your time if you put effort into exporting all your colours and fonts in code format to speed up development for your programmers, when it is not set up for the styles to be consumed that way.

In teams that communicate and understand each other well, many decisions are made without a computer at hand. Providing “L size” spacing means the same for everyone (1em, 16px, etc) all you need is a blackboard.

A good Design System helps you make decisions and to know what to do at any given time, not only when you want to follow the consensus but also when you have to deviate from what has been agreed. That’s why the key lies in easy access to documentation.

A good Design System is a living being. Not only does it evolve over time, adjusting to trends and taking advantage of new technological potential, but it also allows us to correct wrong decisions after they have been implemented.

Cheers!

Turo
DesignOps at Adevinta Spain

About our team:

At Adevinta Spain we have Design Systems for all our brands which include style guides, collaboration manuals, Tokens, Components and UI Kits for both Web and Native Apps.

Check out SUI Components our React Open-Source project which we use to create all our websites.