Rationalise it! 5 steps to introduce a new component to the design system
Boosting the design system contributions by a robust process.
Adding new components to the design system is a common routine task. Ideally, the design system team would figure out their own process for that. However, sometimes they won’t. Sometimes there’s no team at all. In that case, components are contributed by different people, so how do you ensure that every new team member can contribute with ease and that quality stays at a consistent level?
At Beamery, each new component goes through the same 5-step process we call “rationalisation”. By the end of the process, the component is ready to be taken into development and can be used by designers.
The process
Here are all the five steps of rationalisation.
- Inventory & Industry analysis
- Collecting inputs, requirements
- Configuration & Scoping
- Design for the scope
- Documentation
You may recognise the classic “double diamond” pattern here, and you would be right! The same process we use for product development is fairly applicable to the development of components.
Just like “double diamond”, this process is a guideline, not a dogma. This means you can expand, contract or sometimes even skip a step if needed. Some components will need more digging than others and that’s cool. Also, the smaller your team is and the earlier the stage of the design system, the less bureaucratic you want to be. This means optimising the effort on each stage proportionally to the value.
For instance, you may discover that there’s no real benefit in thorough research for a small and well-known component. Or, in other cases, you would have to put off writing exhaustive documentation to unblock the development.
Step 1. Inventory & Industry analysis
Inventory (or audit) is an essential step for any design system work. Before thinking of introducing something new, you need to understand well what already exists. Tangibly, this means answering the following questions:
- Does this pattern already exist in the product?
- If so, does it have any distinct variants?
- Is it used consistently?
- Is there any other component(s) in the product that serves a similar purpose?
The goal of this exercise is close to that of the discovery phase in the product development process. When trying to understand the problem, we’re collecting all the existing evidence. Ultimately, we want to ensure that no component is built in a vacuum, but instead, they are all based on the actual use-cases and specifications.
The output of inventory can be a bunch of screenshots or a long spreadsheet; whatever serves the purpose and is comprehensible for others. At Beamery, we normally store project documentation in Confluence: It’s quite handy for inventories as it allows multiple ways of organising information.
Just like the inventory helps understand what already exists in your own product, the industry analysis shows what exists outside.
No product is the same. Each company has its own unique context behind the design system. However, when you break it down to the basics, almost every system has a similar suite of components. This means we can learn from each other and take the advantage of industry best practices. There’s no need to reinvent a button every time.
In practice, when kicking off the work on the new component, you can take a look at how a similar component is built in different design systems. This can be a great source of inspiration for how to craft and document your own solution.
There are a few popular collections of publicly available design systems [links here]. My personal preference is to use the component gallery — a very handy resource organised by component type.
Step 2. Collecting inputs, requirements
If you’re building an in-house design system, your components can’t live in a vacuum. Just like products, good components are based on real use-cases and intended to solve particular user goals. That’s why user research is an integral part of developing a component.
The goals of research are to:
- Identify the problems with the existing component (if it exists)
- Collect up-to-date information about the use-cases that the component needs to support
- Find out if there are any preferences or extra inputs that you need to take into account (e.g. dependencies, constraints, etc.)
Depending on the size of the organization and the complexity of the component, you may go for a different scale of the research. However, usually, a group message in Slack is a good starting point.
Make sure to document your findings alongside the results of the previous step. You are likely to refer to them later. Also, it will help significantly if you decide to rework the component in the future.
Step 3. Configuration and scoping
After you’ve gained all the necessary context, it’s time to give your component proper thought. At this stage, you will design the structural skeleton and outline the scope of the solution. To do that, you need to answer the following questions:
- What are the variants of the component you need?
Look in the notes from the previous two steps — they must have an answer. The examples of variants are primary vs secondary buttons, or a standard vs inline link. Sometimes a variant could be so distinct that you may want to separate it into a different component. - Which options will your component have?
Think of these as variables that can be turned on and off or take some value. For instance, a primary button can take an icon as an option. An input could have an optional description and so on. - What interactive states will this component have?
If a component is interactive, you need to plan all the states ahead. This will save time and prevent some common questions from engineers (e.g. “how does this look like when there are no results or a user interacts with a keyboard?”) - What is the minimum viable version of the component you can start with?
Be especially mindful when planning the component. Start with variants and options with a known use-case and leave nice-to-haves for later. It’s really easy to overcook the component and then bury yourself in development.
Usually, the artefact of this step is a document or a spreadsheet with a scope of the component. Now, this can be easily turned into Jira tickets and planned.
Step 4. Design for the scope
Now you’ve identified the scope, ensured that it’s not too broad and finally arrived at a stage when you can start visualising the component. From the “double diamond” perspective, it’s time to diverge.
Practically, that means broadly exploring design options for particular parts of a component. For instance, you may be designing a notification component. Then, at the design stage, you’ll explore various treatments for background, outline, shadow, etc.
This step is very collaborative. It’s crucial to align the decisions with input from customers of the design system: designers, engineers, product. Make sure to keep engineers in the loop early and often. Every design decision may have a broad impact on the implementation.
Worth mentioning that sometimes the normal logic of developing a component may break. It might happen that you implement the component before it has been designed! Whatever counterintuitive it may sound, that reversed order isn’t always bad. When using headless components, you can lay down the technical foundations of a component without touching the UI. This is a lifesaver when you need to unblock engineering and lack the necessary design resources to move faster.
Step 5. Documentation
Documentation starts with the first steps of rationalisation. When collecting inputs, figuring out the scope and designing the component, you must log your results and decisions. When the next person comes in to update the component, they should be able to retrace your steps and understand the rationale. That will save time and ensure the consistency of decisions.
After you’ve gone through all the steps mentioned above, it’s time to step in your customer’s shoes and ask yourself: “What information do I need to use the component with the least effort?” Usually, the component documentation strives to answer the following questions:
- What does this component do?
- When should I use the component?
- How do I apply the component correctly in code and design?
- What variations and options of the component are available?
- What are the style properties and specifications?
- How can I find this component in code and design?
This list can go on… Each team chooses the level of depth that’s most appropriate to the component, their resources and their audience. You may start simple and learn from your customers’ feedback.
Documentation is an immense topic and a fundamental part of a design system. Make sure to read one of the canonical write-ups on this theme by Nathan Curtis.
Conclusion
Enabling contributions to a design system is a vital step to make it sustainable and scalable. This will unlock the system’s potential and help it grow alongside the growth of the product. Design system maintainers will no longer be a bottleneck for introducing new design patterns.
However, contribution can become tedious if it comes with too much admin. Having a soft playbook for design contributions lowers the effort and makes the output more robust. By following the same steps as they would for a normal product design discovery, designers will be able to craft thoughtful, ready-to-be-developed components.
Interested in joining our Engineering, Product & Design Team?
We’re looking for Senior & Mid Product Designers, Senior & Mid Product Operations/Managers, Software Engineers Front & Back Mid/Senior, SRE Platform Engineers, Engineering Managers, Tech Leads across all levels and even more roles across London, Remote & Berlin! to join us — apply here!
