The different lenses of Design Operations
Despite the silence in this Medium publication Design Operations (DesignOps) and myself have been moving at a steady clip. I have been in a steady state of transformation myself these last few weeks and so has DesignOps and I’d like to share some of my recent thoughts about DesignOps, especially as I transition from planning the program for Enterprise UX to planning for DesignOps Summit.
If you are reading this, odds are you read some of my other posts on DesignOps. The great thing about writing and curating conferences on a specialized topic is that you get to meet people and have deep conversations with them about the topic.
The greatest outcome of these conversations for me, is understanding. I now understand more of the scope and structure of a DesignOps practice than previously. However, what interests me right now is how I’ve been introduced to a myriad of different lens that DesignOps leaders look through when standing up their DesignOps organization.
I have recognized, so far, 3 types of DesignOps organizations. To be clear, these are more historical lenses. That is to say, the people standing up these practices usually have a lens as their starting point, but as their practice grows, so does their inclusion of other parts of the total DesignOps puzzle.
The first and most popular one of these lenses is what I call Product Design Lifecycle Management, or Program Management. They usually work where design is more of a centralized practice at scale. You’ll hear organizations with this lens with roles like Program Manager, Project Manager, or Producer. The focus of this role is usually from the point of view of workflow or activity stream.
This lens focuses on the question of How can I make my team more successful at getting work done?
The next popular lens is Community Manager. These DesignOps folks are usually practice managers and focused on coalescing a design practice across an organization of separated embedded designers. This role will focus on the people operations side of DesignOps more than the others.
This lens focuses on the question of How can I support the practice of design to help elevate it?
The last lens is the business operational lens. This is usually the most wholistic lens, but still has its roots in business operations. These folks usually work in larger organizations where there is at least a VP of Design or a Chief Design/Experience Officer. That leader will have a person who is their Chief of Staff or similar role. That person takes the burden of business operations off of the design leader. This role occurs in both centralized and decentralized design organizations, but in the latter there is still a horizontal design organization supporting all of the embedded design teams across an enterprise.
The focus of this DesignOps leader as noted is business operations. Finance, IT, procurement, legal, marketing, and Human Resources. They act as the primary emissary between the design community/organization and the Operations organization. In so doing they will need to focus on economies of scale across the design team to help influence more unifying decisions, or create operational models that manage towards autonomy by protecting the design team from the governance models of the broader enterprise operations.
This lens focuses on the question of How can I support my designers to work with the enterprise better?
All of these questions and lenses and more are important to DesignOps and none of them is really more or less valuable tan the others. Different organizations just came to the question of DesignOps from different needs, at different moments, where their first or larger problems were different. Sometimes they just followed what other parts of the organization were doing. They took different practices operational models and copied those because they communicated easily through the organization and well, culturally just made sense to replicate.
What I have noticed is that regardless of what lens a DesignOps team starts with, their focus will broaden over time as they start to see how the real question they are trying to answer is How do I amplify the value of my design team(s)?
Appendix: Design Systems
There is one more lens that I would be remiss to not include here and that is the lens of Design System. Design systems have been so popularized, they are arguably a default need of any product organization of even limited scale. With the best of intentions design systems are created in an operational vacuum though. This usually becomes the very first push by an organization to begin looking at their design operations with fresh eyes as introducing a design system brings with it a whole slew of new problems that most digital product design organizations were previously ill-equipped to deal with on their own. The success of the implementation of a design system will ride on the support it gets operationally. Have the best designed components but if you can’t create a workflow for their upkeep and deployment not just through your product offerings, but through your design production system itself, it will invariably cause more friction than the previous system did.
When you start with the pain point of a design system, you are starting your operations around a solution to a specific problem. This lens answers the question How do we scale design quality through the enterprise?
The design system focused DesignOps leader often becomes the Product Lifecycle Management type leader really quickly which is why it is in the appendix here and not one of the core 3 lenses of design operations.
