My Role
I built processes, introduced new tools for work, and laid the foundations of our new design system. I took the responsibility of auditing the UI components to design them as a library that consists of reusable and customizable components. I worked with the engineers, interaction designers, UX researchers, and QA to deploy the system.
Establishing the Basics
The prominent issue we had to keep in mind
I started by setting up a few basic elements:
First, I implemented a version control system to store the code. I used GitHub, making sure everyone who needed access could view the code and propose changes.
Next, next I worked alongside developers in CSS to build the system, relying on Sass variables or CSS custom properties to store design tokens like widths and colors.
I also created a "package.json" file to define how applications could build and install the design system.
I then put together HTML documentation that demonstrated how to use the design system, using the system’s own CSS to ensure consistency.
We had two teams of designers, the one based out of north america my team, , and one based our of india
We didn’t have permission to make our design system public, so we took a different approach: we treated it like a small open-source project within the organization.
We placed the code in a shared repository that both teams could access and encouraged contributions from everyone.
My Team took responsibility for reviewing and approving these contributions, but anyone from either team could participate. The team in India, acted as both users and custodians of the design system.
These collaborations didn’t just help both teams improve their work; they built real trust between us. My team noticed how thoughtfully people were using the system and even bringing in new ideas.
On the other side, the team in India saw that the system was truly made for their needs, which made them feel more at ease working with it, rather than pushing back against it. Which was a fleeting concern I had. being that most of us re resistant at times to changes in our workflow.
Since both teams were already juggling a lot, we decided to focus on making the design system as simple and easy to use as possible. We agreed to skip debates about web components, put more emphasis on CSS, and ensure the documentation was clear and user-friendly.
Auditing the existing components in our library
I started noticing repeated patterns and slight differences in similar elements, like buttons and login forms looking a bit different across teams. I asked myself,
“Why do these variations exist?”
and
“Which ones are intentional?”
For example
A primary button versus a secondary one is intentional, but some variations seemed accidental. We needed to clearly name and catalog the purposeful patterns, while cleaning up the accidental ones to avoid unnecessary redundancy.
I was sure to align with your developers on how they would like to handle the icons and images.
Mistakes we were making early on that we corrected
Taking a holistic approach and with "the single source of truth" in mind we agreed that design documentation would be that.
This required consistent naming conventions and ongoing collaboration between design and engineering. I stepped in as a bridge between the teams since I understand front-end development and know how engineers work, along with the technical challenges they face.
We joked about potential naming conventions I personally liked the idea of naming the system Danzi, and name these buttons below after members of the misfits.
Being "boring" in our naming conventions was the best approach to aligning all teams working on the design system.
One of TCS' core brand colors is a hue the resembles magenta. We voted and decided we would call the system magenta.
Design Documentation in figma
Specifics
We were meticulous in our design documentation, perhaps to. fault, because redundancies and inconsistencies started to occur. This was one of those " too many chefs in the kitchen" types of situations so I took over design documentation along with raj the lead on the india team.
variant properties
antomy
best practices
Versioning & Updates
Design systems are living breathing things. They will evolve based on feedback and new requirements.
Version control ensures that updates are properly tracked and communicated to all teams. Major updates Would be documented, and teams Would be informed via regular updates.
Lastly
Magenta, our global design system, was created with the unique needs of TCS Interactive employees in America and India in mind. It’s more than just a set of guidelines; it’s a tool that streamlined our design and development processes, allowing us to work together more effectively while maintaining a consistent user experience.
What I love about Magenta is its flexibility. It let us adapt designs for our local markets while keeping our core principles intact. we reduced redundancy, boosted productivity, and still encouraged creativity across our teams globally.
Collaborators
edward martin - UXR
Alison Cohen - Interaction
Sean Hamilton - Full Stack Dev
Saurh Pendey - UI