What I learned about Design Systems working as a Jr. Designer
Design systems have become a buzzword in many UX job postings lately. While the concept has roots in various fields like architecture and graphic design, understanding it within the context of today’s digital transformation is crucial.
What exactly is a design system?
When I started my UX journey, I thought design systems were equivalent to creating a color palette and setting definitive text styles. My experience working with a structured design team at Allied Solutions taught me that design systems encompass much more. According to me,
Design Systems can be seen as a system with repeatable solutions to commonly recurring problems, bridging the gap between design and development, and helping organizations create scalable environments.
Design systems are primarily focused on formalizing the idea of consistency helping us build products quickly and efficiently. Things happen over and over in any organization. Great products are not built in one shot. This iterative nature of the building process demands a system to make the product scalable.
Who uses a design system?
Design systems are used by people in various job roles for various reasons. While senior and/or lead designers in the team organize the design systems and create new components, even junior designers get to work on creating new components. Once the system is established, designers of all levels use these components to create high-fidelity prototypes.
After the components are created, they are marked ready for development. A UX Engineer or a front-end developer (based on the team structure in your organization) picks each design component to convert them to code components. These components on the dev side are reusable pieces of code that help front-end developers build websites faster.
What does a design system comprise?
UX teams usually create the design system with the following constituents for it to work efficiently. I always thought that the design systems are made of design components like buttons, input fields, etc., but they comprise other things too. The building blocks of a design system are — design tokens, variables, component library and iconography, and documentation. Let’s discuss each of them in detail.
1. Design Tokens
Initially introduced and created by the Salesforce design team, design tokens are “indivisible pieces of a design system such as colors, spacing, typography scale” (definition by Design Tokens Technical Report). It is a name-value pair created in a platform-agnostic way to set a standard for design decisions across the organization. They act like a single source of truth for designers and engineers, helping engineers to build code quickly and consistently.
The following is an example of a simple design token in a JSON format (simply, a way to represent data in a name-value pair). Formats like JSON and XML are platform-agnostic because they are compatible with any programming/ markup languages developers use.
"brand_colors":{
"blue":{
"value":"#004E82",
"type":"color"
},
"red": {
"value": "#ED2939",
"type": "color"
},
}Separate JSON files are generated for such pairs, each representing colors, text, spacing, radius (colors.json, text-styles.json, spacing.json radius.json), etc. Our organization uses the Tokens Studio plugin on Figma to generate these tokens. It is a non-code way of creating these JSON files. These tokens can then be exported into Figma as variables, from the Tokens Studio plugin.
2. Variables
When Figma launched variables in 2023, they mentioned that the feature is a more holistic approach to representing design tokens. Variables, as Figma defined it during the Config 2023 are “a common foundation for designers to build design tokens (and so much more)”. Meaning, that variables are not the same as tokens but they are representations of tokens in Figma. In our context of design systems, variables store reusable values that can be applied to various properties, instead of entering the values manually.
Example of Design Tokens and Variables ↓
Tokens and Variables — an example
I know, too much technical jargon right? Let’s take a pause and understand how design tokens and variables are used in real-world projects.
Design tokens are usually maintained in the structure shown in the image below. Even our organization follows a similar hierarchy of having three types of tokens: Primitive, Semantic, and Component.
Here is some explanation to help you understand what each of these tokens means. Primitive tokens are the most basic tokens that you can define. For example, defining a red color — red900 with value #BC061B.
Now, this primitive token, i.e., the same color red900 can be used as a background color for an error state, as a stroke color for an error state, or as a text color in an error state (background/error, border/error or text/error). So we define these tokens as Semantic tokens.
Finally, Component tokens define how these semantic tokens apply to components. For example, you have two components — inputs and badges. Assume that the error state for both these components will have a red-colored border. So, we define two tokens inputs/error/border and badges/error/border, and map both of these component tokens to the border/error semantic token.
Once these tokens are created, they are exported as variables with the same naming convention. The variables are accessible across the design system library file and also any other design file that uses the library file.
So, when an engineer works on a new component or creates apps, they refer to the properties using the JSON key-value pair. And, when a designer creates new components and screens, they refer to the properties using variables.
3. Components and Iconography
Components are created using basic shapes and text. Components can be input fields, buttons, dropdowns, etc. These components will have multiple states like default, hover, active, disabled, etc., as relevant, and also variants like different sizes (sm, md, lg, xl). While building these components, we use variables to keep the colors, text styles, spacing, border, etc consistent across the entire design system. Iconography is pretty straightforward: including the vectors of various icons with multiple variants like sm, md, lg, and xl in the design system.
4. Documentation
While creating design systems, documentation is equally important. Our team has documentation written in Figma for each component, outlining their anatomy, usage, design decisions, best practices, and any accessibility considerations. This greatly helps new designers in creating high-fidelity designs. Engineers will have detailed information about components and code snippets on Storybook, as a one-stop destination for front-end engineers to refer components while coding for new screens.
Design system best practices
At Allied Solutions, I got to work on various components like input dropdowns, menu dropdowns, lists, and tooltips. I also got to create high-fidelity designs for multiple projects using the design system components. By working with design systems for around 6 months along with our design team, here are the few practices that will help the design system to scale better without it being chaotic as it grows.
- Always keep developers in the loop while designing new components to keep the designs grounded.
- Do not try to reinvent the wheel. Get inspiration from the existing design systems, their naming structure, and design decisions. Remember, “users prefer your site to work the same way as all the other sites they already know”.
- Never forget to document your design system. Make it as granular as possible as it serves as a document of truth for both designers and developers.
- Design components on a need basis. Thinking about the future is fine but if you are not sure if a component is used now but you feel “might” be necessary later can probably be designed later. You do not want your design system to be bloated with unnecessary components.
In conclusion, design systems is a much more nuanced concept than I had imagined as a beginner, and my work experience helped me understand the nitty-gritty of it and made me feel confident about working with design systems. Excited about what the design community has to bring to design systems in the future and how it can help designers and engineers more.
Thanks for reading! Want to discuss more about design systems? Hmu on LinkedIn. Also, do check out my portfolio here.
