The elements of design systems for teeny-tiny teams
Without a team of folks to support your system, it’s important to understand the tools available to build a beautiful, functional, and scalable design system.
In this series
- Does your teeny-tiny team need a design system?
- The elements of design systems for teeny-tiny teams (You are here)
- Building your teeny-tiny team’s design system
- Implementing your teeny-tiny team’s design system
Raid the reference section
The best system-building tool is knowledge. A good design system takes a lot into consideration, so understanding where to find that information and refer back to it continuously is extremely important.
Understanding the materials
For any product, digital or physical, it’s vital to understand the medium your craftspeople are working with. If you’re designing a system for a digital product, ask the development team what frameworks they’re using, what component library they’re using, and what they view as easy vs. difficult in those frameworks. Look up the documentation yourself and read about what those frameworks and libraries readily allow in terms of customization. You’ll need a business case for the effort involved, so understanding the effort is extremely important.
For physical mediums, it’s also really important to know how materials behave, how they can be modified, their literal strengths and weaknesses, and the flexibility of choice of material. For many designers, the physical medium is paper, but it could be molded vinyl, powder-coated sheet metal, or ceramic. Knowing the properties of the materials is a requirement to a good design system.
Brand book
Small teams may find themselves overlooking core functions of the business just trying to survive the day-to-day. When building a design system, however, it’s vital to understand how the company is presenting itself to the world through branding and marketing.
While it’s not advisable to design products the way visual branding and marketing is designed, the brand book can provide inspiration on how to break away from the doldrums of tech stacks and standardized design functions. It can be the frosting on the cake and provide a sense of brand cohesion. The product you’re designing is often the core way that customers understand the brand, so injecting the brand into their experience can be a vital way to differentiate.
If your company has not had branding defined, or if the branding is poorly designed or not thoroughly implemented, it may be better to encourage the marketing team to consider bolstering the brand with the intent to carry it into the product’s design system.
If you’re working on a project with many brands which need a unified touchpoint, brand books for each brand may give you insight into common visual patterns that you can use to work into your design system. It can also give you a clear understanding of the flexibility the design system will require, if common elements need to look different for each sub-brand.
OK, OK, so what can we actually do with that knowledge?
When you get enough research in hand, you can decide which of the following elements (or even partial elements) are right for your business-case.
Design component library
As the name suggests, a design component library primarily aids the design team in creating repeatable design components and patterns. The breadth of what you can build into this library depends on the software your team uses, and how much your design team communicates.
The most basic libraries simply echo the brand book with fonts, colors, and logos, but more advanced versions can build beyond buttons and aim for entire templates with swappable slots, links to documentation, animations, loading conventions, and more.
This is where mental frameworks like “Atomic design” can be implemented and practiced. These frameworks break complex designs into small, digestible ideas that encourage building from micro-interactions up. This thinking has good UX implications, but also dovetails with how design systems work, and make a natural pair.
I’ve personally seen many companies build a design component library and stop there, calling it their “design system.” In some points of view, perhaps it is, but it alone doesn’t achieve everything. One primary weakness is communicating the design concepts to stakeholders and developers. Because it’s abstract to all but designers, building a business case for spending a lot of time on this alone might be a challenge, and the return on the effort might be difficult to measure.
UI-kit
The UI-kit is what your developers will use to translate designs into product. These are standardized components and variables which are intended to increase velocity when building UI.
UI-kit libraries are extremely common. Because they can be so useful, your development teams are likely currently using one, which they then modify to match the designs (to whatever degree possible). In the first stage of this article, I mentioned understanding the tech stack. A UI-kit is part of that stack, and understanding what components are already in use may help speed the adoption of whatever design standardization you roll out to your teams.
Once you understand the components being used, you can work with developers to style these directly, rather than reinventing the wheel for these types of micro-interactions.
UI-kits can also house completely custom templates and interactions. Working with developers to build these can ensure that your designs meet their expectations, speed their velocity, and save time for executing the really important and/or novel experiences.
Tokens
Design tokens have been an extremely popular topic in product design because of how much control over the UI they can give designers when implemented well. Tokens are essentially design variables: colors, fonts, Boolean states, border widths, badge content, etc. Any small, reproducible, element can be a token.
These tokens can then be referenced by other tokens, creating a true system of a set of base values, what role they play in your organization, and how specific components utilize them in the UI.
Additionally, with some effort, these tokens can be pulled from the Design component library and injected into the UI-kit — instantly updating styles and code-based components.
What’s next?
Have a good idea of the tools available to you? Then next time, we’ll talk about building that design system for your teeny-tiny team.
