Design system: an object oriented design approach

A design system is not infamous anymore and every UX designer has known of it. It helps a design team understand the product more and how it is built up. In this article you learn more about why design systems also benefit developers and in what way you think the same as developers.

The importance of Design Systems

Interface design is complex and as the project grows, there is an increasing need for a certain standard that designers and developers can fall back on.

A design system ensures unity between designers and developers. Thanks to a design system, the process gets a boost and this will ultimately also benefit the user experience.

Because an inconsistent design regularly causes frustration and damages the user experience. The most important reasons for a design system are efficiency, consistency and the need to scale up.

This will ensure that your colleagues do not keep asking the same questions or a design. Or developers have lost too much time because an adjustment takes longer due to inconsistency in design choices from the past.

But where to start?

Start a design system with an atom

First of all, you need to submit a plan to your stakeholders (designers, managers and developers) to set up a design system.

After approval it is the intention that you make an analysis of the current components and elements that already exist. This gives a good idea of where you stand as a design team when it comes to consistency.

When you finally start setting up, you start with the atom.

The Atom is part of the Atomic Web Design created by Brad Frost. This system ensures that components and elements are broken down to the smallest denominator, for later use in future components.

Object Oriented Design (OOD)

Object Oriented Design comes from the technical Object Oriented Programming. The latter is a way of programming efficiently and consistently. Not only will this make the code smaller, it will also significantly reduce unnecessary code repetition.

As you can see in the wireframe below, the model is fairly simple. Based on this deconstruction we can easily classify the design. So each color would represent a part of the design that later on can be build as a separate object that can be used multiple times in an application.

You can see that a technical component has been created, this component consists of different parts of code. This division of the component can also be used in design systems.

In design systems it is not the lines of code and functions, but the composition of elements and components.

The risks

In addition to all the benefits that these systems bring, there are also risks that you should be aware of.

A design system can take up a lot of your team’s time, so think carefully in advance whether a design system is really necessary. For example, a start-up will have less need for a design system than a multinational. Because the teams are smaller and the time per employee should place more priority on tasks other than a design system.

There is also the risk that colleagues do not pay attention to the design system, so that it will be neglected over time. This is also in line with a clear process that must be set up to properly maintain the design system in the future.

Final thoughts

I hope you have learned more about design systems in this way and that, despite their popularity, it is not always wise to have a design system. Especially when a company is at an early stage or when the teams are very small.

Design systems will remain for a while. And who knows, the design system may be further developed into an agile way of designing components, whereby a process between designer and developer can be improved in small teams.