So you’ve built a design system, what now?

Part 1: Iterating, embedding, and growing after launch.

Much has been written about how and why to stand up a design system for your software product development organization: the technical and strategic decisions, how to establish it as a discrete cost center, get buy-in, audit and solicit ideas from the team of designers and developers you intend to support.

This is not another one of those articles. I’ve spent the last year managing the UX design efforts for Forge, our design system at athenahealth. I joined about 3 months after Forge went live, so this is about how the game changes after your design system launches and reaches a level of maturity that it at least becomes a known quantity within your org. Like all products, some of your customers (people within your org) will have favorable impressions, others less so. My intention here is to share my experience of how the work of maintaining and evolving a design system changes once it’s out in the wild.

Here are some of the things I’ve learned:

Without consistent outreach, it’s easy to get stuck in the ivory tower trap

There’s no question that there’s a phase of work in designing and building a design system that requires real heads-down work and the making of difficult trade-off decisions. What technology stack should the design system be built on? What governing body will decide what makes it into the design system into the future? How often will you release updates? There are a thousand decisions, big and small, that will need to be made. The optics of this, especially at a large org, can sometimes be a problem. Almost everyone has an opinion about the tools that they need to use to do their jobs. If the perception is that there’s “some team, somewhere” who are making all of the decisions on behalf of designers and developers who are shipping product, that can be a problem.

Our design system’s team has a couple of recurring office hours, but that’s not nearly enough to address and head off concerns that the decisions that went into creating the core of the design system were somehow arbitrary. Office hours are okay, but a consistent communication strategy of sharing out work, soliciting feedback and input, and engaging with the people using the system every day is critical in ensuring that it stays relevant.

How to head this off:

• Engage with your users. At athenahealth we’re lucky to have teams and tools for measuring engagement, and so we were able to perform an opportunity identification analysis on our users. It’s not as clinical as it sounds. Through a series of interviews with designers and developers at various levels of experience, seniority, and geographies, we were able to identify our biggest opportunities to address the unmet needs of our users.
• One on ones are a great way to get informal, anecdotal feedback on what’s working and what’s not working with your design system. They have the additional benefit of creating backchannels between teams: something incredibly useful in a large org with layers of hierarchy.
• Office hours should be an opportunity to show off work or concepts that are in development and get design feedback about how the components are being used. Special care should be taken to address the power dynamics in these situations. On the one hand, the designers responsible for creating the components within the design system have a very clear idea of how they intended for those components to be put to use. On the other hand, they lack much of the product-specific context of how integrating those components will effect users. These sessions should feel like partnerships, with designers from each team being receptive to new ways of interpretation and implementation of the core components. Creating an environment where experimentation is encouraged and celebrated is crucial.

Contributions can be double-edged

There’s a story about design systems that gets told that goes something like this. “Yes, we’re investing a lot of time and money in a dedicated design system team to build this component library up front, but within X months the various product teams will be contributing back and able to share code across products”. In a world where budgets are finite and spend on design and development resources is scrutinized, it can sound very attractive. Who wouldn’t want a self-sustaining ecosystem of community-supported code and design libraries, documentation and guidance?

The problem here is that different teams have different priorities. Given the constraints of budget and release deadlines, the mantra of many agile product teams (for good reason) is that “perfect is the enemy of the good”. While product teams are responsible for delivering production-level code, they are not required to make sure that the components that they build will be robust and useful for others — rather they simply need to work just well enough for them. Compare this to the mandate of a design system team: to provide components and documentation that can be used by other teams, ensure everything adheres to accessibility guidelines, design components that sit comfortably within the rest of the system. The gap in desired outcomes between the components that a dedicated design system team builds and those that a product team builds is often understandably large. In fact, we’ve found that in many cases the amount of work that our design systems team would need to do in order to accept a contribution would be a heavier lift than just building the component from scratch themselves.

Things you might want to pay more attention to:

• Being explicit about which components are immature contributions that might not tick all the expected boxes (we label them “extensions”), and what are true core components that have been built or ingested by the design system team. Our design system team is transparent about the robustness of their Definition of Done (DoD), which has been helpful.
• Encouraging teams that are building components to go the extra mile and build robust components — pitching it as an opportunity to learn and giving reward and recognition to teams that put in the time to create a true “public good”.
• Balancing design system team resourcing between the outright building of new components (as requested by product teams), ingestion and clean up of extensions, and helping teams to build robust components themselves.

It will never be all things to all people

Most design systems now follow an atomic convention, and with good reason. While picking primitives like color, type, iconography can be controversial in the initial stages of design system development, they serve as the foundation for the decisions that follow. As elements come together in more complex patterns, those patterns and templates will be almost by definition more specialized. New controls may be required in order for teams to realize their visions. Inevitably, we hear that specific components aren’t a perfect fit for a team’s use case or that we lack the exact component they need. Managing these situations requires ensuring you are setting the right expectations about what the design system is and is not by design.

Give designers time to practice

Constraints are an important part of any design undertaking. For designers working on legacy enterprise applications, those constraints can be a challenge to navigate. It’s true that making the decision to adopt the design system adds another constraint, but a unique one. It is the constraint of relinquishing control over the minutiae in order to focus on a broader experience.

But not all designers will know what to do with their new libraries, or even how to design within the system, and that’s okay!

How we’ve done this:

• Providing the space, both physical and mental, for designers to work through their own challenges, see how others are working, and ask questions about how to use components or even why they were designed the way they are can be incredibly useful. At a large org, it provides an opportunity for designers across products to get fresh perspectives on their work and maybe pick up a trick or two.

Pick your battles

To open source or not to open source? What’s the right balance between a feature for a specific business unit and skeleton states? At some level these conversations will turn political in a large organization, so bear in mind who to keep sweet and where to marshal your energies.

What’s worked for us:

• Creating allies within various product organizations is a great way to understand some of the tactical challenges that can hamper adoption. Find out who’s excited about design systems generally, what they think are the biggest obstacles and challenges, and share your own priorities and concerns.
• Listening to the people. Rolling out new products, or even old products that have been reimagined (or even simply reskinned) will inevitably upset some users. A lot of the time, those complaints die down after a while, but others can persist. It’s crucial to address those, and if the design system can flex and adapt to address those issues, everyone wins.

We’re all in this together

Getting a design system up and running at a large org is a huge amount of work. But equally important is the time and care that goes in to ensure that it’s working as it needs to. Beyond simply listening to the needs, challenges, and goals of those who use it, convincing your colleagues of your collective responsibility for making and maintaining the design system great can be hard work, especially in a big organization. It can feel like a long game at times, but it leads to good things.

Want to hear more? Check out part two!