<aside> 📣 This case study will focus mainly on a broad experience and learnings working with a Design System. If you'd like to learn more details about the inner workings, send me an email at tienc25@gmail, and we'll chat!
</aside>
I joined CallRail as a UI Designer who has translated and evolved to a designer for visual systems. I collaborate with a team of UX Designers and Front-End Developers to develop flows with current and new components. My role is to work with the team to create solutions that address the details and are mindful of systematic impact.
I came into a pre-existing design system in the works. My main focus is to maintain and update the current system and adapt it to the needs of our current and new products. I'll update components, introduce new patterns, and maintain parity between design and development.
I've worked on a few projects exploring how we implement new patterns, treat hierarchy, introduce new components and layouts across our products.
Here are a few examples:
<aside> 🙌 A highlight was the creation of Design System Gardeners. Many of our engineers have guilds that focus on subjects, like back-end, front-end, etc. We started a guild to explore how to improve our system in an open-source-like or Federated- Centralized collaboration model between designers, developers, and anyone else interested!
</aside>
There are a variety of ways that a Design System is governed depending on the organization. In CallRail's particular situation, we function on a centralized/federated model (leaning towards a more federated model). No solitary team serves as the keepers of the system. As a UI Designer, we focus on the components and patterns that evolve and are outgrown. Our visual design roles help us become familiar with the variety of components used and how they can support designers in their workflows.
With our familiarity with the components, our focus is on adding, deprecating, and evolving the components in the system. When designers come to us for problems, we collaborate with them to find an ideal solution with the current components. We also work together to build hybrid or new components based on the problem they are trying to solve. We will then review the case for it and add it to our existing library.
The way the system functions is a little more open-source. Adding or updating components renders a collaborative process. When a current design is updated, if nothing too drastic has changed, it can be made and pushed into production depending on the project that needs it. New components or redesigns usually start from the ground up, which requires a little more thought. Does it solve the problem it's currently addressing? How does this fit into other flows in the? What about other products now and in the future?
Let's say a transcript component is in the design process. From the most basic structural standpoint, transcripts follow a back-forth conversation between two people (represented with two blocks).
As we think about more functionality, we need to consider the other UI elements that would appear on the transcript (highlighting, favoriting, searching, etc.) depending on the context in which it's used.