DesignOps Zeitgeist 2023

Meet the Moment, a call to action by Jon Fukuda

Note: In this article, the word “design” will mean:

  • Research and design
  • Human-centered-design
  • UX/CX/Service design
  • User-centered-design

This supports the perspective that these disciplines are all after the same truth – to make products, services, features, and functions better. “Better” is up to your interpretation (for the user, business, customer, OKRs, KPIs, etc.); we aim to improve it.

The design lie.

For the better part of two decades, the market has proven that sound research and design-led product teams win in the market. Over the past five years, there’s been a focal shift in design leadership to support scalable models to better integrate research and design into existing continuous development frameworks.

Before talking about the “lie,” we must acknowledge how far the conversation of design operations has come. Today, there are established communities and conferences to give this form of design leadership a loud and influential voice. Organizations have allocated funding to establish research and design operations functions to support their integration across various maturity levels. These advancements are a significant victory on the road to becoming an integrated design org.

Based on achievements shared at the 2022 Rosenfeld Media DesignOps Summit, it’s clear that bearing the value of more deeply integrated research and design takes dedicated focus, leadership, and clarity. Noteworthy accomplishments in the field of DesignOps highlighted at the summit include:

  • establishing career scaffolding for the design organization, complete with learning and development frameworks
  • onboarding into design orgs, product teams, pods, or squads
  • implementing design systems or insight repositories complete with operating models for utilization and governance
  • integrating and automating systems and workflows for research and design management
  • introducing culture design methods for better integrating research and design practices
  • growing more specialized and diverse DesignOps teams to support the growth and integration of design in the organization

While there are many more achievements to cover, these are huge victories by any standard. They illustrate that DesignOps has not only built more stable, scalable models to integrate research and design practices but also provides scaffolding to deeply integrate these practices into the fabric of how organizations think and behave as better human-centered businesses.

From where the industry was five years ago, it would have been okay to say this is enough, but it’s not. So here’s the lie –“Big tech organizations understand the value of integrated research and design operations to support product development and business innovation.”  

While some orgs may know and believe this and even have operational behavior that supports this, the depth of understanding is the actual lie.

Over the past several weeks, big tech organizations have had a staggering number of layoffs. It’s hard not to notice how many individual contributors to research and design operations leadership were laid off. 

Sidenote: If you are one of the affected by recent rounds of layoffs please take the time to add your information to this growing roster of DesignOps talent – created and hosted by the DesignOps Assembly.  This document has been shared far and wide for maximum reach.

Maybe the promise of DesignOps’ potential and success isn’t a deliberate lie; maybe the vision is strong enough to generate a mirage. But it has yet to be realized. So, let’s talk about what’s real.

The argument.

Revenue directly reflects the market’s (read consumer’s) needs and desires. On some level, every digital transaction serves a level of Maslow’s hierarchy of needs. As we trudge evermore into the metaverse of our digital lives, the spectrum of needs and desires rely even more on digital products and services. 

“Here’s the lie – Big tech organizations understand the value of integrated research and design operations to support product development and business innovation.” 

Here’s the myth we all like to believe – that these digital product and service businesses are:

  • listening to the needs of their audience (users, customers, employees, and other stakeholders)
  • crafting experiences that drive and cater to behavioral bias (conscious or unconscious) to satisfy needs and desires
  • incrementally deploying, low-stakes/low-risk, and tested designs and patterns with actual end users with integrated A/B testing frameworks in ways that don’t break entire experiences or full-blown systems of stability(eh-hem, Elon)
  • deeply integrating insights, tested experience patterns, designs and models, and sound experience delivery practices
  • thriving on repeatable processes, scalable infrastructures, and cross-functional leadership

And they might be, but if there’s one thing that’s true about the state of DesignOps, as Dave Malouf has said more than once, “the future is now; it’s just not evenly distributed.” This statement is probably the only capital T-truth about DesignOps. All other aspects are only true for the fortunate design-led organizations that value how DesignOps is shaping the conditions for innovation and resilient product and service strategies to take hold in organizational business culture. For most of us, roughly 80+% of businesses, there are far lower levels of maturity, not in the intention of DesignOps managers, but in the cultural readiness for their organizations to embrace the value that design integration can deliver.

