The origin of our Design System: COGS
Charlotte and Tom paper prototyping changes to COGS components
We didn’t always have a design system that focused on accessibility and consistency across our UI. We’re glad we do now!
Our PartsTrader USA platform was created ~10 years ago. UI modernisation had been attempted in the past, but company-wide adoption had been difficult.
What better way to do a UI refresh than get a group of interns to do it!
What could possibly go wrong? Don’t worry, we’ll get to that…
COGS: The Beginning
It started with three rogue interns who dug up a small existing repo that was left over from a previous attempt at building a component library. This attempt was called the Cool Old Guy System, or COGS. It wasn’t even using NPM or Storybook and was hosted on some forgotten-about PartsTrader CDN. Us developers (then interns) had barely touched React before but thankfully were joined by a senior React SME, Malin.
He saw the state of our code and decided it was best to add some rules to our code base in the form of static code analysis. After two short weeks of Intern Code, our SME thought he’d simply add linting. 2000+ errors fixed later, and we had ESLint and Prettier in our repo.
The next task was to replace the components that were using Telerik - we still had an old version of the UI component tool in our application and found it difficult to now work with. We managed to create some basic components - a Button and a Link. After going through our platform we discovered we had some components that looked like a link or a button but acted like the other. Thus, we introduced the LinkButton and ButtonLink components. I’m sure you can see the problems starting; we, however, were none the wiser.
What went wrong
For every problem we removed, we added twice as many back.
While static code analysis made our code more readable, it couldn’t help with our lack of knowledge regarding the architecture of a component with respect to our entire system. By the end of our ten-week internship, our Button component had been reworked three times to add/remove props, add in themes for different applications, and remove functionality we hadn’t considered. Our “simple” RadioGroup component was around 300 lines of code, and our DataTable component, not to get confused with our Table component, had 1 million props.
We also wanted to increase our company adoption, so we had sessions with each of the feature teams to teach them how to use our React library. Change is always difficult and we found that some people begrudgingly used COGS for the challenge we gave them with no intention of touching it again. It also ended up breaking production for one of the applications - oops.
The great thing about doing something with no experience is that there’s an abundance of lessons learned. Here’s a handful:
If you are trying to introduce new tech or a process, hype it up and “market” it to your team before expecting them to contribute or use it. We ended up doing this partially in the wrong order, assuming that shiny tech was exciting enough. It is not.
Automate as much as possible. While the initial motivation for this was protection from the intern code, it has become massively important in the continued development of COGS. Onboarding people with code standards and established automated workflows is much easier.
The solution to having an old monolith application is not to make it look new 🐷💄
If you have a really small team of one designer and one developer, for example, the single source of truth and standards can be easily applied consistently. Decisions can be made quickly and implemented by the same person.
When your company has multiple teams and products that aren’t focusing on the same goal, adoption is much harder
Design systems save serious time and money. In fact, over 60% of tech companies have implemented one, and when designers and developers have access to a design system, they completed their objective 34% faster than without one.
Having a design system in place helps every actor in your organisation understand and align with the company’s vision. Interfaces, colour choices, and tone of voice, if all such decisions are centralised and accessible, it removes the need to continuously reinvent the wheel and allows people to focus on what they are good at. No one wants to bicker between two shades of grey or if the purple colour should be named Lavender or Indigo123. Having our well-defined design system now means people can focus on solving the task at hand.
A snippet of our colour palette and usage guide from COGS
Looking to get started? Feel free to ask us for advice, or check out the Storybook showcase for examples of major companies using a design system.
Charlotte Gimblett & Tom Buurmans
PartsTrader Software Developers (née COGS Developer Interns)