Clear guidance will increase curiosity, improving adoption.

Quick teaser videos were a great way to share what was being created and how. Not only did this give designers an opportunity to provide feedback on these developments, but it gave them good insight into how I approach creating a component that can have multiple usages. Up-skilling where you can!

Component demonstrations have an impact when it comes to their usage. Designers can include a component in their designs, but what’s the point when it is not being used as intended? For elements like a button or an avatar, there isn’t much to misinterpret, but for a menu in Productboard’s application, there is helpful guidance available. Video tutorials benefit the whole team, saving time in support requests.

Providing a greater level of detail

Once a component was refactored, typically we:

Reduced the number of component variants exponentially
Applied the improved Figma functionality
Addressed any accessibility concerns
Tokenized correctly

In addition to all this was information about discoverability. Since we had a two-year legacy of component contributions in our libraries, we had accumulated many types of similar components, and it was confusing to know which ones were correct.

Provide as much useful detail as possible for components.

We needed to archive all these in Figma and merge their usages in code with our refactored component variants. This, as you can imagine, is quite time-consuming when we are dealing with many usages across different domains. As part of the update, components now receive the correct configuration details for better discovery and link to Storybook and our Nucleus documentation.

Announcements

We now have the component ready in design and fully tested in code, along with the relevant documentation on how to use it properly. Announcing a new component would be relatively straightforward, but because we were replacing old with new, I needed to provide a softer landing for designers to experiment with these updates and replace any old instances in current designs.

*It’s worth mentioning we did not request designers swap every instance of a component in legacy designs, only current flows and screens that were deemed necessary to change.

Release plan

To keep track of what status each component was in and what we had finalized for each, a release list was created in Notion and embedded in our docs site for visibility. Plans can change depending on business needs, so we needed to be reactive to this and plan accordingly.

An announcement message explaining the updates and how to provide feedback.

Tiering structure

Although the process of creating a component in our design system is consistent, (naming conventions, styling consistencies) the complexity of each varies considerably. A button has even more usages arguably than a modal but has far fewer props to configure and limited customization. Swapping a button like-for-like should therefore be an easy process for designers, whereas a modal requires more time for discoverability and understanding.

We gave a four-week deadline for changes to be implemented in designs.

Placing each component into a three-tier level release system gave an appropriate time frame between announcement and deprecation for designers to make their changes. However, once a deprecation date arrived, the old component was placed in an archive library that was still accessible should additional time be needed. During this time-frame window, I encouraged more feedback on the design, code, and documentation contribution, so the Nucleus team could make changes before the final feedback loop closed.

Results

Looking at the analytical data, we saw an increase of core components from 31 to 42 (+35%), which seemed like we were adding even more to support. But in fact, we were taking these away from domains, as they were being used in multiple parts of the product, and we could now maintain them correctly. Alternatively, there was a need, in some cases, for a new component addition to the library, such as Date Picker or Pagination, that wasn’t previously supported.

The biggest wins for us were the decrease of variants supported in Figma, down from 3192 to 879 (-72%), and the sizable code deprecation from the React repo. With all this removal of legacy design and code, our parity between both has increased to more than 84% (at the time of this writing). This is what really matters, as both design and engineering can now be confident when working with our components, reinforcing that React as our source of truth.

Survey and key takeaways

Each quarter we provide product teams with a design system survey based on our performance over the last three months. Sentiment questions on satisfaction and usability and open-ended questions on challenges and improvements are asked to gather insights that help us understand the pros and cons we are currently working with.

Asking specific questions helps gain a more honest answer. Further explanation can be asked for later.

From these results, we are able to provide some key takeaways for the teams, so they know exactly what the Nucleus team is going to take action on next. Examples of key takeaways include further explanation of slot usage, complexities with the UI selection framework and library housekeeping improvements. For visibility, all this data is collated into a quarterly newsletter that I add to our docs site, with further information on component usage, what’s on the roadmap and feedback summarization.

Our lessons for the Nucleus team

Refactoring will feel like (and probably rightly so) a daunting task, especially if you are working with an established component library. You can make this process smoother, however, by being transparent about the job at hand and how long it may take. There is no perfect way of doing it, but making a solid plan of attack will help guide your team on its progress by providing a detailed process to follow.

Giving your users visibility on this process is vital. It is one of the biggest things I have learned while at Productboard. It’s important to demonstrate and carefully explain any changes to the product and therefore your customers.

I was lucky to have a team that had bought into the process and what it meant for the design system. Not all teams are like that. So try to be calm and pragmatic when it comes to questions, it will almost always come from a good place. 😃

Would you like to join us?

If you’re looking for an exciting and complex tech initiative with a real-world impact, here’s your chance. Head over to our careers page, it could be the start of an amazing adventure, and we’d love to hear from you.

It’s all about purpose. What’s yours?

Productboard has raised a $125M Series D

Join thousands of product makers who already enjoy our newsletter