Scaling the DesignOps Summit

John Calhoun
Salesforce Designer
6 min readJan 23, 2019

Reflections on a UX conference dedicated to … Operations?

Last November, a small group from our Salesforce UX Operations team traveled to New York City to attend the 2018 DesignOps Summit. The purpose of this conference was to bring design leaders, program managers, and starry-eyed lovers of spreadsheets together in one place, to discuss the challenges of scaling and managing Design Operations. But there was just one catch …

DesignOps Summit, I know you’re here … somewhere.

What the heck is Design Operations, anyway? At Salesforce, we have a UX Operations team dedicated to helping our 250+ designers, researchers, and engineers “make work awesome, and make awesome work.” That’s our motto; it fits because Salesforce’s product is enterprise software — “work software” — and we want our UX teams, and our users, to say that the product is awesome. It’s UX Operations’ responsibility to cultivate the conditions that make work awesome (discovery and research time, clear prioritization of work, user advocacy etc.), and define the process and rhythms to do awesome work at scale (backlog maintenance, standardizing workflows, constant communication, etc.).

After two days, it’s clear that Design Ops and UX Ops are basically the same thing, with the slight exception that our Salesforce UX Ops team supports not just designers, but researchers and engineers, too. We had a wonderful time networking and learning at the conference, and I wanted to share a few takeaways for those of us who live at the intersection of Sketch and JIRA.

A Beginner’s Mind

Among the 700 or so attendees, there was an overwhelming sense of newness to the Design and UX Ops role. Makes sense: user experience itself is a rapidly evolving profession. Its specializations and swim lanes are still being defined, even as more and more people enter the field.

I appreciated that none of the speakers or attendees pretended they had a silver bullet to make a design team operate better. Rather, there was a sense that the right thing was to let processes emerge organically, to be human first, and to be willing to experiment and adapt a variety of best practices to ascertain what is truly “best.” The challenge for UX Ops, then, is to balance this flexibility of process with the rigid demands of designing software that must be shipped (and tested, and adopted, and improved …). Perhaps that is why half the attendees came from a traditional operations background, and half from a design background: We have to draw solutions from both worlds, and acknowledge that we will be starting from scratch for years and years to come.

Oh, if this is all sounding a bit like a Zen koan, I should point out that Bruce Lee was the most oft-quoted philosopher of the conference.

The man, the myth, the inspiration for nearly every DesignOps Summit speaker.

The Design Operations Menu

One of my favorite talks came early, from Brennan Hartich, Design Ops leader at Intuit. He talked about how to communicate the value of Design and UX Operations, and outlined his “six-item menu” of services and offerings that he roadshows with his partners. Without further ado, the menu:

Now, I’m somewhat new to the Operations world, and I would say I can clearly articulate my team’s day-to-day functions. But this was the first time I’d seen our roles and responsibilities so neatly and succinctly defined — and summarized in a 2x3 matrix with bullet points! My sorting-and-organizing neurons lit up when I saw this; and I want to work it into our UX Producers’ Charter and do a similar roadshow promotion in the new year.

There were some interesting statistics from Brennan’s own team, showing that a dedicated Design Operations person can be a literal force multiplier in a Design or UX organization. (How? A single Ops person dedicated to organizing, prioritizing, and simplifying means multiple designers and researchers can spend less time hunting, wondering, and restarting.) Here at Salesforce, we’d already adopted practices to measure and scope work consistently across teams; having been inspired by Brenna’s story, we’re going to tune our own metrics to (hopefully) measure our own increases in efficiency.

Bonus: The Research Operations Menu

Let’s be honest — it’s really, really hard to have good design without good research. At Salesforce UX, “User Experience” is an umbrella term that captures both, but that’s not true at all companies. That’s why a full quarter of the conference was dedicated to Research Ops, and the methods this role can employ to bring the powers of efficiency to research teams, large and small.

I promise this is a conference journal, not a restaurant review, but I wanted to share another menu presented by Megan Blocker, a senior research manager at McKinsey & Co. Without the benefit of a cool infographic, the six operational areas of Research Ops are:

  1. Philosophy and Practice
  2. Tools and Infrastructure
  3. Insights and Strategy
  4. Advocacy and Outreach
  5. User Engagement
  6. Participant Management

For me, the similarities (and overlaps) between the Design and Research Ops menus showed me where our own Ops team is excelling, and where we have room to grow. It also proved the value of the beginner’s mind approach to operations: design and research are dance partners, and there are some steps they should follow together, and some steps that will be unique. Allowing both functions to flourish, standardize, and differentiate as needed is the key to harmonious results.

A typical day for Design Ops and Research Ops teams, always in perfect harmony.

The Tipping Point

One of the unspoken themes of the conference was design or research teams hitting a tipping point, where the way things had been done before could no longer work. Whatever the triggering factor, this tipping point was usually when the need for a dedicated Design Ops person was realized. Dan Willis, a speaker and consultant with the U.S. Digital Service, put it bluntly:

“I’ve seen scale, and you can’t do it without Design Ops.”

We don’t all have to operate on the scale of government to appreciate that user experience is hitting a tipping point. When I talked to attendees representing organizations from big banks to small bakeries, the same theme emerged: good UX is no longer a differentiator — good UX is table stakes that users demand. If they don’t get it, they’ll take their business elsewhere. Recognizing this, UX teams everywhere are growing. And having a dedicated UX Operations role — one focused squarely on navigating the challenges of UX scale and growth — will become all the more valuable in the future.

Know when you’ve hit the tipping point, and hire accordingly. (Image: Luc Galoppin via Flickr)

That’s a Wrap!

So what were my takeaways? First, re-watch Enter the Dragon. Second, I want to work some of the clarity and language presented in the two-day summit back into my team’s charter, and promote our team’s services in a simpler, more customer-service-oriented way. It’s not enough to say, “I’m from UX Ops and I’m here to help,” and then go do stuff. We have to be advocates of our own value, and apply our services in a way that complements and reflects the needs of each individual product UX team. I want make sure our UX Ops team thinks globally about some truly cross-functional areas, namely process design, onboarding, and communications. Lastly, we’re (no doubt) going to continue to say “scale” a lot, but I want to make sure we’re achieving scale alongside the equally important measures of quality, efficiency, and happiness. Ultimately, UX Ops is all about making work awesome, and making awesome work!

I’m looking forward to future iterations of the DesignOps Summit, and look forward to hearing your thoughts in the comments below.

Follow us at @SalesforceUX.
Want to work with us? Contact
uxcareers@salesforce.com
Check out the
Salesforce Lightning Design System

--

--