What is design operations and why should you care?
There are several ways to parse design operations (DesOps), but probably the most important one is as a way of mapping design work against the mindset and goals of developer operations (DevOps). As one person recently put it to me recently, DevOps was created as a way to remove QA and SysAdmin from the operations equation. Developers owned their own QA as well as given means and authority to deploy their code directly through to the delivery system(s).
Why do this?
- Speed: Increasing velocity from requirement to delivery
- Optimization: remove impediments, decrease humans (resources/expenses)
- Accountability: Be the ultimate authority for the code you develop as an engineer.
- Focus: Since you are doing more per line of code, you need to reduce the amount of lines of code you create, which translates to the number of features/stories you are responsible for as well. (this limits optimization). Architectures like microservices though help on the other side.
In the product triumvirate (Product Management, Engineering, Design), design is least integrated into DevOps environments. This has caused the classic “wagile” (waterfall before agile) systems that many organizations have fallen into, while the smarter organizations have been utilizing “Dual-track” approaches that separate discovery from delivery all together. Read Marty Cagan’s “Inspired” for more on Dual-track.
When it comes to the design side of the equation there is nothing quite like it. Systems like Lean UX, are great, but few adopt. They talk about process, but unlike DevOps, they don’t operationalize design at all, let alone in a way that allows organizations to keep in step with true 12-factor (or similar principles) Cloud Native application development at the heart of most DevOps systems.
If I were to articulate for myself what I have taken away from DevOps as a set of principles that I’d like to apply to DesOps, it would go something like this:
- Hold the designer accountable.
- Get to “learn” as quickly as possible.
- Pivot on lessons quickly.
- Use software to do more to help create & manage software.
- Reduce risk through compartmentalization.
I’d love to hear other additions to these that people think are relevant to design. The folks at Rosenfeld Media are hosting a Slack-based conversation about Design Ops. If you are interested, shoot me a response here, telling me what you think about Design Ops, and how you want to contribute to the conversations.
Designer’s Operational Issues
To achieve the above there is a lot for designers and the rest of the product team to overcome.
Tools
Tools just aren’t there. There are a host of reasons as to why, but unlike for development, design tools don’t offer the marketplace the same level of scale. When designers are employed at 1/5th (the best) to 1/100th (more likely) the rate of developers, how can design tools compete for investment the way that development tools have.
Couple that problem with format and tool wars for what tools we already use, and it is incredibly difficult to be build software to be the glue between the tools and the system (the software that manages the software). For example, there is no real system for applying version control with object deployment with source material. This makes up the very basics of many DevOps systems.
Managing “design systems” often means that large organizations are building their own software for doing this, often relying on developer-centric tools like GitHub to do designer flows and activities. Likewise, tools for managing research data are also sorely lacking. There are a couple of home grown tools out on the market, or templates available, but nothing to build an enterprise grade architecture off of that handles the full research lifecycle and connect that lifecycle to lean methodologies and the product lifecycle.
Digital means we are all remote and because of that, the pain called by poor collaboration tools impacts us heavily. Real-time conferencing tools are so bad to use that most organizations have a 10min meeting tax just for tech issues. Other collaboration tools are not much better. Whether the misuse of email and Slack creating way too much noise to signal, or the inability to have cogent threading within chat rooms.
Tooling for remote synchronous and asynchronous collaboration just doesn’t affect design, but design has a particular set of needs that tools that don’t consider design often fail at addressing the specific nuances of design. For example, because design is emotional it means that it is already a fairly difficult deliverable to communicate accurately. Couple that with abstracted digital toolboxes, you will end up with a ton of misalignment between team members.
Designers
Designers aren’t there. While agile and lean have done a great job of forcing designers to pick up the pace, the popular design methods still happen before and separate from development and design is seen as an impediment as opposed to a valuable step in the learning process for developers and product managers. As a design luminary put it recently in a private conversation, “Design still needs to be done up front.”
Human Resources
Human Resources (HR) isn’t there. Few organizations have mature career paths for design. Most startups Frankenstein their teams together based on direct resource needs without any strategic considerations. Generally, assessment of prospective and existing employees is not codified in a way that the entire enterprise understands what is expected of given roles and how those roles are meant to provide value to their team and the organization at large. At best, these exist but they are written by people with limited knowledge or understanding of designers and their culture.
Research has its own operations needs
Many research organizations have the makings of an operations model in place, once they hit a certain level of scale. Many of these same things should be equally applied to the rest of the design organization. (Yes, I assume that research is inside of design and I can see arguments for it either being inside or parallel to design, but I personally favor inside.)
Some of the core pieces are brief templates, recruiting on boarding, recruiting management and session scheduling (space, time, participants, incentives, etc.) and finally data capture. The area as alluded to above that needs the most work is what happens to data and insights after data is collected. This is a complex problem area and probably requires its own article, but the main pain point is rationalizing design insights through a broad scaled enterprise is still very difficult and neither tooling nor culture work to solve this problem currently.
Your team’s APIs
How do you on board projects? What are the communications and collaboration methods between design and other internal and external stakeholders? What are the objects of value created by design and how are they integrated into the rest of the workflow of the product lifecycle? This is more than just tooling, but includes everything about an organization’s design.
Moving forward
As DevOps itself is still a learning endeavor, DesOps is even more so. We, designers, still have so much to learn, create, try, and measure to see ultimately how will we amplify the value that design brings to organizations.
Someone in your organization needs to be assigned the role of mapping out and managing your design operations from resources to tooling to processes/methods. This person can be a shared resource and have other hats, or be fully utilized in this role depending on the scale of the organization. But as some organizations have “Agile coaches” to help them get the most value out of their development teams, the idea of hiring a “design studio coach” should not be such a large leap.
Their job is to create a stakeholder map in your organization, and couple that with a culture map. Then based on objectives, create new versions of how the flow of information and artifacts need to occur. In so doing, they will design the feng shui that is ideal for your needs. Of course, there is no idea, so experiments based on strong hypotheses are created and experiments are monitors for results. Then adjustments are constantly made.
Since we are talking about doing work, change at pace in this way is very difficult, so this person needs to manage change as much as be a change agent for what they want to achieve.
Next step
So where do you find these people? Well, just like when your VP of Engineering first needed to create an operating model for their development team they may have hired an “Agile Coach”, they need to find someone who can consult short term and maybe stay on long term to move them past the common issues of approachability, change inertia, and ocean boiling that usually haunt projects like these.
The point
Be as intentional in your design and execution of your design operations as you would about any other part of your organization that you expect to gain value from.
Short cut
I’m starting a new consulting practice as a Design Studio Coach. What I offer is much of what I described above:
- Evaluate current culture with a focus on communications, processes, workflow, team and organizational goals
- Create vision for the team based on organization’s investment plans long term.
- Craft staged plan towards achieving measured goals with gates for evaluating hypotheses to evaluate new directions, accommodations, or tweaks.
- Offer best of breed tool evaluations across the set of operational needs against, the organization’s against contexts.
- Ongoing to coaching to help the organization adjust to change, stay on target, and make adjustments to ongoing practice as necessary.
- Evaluate current designer management from hiring to promotion and other strategic team development issues.
- Lastly, I offer training on core design issue to help level up your design organization.
In the end the goal is exactly to do what is necessary to amplify the value of your design team and its perception as valuable in your organization.
Let’s do it together.
Best place to do it together is at the only conference that focuses on Design Operations — The DesignOps Summit. (next edition NYC Nov 2018)
