8 Ways to Make DesOps Work For You

In the modern world, it’s the development team’s speed that often defines the viability of a product. At the same time, there is one key element which is most important, and most problematic: design.

Design often becomes a bottleneck and significantly impacts the whole development process, no matter the size of your team. Sometimes superhuman efforts from a design lead help drive the design process, but as soon as workload increases, you have to scale your team.

How often have you seen:

• developers sitting idle, waiting for artwork;
• developers lacking design assets;
• mysterious new components that look suspiciously like duplicates of existing components;
• diverse design elements from different designers, for the same project.

If any or all of these sound familiar, then it’s high-time to implement DesOps (Design Operations).

DesOps Specialists

The term DesOps or DesignOps is a replica of the term DevOps which is a software engineering practice that aims at unifying development processes to create greater efficiency. Similar to DevOps specialists, DesOps specialists are experienced designers with management skills who understand the design process within the larger context of product development.

While we may not all have the “DesOps” term in our job title, many senior designers are already responsible for the same role. From establishing design processes, to developing design systems, to creating strategies and managing design teams, DesOps is an increasingly in-demand role.

8 Ways to Start DesOps

What really matters, is that this approach is scaleable, and relevant even in teams with a single designer. So, how do you start implementing DesOps?

1. Develop a Criteria for a Completed Design

Designers need to know when their job is complete and ready to be passed to the development team. For example, designers need a clear understanding of which states each screen needs to have, and which assets will be required for the development team to build those assets.

It may feel like this is an area that designers should inherently understand. But it is actually one of the most common points of friction in a project and shouldn’t be ignored. If you articulate what is required clearly, then you’ll reduce conflicts, and ensure that everyone understands their responsibilities.

The benefits of this are: it allows a steady development pace to be maintained; it reduces the total development time; it reduces the number of discussions necessary between designers, developers, and leads.

2. Define Design & Delivery Requirements

For the last point, we were considering specifically what the designer should convey to developers. This point is about what form the designer should use to convey the design—mockups, polished design, prototypes, moodboards—what does the designer need to provide in order to effectively convey their intentions in a format that the developers can understand.

There are numerous options, such as Zeplin or InVision but one of the most common complaints from developers is that these formats don’t provide everything they need (such as exported assets). However, that is usually because designers haven’t properly exported their designs. By clarifying for designers what they are expected to produce, they can pass the right assets on easily.

You should create an internal document that will contain specific technical requirements for assets, design tools, collaboration with developers and other team members; finally, this document should clearly define when and how designs must be delivered.

3. Develop a Design System

A set of design and engineering solutions, as well as guides for their implementation, will ensure a number of advantages: product integrity; simpler and faster onboarding of new team members; more efficient work of both designers and developers (as they can communicate in one language defined by the design system).

The benefits of this include: improved overall quality of work; reduces “sag” when you scale the team; increases the speed of both design and development.

4. Select, Monitor, and Restrict the Team’s Toolbox

We all love cool new tools, but an effective team works with a uniform set of tools, and ensuring this unity is your responsibility.

All tools should be up-to-date, but if an update is skipped for any reason, then everyone should skip it.

The benefits of this include: increased team engagement; increased design and development speed; improved team collaboration.

5. Develop an Approach to Version Control

Developers are luckier in terms of this task, because version control for code is a mature industry with plenty of options. It’s hard to produce a similar approach for designers, as processes are so diverse, but in the last year tools like Abstract, Kaktus, and Plant have been increasingly popular. You can even have multiple designers working on a single layout with something like Figma.

The benefits of this are: improved communication; simplified team scaling; fast tracks design processes as multiple designers can work on a single project productively.

6. Implement Prototypes and Visual Documentation

In order to describe all functionality related to designs, try to use “visual documentation” instead of writing tech specs. In most cases, it is enough for a developer to have an interactive prototype to understand the basic logic and find answers to most questions.

The benefits of this include: reduced time writing tech specs; reduces the scale of work for technical writers; developers spend less time reading documentation and more time writing code; designers are more productive; accelerated development pace.

7. Integrate Designers into Your Development Framework

There is absolutely no place for design in many popular software development methodologies; whatever development process you’re using, find space for designers.

The benefits of this are: a united team with improved communication; increased development speed; reduced rework, and developer downtime.

8. Present Measurable Indicators of Improvements to the Whole Team

You should constantly demonstrate the growth of quantitative and qualitative indicators thanks to the implemented changes, for both team members and top-management. Without this, a team will be reluctant to change, while top management won’t be able to understand where and why additional resources are spent. Constant collection and presentation of positive results after implementing changes will help you obtain credibility and necessary authority for further changes in team workflow.

Benefits include: increased motivation and a stronger team; facilitation of new rules and practices; support for future innovation.

Summary

The term “DesOps” is quite new and is just starting to acquire its meaning; the first DesOps conference was only held in November, in New York.

For now I would simply call this a culture that aims at developing and facilitating solid design processes. But I feel that in the near future we will have this as a separate design role in every product team. However I feel we can already safely talk about the importance of introducing these practices in order to improve the efficiency of design workflow and product development in general.

Anton Suprunenko

Anton Suprunenko is a product designer based in Ukraine, the largest European country. With Fine Arts and Tech background, he dived deeply into UI/UX Design and has been there since 2002. Anton applies his knowledge and experience in consulting startups, mainly from the United States and Europe. When it’s a vacation time, it must be a round-the-world trip, cause he can’t stop making photos. Currently, Anton is giving 120% as a lead product designer at Australian product company PsyQuation, one of the world leading trading analytics platforms.