Thumbprint
Design Systems
Overview
Thumbprint is the design system of Thumbtack, a local services marketplace that connects people with pros who can get things done. Thumbprint enjoyed wide adoption across the product org and we collectively created a culture of collaboration around the system. Our team was quite proud of it.
Over the course of 2 years I designed and wrote documentation for over 40 types of components. Thumbprint covered web, iOS, android, email, illustration, and other supportive libraries. I also created educational sessions and fun demos to help socialize the system and get everyone bought into using it.
THUMBPRINT WEB + GLOBAL
Building foundations for desktop and mobile web
Back when I first joined Thumbtack, we had a very rudimentary design system called Primo that was mostly just a loose collection of Sketch libraries. Designers would build on top of old mocks, developers would often be irritated at handoff, and ultimately the product suffered - it felt disjointed from page to page. There was so much tech debt built up from years of quick solutions that making any kind of global change to most things was hard.
The need for a more robust design system was clear. Designers needed a clear source of truth to design better experiences, and developers needed a system to be able to move quicker.
Setting solid foundations and cleaning up tech debt
By successfully auditing and improving small yet impactful areas of the system, we were able to achieve quick buy-in from those around us, while setting the stage for future work to be built upon.
We set out to not only reduce the amount of options or simply clean something up, but to apply systems thinking to everything from the naming to the experience of interacting with components in the design tool. But oftentimes, just the clean up is a huge task. It certainly was for us.
We set out to improve these 4 foundational areas:
- Space
- Color
- Typography
- Iconography
A new spacing system
Before we implemented a spacing system, designers would space elements in increments of 4. Developers were manually inputting space into each component. This resulted in content across the experience jumping around.
Upon audit, it was revealed that we had 821 separate instances of space in the product with 47 different increments. It was a bit daunting to grasp how bad the situation had gotten, but we had to do better.
The solution was a system of 8 spacing increments that gave designers enough flexibility but also allowed space to be tracked and controlled globally. Win-win-win. What resulted was a color-coded system that allowed designers to move quickly through spacing issues and to be more consistent across the product.
I also created assets in Figma to help designs apply space. This would help new designers get aquatinted with a spacing system quickly. Easily accessible cheat sheets were also made in Figma for quick reference.
Clarifying colors and making them more accessible
With Primo, an audit revealed that there were 133 different colors being referenced in the product. We able to get that down to 30 with a better system.
When Thumbtack rebranded in 2018, the colors that were set out were only WCAG AA compliant. I set out to expand the system to increase accessibility and contrast across the palette.
The solution was to leave the primary colors largely unchanged to avoid any large changes in the system, but we opened up another level of options in Figma in order for designers to drop into an more accessible palette if they want to. Accessibile colors were also updated and promoted in the system wherever possible.
Cleaning up typography
Typography was also cleaned up and improved. An audit revealed we had 65 different instances of type in the system. We were able to get that down to 25.
Only icons that spark joy
Icons were also cleaned up considerably. We ended up identifying 530 different icons in the old system, and we were able to consolidate that down to 152.
Results
After a year of work we had a rather mature library for web. However, we found that designers and developers who worked on native experiences were feeling left out. Luckily, we were about to start realigning our design process to be native-first, which gave us a good reason to start a native library.
But first, a moment on tooling.
HELLO FIGMA
Upgrading and migrating our tooling
One of the first big tasks when I joined the team full-time was to learn a new tool (Figma), migrate all of our existing assets to that tool, and support the team after the transition with educational content and hands-on support. So, I set out to dive heard first into Figma and rebuild the system.
Where we were as a design team
At the time, we were using Sketch/Abstract/InVision, but we had multiple issues with each. Sketch didn't have design system support like we wanted, Abstract was clunky and lost projects, and InVision was expensive. Lead designers and managers decided to make the move to Figma, and I was in charge of the migration.
Moving to Figma
Over the period of a month, I rebuilt our existing system in Figma. I found Figma to integrate design systems in a far superior way, and was able to replace the functionality of 3 tools with just one.
After we had Figma up and running, we gave the team 2 months to switch over to Figma. Some were anxious and switched immediately, while others were apprehensive and took their time. I think a systems designer is unique positioned to help people during these periods of transition.
I created onboarding and support content for the team, and held anyone's hand who needed help getting up to speed. On an ongoing basis I would meet with every new hire on the design team to go over the system and help them along their path.
Results of the migration
In the end, we spent 3 months and successfully migrated a design team over to a new tool. We had zero issues on both designer and dev sides. We provided lots of support around developer handoff, which helped developers get into the process sooner, and for final mocks to be found easier.
We ended up seeing a 22% increase in sentiment towards tooling after we switched to Figma.
THUMBPRINT NATIVE
Adding iOS and android to the system
By the time 2019 had rolled around, we found that Thumbprint had lots of adoption on web, but very little on native (iOS and android). We were moving to a native-first company as well, so it made sense to support better native design through improved design system support.
So I got started on creating a native library for Thumbprint...
There was only one problem...
We didn't have any dedicated native developers to do any work! It was an issue that we had to navigate with patience and tact. Thumbtack had plenty of talented people who wanted to help, the issue was finding consensus on issues and trying to grab time for bits of work. I proposed and ran a meeting helped us all move forward, called the Weekly Native Session.
Just get people in a room
Since we didn't have dedicated developers but plenty of dedicated people, I grabbed the platform leads and asked them for a bit of time every week to discuss issues that pertained to their respective platforms. I made the meeting notes public, and anyone could attend and talk about any subject.
This gave us all time to find consensus and go forward fixing issues with confidence. Often I would find an issue on one platform would have to be tackled in a completely different way on the other, and this time was crucial for us all to gain knowledge to be able to share amongst our teams as well.
Over time, this meeting helped us move forward with developing a system with zero dedicated resources. It was a mark of pride for us all to figure how to get things done, either by simply asking for time on goodwill that it will help everyone, or by piggy-backing off of new work that had to be developed. It helped me realize that being scrappy is often the best way to get things done.
It also helped us discuss and work through native parity...
Designing for parity, and then some
As we worked through iOS and android issues, we paid extra attention to the disparities and differences in the platforms. We made sure to lean into a platform's inherent pattern as much as possible. This would save time on development and decrease tech debt.
We thought of parity in terms of naming, functionality, and process parity. This allowed everyone to speak the same language, the product to function in a similar way for everyone, and made sure every platform had a component. We kept track of this in a log so we had visibility into what coverage we had and didn't have.
Layouts as a starting point
To help support and promote better native design, I created a series of native layouts for iOS and android. This gave designers a quick way to get started on a native design and also provided guardrails for what's allowed or promoted on a particular platform.
This gave designers, within seconds, a way to get started on a layout that's comprised of system components and easier to work with than finding it elsewhere. And, because everything was constructed with nested components, designers can break the instance and make their own with a simple click.
Results
At the end of a year, we ended up shipping over 40 components - all without dedicated developers. It was a testament to the desire of talented people coming together to get something done.
And, of course, we saw web developers get jealous of all the attention and start to ask for more back on web.
"I feel the components that exist are very robust. I'm glad to see updates to Android layouts - this will help me immensely in my work."
- Thumbtack Designer
"The new Pro Listings Page was much faster to build with Thumbprint components."
- Thumbtack Developer
ILLUSTRATION LIBRARY
Building bridges with an illustration library
Historically, Product Designers at Thumbtack had poor access to creative assets. There was a big gap between Thumbtack the brand and Thumbtack the product. Ultimately, the product suffered and felt stark and a little lifeless.
The Creative team approached us with a set of new illustration assets that they wanted to get integrated into the product in a better way than before. I saw an instant solution in Figma - why not put the illustration assets with the other product assets? We could retain control over the images globally, just like we do with normal components, and give designers access like never before. Win-win.
Defining the process
We pulled together a team of developers, designers, and illustrators to define how designers and developers would access the illustration assets, get them into the product, and be able to track and update them globally.
I laid a plan on the design-side, and took ownership over digesting the source files and gettin the library built and organized in Figma. I laid out delivery specs and partnered with the creative team every step of the way. Once we had all of the assets prepped, it was ready to get them into the system.
Utilizing the Image Service
Thumbtack's Image Service, although is was very simple, was quite easy to work with and did everything we needed it to do. Development made a few tweaks to the upload interface to anticipate the increased traffic, and we were off and running quickly, as far as development went.
I would add a high-resolution source file to the Image service and would receive a unique ID that referenced that image. I would then create smaller versions of those images based on their intended size. These images would then get incorporated into Figma along with its unique ID and some other helpful search information like sizing and search terms.
The ID would then be the only thing a developer would reference in the code, and the Image Service would render, on the fly, whatever resolution and size image was necessary for that particular experience. It was pretty cool.
Making it easy for everyone to use
I attached all of the relevant information to the description of the component in Figma, which allowed everyone to see that upon review. All the dev had to do was reference that ID and everything worked.
Results
What resulted was an illustration library that allowed anyone in the product team to enable and disable with single click. The creative team maintained control over the assets, but I was able to keep it organized and easy for designers to use. All developers had to do was copy and paste an ID.
It was an awesome example of working cross-functionally to do something new, and enable those around us to design better than they could the day before. This can be scaled to any type of creative asset, which is really powerful.
THUMBPRINT EMAIL
Fixing email with systems thinking
Email was always deprioritized when weighed against more important product work. This is understandable, but over time, problems started to snowball, until it was finally decided to assemble a team to finally fix email once and for all.
It was my responsibility to audit the existing email system, create a better one in Figma and in code (with the help of a developer), create layouts that help designers and content writers create and edit emails rapidly, and clean up any inconsistencies and identify when to consolidate components for ease on development.
We also wanted to continue building bridges with the Creative team, so they brought in as direct partners in the process. Historically, marketing and transcational emails were in completely different systems and designed in different ways. This made them feel a bit fragmented.
Designers also had no support and there was no real source of truth. Over time, designers and managers just created whatever email they wanted, and certain flows started to feel like they were from different eras.
The ultimate goal was to build a highly flexible system that served everyone and featured rapid prototyping and copies of every existing email. At the time, that was 187 emails.
Auditing the problem
The first step, as always, is to take stock of the situation. I got to laying out screenshots of every email we sent out in order to take accurate stock of the problem. Some patterns started to emerge...
Creating layout types
After some sifting and organizing, I found 15 layout types that would be able to serve any type of email, as well as a suite of supporting components to make the system super flexible.
The layout types: Basic, Booking, Choice, Hero (Simple), Hero (Full Bleed), Invite, Letter, Message, Payment, Project (Customer), Project (Pro), Receipt, Report, Review Creation, Review Received
Creating smart layouts with auto layout
I also took advantage of Figma's new auto layout functionality to make the layouts highly responsive. In a matter of seconds, designers could get to a final mock that would be aligned with the coded email.
Content writers could also, for the first time, get into the design files and test out content in context. Managers could even get in on the fun, creating quick emails without design input if necessary, since all the components were already designed and ready to go.
Results
I had tried to fix Thumbtack's emails twice prior to this push. In the end, I created a solution that had never really been seen before. I was proud of finally solving a bif problem and creating something that anyone could use. It utilized new features to get there, and it was fun to figure out how to build something in a new way.
SYSTEMS INFRASTRUCTURE
Construction and taxonomy
How you build a component and what you call it have big implications for the designers and developers around you. Including helpful icons, variables, and other helpful bits in component construction allows designers to move quickly through what matters and keep within system guidelines.
Component construction
It's important to not only think about the component you're building, but how you're going to build it. A good systems designer must take into consideration existing patterns, tool functionality, and how your designers are going to use that component. Just because you make it doesn't mean people will use it.
The component must be easy to use, with added helpful features tucked into the layers. It's also important to keep in mind how the team swaps out components. It's all part of a good QA process around shipping quality design assets.
Digging into taxonomy strings
We also came up with a complex taxonomy string to help guide the naming of all Thumbprint components. This string, while it looks scary in its full form, would reduce nicely, and gave everyone insight into what was in the system, what was out, and what components were nested within which.
Theme · State · Size · Name · Prop1, Prop2...(template) + compound components [Context]
And then when applied in reality would produce:
Primary · Default · Large · Button [Native]
Checkbox + Label, Text [Web]
Partial Sheet (Action) [Android]
This was also optimized for swapping out instances, so it worked for multiple different teams in different ways.
SURVEYS & FEEDBACK
Building trust with surveys and release notes
Design systems work and success can be hard to measure and often suffers from visibility problems. How do you know you're doing a good job? What should you tackle next? Does anyone know what you just released was just released? Even if they were simply aware of something being released - did they understand it enough to use it when they need it?
Bi-annual surveys gave us data and quality feedback
One of things we did from the inception of the Design Systems team was to send out 2 surveys a year to the Design and Engineering departments. Most of the questions would remain the same, with a few changing to reflect current issues or changes in functionality.
We also solicited feedback constantly, but would pay special attention to the feedback that was received in the surveys. It would help us get individual feedback that designers and developers wouldn't say our face (even if it was great). We would then take that feedback on what is working and what isn't and would apply that to our roadmaps.
"Over the last year, many new components and functionality have been developed that are making the work easier to accomplish. The design systems team has been listening closely to what feature teams need most and prioritizing accordingly to maintain a strong alignment with company goals."
- Thumbtack Designer
Putting the time into release notes
If no one hears a component get released, does is it really? For designers, this answer may be no. I have found it crucial to make a detailed release note email that dives into detail what is new. Anywhere possible, I include gifs of the features in action (big fan of Gifox), which helps the emails feel more dynamic, helpful in context, and more visually appealing that simply reading text with a static image.
IN CONCLUSION
Results
In the end, our small team ended up making a huge impact at Thumbtack. Thumbprint became so well-respected that recruiters would include it in their email signatures and materials. Designers were designing faster than ever, developers were happy, and everyone was focusing more on the right things - solving problems. This is why good systems are important - they allow the entire product org. to be more efficient and focus time where it matters.
Because we had tracked sentiment and usage, I'm able to present the following numbers and quotes that help to illustrate what we accomplished over the course of 2 years:
Let's look at the numbers
4.86
out of 5
Confidence in the future of Thumbprint
4.27
out of 5
How easy is the documentation to understand and use
74%
Of developers believed Thumbprint helped them build UIs faster than three months ago
86%
Of designers were referencing documentation at least monthly
"I haven't experienced any issues with what's offered currently in Thumbprint. I have confidence the system will continue to evolve with our needs."
- Thumbtack Developer
"Thank you for sweating all the details and really thoughtfully approaching each component you create."
- Thumbtack Developer
"Having Thumbprint is the cornerstone for design quality."
- Thumbtack Designer
© Jon Kerwin 2020