DesignOps at General Assembly
DesignOps (Design Operations) is a bit of a buzzword these days — but, it is relevant because the act of design and development have become so complex and critical to a team’s success, some(one|group) typically spend time making sure everything runs smoothly.
First, what is DesignOps?
The processes, workflows, and tools that designers use to create have increasingly become influenced by their developer counterparts. DesignOps is comparable to the DevOps movement in which those who write code are brought closer to those who look after infrastructure in order to deliver high quality scalable solutions.
It is an acknowledgment that design practices have become more complex and integral to the success of teams. Attention towards improved collaboration, organization and effectiveness are crucial traits for an ever evolving workflow. DesignOps seeks to embed systems thinking at the core of the workflow to allow a team to validate ideas quicker, maintain consistency, and ultimately ship better experiences.
I like Andy Budd’s explanation:
"In short, it's about getting design improvements in the hands of your users as quickly and with as little friction as possible.” - Andy Budd
and the NNGroup definition as well:
“DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.” - NNGroup
Why is it important?
The design process affects the whole team, and that taking responsibility and accountability over operational tasks breaks down barriers of friction in attaining a team’s goals. If a team can understand, support, and improve its workflow it boosts the effectiveness of each member. This results in a team who owns a holistic process, choses tools that bridge disciplines, focuses on the customer, and ensures that quality and consistency are the default.
DesignOps at General Assembly
Rewind to 2017, we were reorganizing our product design team. At that time we had no official DesignOps responsibilities but we knew we wanted to improve the effectiveness of our team so we can focus on quality, consistency, and customer solutions.
Team reflection
We performed an audit across all cross-functional teams (designers, developers, pms) to find the workflow bottlenecks. A pattern in the feedback formed in which collaboration was suffering due to each designer reinventing the wheel when it came to process, tooling, and delivering their work. This causes friction on each project team in that designers felt siloed to figure out things for themselves, and teams suffered from the lack of a consistent approach when working with different designers.
The GA organization embraces cross-discipline embedded product team model, which assigns designers and developers together. This places designers closer to the problems, but further apart from each other, and thus inherently dissolves their connection for sharing. At the time, designers were not very well supported operationally, so each designer created their own design process and workflow.
Scaling process
As our team scaled we found that when designers approach their workflow in a similar way it was easier for them and their teams to pair any developer or designer together and expect a similar working experience.
- Some designers stored files in unexpected locations.
- Some designers were not diligent about documentation, some were.
- Some designers paired with developers, and others handed off and moved on to the next project.
- Ultimately we had inconsistencies along how we approached nearly every step of our process which made it difficult for efficient collaboration.
There will always be variance in individual workflow and how designers ultimately approach problems. The point here is that the team identified a series of operational problems that the design team had not addressed. The simple solution was to standardize as many operational tasks as we could while still allowing for individual creativity and freedom in one’s approach to design work.
Thus the birth of DesignOps responsibilities on our team.
The team model
Due to the size of our team we opted for a Federated Model, in which the Product Design Manager steers the ship but is heavily supported by each individual designer in coming to collective decisions for the teams operation.
We got rid of tools that caused chaos in our workflow, and rolled out solutions for creating and maintaining our very first Design System. This resulted in making us more effective at communicating, crafting and implementing solutions with our engineers -- one of our core collaboration problems at the time.
Onboarding
As our team began to grow we also noticed that onboarding new designers was extremely manual and time consuming, and often wasn’t enough to get them up to speed. We revamped our onboarding documentation and mapped out the first week of a designer’s experience working on our team. These organizational improvements have allowed us to answer most of the questions our new hires have, while exposing them to our history and approach as a team. These are two examples of how we reflected on our current position as a team and improved operations so that we could have a bigger impact on the business by optimizing our team operations.
Not all teams are the same
DesignOps will look different from one team to another. Some teams may be more mature than others, some may be larger, some may have more specialization, etc. As with any set of responsibilities, the focus may also shift and evolve as the team does.
One commonality is that all design teams should seek to measure and grow their impact and focus. DesignOps offers all the support for maintaining said focus on solving customer problems rather than on how the team processes should scale.
- Research and audit: Take time to understand your team dynamics.
- Make it actionable: Propose a plan. How might the team overcome some of their operational problems? How might your team utilize its positive traits even further?
- Be transparent: With transparency comes accountability. By sharing the insights and action plan you inherently become accountable as a team to affect positive change
- Show improvement and value: Set KPIs and metrics to improve as a team
- Documentation: is crucial to sharing a collective mindset on design operations so that others can contribute and make hiring of more resources possible.
- Scale responsibilities: As the team grows you may need a a dedicated role/team, a federated model, or other structure.
What skillset does DesignOps demand?
DesignOps is an infrastructure support role that may be the responsibility of one or many people tasked with ensuring the evolution and success of the team. An individual with these responsibilities should be skillful in:
- Ability to organize and support various designers and their workstreams (implementation)
- Ability to align a team (Sr. or Managerial traits)
- Thorough understanding of the end-to-end product design workflow (eg: double diamond)
- Thorough understanding of the design tool landscape (have an ability to audit and chose the best tooling for your team makeup)
- Thorough understanding of Design Systems (how to enable your team to be efficient while maintaining consistency and quality at scale)
Conclusion
Our team created a space on Confluence (any other internal wiki tool would work) that outlines health metrics, culture, mission, learning opportunities, tooling, and our standard practices (a series of how-to documents with examples). This set of documentation helps crystalize our efforts towards improving our design operation. It acts as a collective of decisions that ebb and flow with those who join and leave the team.
We are currently undergoing training on a new design tool that aims to bridge a gap of friction that we currently have with the maintenance of our design system. Our design system supports over 6 applications and dozens of developers globally. We hope to switch to a tool that will help us maintain our large symbol library from a single source of truth, the code itself. We currently “imitate” our components with static symbols in Sketch. This has worked great for the past few years, but has caused confusion in lack of maintenance and energy it takes to keep a 1:1 copy of static symbols to verbose and dynamic components.
To hit on the Growth & Learning aspect, we have also created in depth growth plans for each member of our team and actively check-in biweekly during 1:1s. We have dedicated time for the team to hold weekly feedback sessions, critique, and quarterly updates for the sake of transparency, one of our health indicators.