Understanding the Value of DesignOps
What DesignOps Can Do for Your Design Organization
This is going to be a good year for the adoption and advancement of Design Operations, or DesignOps. Recently, buzz about it has been growing in the Design community, including more articles being written, an information site, its own conference late last year, a monthly conference call, and even a Slack community around it.
The idea of DesignOps isn’t something new. Dave Malouf had discussed some of these principles a year ago. Some folks had even shared these ideas back in 2016. Design has just been so focused on “getting a seat at the table” and working out our process and tools, but it’s time to move on to the next phase of its evolution.
Design is now maturing. We can now begin to see value in operationalizing Design. The “fly by the seat of our pants in the hopes that everything will work out” mentality, just won’t work for us anymore. Design stands to benefit from systems and standards. Designers deserve to do more of what we enjoy.
As DesignOps is still in its infancy, you will probably get different definitions from different people. This is for a good reason. It is still being established and different organizations need different things from it. For me though, I like to define DesignOps like this:
DesignOps: principles and processes to assist designers in becoming more productive and collaborative
This may be somewhat vague, but it depends on the design organization’s needs, and then how they translate it. For some, it is about process. For others, it’s about tools. For some, it may be about standardization. Or it could be a blend of all these.
For those familiar with DevOps, you may be wondering if this just DevOps for Design. There are a couple similarities, which Adrian Cleave talks about on Airbnb’s site. One is the idea of collaboration and automation. Another is about having “operations” for scale and running high performance teams to meet the needs and pace of a company. Both of these are core values in DesignOps.
Solving Problems with DesignOps
As a design organization grows, slowly or quickly, it tends to experience many pains. Designers adopt new methods. New tools become available. Integration issues with other tools arise from those new tools. Adoption issues spring up when people don’t know how to use the tools. Also, the needs of the design org change over time, which impacts all the aforementioned issues. Combine these with out-of-date methods and old tools, and you have a wide spectrum of possible design issues.
Most organizations are trying to figure out how to learn sooner, move quicker, and release faster. This impacts the expectations on designers; we need to figure out how to work more effectively. Our tools and processes have a huge impact on how quickly we can design ideas, validate them, and share them.
Where to Start
So how does one go about solving these issues with DesignOps? First, you have to acknowledge that there are issues. Then understand which ones are the most pervasive and slow design down the most. Then come up with a plan, implement it, track progress along the way, and iterate.
I found the the best way to uncover problems is to interview your fellow designers. Ask big questions like:
- What sort of administrative things would you like to be doing less of?
- What activities do you feel you waste a lot of time on?
- Are there parts of your process you find yourself doing over and over again?
- What don’t you like about your tools? What do you like?
- How could you be freed up to design more?
- What things make you feel engaged or happy to be a designer?
Patterns will emerge from the answers to these questions. They will give you some guidance on which issues are the most pervasive.
While I don’t think any of us have the exact answer (yet), these are the principles I believe DesignOps uses to improve Design.
Our tools should make it easier to collaborate, not more difficult. Designers create greater value when we include stakeholders in the design process rather than exclude them. We should work with our design peers to share problems, ideas, and solutions. There’s no need to “recreate the wheel” every time.
You know that great feeling when you are totally immersed in your work, and you enjoy every minute of it? That’s Flow. Part of this is achieved by limiting or eliminating distractions and the things that keep designers from designing. I see this as “design more, admin less.” Flow is also about ways to get insights and knowledge faster during the design process. The sooner a designer can get an answer to a question or problem, the sooner the solution can get to its users.
Learning how to respond to changes in the environment or industry are critical as things are constantly changing. It is also important to understand how to handle and incorporate feedback from all sources. Lastly, it is important to be constantly learning in this rapidly changing industry.
This is where a ton of time can be saved for designers. When the activities designers do are similar enough, making them standards or repeatable systems can increase collaboration and can decrease the time to create solutions. It also takes a lot of the “guesswork” out of the design process. It just becomes “this is the way we do it.”
Applying the Principles
This is where translation begins for the design org. For some it could be a design system. Others may leverage version control for design assets. Maybe a kick-ass new hire experience is important to get them up to speed quickly. It could be the same tools, used in the same way. It should work out ways to improve things for designers.
We (DesignOps) are in service of the Design org. We are focused on making things better for the teams doing the work. ~ Kristin Skinner
Here is how the application of version control aligns to all four of the principles:
- Collaborate: Files can be shared easily with other people. It enables designers to work together on files, even if they are remote. It also identifies who made changes, when the changes were made, and what changes were made.
- Flow: Designers can trust that they will always be able to get previous iterations of work if needed. It saves time having to think about whether something is the most up-to-date version. There is no need to learn or teach complicated naming systems. This keeps you in flow for longer periods of time.
- Adapt: Our developer peers have been successfully using version control for almost 20 years, as have other professions like authors. Working with current technology and solutions keeps your skills honed and relevant to your industry, as well as ensure that you work efficiently. Using common tools also enables people to speak the same language when necessary.
- Standardize: Design files are in the same place, all of them. You know where to store your files and you know where to find your peers’ files. You know that your peers will do the same.
If you apply these principles to the issues you uncovered, you stand to make designers happier, faster, and collaborate more effectively. Ultimately, help them to be better designers.
In the next article I will be sharing how VMware went about getting started with DesignOps, how we uncovered issues, how we translated the principles, the initiatives that came out of that translation, and share some of the results of the work to date.