Enhancing Our Design System for Seamless Collaboration and Consistency
I. Introduction & Context
Over the years, the idea of a design system has become very popular. It is essentially a collection of reusable components and directives that help create digital products. These systems are extremely important because they maintain consistency across different platforms and projects, while accelerating the development process as a whole.
When Doctrine was created in 2016, the design was driven by innovation and flexibility and the concept of components wasn’t really discussed.
In the following years, the industry standards showed that a design system brought too much rigidity, which led us to reflect more on our approach. During few years, we tried to implement components and reusability in the codebase but new designs were incompatible with the consistency that we wanted to implement.
It was later in 2020, facing an increasing number of designers and developers arriving at Doctrine, that we began to understand the importance of creating a design system.
When I joined Doctrine in 2022, we faced real challenges with our design system. One of the major issues was that the code components and design components did not integrate well. Our product had evolved over time, which led to a lack of consistency in the appearance and functioning of elements.
We faced challenges in our project due to the lack of a consistent and widely understood language between designers and developers when discussing design and development. This shared vocabulary, known as ubiquitous language, refers to a set of clear and unambiguous terms that are understood by all members and stakeholders of a product team. In our case, the terminology used was confusing and unclear, leading to frequent misunderstandings and significantly slowing down the entire process.
But we didn’t just sit around and complain about these problems. We took action to improve our design system and overcome these challenges. Today, we have adopted a governance model that emphasizes distributed responsibility, allowing for both freedom and individual accountability within our design system efforts.
II. Audit the system components
During this audit, we considered a bunch of factors like whether a component could be reused, if it matched the overall design language, and if it fit our product’s requirements. If a component didn’t meet these criteria or wasn’t needed anymore, we made the decision to either get rid of it completely or make changes to adapt it to the system.
We also realized how important it was to align our design system with the design files we created in Figma, a design collaboration tool. We wanted the components in our codebase to have the same names as their counterparts in Figma. This way, designers and developers could speak the same language and understand each other better. It really helped bridge the gap between our teams and improved communication and collaboration.
During the audit process, we also found some opportunities to optimize our component library. We noticed that there were similar components that could be merged together, which reduced duplication and made the system more streamlined. This not only made our development process easier but also created a more consistent and cohesive user experience.
By thoroughly auditing our system components, we were able to identify areas for improvement and lay a solid foundation for a stronger and more unified design system. This initial step set the stage for further enhancements in our design and development processes, making our team more efficient and fostering better collaboration.
This audit was lengthy because we had a large number of components, including some that were not system components. However, after putting in effort and time, we ultimately completed the audit.
III. Exploring Collaboration and Governance
The audit we conducted was satisfactory, but we wanted to establish a process that would consistently keep our system components synchronized in the future. This led to the topic of collaboration between designers and developers, which quickly evolved with the introduction of communication channels on Slack. This facilitated ongoing feedback and alignment on design system updates, ensuring that both designers and developers were in sync.
We still have progress to make, especially in terms of the governance and management of this design system. While implementing rules and processes may initially seem like a burdensome task, it is absolutely necessary to ensure the long-term maintainability and sustainability of this system. By doing so, we can effectively address any potential challenges that may arise in the future.
What are the next steps ?
- Document the design system: It’s important to have a detailed and comprehensive documentation of the design system. Tools like Storybook can help us create interactive and visually appealing documentation.
- Expose the design system on a private registry: To make the design system easily accessible to the team, we should consider making it available on a private registry. This will ensure that all team members can access the latest version of the design system.
- Implement a versioning system: To maintain control and track changes, it’s important to establish a versioning system for the design system. This will help us keep track of updates, bug fixes, and improvements over time.
- Deploy the design system: Once the design system is properly documented and versioned, we need to establish a reliable deployment process. This will ensure that the design system is easily available and can be integrated into our projects.
Who is responsible for this work ?
Currently, we do not have a dedicated team solely responsible for the maintenance and upkeep of our design system. Hence, it becomes the collective responsibility of all team members to ensure the well-being and success of the system.
Should we expose it in an external library ?
While the idea of creating an external library for the design system might sound appealing, it is important to consider the potential difficulties and costs associated with it. Moreover, since our web app is currently the only consumer of the design system, there may not be significant immediate benefits to separating the code. However, we are actively working towards abstracting our components and making them as reusable as possible, in anticipation of future projects where the benefits of a separate library may become more apparent.
Conclusion
In conclusion, our path to creating a better design system at Doctrine has been about learning and adapting. Initially, we may not have fully grasped the significance of design systems, but as time went on, we recognized their crucial role in ensuring consistency and efficiency across our digital products. Additionally, we have continuously challenged the status quo, as it is one of our core values, in order to build a cohesive design system.
Looking ahead, we understand that effectively managing and maintaining our design system is crucial for its long-term success. Though it may seem like a daunting task, it is essential for ensuring the usability and sustainability of our system. This proactive approach will enable us to reduce time to market and swiftly release new features. With this mindset, we can confidently tackle future challenges.
We believe that all teams, including full-stack developers and designers, should share responsibility for this initiative. Therefore, everyone is encouraged to contribute and create new system components after discussing them with the team.
