Is there such a thing as a small design system?

This is the second part of the design system series. In this piece, Ana Masnikosa, Product Designer at Studio Direction, explains how a design system scales based on the project in question, what this means in terms of details and do we know when to stop?

Let me start with that last one: No, we usually don’t know when to stop. Thankfully, this is why there are deadlines and time constraints. Digital products such as landing pages, presentational websites, portfolios, and similar, also have their design systems, even though they are not as detailed as design systems for large products such as e-commerce, platforms, dashboards, fintech applications etc.

Timing is crucial. After nailing the art direction and look&feel, we usually create 1-3 pages that best represent future website design. While working on this all sorts of components are made, and they are usually made for one sole purpose, and that’s to represent the design to the client in the best possible way. The component for the article card is created to show how hover functions in prototype, or header component, in order to show transition between closed and open dropdown links.

If we take a look at this through atomic approach. It is safe to say that at the beginning of any website design we usually never create atoms, rather molecules or patterns as components. Later, when design is approved, we go back and add smaller components, define color, and typescale. The modus operandi is a bit reversed in relation to product design. Design system is started later in the process, and sometimes it is not necessary to be fully completed. Changes happen fast and often it occurs the project is already developed before finalizing the design system.

Scaling a design system

If I would reopen some of the files from the previous web projects, it would not be unusual that some of those files don’t have all of the components, even variables or typescale. Going back to the design system after designing all of the pages is never fun, but it is sometimes essential and sometimes it doesn’t happen at all. In this process we create some of the rules by which certain components behave, this way the development team is aligned with the designers’ conception.

We are a small team, so everyone on the project is aware of the file architecture. This can be pretty dynamic if the project stretches to several months, we all know that some of the clients can be somewhat indecisive. This also means that everyone should know where to find components and where they are applied in the UI.

Regarding typescale it is perfectly normal to have a document with definitive size and style of the typography, and not having it inside the Figma’s variables. Unless stated or desired otherwise, it is simply a waste of time to go back and apply variables to all UI, at that point design is usually already finished and development is half way, and because we are a small team, knowledge is shared organically, so unless the client requires a complete design system, we create it for our needs and in our scale, and move on to another project.

One component doesn’t make a design system, does it?

Well, it already has all the characteristics of a design system, so why not. If created with great attention, one pattern component can incorporate variables, typescale, auto-layout, sizing, spacing, image placeholders, different resolutions etc.

Of course, you are missing transitions and interactions, but with one sole component a rule(s) is established, which is then applied to other parts of the bigger system, and therefore it is a system by itself. It should be obvious and self-explanatory, it should reflect brand values, and provide hierarchy between elements (atoms&molecules), in addition to a well structured information architecture.  

Declaration of love to auto-layout

Bojan and I are huge fans of auto-layout. We always say that auto-layout works for us, not the other way around. We just love it. The amount of workflow shortcuts auto-layout provides in the future, are always rewarding and also surprising because you are always thrilled how it shortens some work, or you can do it in less clicks. So, of course, it is an inevitable part of a design system. I remember when Figma first launched it, I was so frustrated, and nothing worked, it was impossible to recreate some of the relations between elements. The logic was so confusing at first, and it looked as if it takes more time to do it the right way, then it provides benefits.

Fast forward, it is our, safe to say, favourite Figma feature. When you get the hang of it, it really works for you. Of course, it also depends on the project, Bojan and I are product designers, so it is really irreplaceable. On the other hand, our designated web designer Djurdja, well, hates it. And I get it, I really do, but it is so beautiful, with all the constraints, applied sizing and spacing variables, rules of conduct, and scalability.

Kristina usually populates the UI with some placeholder or real content, so the ongoing joke is: if she doesn’t break the UI by adding longer, or shorter sentences, words, numbers, then auto-layout is bulletproof. Not to sound too nerdy, but that is a really fun challenge.

In my humble opinion, a system is as small, or as large as the amount of information it contains, in addition to that, its grandeur is directly proportional to well usage of that information. So, use it wisely, use it timely, and don’t be afraid of auto-layout. 😉

‍