What's your approach when design systems clash with project requirements?

1 Scenario 1: The design system is too rigid or outdated

Sometimes, you may find that the design system you are working with is too rigid or outdated to accommodate the project requirements. For example, it may not have the components, styles, or patterns that you need, or it may not support the latest technologies or accessibility standards. In this case, you have a few options: You can request or propose an update to the design system if you have the authority or influence to do so, creating new components, modifying existing ones, and adding new guidelines or documentation. Additionally, you can create custom components or styles for your project if the design system allows or encourages it. Lastly, you can deviate from the design system if the project requirements are more important or urgent than its consistency or quality. No matter which option you choose, it is essential to communicate your changes to other stakeholders and users of the design system, document your custom components or styles, and justify any deviations with explanations of the trade-offs and implications.

2 Scenario 2: The design system is too complex or inconsistent

Sometimes, you may find that the design system you are working with is too complex or inconsistent to use effectively for your project. For example, it may have too many components, styles, or patterns that are confusing, overlapping, or contradictory, or too many variations, exceptions, or edge cases that are hard to follow or apply. In this case, you have a few options: You can simplify or streamline the design system if you have the authority to do so. This involves removing redundant components, creating more coherent guidelines and documentation, and communicating changes to other stakeholders. Alternatively, you can use a subset of the design system if it allows it; selecting relevant components and creating a layer of abstraction that simplifies the use of the design system. Finally, you can ignore or override the design system if project requirements are more important than its complexity. This involves ignoring components that are irrelevant for your project and justifying your ignore or override to other stakeholders.

3 Scenario 3: The design system is too generic or incompatible

Sometimes, you may find that the design system you are working with is too generic or incompatible to meet the project requirements. For example, the design system may not have the features, functions, or aesthetics that you need, or it may not match the brand, tone, or identity of your project. In this case, you can extend or customize the design system if you have the authority to do so. This may involve adding components, styles, or patterns that are specific to your project or creating new guidelines or documentation that reflect the brand, tone, or identity of your project. Additionally, you can use a theme or variation of the design system if it allows for it. This may involve applying a different color scheme, typography, iconography, or imagery that are specific to your project. Lastly, you can replace or supplement the design system if the project requirements are more important than the design system generality or compatibility. You should document and communicate any changes to other stakeholders and users of the design system and ensure they are in line with the overall vision and goals of the system.

4 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?