Guide #006: How to start a code-first Design System

If you’re a developer looking to start a Design System, it’s likely because you’ve encountered some type of friction or inconsistency. Rather than dive right into building one, first seek to define the problem you're trying to solve or the ideal state you’d like to achieve. If you need to gain approval or buy-in for this work, align the benefits of a Design System with achieving a company goal. For example, if your company has prioritized an initiative to build more accessible products, frame the Design System as part of the solution for implementing more consistently accessible experiences.

Take a step back from your current projects, or even your current team, and think about how you might structure your component library so that other teams can use it. Think reusability and shareability outside of your immediate projects and team as your primary goal. Depending on your company’s code architecture, the simplest solution could be to create a new directory outside of your team’s main directory for your new sharable components and styles.

As you start to build components for a shared library, try not to overextend yourself by building every use case for a component. If you’re working with a design spec or refactoring code that already exists, accept that you may need to rewrite components multiple times as they get used. Don’t worry about getting it perfect or catching every edge case or attribute that a component might need. If you’re using React and TypeScript, architect your code to give yourself the flexibility to keep adding props/variants later.

Adding edge case components will slow you down and distract you from focusing on components that everyone can benefit from. If a team needs a new component, it should not automatically be added to the Design System. Once you recognize the need for that component in two or three different applications, that’s when you should consider adding it to your shared library and supporting it.