As we learned from the 2022 State of DesignOps report issued by the DesignOps Assembly, some digital teams exclusively think of Design Systems when they hear DesignOps, nevermind Insight Repositories and any of the process integration infrastructure to build and support the design org. The issue is the need for a unified definition of DesignOps, and a concise articulation of the value DesignOps has to offer organizations at large. We can tell you the value of various DesignOps initiatives and actions, but business owners aren’t stepping out to say, “We need DesignOps because….” The ones who have, are leaning on design leadership within their organization. This is a common problem, but not one that hasn’t been talked about or addressed. (Thank you, Patrizia Bertini– https://get.uxpin.com/measuring-designops-impact/.

“Some digital teams exclusively think of Design Systems when they hear DesignOps” – DesignOps Assembly

When integrated well, research and design functions of the org, with the help of ops managers, are an extremely valuable lever for gains in efficiency, quality, and cost. Pulling the rug from under an organization’s capacity to sense and respond at scale will only incur design and technical debt, slow down, and more innovation in rollbacks and refactored deployments.

Let’s be honest.

If organizations truly understood and valued human-centered research and design, not only would researchers and designers be the last ones laid off during tough economic headwinds, but org leaders would consider how to better support their efficiency of delivery and scale.

Even without economic stress, research and design don’t get enough commitment. Organizations hire researchers, designers, and design ops managers to build scalable processes necessary for optimal delivery and fail to integrate them deeply in a way that could operationalize business innovation.

Across the board, IT departments and engineers have worked hard to scale business operations, ensuring processes and organizational efficiency are supported with collaboration and management tools. But when it comes to design operations, the labor of process management, tooling, and integration of their offering is left up to researchers, designers, and ops managers to collaborate with cross-functional teams effectively and efficiently in vertically or horizontally integrated digital services and products.

You can talk about the value of tools, integrations, and ecosystems that drive operational excellence for integrated research and design. But there needs to be more support for design teams currently left to build it themselves. Optimal research and design comprise tailored processes, artifacts, integrations, and automation that help streamline communications. Whether it’s managed insight repositories, atomic component libraries, and design systems, these are the products of additional work that individual contributors do in addition to their core functions. While engineering counterparts that benefit from these integrations may have helped, this work is not getting the support it needs from the industry.

The sad part about this is that even if steps were taken in the right direction, possibly yielding a 20-30% efficiency gain in delivery and other business benefits, the industry wouldn’t hear about it because the teams responsible were laid off. No one remains to support the frameworks that were built, and with that, orgs have thrown the baby out with the bathwater.

right star burst

We have work to do.

Cross-functional teams must stop pointing fingers across skill centers for when and how they need things. They need to work on the problem together as if the solution will serve the greater good because it will. DevOps laid the groundwork for agile software deployment but did not integrate research and design in a meaningful way. The othering has to stop. Researchers and designers in product teams want the same things engineering teams want, for deployed code, new features, releases, or wholesale launches to be loved and celebrated by end users or held up as models of excellence.

Producers of issue trackers, backlogs, insight repositories, design tools, and product definition and deployment tools and frameworks need to hammer in a shared taxonomy. Not only because this will help us become better communicators with shared understanding but because this taxonomy can be used to align our disparate platforms and models of production. Shared taxonomy will enable a unified design management language with shared objects, irrespective of which cross-functional discipline it serves.

People talking about Ops, let’s stop pre-pending it with ResearchOps, DesignOps, ProductOps, or any other subset; instead, let’s talk about a new unified business operating model with an integrated capacity to sense and respond to the market needs in real-time with scalable solutions. It’s not “digital-first,” it’s “human-first,” with solutions (whether technology or design) serving the use case, not the other way around.

You can use discipline-specific ops classifications to help delineate the lines of responsibility in operationalizing excellence within a skill area. Still, the ultimate goal must be to unify and integrate an end-to-end practice that serves the business’s and its customers’ simultaneous needs. The maturity of your discipline-specific Ops should be measured in the depth of its integration and the collective capacity to sense and respond at scale.

The Dovetails, Atlassians, Codas, Figmas, Pendos, AirTables, or ZeroHeights of the world aren’t taking an authoritative stance on what integrated cross-functional teams need to support a deeply integrated research and design org through continuous deployment. Yes, they want you in their ecosystem, but they’re not looking for friendly ways to smooth over an open framework to allow tri-track staggered deployments. Think about all the innovation it took to glue these systems into a single source of truth. No one did that for you. You did that. We thank our tool providers for the APIs, but we can’t advance the field in a scalable way if we all have to write our integrations to enable seamless workflows through cross-functional systems.

Let’s get to work.

It’s time to meet the moment. If we’re about building sustainable, scalable, and deeply integrated operations to support research and design, we have work to do. When we’re done, we’ll know because research and design will be a part of every digital transformation strategy, every strategic initiative at the org level, and as a critical tool to shape business innovation.

For a more concrete vision for how to drive a more profoundly integrated design culture, I can’t say this better than Jeff Gothelf, and Josh Seiden did in their book Sense and Respond. (If you haven’t read it yet, grab your copy, and learn it as if your life depends on it.) This book outlines the core mechanisms that drive research and design deeper into the central nervous system of the digital product and service teams. If you want the Holy Grail, we’re talking about becoming the wetware and muscle memory of strategic business operations.

sense and respond book

How do we get there?

  • Educate each other – continuous learning is the only way to a future without boundaries. This path moves in every direction; you need to listen and learn, but you also need to share- and what’s more, give the people in your direct sphere of influence resources and tools to educate themselves. If that means laying out a curriculum or recording sessions and making those materials available to your teammates, do it.
  • Culture and change management, there is no more luxury of time to say, “we don’t do it that way” anymore… the only way forward now is to be flexible. The velocity of change is so much faster that if you’re not prepared to bend, you will break. The same is true for the cultural climate your org needs to adopt new processes and areas that can empower your capacity to sense and respond at scale.
  • Integration frameworks – start building them and documenting an authoritative stance on “these are the tools, these are the taxonomies and objects they share, and these are the seamless workflows that support product innovations” from research through design planning, management, and deployment.
  • Industry support – producers of research, design, and implementation software – your functional scope needs to be more thoughtful. Yes, your tools have been valuable up until this moment in time, but it’s over. We need more now, and it’s no longer about your core capability; it’s about the ecosystem your features serve across product lines in end-to-end innovation lifecycles. Your tools need to become more open to integration models that serve workflows in and out of your system. The less you feel the need to account for the ecosystem, the less relevant you’ll become. You know this, but the time to sit back on that idea is over; it’s time to lean in. Isn’t that why we pay for Enterprise level SLAs?

How can we measure our success?

  • We’ll know we’ve succeeded when cross-functional teams start their concepts and design cycles by running reports in an integrated insight repository.
  • We’ll know we’ve succeeded when “design” isn’t talked about in terms of what colors and fonts to use but how to address business design, user needs, and issues in service delivery.
  • We’ll know we’ve succeeded when the tools we use are seamlessly integrated to provide contextually relevant access to our single source of truth wherever that lives.
  • We’ll know we’ve succeeded when we can stop making territorial claims over skill-area-specific ops and share an aligned continuous design and continuous integration operations framework.