Design System 3: Keeping it lean

One of the strongest temptations you might face when creating a design system is to provide the slickest, most beautiful and faultless UI components to your team as quickly as possible, but this carries the same pitfalls as any project if you aim for perfection in the first version - it won't be perfect and you'll rewrite a lot of it when you discover why.

Treat it like any other product or feature release and think about it in terms of normal lean, iterative principles:

Creating a Design System as part of a product development

If you're designing and building components for a live project, it's likely that your team only need what's necessary for what they're doing right now. For example, this might only be the first iteration of a payment form - so only aim to provide them with what they need for the current iteration of that feature.

To figure out what to deliver, think about the design and construction of your components in the following terms (you may have others):

• Functionality
• Layout/default appearance
• Accessibility
• Customisation/branding
• Enhancements, e.g. animation

This should give you a clear understanding of which layers are required for the current project iteration. It's typical that you may only need the first two - functionality and default appearance - to give the team enough to test their iteration.

In later iterations you can add the other layers, ideally in descending priority order, to reduce risk towards the end of the project.

Creating a Design System independently of a product development

However, if you're building a Design System independently of any other projects, the decision is a little harder: To build a whole design system up in iterations such as those described above could be a lot of work, which may be re-factored across a lot of components, even if you only built the basic functionality layer.

This can be carefully planned to make that a more palatable prospect. For example, group your components into common families, such as form elements, dialog components, and whatever else your system comprises and build all of those components up in iterations similar to the above and testing them in each iteration.

For example, build a set of form components, create a form with them and test it. Refactoring those components based on your tests will be much simpler than the whole library, and you may learn critical things about the nature of your components that the remaining components will benefit from and their build will be quicker.