Did somebody say tokens?

The great thing about tokens is that they aren’t tool dependent. Token is simply a name convention between developers, designers, and any third party. We can agree that a color with a specific HEX code will be named $sd.sys.hello-world.sky10, or anything else. The important thing is that all parties know the rules for formatting and what values are behind those names.

Seems pretty easy, but token is also a part of the system, this means it’s dependable from other tokens and its application.

Have in mind that usually there are two types of tokens, system, and reference tokens. For the project I worked on, I defined system tokens as base, and reference tokens as the ones that show where the system tokens are used. Of course, this can be the other way around, and system can be renamed to base, etc. I also used Token studio as a mediator plugin between design and development. Variables in Figma work on a similar level, but they are tool based, so if in need of an independent tokenization, write your own token system.

Implementation works both ways. Designers and developers should work together on implementing tokens. Token documentation is valuable for scalability and if there’s time to include them, they would be profitable in the long run. This way the whole product has one unique language that works for both teams, and is utilized across all design products so there is no confusion regarding the updates, or any kind of additional changes.

Like I previously mentioned, name convention is the base for tokens, having this in mind I didn’t want any confusion regarding how tokens were conceptualized. I created a schema with an explanation for the system, and reference tokens. My idea was to create a rule of conduct, so that anyone with access to the file understands and is able to create a new token.

File structure - looking from the outside

Below is the most complex file structure I had to envision, also the biggest project I worked on from scratch. It was my first project which required tokens, the first design system of this scale, and the first library. Working on a white label project like this required innovative ways of conducting and maintaining files. I had three levels of files. The first level was library level. We had desktop and mobile app, and my intuition and experience told me we should have separate libraries for these platforms. Each library included color styles, font styles, effect and grid styles, and finally components. Second level was reserved for separate files for app, platform, legacy (this was my backup documentation, anything erased went to that file), concept/new features file, client’s file (every client with a contract for the project had its own separate file, major changes were done via branch so the main file isn’t affected), and unsigned clients file (these screens aren’t meant for development, and this design is for selling and presentational purposes). Third level of files were file branches. I won’t go into deeper explanation of the structure inside the files, but general pages were: cover, table of contents, get started (direction for anyone new in the files, or on the project), separate pages for versions (1-0-0-version …), excluded screens, etc.

White label products

This is where things get interesting. In my experience, white label means customization. This flexibility requires strong file and component structure. A digital product conceived so it can be branded and adapted to different companies (clients), means different levels of editability for those clients, as well as different features, services, and development of additional features. Having this in mind, it was necessary to have clients’ files separated from each other and from the source of truth file and libraries. This implies that the base design always stays intact, and safe if the client requires edit permissions.

We didn’t want to allow full customization of components. This decision was based on a long experience of working with different types of clients. The options should be well structured, and abundant, but with some restrictions. Style combination, and in general design elements such as icons, fonts, color schemes, those combinations should be provided by us, because we wouldn’t want the final product to be inconsistent, or the components to be mismatched. After all, this is a digital product with value in everyday usability, not a work of art. Having said that, it was obvious we need to add another level in the structure of component organization. We introduced presets.

Preset is a group of components that are used to build one user interface. The preset contains buttons, icons, cards, card art, and all sorts of elements that are initially inside the app core, but now they can be changed, design-vise. Among other things, the platform worked as a builder for the app, so, as a client designing the app with our components, color schemes, and fonts, you could really adapt the user interface to your needs and branding.

What about design system documentation?

Of course it’s boring, but someone has to do it. The first thing is creation of components, creating variables, and the rest of the elements that are needed so the design system is up and running. As soon as we grab some additional time, we create rules of conduct. These guidelines show alignment of the elements inside the component, spacing and sizing, corner radius, text container height, etc. Documentation also provides expected behaviour of particular components, their dynamic height or width, fixed content, and overall simplified structure.

In addition to component, color, sizing and spacing documentation, we want to be clear about the steps in the process. This is usually shown through the additional segment attached to each artboard (artboards can be based on the type of component, role, position inside the product etc.). Depending on the project, this segment showcases what needs to be done, and the current status of the artboard in question. In this fashion, tasks and statuses can be edited, added or removed.

Maintaining and scaling a design system

Design systems can grow rapidly, but they should also be timely updated. Usually one separate team is responsible for scaling a design system. It’s an intricate job, and has to be done with always having the big picture in mind. Like previously mentioned, design systems are tool based, which isn’t necessarily bad, they work across all features of the tool in question. I can make changes instantly inside the Figma Slides, if I choose to structure assets for the slides in a Figma library. Imagine creating a pitch, but without a final logo of the company, and after 50 slides, it needs to be updated. This, also, can be done via library file.

Design systems are never ‘done’, but rather than that they constantly grow and adapt. As Leonardo da Vinci stated: “Art is never finished, only abandoned”, this is also applicable to the life cycle of a design system. Those files are live and spread across a multitude of files and screens. Needless to say, options are endless, and a system forward thinking shows signs of ever ending expansion.
(A design system not in use is a really sad thing 🥲)