Over the last 10-15 years, organizations have been getting better at designing experiences for all sorts of devices, but the industry as a whole hasn't focused on how design teams and their operational platforms are actually structured until recently.

The concept of DesignOps was developed in response to the movement for operational excellence and efficiency in the field of software development. How do we empower designers to operate more autonomously, integrate better with their code-writing colleagues, and work together more efficiently? DesignOps was created to solve these issues and support the efficiency that business leaders aim for.

This white paper provides an introduction to the people, processes, and tools necessary for a successful DesignOps approach in your business.

## What is DesignOps?
What is DesignOps and how does it pertain to digital design? To answer that question, we should first ask some more fundamental questions. First, what is design? According to Merriam-Webster, the act of design is “to create, fashion, execute, or construct according to plan.” Next, why do we design? We use design to solve problems of all shapes and sizes in any area of life—which is great for us, because digital product design has a problem.

### The Birth of a Movement
User experience (UX) design has been around for a while, but it has really gained recognition and traction in the software development industry within the last 10-15 years. In that time, organizations have been getting better at designing experiences for all sorts of devices, but the industry as a whole hasn’t focused its attention on how design teams and their operational platforms are actually structured until recently. The concept of DesignOps was developed in response to the movement for operational excellence and efficiency in the field of software development. This movement was named DevOps to denote the relationship between development and IT operations.

Under a DevOps approach, developers were empowered to operate with more autonomy while still collaborating and removing development process bottlenecks. Approaches changed from rigid quarterly development release cycles to continuous integration and continuous deployment (CICD), which meant software could be released several times per day instead of several times per year. In all, the DevOps movement solved massive operational problems for software developers around the world, and software designers began to long for a similar transformation in their own field.

So how do we empower designers to operate more autonomously, integrate better with their code-writing colleagues, and work together more efficiently? DesignOps was created to solve these issues and support the efficiency that business leaders aim for. We put together the following guide to provide an introduction to the people, processes, and tools necessary for a successful DesignOps approach in your business. We also surveyed approximately 50 design-focused North American companies in order to offer insights on some of the latest trends in product design management and DesignOps adoption.

## People
To build any strong, efficient, and productive process, a company must build a strong team of people to operate that process—and design is not different. Who do you need on your product design team to make it work? The answer may be different depending on the maturity of your company.

### Areas of Specialization
Respondents to our survey consider themselves to be at a moderate, to moderately high level of maturity, as seen in Figure 1. Growing pains occur at this stage as you try to scale into a large organization, and we will consider how to navigate that growth to ensure operations run smoothly. The maturity of a design team differs by a variety of factors, including the industry, size, and age of the company. The maturity—and specialization—of individuals within a team also differ along similar lines, see Table 1.

