A brief history
UserTesting — started in 2007 — has always been focused on helping companies create great experiences. For over a decade, UserTesting has been the market leader in usability testing and the de facto tool for researchers around the world. A lot has changed in the past 10+ years but the look and feel of the core application have stayed the same.
In 2007, a lot of companies looked like this.
I vividly recall our Senior Vice President, Mark Towfiq, presenting customer feedback where a customer was praising our product’s capabilities but calling it’s design, “like reading the nutritional label on the back of a box of cereal.”
I guess they had a point…
Like most teams, the breaking point for us was the color-filled rectangles known as buttons. These mismatched, frail, collection of items illuminated our inconsistency throughout the product. And what would a Medium article about design systems be without a button grid?
However, these visual discrepancies were more than surface deep and started to deeply affect the underlying experience. For example, the location and style of key actions changed based on the view you were in. Sometimes they were buried in a drop-down, sometimes they were in a tab, and other times it was only available on hover. This increased the time it took our customers to complete a task and left a lot of them asking our favorite question, “do you user test UserTesting?”
Selling the system
UserTesting needed a way to make good on their promise to facilitate great experiences by delivering one of its own. It needed a robust design system to help guide the product’s evolution. This was clear to the design team but we needed to sell this idea to our partners in other departments.
UserTesting exists to provide teams with quick qualitative data. This data is used to make suggestions on product decisions to ensure you are providing the most value to your customers. This process, as you can imagine, happens very quickly. Without a design system in place, it was difficult for our own teams to quickly act on these data points. Without clear guidelines engineers had to create custom experiences (see buttons above) which took longer to build, duplicated work, and set our customers up for failure.
🤑 Our selling point: a design system helped developers not only build quicker but build smarter, all while decreasing the time it takes to ship value to customers.
When I started at UserTesting, “design” was a brand new department. It was a very exciting time, it also meant that this new design team had to create everything from scratch. Not only did this make the early work inconsistent but we lacked a baseline understanding of why things were the way they were. This trickled down to the deliverables to our engineering teams, if we were confused so were they.
🤑 Our selling point: a design system helped shift the focus of designers from granular decisions (what color a button should be) and freed them up to think about big picture decisions (what type of action can improve this flow).
Like most companies UserTesting has departments set up for engineering, design, product, etc. We are set up on squads with representatives from each department all focused on a singular feature stack. These squads work quickly to deliver value based on external feedback and internal vision. Early on there was a challenge to visualize how directions might take form. This challenge made it difficult for teams to get alignment.
🤑 Our selling point: a design system helped give clarity and meaning to decisions made in the product. It was the source of truth that everyone could point to and start a conversation around.
There were a lot of unknowns when it came to the application and only a few had working knowledge of every view. The key asset for us during this time was a spreadsheet that listed out every view in our app in rows and two columns for design and development. These two columns would be used to track how much of the view had been converted to the design system.
🤑 Our selling point: a design system helped give management the confidence to point at a quantifiable percentage of how much of the app has been improved by the design system.
After a lot of slack messages, meetings, presentations, and conversations we got buy-in from our executive team that we needed a design system to move the product forward.
Early on we did a brand exploration to discuss guiding principles and a vision for the product. The word connect continued to appear in our discussions, how we connect the “why” to a user’s actions and eventually how we would connect the product experience with one unifying design system.
Building the team
When we first started socializing the idea of a design system we heard some of these questions: who will work on it? How will existing teams be affected? How long will they work on it? Here is how we addressed those:
Small team, big impact
We were a brand new team and we knew we had to look outside the design org to get this off the ground. Emily Stewart — a self-proclaimed UI janitor — had been laying the foundation for a design system to take root by sweeping unused styles, creating reusable components, and converting one-offs to variables. Emily and I began the process of documenting similar patterns and corralling them into one reusable area. We also used this early documentation to improve the work we were doing at the time, a win-win all around.
Keep the time focused
Emily and I were embedded on other squads at the time. We had to split our mindshare on squad work and design system work. We really believed in the system and knew it would positively impact the entire organization so we were focused on making it work. We had to get creative on how we spent our time we met regularly, used the spreadsheet to track work, and documented everything.
Getting everyone involved
While Emily and I were the point people on the project we couldn’t do this alone. We spoke with every product manager, engineer, designer, anyone that would talk to us to get the lay of the land. These early conversations were important as it piqued interest across the company and gained us some allies that would help with code review or white-boarding solutions. We are all responsible to creating the best experience for our customers and a design system was one tool to help achieve that.
Let’s make a design system
We started with an amazing product and like all great products there is always room for improvement. We communicated the need and value of a design system to get buy-in. We built a small team around it while keeping the rest of the company engaged. Now it was time for the fun part, building Connect.