Clari

I started at Clari right as the product was going through a design refresh and the design system was just starting to be formalized. I had to work closely with the rest of the design team, determining which components to start building first, addressing accessibility concerns that had been overlooked, and building a set of basic design tokens, so that other feature teams could start following the new design language while the component library was built out.

Getting teams to adopt the new design system components wasn’t a hard sell — the components came with the updated look and feel that was showing up in new feature mockups. What was needed was good documentation on what the library had available and how to use it. This was particularly important as the company grew, acquiring more products with new teams distributed around the world.

I took time to thoroughly document each new component, not just listing the different props available, but showing live examples of how changes to individual props would affect the component. I also included examples of common combinations of options, especially for cases where the changes may not have been obvious or visible.

Eventually, I even documented our documentation process and style, so that the writing style and information architecture remained consistent as the library grew, and as more people started contributing to the system.

As time went on, one pain point remained from the “legacy” design: the variety of picker components that were all similar but slightly different. With all the permutations of what the trigger element displays, what content the popover allows, and what kind of data is displayed in the list, we didn’t have a component that could satisfy every use case. I outlined this with the rest of the design team, breaking down which existing components supported what required functionality, and what was needed.

After our struggles with getting third-party libraries to handle all our use cases, I decided the ideal approach would be to make something more modular. This way, our components could handle the common logic and display concerns, while leaving the particulars of the popover contents up to the implementing teams.

As we started to roll out this new paradigm, I noticed inconsistencies creeping in to some of the mockups — the Figma components didn’t adapt and respond the way the way they would “for real”. Before I started building the code for these components, I created a Figma component with variations that matched the visual style we were after, but adapted to different content and options the same as the final code would.

I ended up with a set of components that were easy for designers to utilise in mockups, and would respond to different content and states the way they would in production code. I also had a clearer idea of how the code would fit together, speeding me up when it came time to build the components.