As technology continues to evolve, digital products need to adapt to withstand the test of time.

More than ever, digital products not only need to keep pace with the speed of change, but they must also be scalable and long-lasting. This is where Design Systems come into play. Their maintenance should be an organic process of product evolution, however maintaining a Design System requires time, effort, and resources.

In this article, we will dive into how a Product Designer can approach maintaining a Design System within small to middle-sized teams.

Grasping the essentials

Before we delve into the main topic, let's revisit the essentials of Design Systems. We often hear about its benefits, such as "Design Systems save time and enhance quality", but it's important to highlight a few key points that contribute to the evolution of a Design System. As José Torre mentioned in his Figma Config 2022 talk:

• A Design System is more than a UI Kit;

• A Design System is a powerful tool, but we can't expect it to solve all problems;

• A Design System needs to serve designers and Engineers;

• People should question the Design System.

Understanding where you’re at

Once a Design System has a basic set of foundations and components, it's important to consider the context of the product and the size of the team. Small to medium teams may not have someone dedicated to creating and maintaining a Design System, whereas this is more likely in larger teams.

When it comes to larger teams, there are also Design Systems available on various platforms that offer regularly updated UI Kits, interactive component examples, public repositories, and comprehensive documentation. While these robust Design Systems may initially appear overwhelming for smaller teams, they can also serve as valuable resources for learning and inspiration.

Ultimately, every product comes with its unique requirements, so it's essential to tailor your approach to suit your team and address any technical constraints that are specific to your context.

Brad Frost noted: “A Design System needs to help build real software products.”

Pixelmatters’ context

At Pixelmatters, we create and maintain Design Systems within each project. Since each client has a unique product, brand identity, and needs, these Design Systems cannot be fully transferred from one project to another.

How do we maintain Design Systems in small to medium-sized teams?

1. All Design Systems have been evolving alongside the product and addressing the organization's needs.

2. Since we don't have specific teams dedicated to creation and maintenance, both our teams and clients are educated about the necessity to maintain and evolve a Design System.

3. All Design Systems aim to follow a similar structure, organization, and terminologies. This ensures adherence to best practices and facilitates easy adaptation for any team member (be it a designer or an engineer) during future changes.

4. Time and budget constraints can make it challenging for small teams to ensure that the Design System evolves alongside the Product Designer's growing knowledge. Each project has its own unique constraints, including a limited number of designers and product-level priorities that must be addressed. As products and businesses evolve every day, compromises should be made to keep the Design System structured and scalable.

5. Every time a task is completed (whether a page, feature, or other), the Product Designer updates the Design System and hands it off to Engineering. This involves documenting the component states, behaviors, variations, and edge cases, if applicable.

How does this all work in practice?

As Product Designers, we are responsible for the end-to-end process, which includes:

1. Defining the User Experience of the product (interpreting requirements, mapping the flows, identifying happy/unhappy paths, edge cases, creating wireframes) aligned with the business goals and in collaboration with the Product Owner;

2. Defining the UI, creating the look & feel aligned with the goals of the product, business area, and the existing brand. This process is done through Moodboards and a constant iterative process;

3. Defining and/or iterating the Design System;

4. Development Hand-off through Zeplin;

5. Beginning a new work cycle, ultimately leading to the evolution and maintenance of the Design System as the product grows.

Given that we work with various project typologies, a Product Designer needs to adapt to the specificities of each project’s Design System, whether it be a Web App, Mobile App, or a Marketing Website. As an example, a Marketing Website Design System will differ from Web and Mobile Apps’ Design Systems, which usually are more complex.

Let’s begin by discussing Marketing Websites

As with any other project, Marketing Websites also have different stages. From an initial stage where the look & feel and foundations are being established, to more solidified moments where the look & feel is finished and we’re actively iterating on new components, sections, and pages.

In the latter stage above, we can leverage Design Systems to aid with fast iteration and evolve the design. One possible strategy would be to create a dedicated page in the Design System that lists full responsive sections as they get approved. The goal is for these “full section components” to serve as a reference to identify recurring patterns, create consistency through different breakpoints, and guarantee the design language is applied across everything.

Responsive section for a Marketing Website

As the website evolves, common elements and patterns will become more defined, which increases the reuse of both individual components and interface patterns. New sections can be adapted from existing ones to create components, and emerging components or variations should consider flexibility and modularity to accommodate different use cases.

In the context of a more advanced Website Design System, the process remains similar but with a focus on reusing components and sections and deciding when to introduce new component variations. Maintaining the Design System file is part of the process, even if components are initially created and explored locally, and this is typically done as pages or sections are approved.

Following this is the next phase, which involves documentation and handing off to development. It's essential to highlight that throughout the entire process, from exploration to handoff, collaborating with the Engineering Team is as important as the collaboration with Product. This means asking questions openly and discussing behaviors, interactions, and technical limitations to ensure clarity and alignment.

…and voilà ✨, as a result, both the Website and the Design System grow organically.

Responsive component for a Website Banner

What about Design Systems for Web and Mobile Apps?

In the context of Web and Mobile Apps, the complexity of a Design System is influenced by several key factors:

1. User flows, interactions, and behaviors — Features and functionalities of apps are often more extensive and advanced compared to Marketing Websites. Apps can have complex user flows, interactions, and behaviors that require careful consideration and implementation in the Design System. This complexity arises from the need to handle various user inputs, handle different states and conditions, and ensure an intuitive user experience.

2. Scalability — App Design Systems need to accommodate the rapid growth and expansion of the product over time. This includes the addition of new features, screens, and components, as well as the ability to adapt to changes in the app's structure and architecture. The Design System should provide a solid foundation allowing easy integration of new elements while maintaining consistency and coherence throughout the app.

3. Edge cases — Apps often need to handle exceptional scenarios, error states, and unique user interactions. These edge cases usually require component variations and interactions that need to be accounted for in the Design System. Ensuring that the Design System covers a wide range of possible scenarios and provides solutions for edge cases is essential for maintaining a robust and adaptable app.

4. Usability — The Design System needs to address the specific usability requirements of the target audience and provide guidelines and patterns that enhance the overall user experience. This includes considerations for accessibility, responsiveness, and user preferences, among other usability factors.

5. MVP approach — The Design System needs to support the rapid iteration and development of MVPs, which involves creating a scalable and flexible foundation that allows for quick prototyping and testing. Designers and Engineers need to collaborate closely to ensure that the Design System can adapt to the iterative nature of MVP development while maintaining consistency and efficiency.

6. Collaboration between Design & Development — This collaboration ensures that Design System updates align with both the intended user experience and technical feasibility. Ongoing clear communication between Product Designers and the Engineering team allows addressing challenges, streamlining implementation, and adapting the Design System to meet evolving needs.

Components for a Web App feature.

Challenges in Products with legacy

Maintaining a Design System can also be challenging for apps with a significant legacy. Some components may require a refactor to improve maintainability, reusability, and scalability. However, when a product is in active development with a stable user base, addressing major changes in the Design System may not be a top priority as long as the existing components are usable and reliable.

In this case, one solution would be to maintain the old components in the long term while updating the Design System with the latest components and interface patterns. This approach allows for a gradual evolution of the Design System, balancing between maintaining legacy components and introducing improvements over time, while minimizing disruption to the user experience and development process.

Last thoughts 💭

A Design System should not be restrictive. There may be occasions when you need to design new solutions, change existing ones, or even restructure the Design System itself. The important thing is that the decision to make those changes is made in collaboration with Product teams and is aligned with what the Product needs at a given point in time.