The Headwinds and the Tailwinds

With any huge project, there are forces working in your favor (the tailwinds), and forces working against you (the headwinds). In our case, they were:

The Tailwinds

Our entire product was on a pretty similar tech stack. The JavaScript ecosystem can change in the blink of an eye, and I would never have expected a company of HubSpot’s size to be on the same stack. But a homegrown, developer-driven movement towards React and away from Backbone had been widely successful. This meant that teams could redesign their apps without moving to a new stack and that my team would be able to maintain consistency relatively easily.

We already had the makings of a reusable component library and corresponding documentation tool. As teams started to move to React, one of our engineers had spun up a reusable React component library with easily maintained, coded examples that could be edited inline, which meant we didn’t have to start our documentation from scratch.

The Headwinds

Unlike our apps, our libraries don’t have a dedicated QA period. I had come from a financial software company, and I probably asked my tech lead where the QA engineers were 5 times in my first week before it really sunk in. Not only were we on the hook for doing our own quality assurance, but every change we made would be picked up by all future builds — and because our teams deploy more than a thousand times a day, this meant any changes to the components would go out to every app, immediately.

We’d need a coordinated effort between the front-end infrastructure team and the product teams to ensure that every screen was ready when we launched, while also taking care not to unintentionally cause any bugs in the product. But as long as we moved quickly and kept it easy to revert any bad changes, we could minimize the damage.

HubSpot Product is made up of small, autonomous teams. Teams at HubSpot have complete ownership over a piece of the product, with the freedom and power to research, iterate, and find solutions. We were worried that it would be tricky to implement a new design system aimed at eventual consistency with teams who had such a strong culture and history around autonomy.

During the transition, they’d have to completely stop working on new features, and we’d also be developing the processes and standards that the whole team would need to adhere to going forward. There’s a delicate balance between supporting your coworkers with a system and taking away their creativity with it. But we were also confident that by removing low-level, repetitive problems from our coworkers’ plates, we could free them to channel that creative energy into solving bigger problems.

Our worries were mostly unfounded. The teams, too, were ready for a system-wide redesign, because:

No one had to change their stack or business logic. Inconsistency was dragging us down. Product managers saw it in user feedback. Designers saw it in the numerous shades of gray across our product. Developers saw it in way too many date picker libraries. A reliable, reusable component library built and maintained by another team sounded like a pretty sweet deal. Our new design system, HubSpot Canvas, looked good. Like, really good.

From Project to Process

When other companies do big redesigns, they’ll often unveil them with great fanfare, like pulling a sheet off a car — yesterday you had the old, and today you have the brand new.

That wasn’t going to work for us.

Our product and our product team were just too massive to do it all in one go. We decided instead to tackle parts of the product one by one, starting with those that had fewer users and moving progressively toward the core of the software. This process would be way less disruptive, and meant that we’d get to make improvements to the design system before it was widely adopted.

We wanted to move fast, so we laid down some rules. We stressed that the first pass would only be a visual refresh — no new functionality. We wanted to repaint our house, not build an addition. If teams were adding new features while rebuilding their products, we’d drag out the timeline indefinitely.