I have been the Frontend Engineer at CloudPlexo for a while now, and over that time, my team and I have built a number of products, internal toolings, websites, and everything in between.
Although these products have largely been built by the same people, something has been amiss, and it has been bugging me for a while.
What Has Been Amiss?
If I showed you all these products without telling you who built them, you probably wouldn't be able to tell that they came from the same team. They have different tones, different aesthetics, and different styles. I'm not suggesting that every product should look the same, that wouldn't be ideal either. Different products solve different problems, serve different users, and should be allowed to have their own personalities. What I want instead is a sense of family resemblance. I want a stranger to look at these products and get the feeling that the same team might have pulled them off. There should be something familiar in the typography, spacing, interactions, language, and overall design philosophy. The products shouldn't need to look identical, but they should feel like they belong to the same family.
Even our website hasn't escaped this problem. Different pages sometimes feel like they were designed with completely different visions, design flows, and principles. A major reason for these inconsistencies is that many of these surfaces evolved around immediate marketing or product needs rather than from a shared design foundation...and understandably so. Initially, it was only a couple of landing pages -> then products were added to those landing pages -> then more products -> then more services -> which begets even more pages -> then internal tools.
Eventually, what started as a handful of web pages became several products, internal toolings, and an increasingly large company website. The system grew faster than the design language governing it.
We shipped quickly, the company grew, products accumulated, visual decisions became decentralized, and now the absence of a shared design language is creating visible fragmentation or design depth.
In hindsight, I should have pushed earlier for a shared design foundation. At the same time, the need wasn't nearly as obvious when we were maintaining only a handful of landing pages. What we have now is essentially design debt and I've been meaning to address it before the team grows beyond us, esp the web/product design side of the engineering team(which currently consists of four people, including the tech lead).
With the company currently undergoing a rebranding phase, this feels like the perfect time to finally do it properly:
- Build the foundation.
- Define the principles.
- Establish the rules.
- Create a core design system that future engineers, designers, marketers, and product teams can rely on.
And yes, that also means revisiting existing products and gradually redesigning them to adhere/align with those foundations. This is going to be a lot of work, but thankfully, AI exists, so I'll probably be burning an unreasonable number of tokens along the way to hasten the research, experimentation, documentation, and coding.
I haven't built a full design system at this scale before. I have, however, written about design systems many years ago, and that article pushed me into studying and researching design systems from organizations such as Apple, the U.S. Government, Shopify, Atlassian, NASA, Salesforce, and a plethora of others. Nevertheless, studying design systems and building one for an actual organization are two very different things and that's precisely what makes this interesting.
What's Next?
Given that I want to build & design a standard, well-orchestrated system for CloudPlexo Tegis Group, I'll once again be studying companies and design systems I've come to admire but this time, I'll be doing it while building one myself. I'll also be documenting the journey, not just what I build, but why;.
- Why did we choose this typeface?
- Why this spacing system?
- Why should our products move this way?
- What belongs in the core system, and what should remain product-specific?
- How much freedom should individual products have before they stop feeling like Tegis products?
- How should design tokens work?
- How do we make accessibility part of the system rather than something we remember afterwards?
- How should the system evolve without becoming a bottleneck for the people using it?
I'll document the research I'm doing, the decisions I'm making, the alternatives I'm rejecting, and the reasoning behind those decisions. I'll also include the team's opinions, disagreements, contributions, and decisions where necessary. Credit where it's due is both the foundation and the pinnacle of collaboration and teamwork.
I don't want this to become a diary of:
Day 12: Built a Button component.
I'm much more interested in documenting the decisions behind the button.
- Why does it have that height?
- Why that radius?
- Why that hover state?
- Why that motion?
- Why does it behave differently in a dashboard compared to a marketing website?
And most importantly: What makes it feel like Tegis?
That's the question I ultimately want this design system to answer. By the end of this project, a Tegis product shouldn't necessarily need a Tegis logo plastered across every screen for someone familiar with the company to suspect where it came from. There should be a recognizable design language underneath it, a shared foundation, a shared philosophy, a shared lineage, and so forth.
Enthusiastically, I'm hoping to complete the system design and make significant progress on the existing product redesigns before the end of the year and yes, this is officially my personal Ember Months core project.
Here's to learning and building!