How it all started

When I first joined Saleswhale in late 2019, it was my first job as a UX designer. One of the earlier things I got to do was a sweeping UI audit of the platform, trying to catalog the elements (buttons, form fields, and so on) that were in use on the platform’s frontend. There’s no polite way to put this, but it was a mess – buttons would be one of four heights between 35.4 pixels and 38 pixels, there were three distinct modal patterns, and five styles of notifications just for errors. 

Recognizing the issue

We had a component library on Figma, but it was loosely managed with little governance and wasn’t kept up to date. At many times, it was easier to copy a component from a recent prototype because it just wasn’t available in the library. Our components were also kept in 24 separate Figma files – perhaps from a time where we weren’t quite thinking how the system could scale – which meant you had to toggle on multiple libraries whenever you created a new prototype that used components. Also, some of the components we had on Figma were clearly mismatched to the frontend. 

Some parts of the interface audit.

It was also impeding design work – I was spending a lot of time searching for the most up-to-date tooltip or whatever we decided was the last appropriate H2 size; even at the end of the process, I still wasn’t sure if I was using the correct component sometimes.

Getting to work

Maybe it arose from my background in graphic and editorial design – I was used to well-organized catalogs of paragraph and character styles in InDesign that I could use, reuse, and update with ease.

I sat down and typed up a proposal on Notion. I was trying to sell the team on investing time into a properly fleshed-out system, to ensure consistency even as the platform scales, and to put in the difficult work now so we can focus on delivery in the future.

There were many considerations: How would we document it? How does the brand come into play? Will we use design tokens? How do we get our frontend developers on board? 

Start anyway

You know what they say about best-laid plans. I could’ve written all the Notion docs (I ended up writing three) in the world and there still wouldn’t be something to show for it until someone started doing the work. 

While discussions were still ongoing, I told the team I was going to spin off a version of the component library that I would build up alongside my day-to-day work. I started by rebuilding components already on the old library but trying to be a bit more conscientious in accounting for various aspects.

• Standardizing color, typography, and spacing
• Setting proper constraints so components resize properly (if they’re even meant to be resized)
• Accounting for all states (e.g., disabled and error states)
• Aiming for WCAG compliance wherever possible
• Building “molecules” of common components that occur frequently together

As I built out this new library, design work was going on as usual. So whenever I was prototyping and needed a component that would be obviously reusable, I would just take a few extra minutes to add it to the library and then drop that new component from our library into the prototype I was building. 

In a few months, I had built up a library that had reasonably accounted for most of the components we would need to prototype quickly and efficiently. I had also gotten the rest of the team on board to contribute to and update the design system after I had established the foundation. It was no longer just me working on this rogue project, but now I had the team’s buy-in, and we had more or less transitioned over to using components from the new library. 

Making it a system

You might have noticed I’ve been using the term “component library” a lot thus far. A component library doesn’t quite begin to be a design system until some level of connectedness exists between design components and code. Having all these instances documented was great, but if we were still copying and pasting code on the frontend, the system isn’t doing its purported job – to ensure consistent and efficient implementation. 

The easy part was that our frontend team was immediately on board with the project. Now the hard part was actually moving past our legacy code into this new paradigm. We had discussions with the team about how we could start translating some of these into code that could also be effectively componentized – that is, keeping them flexible while avoiding a unmanageable sprawl of variations – so both design and engineering could reap the benefits of a design system. 

What we eventually agreed on was that things would be tackled incrementally. Alongside feature work, our frontend team would start updating and consolidating components in the code for various elements when time permits or when a component is part of the current feature’s scope.

After lots of discussion about documentation, tokenization, and deprecating old code, things were going to happen gradually and that was… okay. At least we were moving, and it was good to be moving. 

Should you build a design system?

Looking back into the hours I’ve sunk in building our design system, I am glad we bit the bullet and launched into it early. As I continue to work on and with our design system, I’ve come to appreciate the benefits, some obvious and some not-so-obvious, that have come alongside the design system:

