Beyond a UI library: Fostering the culture of collaboration using a design system
Collaboration between design system designers and product designers is crucial for the successful and efficient development of a design system.
Design systems are sets of rules, components, and design patterns that bring faster design and development processes and reduce development costs. These increase design consistency across the company products and ultimately improve the user experience.
Involving its stakeholders while maintaining and developing a design system ensures that it is tailored to the needs of all teams and products. Failure to involve stakeholders in the process might result in low adoption of the design system. And design systems that are not widely adopted are of very little use. The design system must be customized for the organization and its products to improve design and development productivity at scale.
So, how do we try to increase the adoption of our design system?
How we sync on the design system with our designers#
In Ataccama, we use our very own Flamingo design system to collaborate on design. It’s not just ‘yet another’ UI library. Here are a couple of practices that we do to sync and communicate:
Doing regular syncs#
The design system designer attends weekly design review meetings, where product designers present their work. They provide feedback on product designers’ Figma files, ask questions, and challenge their designs from the perspective of the usage of the design system. Additionally, the design system designer brings their own suggestions and ideas to these meetings. These are often new components or design patterns. Feedback from product designers and UX writers is very important for developing the design system.
Active monitoring of ongoing design work#
The design system designer actively monitors product and design developments within the company to ensure the design system is used widely and correctly.
An example from the recent past:
We saw two projects — data lineage and data transformations — developing new features using the same new UI elements. Both projects employed a visually oriented UI approach, utilizing an infinite canvas presenting objects (cards) interconnected (with arrows). In both cases, there were also controls that allowed users to manipulate the canvas.
To align these two designs, we organized a series of workshops and involved the two product designers and the design system designer. This presented a significant opportunity to bring the UIs closer together and align new UI elements with Flamingo. It also greatly contributed to new tokens and extending existing components in Flamingo.
This workshop series was highly successful as we identified many opportunities to unify our efforts and build just once to a single code library on all levels — tokens, components, and patterns.
Consultation and feedback#
Any product designer, UX writer, or product manager is invited to ask the design system designer for advice or help. Whether they need consultation on a specific project, feedback on design decisions, or help with any related topic, our design system designer can assist.
Most designers regularly take advantage of this opportunity, often through shorter or longer Zoom calls or in-person meetings. In turn, designers provide feedback to improve the design system to match their needs and use cases better.
These consultations sometimes represent a significant amount of time, but they are invaluable. However, we try to reduce some of the time needed for direct calls and discussions by offering extensive documentation and a good level of internal communication:
Leveraging Slack#
In Ataccama, we rely on Slack as the main communication channel. These are the public channels dedicated to the Flamingo design system:
- #t_flamingo is the main Flamingo channel open to everyone in the company, where we announce all important changes in the design system. This is a busy place full of designer and developer requests and questions.
- #design_is_life is a design topics channel for all product designers and design system designers. It’s a great source of invaluable comments from designers about their specific use cases.
We also publish a weekly newsletter called Product experience filter and distribute it via Slack. It includes the Flamingo section that communicates the most important updates of the design system.
We believe that sound and open communication using Slack channels contributes practically and symbolically to the culture of a design system as an open platform for collaboration.
Iterate, test, and iterate again#
It’s impossible to anticipate and cover all possible scenarios in a design system from the beginning. Taking an iterative approach to learn from inevitable mistakes and keep developing the design system is essential. Designers and their teams are regularly asked for their feedback so we can see whether we gradually improve over time.
Ataccama's design community has a great culture of open communication. We try to cultivate this openness and encourage collaboration to tailor a design system that works best for everyone. If it doesn’t work for you and you’d like to change it, you’re invited to propose an update anytime:
The Flamingo Hatchery#
Our designers sometimes require new components or tokens for a specific feature or project in Ataccama. In the past, new components would sometimes get designed only to end up being hidden in a Figma file for a new feature or a project. Similarly, new components would get coded but then left out in a library within the codebase. As a result, nobody could easily reuse these components.
Furthermore, the Flamingo team didn’t know about the existence of these components, which prevented them from improving, documenting, and incorporating them into the design system, making them available to everyone in the company. This might have introduced a certain level of redundancy of similar components in different teams, as well as variable quality of code and design. So, we considered some alternatives to fix this:
- Could we let product teams ask the Flamingo team to develop a custom design system component? This was already happening, but the limited Flamingo team capacity (2 developers and 1 designer) was often a bottleneck for the product teams. So, that’s a no. But…?
- How about enabling product teams to develop components by themselves and merge them into the Flamingo design system? We also tried this approach, but the demanded level of code quality and universality wasn’t always met, or it jammed the product development. And we would still need to find somebody to write the component guidelines. In the end, we took the middle road:
- Allow product teams to contribute to an experimental design system branch. This was the approach we chose, and we call it the Flamingo Hatchery. It enables anyone to contribute anything without waiting for the Flamingo team. Anyone can find, view, and reuse these components (even if they lack guidelines or have some missing parts). When the Flamingo team sees fit, they can select a component from the Hatchery, improve it, document it, and move it into the Flamingo design system.
Flamingo vs. the Flamingo Hatchery#
Let me compare the approach in Flamingo vs. the Flamingo Hatchery to explain more. All parts of both (tokens, components, and patterns) are:
Flamingo | Flamingo Hatchery | |
|---|---|---|
Ownership | Flamingo team | Product team who contributed, supervised by the Flamingo team |
Code repository | Flamingo (including dev documentation, unit tests, and screenshot tests) | Hatchery (quickened merge and approval, optional tests) |
Visibility | To anyone via the repository | To anyone via the repository |
Guidelines | On flamingo.ataccama.com | Usually, minimal or no guideline |
Figma | Flamingo library | Separate section of Flamingo library |
Lifecycle of the Flamingo Hatchery#
We typically conduct a major cleanup in the Hatchery every six months. During this process, we evaluate each hatching component. We’ll determine if it’s worth improving and moving to Flamingo or decide if it would remain in the Hatchery. Sometimes, we might even come to the conclusion it’s better to deprecate it.
Summary#
At Ataccama, we strongly believe that fostering a culture of collaboration is essential for the success of a design system. That's why we do regular syncs, active monitoring of design, consultations, and feedback to ensure that our Flamingo design system is tailored to the needs of all our teams and products.
We understand that taking an iterative approach to developing the design system allows for gradual improvement over time, and we're constantly working to improve it. Additionally, the Flamingo Hatchery provides an opportunity for anyone in our organization to contribute to the design system.