When I co-founded the DesignOps meetup here in Melbourne, back in 2017, the term “DesignOps” was brand new to us. However, for 2-3 years prior, we would meet for dinner (always Korean food at the same place) every month or so to talk about our ideas on design and development, which would later become the basis for the DesignOps meetup.
Once we heard the term “DesignOps”, we knew that the culmination of everything we had been talking about for the last few years together was on the tip of our tongues - we just gave it name.
Back then, at the end of 2017, I vividly recall trying to find other people we could talk about these ideas with, trying to find people who had already discovered “DesignOps” or at least had heard of it. To my surprise, I did a search on LinkedIn, and I’ll never forget seeing that there were ~15 people on all of LinkedIn that had any mention of “DesignOps” in their profile or content; 2 of them were my co-founder (Ch’an) and myself.
The public ongoing joke with our meetup was that “We don’t know what DesignOps is”, and it was true, because nobody did. Our idea was to take this fresh term, and merge the ideas we had been talking about for the last few years into it, in order to propagate these ideas out to design/development teams everywhere by giving them a name.
The sad hijacking of “DesignOps”
DesignOps was supposed to be about design and code being the same thing.
In our vision, DesignOps was destined to become the way to describe design and development becoming the same thing. Frankly, the term itself sounded pretty cool to us, and some of the early descriptions from other companies like Airbnb aligned closely enough with this for us to jump on it and create a meetup around it.
After DesignOps started getting a bit more buzz online, we started to see some (very vague) articles come out about it, not really demonstrating much idea about what it means. In hindsight, that was fairly harmless, because the wave that came afterwards was somehow much worse.
Suddenly, a bunch of content started flooding the internet about how DesignOps and ResearchOps are essentially go hand-in-hand (what the heck is ResearchOps, we first thought), and then gradually started nudging DesignOps into a role that barely focused on technology or code at all, and started becoming way more focused on essentially being a glorified manager for design teams.
This was incredibly disappointing to see, partly because (ironically) the role that other people were talking about should not even need to exist if our original vision of DesignOps was being successfully achieved.
When design and code become interoperable, you no longer need a “manager” to oversee design and development teams; this crazy “gap” that everyone wants to bridge disappears, so it’s no longer a problem to solve with someone like the alternative DesignOps role describes.
It’s a red flag when even people in DesignOps roles are confused
There is so much misinformation and confusion out there about DesignOps that the term has essentially become meaningless; it means nothing and everything at the same time.
One way we could measure this confusion is by looking at people employed to be DesignOps Managers.
In an article called Defining DesignOps — my first 6 months as a DesignOps Manager, recalling the week before starting his new role as a DesignOps Manager, the author writes:
A week before my new venture into the mysterious new world of DesignOps. I sat Googling “What is DesignOps?”.
First of all, the point out the first red flag; If you replaced “DesignOps Manager” in this case with an role like “Chief Medical Officer” in the paragraphs above, it would seem crazy. For example, where it turns into:
“A week before my new venture into the mysterious new world of medical advisory. I sat Googling “What is a Chief Medical Officer?”.
The author then continues with an honest reflection of his confusion around the term:
The more I read (and I read a lot), the increasingly confused I became. Is DesignOps a design managers role? The efficiency of design? Perhaps evangelising design? Or recruitment and teams skills? Career progression? On boarding and people stuff? Software and tools? Or was it all of these things or something else?
Pointing this out is in no way a dig at the author; on the contrary, clearly the fault does not lie with him. When you’ve got experienced designers like this feeling lost about a term that describes the job they’ve just accepted, it’s another a red flag that something has broken down elsewhere. Such confusion should be cause to take a step back and look at why this is the case.
The goal was never “bridging the gap”, it was about removing it entirely
As Sam Neil says in the 1997 major motion picture “Event Horizon” describing a wormhole in space:
“The shortest distance between two points is zero, and that’s what the gateway does, it folds space so that point “A” and point “B” coexist in the same space and time. When the spacecraft passes through the gateway, space returns to normal.”
This is exactly the image that comes to mind when I talk about DesignOps, and indeed, our tagline (“the distance between design and development should be zero”) for the meetup itself was inspired by this visual.
The future of design is based in code
I am more alarmed that other people are not more alarmed, but I do think that’s partly due to telling ourselves two different stories:
The first is a story of pessimism, where there are just way too many problems, but we’ve clearly reached the limit of of how we can solve these problems, so we might as well just accept it and add more “layers” to try and manage it best we can (eg. DesignOps Managers).
The second is a story of optimism, where things are better than ever, and are getting better all the time. We have more tools than ever, the biggest companies in the world have massive design teams all approaching things in roughly the same way, so we’ve probably reach “absolute truths” with how to solve these problems, and everything is going to be fine if we just follow along and adopt “best practices”.
Both of these stories that you could tell are dangerous in the same, because if believe nothing more can (or should) be done, the result is that they both lead to the same outcome: doing nothing.
As you might be able to sense; from my perspective, seeing the world this way is pretty lonely, and causes constant cognitive dissonance. I am so convinced that the future of design is based in code, that seeing the current state of things feels like I’m constantly looking back on the past every day.
I find it odd that most of my peers do not see the problem the same way that I do, and I often wonder if it’s simply due to not following the current mainstream path for a long enough period to see all the inevitable problems in their future; or i they can see these problems, but choose to ignore them; or maybe they see them, but have no idea what to do about it and are waiting for “the industry” to also sound the alarm and tell them what to do next.
DesignOps Managers are currently modern day Switchboard Operators
One reason I am less worried about the corruption of the term “DesignOps” (than maybe I should be after it being so personal to me for years) is that I believe we are living through a very awkward transition period between the source of truth for design being “pixels” to the source of truth for design becoming “code”.
I have believed this for the better part of a decade, and continue to hold this view, because I still believe that I’m right, but probably still just a bit too early. That’s why I am so insistent that we need to move faster, because even when we get the technology right to start solving this, the culture is going to take even longer to “cross the chasm” of how we’re going to design and build things in the future.
When you remove the layer of abstraction (hand drawing pixels to “emulate” a foreign production environment) when designing digital products, apps and websites, you remove the cause for so many other unnecessary problems and roles/processes that are thrown on top of these problems to try and “manage” them, instead of making them obsolete.
Once that does eventually happen, we won’t be talking about “DesignOps” or “bridging the gap” anymore; and that’s as it should be.