**Figure 1** 
![Figure1](https://cdn.levvel.io/whitepapers/Intro+to+DesignOps/graph1.jpg)

Great digital products and experiences aren’t accomplished with a single design discipline, nor are they often managed by a single person—at least not with optimal results. A business needs different people to focus on research, content strategy and information architecture, interaction design, visual design, and (with most teams) front-end development. Specialization helps a team excel in the many nuanced areas of product design by allowing staff to dig deep into their respective areas of focus, thus creating higher-quality outputs from each discipline in relatively shorter time frames. Your team’s level of maturity can be reflected in the level of specialization you have achieved, as seen in Table 1.

**Table 1**
![Figure2](https://cdn.levvel.io/whitepapers/Intro+to+DesignOps/Table+.jpg)

Let’s look at a possible scenario of the maturation of design team.

#### Early Design Practice
You have a team of two or three multidisciplinary rock stars. Your interaction designer is also good at information architecture and knows enough about usability testing to get feedback on designs. Your visual designer is excellent at front-end development. Processes don’t easily scale right now, and that’s okay because you’re just getting started. Your small group is working on the beginnings of a design system with a style guide and small pattern library to provide consistency and standards, which will benefit a larger team someday.

#### Mid-level Design Practice
Your team is growing and becoming more diverse in its disciplinary expertise. You have one or more people focusing purely on information architecture and content strategy. This frees up other staff to focus on interaction and visual design. You start contracting out usability testing while continuing to expose the team to users. For your web-based property, front-end development has gotten its own corner in order to focus on the nuance of HTML, CSS, and JavaScript. Your team is beginning to become multi-threaded. It’s using a design system to create new experiences in faster, more streamlined cycles.

#### Mature Design Practice
Research is now its own function with its own team. The team drives research efforts that sometimes operate outside of sprint cycles to drive deep insights that affect the product roadmap. Interaction design and visual design are now separate areas of focus. Interaction designers focus on the overall experience down to direction on patterns, allowing visual designers to focus purely on granular interaction patterns, micro-interactions, and art direction. The design system now has its own person, or personnel, to manage and govern its continual evolution.

## Processes
To support a fully functional design team, processes need to be in place to make sure that as the design team grows, it can function and integrate well with the rest of the company. This is where operational excellence can really take shape and begin to benefit the company’s bottom line and ability to create.

### The Design, Build, Measure, Learn Loop
We care about efficiency, but we also care just as much about effectiveness. If we want effective design teams, we have to provide them with a working model that allows them to deliver valuable products that make each deployment count.

In our survey, we found that rapid prototyping is the top area that companies want to improve, followed closely by design systems and design thinking, as seen in Figure 2.
 

**Figure 2** 
![Figure2](https://cdn.levvel.io/whitepapers/Intro+to+DesignOps/graph2.jpg)

Consider that the entire software development process can be seen as iterative design at different levels of fidelity. Those different levels have different costs in terms of the time and money they require. From that angle, you can start to see that we don’t have to separate design from development so much as we need to be more confident in how we create user experience.

**Figure 3**
![Figure3](https://cdn.levvel.io/whitepapers/Intro+to+DesignOps/graph3.jpg)
With an iterative design approach, testing fidelity with users will have different costs depending on the testing method. Sticky notes and whiteboards are an inexpensive, testable level of fidelity (yes, you can test a whiteboard with customers!). A content document is another cheap option that allows you to test the conversation you want to have with the user. A low-fi mockup is slower, but still inexpensive. A high-fi mockup (if one is really needed) is moderately expensive and much slower; with this type of mockup, you would need to make smaller course corrections than on a whiteboard or in a Google Doc. Once you get to code, you’re at an expensive level of fidelity. You can—and should—still design at this fidelity, but the changes you make have to be much smaller and more precise.

What could the UX process look like if we thought of fidelity like this? Could we go through the loop at every level of fidelity? Absolutely, and we will cover what that would look like in more detail in later publications. For now, a key takeaway is that the feedback loop at high fidelity becomes much shorter with a design system that allows you to build experiences with functional building blocks of components.

### Governance
As fidelity increases and it becomes more expensive to make course corrections, you will need parameters in place to determine what gets to the next level. Governance is an important part of ensuring that your company understands the parameters within which to create great experiences. You don’t want to be so rigid that it hinders your ability to produce, but without parameters in place, ensuring the integrity of the customer experience—and ensuring the maintainability of your properties—becomes difficult. Here are a few principles to guide a healthy yet flexible governance process:

#### Governance Should be Cross-functional. 
You want to have people from business, technology, and design involved in governance, because real problems cross disciplines. You don’t want to make governance decisions about business problems without representing all of the proper perspectives.

#### Governance Should Allow for Flexibility.
A tightly restrictive governance process hinders innovation and will become a pain point for your teams. A balance between flexibility and constraint is the goal here. Consider having open channels for design reviews that include individuals from each business, technology, and design who must make sure they provide feedback and approvals. Everyone should be able to comment, but make sure the decision makers you identify are known and engaged.

#### Governance Should be Easy.
Don’t make it hard for people to have to review features or experiences, and make sure there is channel for discussion on these items always available. You can hold meetings, but don’t make them the only—or even the primary—path to approval, because often they will not align with the speed at which a team needs to move. Make it easy for them to live within the constraints necessary to ensure a good product. If your governance model is cross-functional, flexible, and easy, you will have a sustainable method to safeguard the integrity of your product as it grows and increases in complexity.

There are many more considerations around processes, but these are a good start to increasing your operational excellence.


## Tools
### Design Systems
Many of us have worked on digital experiences that, over time, became messes of redundant variations, small and illogical inconsistencies, and unmanageable amounts of content, pixels, and code that added painful time and expense to design and development cycles. As digital experiences get larger and more complex, you have to be able to maintain consistency to keep delivering a great experience. Design systems can help with that. At its core, a design system is a set of parameters and a set of tools to build experiences within your product, or suite of products. Design systems can consist of style guides, pattern libraries, and code libraries, depending on a company’s level of maturity.

#### Style Guide
A style guide is a set of principles that guide design for your product; it should connect to your company brand. You must make decisions by asking certain questions, such as “What colors are used and when? Should we go for progressive disclosure or display an entire form all at once?” The answers to these questions are the principles that your style guide rationalizes and sets for your company, based on the needs and behavioral habits of your users.

#### Pattern Library
Everybody at the company involved in crafting user experiences should know the existing building blocks available to build those experiences. For example, business and product managers should know what components are available for the e-commerce experience. Components should also be documented with interaction specs and usage guidelines so that knowing when to use them is as clear as possible.

#### Code Library
Ultimately, a pattern library needs to live in code because this is the final state of any pattern within it. At the highest levels of maturity, a pattern library’s components can be installed as packages by developers to implement in a given experience.

### Software
In the companies we surveyed, Adobe Photoshop is design teams’ most-used design tool, followed closely by Adobe Illustrator, with Sketch at a distant third, see Figure 3. Some of these tools are good options for design teams, but the most commonly used tool, Adobe Photoshop, is not ideal for efficient and scalable design strategies. 

**Figure 4**
![Figure1](https://cdn.levvel.io/whitepapers/Intro+to+DesignOps/graph4.jpg)

Whatever your tool of choice, here are three questions design managers should ask themselves about their team’s software tools:

- If I hire a new designer tomorrow, are they likely to be proficient using our chosen tools? If not, why not?
- Does this tool allow my team to quickly make usable assets available to developers?
- Do we know the landscape of available tools and why we are choosing to use the tools we currently use?

## Where Do We Go From Here?
The DesignOps discussion is young, but it is much needed. The industry is collectively discussing how to aggregate best practices from around the software industry. This primer can help you in your efforts to understand some of the major subjects and join the conversation. Below are some of the best channels to engage in the discussion.

### Attend DesignOps Summit
This is the premier DesignOps event, where leaders from all over the world and companies of all sizes come together to discuss best practices.

### Look Out for Future Research 
Levvel is currently conducting more market research on the exciting field of DesignOps. Look out for our full-length, in-depth research report on the subject in the fall (Q3, 2018). 

## About Levvel
Levvel helps clients transform their business with strategic consulting and technical execution services. We work with your IT organization, product groups, and innovation teams to design and deliver on your technical priorities.

Our Design team helps clients create new digital products and services by focusing on outcomes. We accelerate your product lifecycle and innovation process by running strategy workshops, designing & testing experiences with users, and writing code alongside developers. Our cross-disciplinary team partners with you at every stage in the product lifecycle, delivering the product strategy, user research, UX design, user testing, and implementation services necessary to achieve your goals.

For more information, email [hello@levvel.io](mailto:hello@levvel.io "Send email to hello@levvel.io").

Intro to DesignOps

Ease of collaboration and communication while magnifying the capability of design within your company.

Intro to DesignOps

Read the White Paper