When Should You Build Your Own Angular Design System?

When should you start thinking about building a design system?

Wade:

In an ideal world, you’d begin defining some degree of a design system before constructing any products. Formal style and branding guides are a good start. In reality, the investment of time and resources required to build a fully realized design system starts becoming critical as you find your team growing and begin to struggle with visual consistency and knowledge sharing.

Idris:

Wade is spot-on with his answer; I always say there is never a perfect answer for when to start building a design system, but I would add as soon as the product starts and branding has been established, then start making plans for building a design system.

What problems will building a design system solve?

Idris:

Ease pressure on developers. As applications grow or as new products are being developed, having a design system helps your team become more efficient by allowing developers to focus more on shipping out features more rapidly and less on having to start implementing new UX designs from the ground up.

Wade:

A design system serves as a single source of truth visually and functionally for your products and defines and provides reusable implementations of common patterns. Building a design system will facilitate communication between product, UX, and development teams members and establish verifiable components that can be dropped into applications to reduce the need to construct common patterns from scratch. As components can be verified individually, developers and QA testers can spend less time rebuilding and testing the same thing.

Why should you consider building your own design system?

Wade:

As your products and teams grow, investing in the construction of your own design system can be a worthwhile investment. Documenting your design standards and building reusable components can save time and money for onboarding, development turnaround, and verification. If you and your team find yourself fighting to customize an existing off-the-shelf component or style library, investing in a design system can save implementation time in the long run (since developers won’t need to continuously rebuild the same components from scratch) and give designers the flexibility they need to ensure your products have the best user experience possible.

Idris:

Creating your own design system ensures visual consistency across teams and products. As product and team grow, the lack of a unified design system can lead to visual inconsistency, and the UX might feel scattered and off-brand. Having your own design system helps alleviate these issues as they provide a unified pattern for implementing your web components.

How to ensure your developers follow your design system?

Idris:

Having verbose documentation for your design system can go a long way, but pairing it with Custom Code Snippets or Live Templates might be the perfect combination you need to enforce strict use of your design system. Code Snippets can help you save and reuse your component library code fragments. You should create a Code Snippet for all your design system's components and share it among team members - by doing this, you can be sure that your team would use each component of your design system exactly as intended. Code Snippets are a standard feature on most IDEs.

Wade:

Training and documentation can go a long way toward getting developers to follow a design system. Providing developers with access to documentation covering both your design principles and a technical reference for consuming components and handling styling is critical. Establishing a knowledge base of reference materials can be accomplished through traditional documentation strategies, or even better, with a tool like Storybook, particularly when it comes to component documentation.

Training is also essential. Making sure developers are comfortable working with the design system you’ve built and are aware of what reference resources exist and what they contain empowers developers to take full advantage of your system. Topics can include training on best practices for consuming style and component libraries, contributing to the design system implementation, and how to leverage conventions provided by your design system when collaborating with team members within non-development disciplines.