Navigating the DesignOps Wilderness

The topography of initiatives a Design Operations team encounters is incredibly varied. They may spend one week traversing a large cross-functional program, the next digging into an ad hoc software request, and the following navigating an unanticipated re-org. Add to that the challenges of effective change management, ongoing upkeep, and limited resources… well, it can be disorienting at times.

In this article, we’ll walk through practical strategies to chart your course: how to identify your team’s needs, prioritize opportunities, and distill a focused (yet flexible!) DesignOps roadmap. Additionally, we’ll cover how to bring partners along for the journey and build the trust you’ll need to drive meaningful change.

Forming a Lay-of-the-Land

Whether you’re in an established Design Operations function or starting your first 30 days as a team of one, your job is to listen and to learn before introducing change. In order to identify and prioritize opportunities for a DesignOps roadmap, you first need to understand the current state of the UX org: what are the pain-points, cross-functional gaps, and other team needs that DesignOps can meaningfully address?

A variety of methods are available to go about this. A common approach if you are a new DesignOps leader is an interview-based listening tour (sometimes called a discovery tour). For a great primer on listening tours, see Adam Fry-Pierce and Salomé Mortazavi’s discussion The first 90 Days of the Head of DesignOps and Tova Soroka’s Listening Tour Playbook. Other supplemental methods may include leadership workshops, pulse surveys, retros, and more.

Method is less important than intent and outcome: seek to understand prior to introducing change, and cultivate relationships with the ICs, managers, and cross-functional partners who will inform and adopt the processes and programs your team introduces.

Whichever approach you take, your next step is to synthesize learnings and document a Lay-of-the-Land, a current state audit, and an assessment of DesignOps focus areas. This document is a living, collaborative artifact that partners UX and cross-functional leads. We break it down by People, Process, Systems, and Cross-functional initiatives — but align your Lay-of-the-Land with the model you use to discuss DesignOps within your org.

Example: Lay-of-the-Land document capturing People related focus areas

For each area of focus, document:

1. What is the current state?
   Nonexistent? Exists but needs improvement? Going well?
   
   

2. What resources & documentation already exist?
   Leverage your UX and cross-functional leads to gather and consolidate links you may not be aware of.
   
   

3. What feedback & themes have you identified?
   Synthesize learnings and opportunities from your interviews, workshops, etc. Capture open questions and get input from your primary leadership partners.

Charting your course

Once you’ve captured a Lay-of-the-Land, your next step is to identify, scope, and prioritize the right initiatives for your roadmap. You’ll have top-down and bottom-up approaches to consider in tandem:

Defining DesignOps OKRs (top-down)

If your org has company-level Objectives and Key Results (OKRs) or your UX team has function-level OKRs, how can you define DesignOps OKRs that roll-up in support of them? If these higher-level OKRs do not exist, define OKRs to support your DesignOps mission statement. Documenting objectives and measurable outcomes helps you select and prioritize the right initiatives to support them. For bonus points, further connect DesignOps OKRs to individual growth and performance goals!

For more info on crafting OKRs, see Aviram (Avi) Vijh : Reimagining OKRs for designers and design teams & Camille Fournier : OKRs are Hard

Mapping impact & effort (bottom-up)

Work with your team to translate your Lay-of-the-Land into potential initiatives, based on the current state and feedback. Then, in a collaborative workshop with UX leadership, plot these initiatives on Impact x Effort grids (or your preferred framework). Once the participants reach a consensus on Impact x Effort placement, provide an opportunity to dot-vote or rank the initiatives.

Example: Mapping Impact x Effort — People initiatives

Next, triangulate initiatives to include on your roadmap using your DesignOps OKRs, Impact x Effort mapping, and bandwidth considerations. Some tips and recommendations:

• Identify your P1 initiatives: These are your critical, high-priority items for your team to be successful, and will demand your primary attention. Define these clearly as your must-haves upfront.

• Look for quick wins: Not everything should be a big new program or process. Identify low-effort and med-high impact initiatives; if you are a new DesignOps leader these are your best allies in driving change and building trust (more on this later).
  
  

• Review with partners: DesignOps relies on working groups, cross-functional partners, and internal end-users to inform the best solutions possible. Discuss initiatives early with partners to ensure they will have the bandwidth to help.
  
  

• Create a backlog: Don’t lose track of what does not “make the cut” for the roadmap! Create a simple backlog of all initiatives to revisit during future roadmapping sessions. Even better, map Now/Next/Later to meet your OKRs. Want a great breakdown of this approach?
  
  Visit Peter Boersma’s How to Define and Maintain a DesignOps Roadmap.

  Creating your Roadmap
  
  

  After identifying and prioritizing initiatives for the roadmap, you’re ready to put it together!
  Below are some practical tips to help you structure your actual roadmap artifact:

  
  

• Leave a 10–20% buffer: Over time, DesignOps accumulates a growing list of “Keeping the Lights On” work — facilitating rituals, maintaining documentation, repeated processes (i.e. helping with onboarding), etc. Account for this work and represent it in your roadmap!
  
  

• Feasible but flexible: Roadmaps should be feasible — as a leader, it’s your job to represent a scope of work that your team can accomplish. That said, DesignOps as a function should flex the roadmap as reactive needs arise. Let’s say your company makes an acquisition and is merging UX teams — you can bet that’s taking priority.
  
  

