Making a Case for Design Ops

Many of us have used the following mantras, or something similar:

“We need to build experiences in the medium they are destined for.”

“Design systems do not exist unless they are in code.”

The groundswell behind design systems is more proof that the industry needs to improve the tools and practices, allowing for better management of the digital experiences we build. However, there’s still a lot of unsettled philosophical baggage about how design systems are managed, run, contributed to, and fundamentally owned.

This ambiguity leads us to the classic debate — who is ultimately responsible for the overall experience of a user?

Do designers have the last word about what shapes a user experience? Is it right to demand “pixel perfection”? Should front-end developers be empowered to make their own design choices that address core experiences for digital applications? Consideration for edge cases?

Design systems add another dimension to this ongoing challenge. As our industry makes the transition from pages to components and from comps to prototypes, designers are adopting better technical skills and tools. At the same time, front-end developers are asserting more control over the fidelity of an experience. On top of all this, the web is still evolving in standards and capabilities, JavaScript frameworks being a prime example.

So, who owns the definition of a good user experience?

Design is facing a headwind. Organizing Sketch assets into component libraries, creating true (code-like) revisions of designs, and improving support for universal design tokens doesn’t change the reality that users don’t consume apps via Sketch.

The gap between what designers use to create experiences and the browsers and devices that users actually use to consume those experiences, is felt more now than ever before. Tools that can bridge this gap are both rare and woefully inadequate (sure, Sketch uses JSON, but have you ever tried to create a usable Sketch file with ReactJS?). There are a lot of jokes about how serious designers and developers left the days of Macromedia Dreamweaver behind for a reason. However, the need for tools that empower designers, but can bridge the gap between design and code is still very real.

The pain for the user is real, too. A designer can hand a great comp to four different developers, and, regardless of how that comp was created, could receive four different results from those developers. That’s a bad experience for everyone and it creates a lot of time spent batting comps back and forth, to solve fidelity issues around small, but important design details. Eventually, the friction becomes untenable and front-end developers simply forge ahead to meet a goal, or worse, create fragmentations in the experience.

Recently, front-end development has found itself in the driver seat. A revolution in new front-end capabilities through modern frameworks combined with better practices grounded in sound software principles, have brought about amazing changes. Static site generation, TypeScript, WebAssembly, GraphQL and dozens of other pieces of tech have given the front-end a huge amount of flexibility and choice. With that, the need to see an experience in an environment the same way an end user sees it — via a browser or a screen — has become paramount.

However, the industry has forged ahead while somewhat ignoring the important role that design and UX play in the creation of these experiences. Amazing tools have become available to help front-end developers build things better, but are they really better for users if designers aren’t involved?

Further, the movement toward systemizing front-end experiences has created a lot of “samey-ness” around site experiences. Vox struggled with this during many of the early iterations of their design system (learn more by viewing Yesenia Perez-Cruz’s presentation at An Event Apart), and it’s not really a new problem (I clearly remember the days when you could play “guess this CMS”). Introduction of new systems creates rules that might be inflexible or lead to uninspired experiences in favor of scale and savings. Worse still, diminishing the role of design might mean that great ideas are being fed into the process, but not making the intended impact.

Design Ops is a great tool for attacking this problem.

I’ve been thinking a lot about how to apply Design Ops more broadly to the development of digital products, which is probably a whole series by itself. However, for now, it is important to think about how design teams can work within these new tools and philosophies to scale themselves better. Having design meet development in a common set of tools with a shared understanding of pacing, needs, and objectives allows design to influence development in the same ways that these new tools have changed the role of front-end developers. Good design ops focuses on four key things:

1. Work with open systems that allow you to easily connect to one another. This is a hard problem that is by no means solved. The “single source of truth” is still elusive, but the role of design ops is creating designs that can be broadly, and easily, shared with a lot of different teams working on many different products.
2. Favor simple solutions and processes that emphasize reuse instead of repetition. Design can be really inefficient — creating and updating sticker sheets, building comps for every breakpoint and device, creating pixel-perfect pictures of screens that are doomed to an archive of obscurity after a product launch, etc. Design ops change the focus to be on what is actually most useful to the design process. It looks to create abstractions and rules to automate or imply a lot of design choices, and it only looks to document the parts of design that have real intent and impact.
3. Match your cadence to the people building the final product. Developers have clear design needs at regular, and largely, predicable intervals in a project. In turn, dev teams need to show the results of their work to designers at intervals that make sense to them. Few things are more frustrating to a designer than seeing the finished experience months after they sent over comps, and it really limits the ability to give actionable feedback.
4. Utilize tools that integrate with the way your company (and your dev team) want to work. Get a Slack channel with both developers and designers in it. Create a system where devs and designers document things in the same place. Fill it full of information about your purpose and principles, but also your coding standards and data structures. Build little tools that help people collaborate. Look for things with APIs that you can extend in interesting ways. Put up a public website that showcases the awesome ways you’re collaborating. Name it something that isn’t “My Company’s Design System”, and then talk about it with anyone that will listen.

The best part is — Design Ops is still in its infancy. Most of what’s to come is still nascent, and I bet we’re going to see an explosion of tools and ideas in this space over the coming years.