Day 64 — Future of Design series 5/7: “DesignOps Integration”
When design teams grow to 100+ people design organization, does it still make sense to operate like a 10 people team? How can we enhance the performance and reduce the redundancy by operationalize design organizations? DesignOps is here to rescue.
- What is DesignOps
- Why is it important
- Difference between DesignOps, DevOps, and DMO
- How to integrate DesignOps
What is DesignOps
According to Pabini Gabriel-Petit, “DesignOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver well-designed, high-quality applications and services that meet people’s needs, while working at high velocity. More efficient UX teams enable organizations to evolve and improve product and service designs at a faster pace than organizations using traditional UX design and research processes, without sacrificing quality; better serve their customers, and compete more effectively in the market.”
“More efficient UX teams enable organizations to evolve and improve product and service designs at a faster pace.” — Pabini Gabriel-Petit
That being said, the coverage of DesignOps include the following area as the figure below:
The Value of DesignOps
According to John Maeda’s 2017 Design in Tech Report, over 70 design firms have been acquired since 2004 with around 50% of acquisitions taking place in 2015 and 2016. We’ve seen CapitalOne acquired Adaptive Path, Deloitte acquired Heat, McKinsey acquired Lunar, and Salesforce acquired Sequence. More and more enterprise put significant amount of effort/ investment to upgrade their design capabilities and capacity. When a design team working on the same platform, scaled up to a 150 designers organization, there are tasks that are simply economically unwise to repeat or be handled on an ad hoc basis. For example, software, tooling, templates, process management, consistency, reusable component, branding, etc. Therefore a centralized force to create scalable solutions is needed in order to transform from growth model to scale model.
Except for simple numbers on the economic side, there are other important values that can be acquired through DesignOps. According to Dave Malouf, there are four ways to evaluate the value of Design Ops:
- Designed but not delivered in build: Is the build actually followed what’s been designed? How big is the gap and what’s the cause of it?
- Favoritism engineering over design: Are we seeing the process of creating a product is dictated/ driven by engineering team? What is the adoption rate of Design Thinking and how well is it implemented?
- Attrition rate: design team over org: Are designers happy with the work environment? Do we see them coming and leaving very fast? What is the attrition rate (definition here)?
- Time spent in designing things: Is our team spending 90%+ of their time to design, as what they’re hired to do? Or are they spending a big chunk of time dealing with re-creating template, getting the required equipment, or any other work that’s outside the core value of design?
If you’re seeing a large gap between the ideal state vs. the reality based on the questions above, then there’s a great chance you need to consider adopting DesignOps.
What’s the difference between DesignOps, DevOps, and DMO
DevOps
According to Wikipedia, DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives. The philosophy of DevOps is about removing the barriers between two traditionally siloed teams, development and operations.
Difference between DevOps and DesignOps
The common theme between DevOps and DesignOps is to “Operationalize” certain part of the process to increase the efficiency, so that the developers/designers can best use their talents and focus on delivering work. Meanwhile, the differences are:
- “1+1 = 2 vs. 1 x 2= 2”: DevOps is a joint effort between Dev team and Tech Op team (IT department). In design world, there’s seldom a dedicated Op team existing in an organization; more often then not, the closest equivalent (design assets management team) is merely one branch under the design organization. Therefore DesignOps is more about reinvent the process of an existing design organization to boost efficiency in delivering value.
- “Code v.s Creativity”: Although both efforts are trying to create collaborative culture and better process, a big part of DevOps is to utilize code to automate the process; that’s quite hard to be mirrored into designer’s work. Instead, DesignOps focus on create an environment to foster creativity so that we can still achieve the 10X effect without code/ automation.
Design Management Office
The concept of Design Management Office (DMO) is from design agency Moment, where John Devanney (video below) introduced the idea of DMO. The goal is to bring in better process to help designers and the product team on efficiency, morale, and individual’s career growth. Here’s the highlight
- Influence through Process: The 3 step process, Define-Equip-Connect help organizations adopt user-centered design approach, with both user research and design system, with the end goal of impact the whole organization for a design-led transformation.
- Capacity through People: The idea here is to formalize the design team’s learning process and knowledge management, and standardized the team approach. The goal is to help individual’s growth, so that not only it boosts the team morale but also allows them to reach to their full potential on project performance.
- Project impact through Measurement: By consolidate the project pipeline with the tool of project framing, design teams can better understand how they can better contribute to the core solution; and through impact valuation, design teams can better communicate their value through measurable impact.
Difference between DMO & DesignOps
Although there are lots of common area, there are some differences between DMO and DesignOps. DMO mainly comes from a business management mindset, therefore the focal area is around business impact through better process enhancement. DesignOps also cover this area, but with a larger scope due to the “Operationalization” concept. For example, software & tooling, space for craftsmanship and creativity, also product, design, and dev process integration.
How to integrate DesignOps
Top-down approach
Top-down approach means the decision of adopting DesignOps is from the senior leader, whether it’s CDO (Chief Design Officer), CMO, CTO, CIO, Head of Design, etc. If we can get our organization recognize the value of DesignOps, usually the top-down approach is more efficient with larger resource. Also, given the nature that DesignOps can be only effective with other team’s collaboration (e.g. Dual Track process), top-down approach is also easier to get other team onboard. Once we have the budget and resource, there are consultants specialize in this area that can help our team to adopt DesignOps approach or formalize a internal DesignOps team. However, it’s not saying there’s no downside of this approach. The typical challenge is to convince senior leadership to recognize the value of it. As we know that most of the designers are not train to read balance sheet or drafting business case, it might be hard to put the numbers together to convince a non-designer for large amount of investment.
Bottom-up approach
The bottom-up approach means without the large amount of investment/ resource and formalized effort, some enthusiasts among the team members start trying different DesignOps approach and gradually adopt the methods. It’s like building LEGO, brick by brick, slowly but surely making DesignOps a normalized process in the team. Undoubtedly, this approach takes longer time. However, because of the grass root effort, this approach actually holds stronger because of the organic culture shift and volunteered work.
Join Force
The best approach I’ve seen so far is to mix both top-down and bottom up approach. By training individuals to become ambassador/ enthusiasts, these individuals can help strengthen the confidence of the team on adopting this new approach, therefore speeds up the top-down adoption.
Conclusion
- DesignOps is a formalized effort in order to operationalize design process and related tasks, plus the collaboration with product/dev team;
- DesignOps not only focus on enhancing measurable business results, but also removing low-value work from designers daily jobs, and helping designers’ career growth;
- To effectively adopt DesignOps, we need both senior leader support and enthusiasts in the team to grow the practice in both organic and structural ways.
Do you have any experience integrating DesignOps? What was your approach, and what did you learn? I’d to hear from you.
ABC. Always be clappin’.
To see more
The opinions expressed in this article are those of the author. They do not represent current or previous client or employer views.
