An introduction to Thumbprint

The Design System’s team at Thumbtack is proud to introduce our newly open-sourced design system called Thumbprint. Consisting of design assets, guidelines, and component code, it’s the result of a collaboration spanning many months, multiple teams and most importantly the contributions shared by so many in the Design Systems community. We hope you’ll find Thumbprint a worthwhile addition.

Humble beginnings and second chances

The first incarnation of Thumbprint was released in mid-2015. A team of five produced a comprehensive style guide that established a stronger Thumbtack brand by consolidating years of drifting styles into straightforward color options, type sizes, and all the design components one would expect. It looked great. Assets were created. There was joy throughout the land.

But if you’ve been involved with an effort like this the rest of the story will sound familiar. Soon after launch the original designers and developers moved back to product work. Without a dedicated team to manage Thumbprint, especially in a company hiring aggressively, it quickly became outdated as new use cases surfaced and code approaches diverged. The weeds of design and technical debt we had so diligently pulled began to push through the foundation yet again.

This acknowledgement — that style guides alone are insufficient to effectively steer product work — has led many companies to form Design Systems teams. At Thumbtack, this happened formally in late 2017 with two designers and two developers and coincided, serendipitously, with a major rebranding.

I say serendipitously because though our new brand launch was only a few months away it meant we could create a modern Thumbprint design system from scratch. Thumbtack’s Brand team had delivered a new logo, colors, and font. How they were applied in the product, and what components should be built, was up to us.

Getting it done

We initially started by auditing the entirety of thumbtack.com, looking at every element, in every nook and cranny. Though this is standard procedure in the design systems world it proved to be overwhelming and we struggled to determine our next steps. It was only when we decided to break this process into product releases — what we call Toolkits — were we able to gain steam and demonstrate our impact.

A toolkit captures one well-scoped concept. In some cases they are broad and lengthy, like determining how our modals should look and behave. Others, like loading animations, are faster to complete. This approach enables us to plan our work far into the future and the transparency allows teams and leadership to help us reshuffle priorities as needed.

Throughout December of 2017 and the first quarter of 2018 we finalized our color, type, and icon toolkits and began updating our primary website, thumbtack.com. This involved thousands of scripted changes and gingerly sifting through layers of legacy code. We officially launched Thumbtack’s new brand on May 1, 2018.

From there we focused on being the glue between design and engineering; working collaboratively to establish a common language, solving problems, and teaching them how to use the new system. We also continued building, updating, documenting, and integrating our toolkits, among them buttons, form inputs, cards, tooltips and modals. And we made sure it was easier for everyone to use Thumbprint components and assets than building their own. As hoped, usage rose steadily, lines of custom CSS dropped, and quarterly polls revealed a high confidence in the system, trends that continue today.

Most of our team’s efforts have been centered on the web. While there is still plenty more to do there we’ve recently expanded our purview to include our Native apps. We’re now exploring how much of the existing design system can be shared, how we document those differences, and where Native component designs and code should live.

A few lessons learned

Over the course of the last year we learned a ton. In future posts we’ll describe them in greater detail but a few rules emerged that we found indispensable.

Document well. We knew from the beginning that documenting our components, providing guidelines, and offering quick, reliable search would be critical. We’ve invested heavily there and it has paid off. Currently we use a combination of Figma for design, GitHub for code, Gatsby for the docs, Netlify for hosting, and Algolia for search.

Communicate early and often. Design systems are intentionally incomplete. There will always be new use cases and designs that evolve. When questions arise we direct our users to Slack and make it a point to respond immediately. Though this can interrupt our work it is vital we maintain trust, and their concerns often expose weaknesses in our system that we can track and address later.

Build conservatively. It’s tempting to anticipate needs by building designs and components before they’re requested, like a custom Bootstrap. But we’ve found this often leads to work that either goes unused or solved the wrong problem, and deprecating and removing it can be tricky. We’d rather teams create “one-offs” and consolidate them later into the right solution.

Stay pragmatic. Working at a growing company with a rapidly changing product means nothing is ever permanent or perfect. We learned to focus on shipping good tools that help the team today rather than designing great tools to ship next quarter.

More on the way

In the coming weeks look for posts about our process and a technical deep dive into our documentation. Until then take a look around. We’d love to know what you think.