• Prototyping is faster. This one is straightforward – I no longer have to dig into recent files or try to search for the last time I used a specific component. The component I need, and all necessary variants, comes up when I search for it in the assets panel. 
• Things are easier to fix and update. If I realise that that a component need to be changed because I made a mistake or didn’t consider a certain case, it’s a lot easier to do it when it is tied back to one main component. Updating that main component means that changes can be propagated across all instances with one click instead of having to search for, potentially miss, and manually change each occurrence of the component. 
• I can focus on solving the important problems. I’m no longer lost in pixel counts or hex values, and can properly focus my attention on generating flows and solutions.
• It helped me think systematically. At some point, a growing and interconnected design system also becomes an issue of organisation and systems thinking. You start thinking about how individual components relate to each other, and how they work together as more complex organisms – accounting for various states and use cases.

Lessons in building a design system in a small startup

• You’re never going to find a perfect process. In a small company, your resources are already constrained – sometimes you’ve got to just put in the work even though your processes aren’t fully ironed out. 

• Consistency isn’t the endgame. You’re never going to get rid of all inconsistencies – this is especially true for us in Saleswhale where we had to balance legacy components while trying to “upgrade” our platform to a more robust design system. Make peace with the fact that there’s probably a handful of buttons somewhere in the platform that are the wrong color and height, and that these things are unlikely to destroy your UX or result in catastrophe – there are more important things to work on.

• Build for the future. Consider how your components might scale or be adapted for more use cases. While this might seem a little abstract, perhaps think of how you might update a component without breaking your existing prototypes. Consider if you needed to add in an icon in a button, or change the dimensions of a form field in the future. How do you build in constraints, use tools like Figma’s auto-layout, or arrange layers in your component can make the process either very easy or very difficult for future you.

• Borrow liberally. You don’t need to start from scratch. While building up the design system, I consulted various other frameworks like the Atlassian Design System, IBM Carbon,  and Salesforce’s Lighting Design System whenever I got stuck on how a particular component should be implemented. These established companies have a wealth of knowledge that has helped them account for use cases and states – use this to your advantage.

• Keep communications open. I’ve talked before about maintaining healthy relationships between designers and engineers. At the end of the day, your frontend engineers are going to be the folks turning your design into code. Get them to look over your designs (when they’re available), ask them about feasibility, don’t just assume “it’s just a small change”.

Just enough system

All that to say – build just enough system to support your processes. In a small organization, you don’t have the privilege of having a dedicated design system team or a fully-fleshed-out governance process. And like every startup, you find ways to be resourceful in the face of constraints. All these are questions worth asking as you’re trying to balance your time between your day-to-day work while maintaining a design system on the side:

• What is the minimum level of coverage you need to prototype efficiently from day to day? 
• What’s a sufficient foundation to lay to ensure that the system is scalable, and, in the most ideal case, future-proofed?
• What kind of documentation needs to be in the design system? What is it for,  and how does it affect implementation, and, most importantly, is anyone actually going to read it?

At the start of the process, I was super excited to Get Things Done Properly. I create a tracker for the status of the design system, first built out on a way-too-elaborate spreadsheet, and then eventually moved onto Jira to (supposedly) “better collaborate with engineering”. I never revisited either of these after I made them – it was too much system when I had the benefit of working on the design system in a more organic and ad-hoc fashion. Maybe we’ll need this when the team expands or the system grows more complex, but it wasn’t useful at that moment.

Can you believe I did this twice?

But wait!

A design system will always be a work in progress. Even as we’ve built out the foundations to support key design work here at Saleswhale, we’re still looking for ways to ensure the design system continues to be a useful and usable internal tool. Here are some of the ways we’ve been thinking of moving forward with what we have right now:

• In our early discussions with frontend, we had grand plans of creating some central repository that can bridge design and code (for example, with Storybook). With our current resources, this might still be a pipe dream – but some time in the future, hopefully, we can start robustly documenting components in a centralized location for easy reference and updating.
• How does the system work for other people? A good part of the work I did on the design system happened when I became the sole product designer at Saleswhale. I’m curious to see how the use, maintenance, and governance of the design system will scale as the team grows again.

And that was a convenient way to segue into this next part: Saleswhale is looking for product designers, engineers, and product managers to join the team! Come stress-test our design system while solving complex problems and working closely in an interdisciplinary team. If you’re interested, drop us a message on Intercom in the lower right!