The product management of a design system

One of the most rewarding experiences I’ve had during my time as a Product Manager at Autodesk has been in building out and deploying a design system. A few years ago, it was becoming really cool for companies generally and software products specifically to create and publish design systems that catalogued atomic parts of interfaces and defined or otherwise described how they should function. We had a decade-or-so-old product with some questionable UI interactions, dated visuals, and a complete lack of consistency. What we needed was a design system.

Many, many excellent articles have been written about how to both design and make design systems, so I’m not going to be able to add much there; what I do want to say is that mostly what made it difficult was the constant looming threat of opportunity cost.

From the day I was brought onto the “UI Components” cross-functional team, it became clear that the main struggle (in large part thanks to an extremely competent team) would be minimising distractions for the designers and engineers. What we were doing was both worthwhile and valuable to the future of the product, but what it wasn’t going to do was solve problems overnight.

Part of the issue was that replacing any of the existing UI would, in the short term, create (more of) a visual discrepancy. Due to the nature of the legacy codebase, there was no real opportunity to systematically swap out buttons throughout the interface. We’d have to make a decision to specifically commit resources to updating the buttons and then grit our teeth and get on with it. And that would leave us in a scenario where we’d have incongruous buttons on a dated interface.

This was before we’d started making a habit of writing formal product briefs, so rather than define what we were going to do in a formal way, we approached this in more of an ad-hoc manner. What did we need to do? What do we have already? What else is happening that might help or hinder the process.

What we did have was the foundations of a visual design. At Autodesk, there were many different products from different origins, and this meant there were several different design systems in use. A project to unify them all across the company was underway (probably worthy of a story in its own right), and while it wasn’t mature enough for us to adopt it immediately, we were able to use it as a basis.

The other thing we had was a decision about technology. The company was investing in React as its front-end technology of choice, so that was where we started. This allowed us to define a tighter scope- the design system would only support React-based experiences. From there it was easy to make decisions like adopting Storybook to help build and test components in isolation, and deciding on full test coverage– an early principle we decided on was that it was more important for components to be robust than to have more features.

The other thing that helped was that there was a new product one of the Shotgun teams was building, a desktop app (“Shotgun Create”) with a React front-end. This gave us a unique opportunity to define our internal roadmap in a way that would support that team, and the by-products would be useful to other teams from that point on. So we set to work, identifying which components would be most useful and most urgent, and prioritising those.

The thing about design systems is that it’s great when you already have one and can reap the benefits. Building a button is an upfront investment of resources, but one that can be amortised over a long period of time as the number of places that use it increases. The hard part though is having to justify the high cost of building the button in a systemised way in the first place.

Initially, we talked about the work we were doing in terms of the obvious design system benefits: faster development and design time. However, it was clear that those benefits were not actually being realised at the time we were talking about them; in fact if anything it was slowing people down as they had to adjust to new ways of working, as opposed to just being able to slap in some off-the-shelf code and move on. Because the design system was new, updates would often include breaking changes, and that created more work for consumers. Documentation helped, but also increased the resource cost, thereby creating a negative feedback loop. We had to find a way to talk about the progress we were making and how we were increasing utility of the design system in ways that made sense in the short term.

Instead of talking about saving time, we emphasised the robustness aspects of the components we were building. Instead of rushing to meet a deadline to deliver a working component, we instead allowed consumers of the design system to use whatever they had to hand, so that they weren’t blocked. Then we would dedicate time in helping them swap out their placeholder component for the design system version, once it was ready.

Eventually the Shotgun Create MVP launched, using all 14 (at the time) components from the design system. One possible path forward was to continue working with the Create team to build out additional components, but it felt like there would be diminishing returns in terms of the potential to reuse those components elsewhere.

One of the trade-offs to balance is in how comprehensive to make a design system. If a design system only supports a single product, or if it is being built in advance of shipping products that actively need it, there’s perhaps no disadvantage in making it contain all the components the product(s) need. But for us, it helped to try and clearly identify components that would be reused elsewhere and prioritise those. To that end, although the Create application didn’t initially need a combo box (for example) anywhere, other products were desperate for one, and so that became a factor.

With Create out in customers’ hands, we faced a new problem. Using React as a front-end technology had been validated, but we were short of engineers that were skilled in React; that is, except on our UI Components team. A decision was made to take that expertise and distribute it across as many of the other teams as possible– there would no longer be a dedicated design system team, but everyone would be responsible for using and adding to it, and the original team would form part of a “guild” to help maintain and provide guidance on its development.

This change allowed us to turn our attention back to the core Shotgun app. We now had the beginnings of a design system, but also a legacy application that was not leveraging it in any meaningful way. Worse, any new experiences built in React that could potentially leverage the design system might avoid doing so or else risk mixing different visual designs. It was easy to foresee that this could lead to development teams looking at the design system and making a collective shrug as they instead just built components haphazardly in a way that was familiar and fitted the current aesthetic.

So we had a problem, and needed to find a solution. Swapping out things piecemeal was an option, but would be arduous. Developer Philip Blyth on the team had done a hackathon previously that did a blanket overhaul of the CSS for the core web product, but the output wasn’t consumable in its current state.

We identified the following options, each with their own risk and effort:

• Replace everything with design system equivalents
• Just update a singular aspect such as colour or typography at a time
• Something in-between

We decided to experiment. We devoted a week of time for one of our engineers to pair up with a designer and try to make sweeping changes that worked well without being too much effort. One of the most impactful changes was in reducing the former colour palette to just those from the design system.

It was promising, and we were able to get leadership support to move forward. Much of the work from that point on was in defining the scope, and doing risk assessment. We knew we would be better off trying to ship as much of the change as possible in a single update (this would help with marketing efforts, among other considerations) and that we would need a way to easily roll-back all those changes if needed.

One of the principles we had was to favour “breadth over depth”. Essentially we’d aim for as much coverage as possible and defer the long tail of specific little details for later (two other principles were “courage over caution” and “move quickly over addressing technical debt”). In spite of the planning and limited scope, it was still a big project and we had to pull in additional developers as we headed towards the finish line.

The other issue we had to consider was customer perception. We knew that user backlash would be a big deal. Even an objectively “better” interface would be felt as short-term pain for users who had built up muscle memory from using the product for many years, some of whom would view this as a “pointless” change. So we looked for a short-term benefit we could provide and use to effectively help “sell” the change. Fortunately, it didn’t take long to find one.

One of the things the design system did was move everything, from fonts to colours, to a set of variables. It had also been architected in such a way (by the truly visionary Beau Roberts) that those variables could be defined in bulk, or to put it another way, that the entire interface could be easily themed. Taking that, and pairing it with a long-standing customer request, we had our selling point– the update would introduce a dark mode to the application (something interesting to note here was that the dark mode palette already existed because that was the only option available in Create, so we had actually added the light scheme later to complement it).

Today, everyone on the team uses (and where possible, contributes to) the design system, which has continued to flourish and improve, and delivers on the promise of design systems generally- saving time for designers and developers, promoting consistency, and enhancing usability for end-users.