The Current State of DesignOps. Metrics, focus areas and approach

Inspired by DesignOps Summit 2020, Rosenfeld Media

This year I was a speaker at the “Resilient DesignOps Organizations” theme of DesignOps Summit 2020 with field practitioners from companies like Intuit, Intercom, Salesforce, Cigna, IBM, Uber, Dropbox, Electronic Arts, and others. And in this article, I would like to share my personal thoughts on the topics that I found interesting from my and other talks.

First of all, I would like to thank

Louis Rosenfeld

,

Dave Malouf

, and the whole crew for such a well-organized event!

The main focus of the DesignOps Summit was on People.

Jose Coronado

covered most of the things within the Resilient DesignOps Team of One, Building resilient DesignOps teams, and Resilient DesignOps Organizations articles. Make sure to check them out! To make our discussion more efficient, I will be covering specific topics in more detail.

The other emphasis points of this summit were around metrics, maturity models, and the DesignOps approach. Let me go through each of these topics and provide my personal thoughts on them.

Metrics in DesignOps

When we are targetting to create or increase the size of the DesignOps practitioners team, we need to show the value. I believe that’s why the community had a lot of questions about metrics.

Personally, I liked how

Patrizia Bertini

covered everything in detail around metrics in DesignOps. There is no one metric for DesignOps, it’s always based on the context (focus area like design systems, research databases, or design culture), goal (increase the design organization, increase market recognition, etc.), and the customer (design partner, a design lead, or design team). As a result, attention is concentrated on efficiency (saved time in hours × rate in $= value) and the quality that brings an organization to another maturity level (after implementing analytics, all our decisions are data-informed). To be more specific, here are some of the metrics from

Patrizia Bertini

’s speech:

In my talk, I was speaking about approaches to efficiency calculation. After interviews, co-creation sessions, or workshops — reviewed in the talk — you will be able to visualize the whole process. This visualization will enable you to provide the approximate time spent on each stage, communication gaps between different actors, and the amount of needed investment.

Investment estimate can be calculated by the time needed for migration (for example migrating all the files to another tool), onboarding time for the team, and time for new process support. For example, your team transitions to a new tool (like Figma) —you can create a survey in advance to understand how many people will need time for onboarding (i.e. training).

You can create different kinds of deliverables like experience maps or workflows that show dependencies and cover all cases. At the top, visualize the approximate time for completion, tools, actions, and actors with some hypotheses at the bottom

After the assessment phase, find the total amount of time spent on a specific process and the number of communication gaps between different actors.

Once you have a specific practice that fits your needs, calculate the value and the amount of investment needed to scale and support the practice.

Here is an example of one practice implementation. After understanding the challenge and coming up with a solution, calculate the amount of time (efficiency) that could be saved. For that specific team with four Code Librarians and one Design Librarian, the total time saved per week is 6 hours. By calculating the rates multiplied by hours you can calculate the real value of such process improvement.

Remember, if you can calculate the optimized time, you can calculate the optimization $ value by multiplying the actor’s rate and time saved. Here are interesting slides from Patrizia Bertini, Dave Malouf, Kristin Skinner, and Kamdyn Moore

Focus Areas of DesignOps

My personal view is distinguishing the focus areas: DesignOps is People, Practices, Tools, and Craft. Where each of them is divided into strategic (organization), tactical (streams), and administrative (teams) levels.

DesignOps Focus Areas

However, another interesting idea was brought up by

John Calhoun

and Rachel Posman, where they shared that Salesforce divides DesignOps into the TeamOps and the ProductOps.

Interesting note that Rachel said that Facebook has almost the same approach.

Some wondered if ResearchOps is a part of DesignOps. And the answer from the expert was affirmative — ResearchOps is a part of DesignOps. I think it’s a matter of your organization's maturity. If you have a team of DesignOps Consultants, maybe it will be better to allocate more narrowly focused disciplines like ResearchOps, ContentOps, CreativityOps, etc.

But why do we need DesignOps? Personally, my view that is investing in DesignOps will give design organizations more time to focus on Creativity, Innovation, and Research due to optimization and increased maturity. Regarding creativity,

Dr Karl Jeffries

had an amazing talk!

DesignOps Approach

It was a pleasant surprise, that all participating experts and speakers had the same vision on the DesignOps approach this year — we need to create and test hypotheses first and only then scale the whole approach. Here is a slide from

Patrizia Bertini

Hypotheses based approach to validate process improvements in DesignOps

Some people might think that strict processes might make us robots. But my personal view is that clear practices are needed only for guidance. And it’s the responsibility of your organization to keep them up-to-date and make sure that you have the right knowledge management.

My approach of capturing the process in details and saving the pro tips and feedback directly in the flow.

You need to understand the difference between the in-house DesignOps manager and DesignOps Consultant. Here is the approach that I’m using personally:

DesignOps Approach is starting from the Assess phase

If you have the access to the recordings from the DesignOps Summit, feel free to check out my speech. I covered the DesignOps approach in detail. And if you would like to take a glance at a study from others, I personally would recommend watching how

Patrick Commarford

and his team improved the staffing process in IBM.

The Future of DesignOps

Wow, I love to think about the future! It helps to specify your goals and have a laser focus on your work.

Dave Malouf

,

Adrienne Allnutt

,

Jon Fukuda

, and

Dominique Ward

spoke about the Future of DesignOps.

I think our biggest concern is about AI. I liked the reply from

Jon Fukuda

about it. We are building products for people and AI will not be able to cover that. Design is not about creating beautiful mockups, it’s about solving people's challenges and that is the kind of thing that can’t be replaced with AI. Here are a couple more slides from his talk.

Currently, we are on the stage of standardizing the way how Design discipline works. Large organizations are creating playbooks and sharing them publicly. There’s still have some work to do because the job responsibilities are different from the company to the company. I hope, this issue will be solved soon.

After passing the standardize phase there will be a clear understanding of what kind of things can be automated. By automating the routine work, the design discipline will have more time to focus on more tactical and strategic work. Here is the feedback from

Dave Malouf

on my talk:

Discover redundancies ⭢ create playbooks/runbooks ⭢ create automations ⭢ create tools ⭢ create platforms. All in service to the People.

Here are some examples of the automation in

Figma

that you can implement in your teams to remove the routine work:

Saves a lot of time spent on communications and creates a better report on the component usage directly in Figma. In our team, we could save up to 12 hours of work!

Saves a lot of time on placing the right spacing amounts directly in Figma

If you would like to use Figma API, here is another example of how to simplify the design review with the FE team. The script generates the component preview from Figma API and pastes it on top of the mobile application made in Flutter. That’s how developers are able to see inconsistencies while writing the code.

Here is the link to view the code https://github.com/vlivanov/flutter_figma_preview

If you would like to ask what is my personal view on the future, I will say that within 2 years we will finalize our practices around design systems, then research databases (next 3 years), and finally knowledge management (next 5 years). What are your thoughts? Reply on Twitter!

Thank you!