Creating Tenet UI (design system) for Cohesive, Consistent and Scalable Design - a case study
One System, Endless Possibilities
The Problem
I always read about design systems solving design challenges from the standpoint of a specific product. However, working at an agency, I had to see design systems from a slightly different angle. Here are some problems that agencies and freelance designers might face.
Designers may overlook the need for a design system - Multiple clients and tight deadlines might be a reason for designers (freelancers and in agencies) to overlook the need for a design system - arguments being, it takes time to build one, makes design process slower and limits creativity.
Inconsistent products - Multiple designers may work on a common module or feature, but work in isolation often coming up with different outcomes leading to inconsistencies. This could be in terms of foundations (colour and spacing) and component anatomy.
Inefficient workflows, slowing overall turn around time - Designers often end up having an increased turn around time simply because of a lack of a system.
Building the same components multiple times - No design system equals no reusable components.
Trying to create a design system for every project - This could be an inefficient approach, provided design tokens and components can be reused across projects (exceptions, of course, being the need for custom components for each project).
With an intention to solve these challenges, together with my curiosity to deep dive and learn more, I decided to build a design system.
The Challenge
Creating design tokens for consistency - Creating consistent design tokens (colour [case study], numbers, typography) that can scale.
Designing reusable, Code-Aligned Components - Flexible and composable components (case study in designing components).
Creating a robust documentation (in progress).
Research
I lavishly used “component.gallery” for my research. Created by Brad Frost, it's a collection of interface components from real-world design systems.
Existing design systems help me understand a myriad of things some of them being
How companies approach setting up tokens
Possible variants and variations of a component, which in turn, could help me figure out how the component API (the way each component can be controlled and configured) or component props can be designed.
How components could be structured (anatomy).
How design systems are documented.
Setting up “Foundations” with design tokens that scale
Creating tokens (variables in Figma) for numbers and typography were pretty straight forward. Colours were a challenge though.
I divided colour tokens into Primitive and Semantic tokens. The Primitive token holds the raw hex value of the colour, while the value of the Primitive is mapped to a Semantic token. I talk about this in detail here.
For naming Semantic colour tokens, I made use of a common structure. Its efficient practice to break down the structure of a token into many different parts. This helps maintain consistency in naming and helps scale the system.
I wanted a set of colour variables upfront that I could commonly end up using. Along with the token structure, I made use of a system and plotted matrices in order to come up with scalable and consistent tokens. I talk about this in detail in this case study - Plotting matrices to create consistent and scalable colour tokens.
I also ensured all tokens had primitives referencing the semantic names. This way, every project or product using the design system, could have the same tokens but could reference different primitives according to what the project demanded.
This could ensure consistency, lesser cognitive load for designers and rapidly build different themes for different projects.
Building components
The challenge,
”How can I design flexible and composable components that let me make changes in layout and content without creating unnecessary complexity, while also being fairly easy to consume?”
Pondering on this problem, I could further break this down to know what I want to achieve.
I have to strike the right balance between flexible and constrained components, ensuring that the components remain intuitive and usable by consumers while still being adaptable to multiple use cases.
Designing a well-thought-out, code-aligned component API (props) is essential to overcoming this challenge, which is a challenge in itself. I need to carefully determine which properties are necessary and configure them in a way that allows for easy consumption.
I talk about how I went about approaching component design in this case study - “Building for efficiency and usability: A Case Study on Component Design”.
Researching components
Creating constrained components
An example - Creating distinctive variants of buttons as separate component sets, rather than 1 huge component set.
Creating flexible components with slots and sub-components
An example - Card component with slot component.
Setting preferred values to map to all the subcomponents.
Designing component API/properties that are easy to consume
For me, building components was about solving problems, especially problems of efficiency and usability. The challenge of building a component apart, the art of making it usable for other designers who aren’t involved in their creation, was an interesting problem to solve.
Documentation
Documentation is an interesting challenge. It should pack in as much information as possible, while being easy to consume and understand. With a robust documentation in place new members (designers) can easily understand the project’s design system, reducing ramp-up time and allowing them to start contributing sooner.
With plugins like “EightShapes Specs” and DesignDoc [Spectral] annotating components and documenting states and variations have become a tad easier.
Documentation for Tenet UI is in progress and is something I am still learning much about.
Closing thoughts
Tenet UI is still evolving, and that’s intentional. It’s not just a design system; it’s a seed for something bigger, a toolkit that could become the backbone of any project that values speed, consistency, and alignment. I’m excited to see where it goes next—and to keep learning as I build.