• Align roadmap + OKRs: Bucket work streams on the Y-axis of your roadmap by your aforementioned DesignOps OKRs. Now your roadmap has explicit built-in intent — “By executing on ABC initiatives, we move towards accomplishing XYZ Objective and Key Results.”
  
  

  

  
  Example — aligning roadmap initiatives with OKRs. Leverage this Figjam template as a starting point.
  
  

Socializing your roadmap

Now that you’ve got the DesignOps roadmap identified, don’t underestimate the importance of sharing it. If possible, socialize your roadmap in a meeting or presentation setting with your UX team; we target twice a year (although the roadmap is updated more frequently). Let’s highlight how to make the most of this time:

• Educate & evangelize: Use a small portion of this time to introduce or reiterate the DesignOps function — What is DesignOps? Why is it valuable? How does it differ from other ops teams? Who is on the team? What is your vision & mission? Are there key wins to highlight from the previous period? Even if you aren’t a new function, new folks unfamiliar with the term “Design operations” may join.
  
  

• Validate everyone’s time: Socializing the roadmap provides a feedback loop to those involved in your listening tour, workshops, etc. They’ve shared their insights and pain points, now you are outlining how and when these challenges will be addressed.
  
  

• Help folks get involved: Include a call-to-action in your presentation. How can folks get involved in a working group? Who should they reach out to? Many DesignOps initiatives provide a great opportunity for ICs to act on their individual goals — for example, if you are formalizing a mentorship program, might there be some senior designers who want to help formalize and pilot it?

Cater your roadmap walkthrough to your audience and respect their time. No need to get into the granular details of each initiative; communicate your team’s objectives and visually tie roadmap initiatives to each objective:

Example — Contextualizing your roadmap initiatives in relation to the objective they support

Your goal here is to craft a compelling and concise narrative:

The mission of the DesignOps team here is [X].
In the first-half, we accomplished [Y], and in the second-half
our objectives are [Z]. We have [A][B][C] initiatives planned to meet each objective. Here’s how to get involved!

Charging your Trust Battery

Illustration via Midjourney

So you’ve shared your roadmap, what’s next? If you are new to the org or DesignOps is a newly formed function, building trust before executing larger roadmap initiatives is critical. A handy metaphor comes from Shopify’s Tobias Lütke in the form of a “trust battery” — expanded on here by Sarah Walsh. A trust battery signifies the level of trust we’ve built up with someone or some team.

As a function that deals with a whole lot of change management, DesignOps gains plenty from charging their trust battery: a UX team more willing to try out and adopt new processes, cross-functional partners more willing to collaborate, etc. With the roadmap established, let’s highlight a few ways you can supercharge your DesignOps trust battery:

• Good news: You’ve already started! Conducting a listening tour, getting input on the Lay-of-the-Land, and socializing your roadmap are very transparent and inclusive practices that build trust.
  
  

• Low-hanging fruit: Are there low-effort wins your team can knock out that provide immediate value? Maybe something as simple as removing a ritual nobody feels is worthwhile, or centralizing key resources that were previously scattered. You don’t have to wait for a finalized roadmap to get started. These small wins add up for your trust battery — especially for new DesignOps leaders!
  
  

• Working groups, guilds, and communities of practice: Charge your trust battery by partnering with your end-users and subject matter experts. There are lots of labels and formats for this approach, but ultimately the goal here is to bring your partners along for the journey, often resulting in co-creation or ownership of the solution. Form working groups and advocates for your roadmap initiatives — and enable others to champion solutions for the team! DesignOps does not need to “own” everything — flex your role to a partner, facilitator, or consult when appropriate.
  
  

• Trojan Mice: For an overview of a Trojan Mice approach within DesignOps, watch Aletheia Delivre’s fantastic breakdown from Driving change with design systems and process. The basic premise is identifying safe-to-fail experiments and starting small, rather than tackling massive, all-encompassing initiatives. Doing so helps your DesignOps team gather data quickly on what does and doesn’t work, while driving meaningful change over time. Starting small is equally beneficial towards charging your trust battery — you get others involved earlier, demonstrate iteration to address their feedback, and lower the complexity of adoption.

Let’s look at an example of starting small: My DesignOps team was faced with the challenge of helping designers share work-in-progress across the whole UX team, to break down feature team silos and facilitate follow-up discussions where appropriate. Instead of developing a large new program or adding more meetings, we experimented using the last 15–20 minutes of our monthly UX Townhall for a “Rapid Fire” work in progress share. On a rotating group cadence, designers, researchers, and other UX functions presented their current work-in-progress in a 2–3 minute single slide presentation: a screenshot or gif, a few bullet points, and related links. The quick and simple format was enough to kickstart the right follow-up discussions amongst the team. After a couple of presentations, our Rapid Fire WIP Share became a huge hit!

Closing Thoughts

With these strategies in mind, hopefully the DesignOps wilderness is a little less daunting. Every organization is different, so flex these approaches as needed to support your team. Don’t forget: there are lots of DesignOps pioneers exploring the same problem spaces, so leverage the wonderful community (DesignOps Assembly) alongside your journey!