Operationalizing DesignOps

Operationalizing DesignOps
Neema Mahdavi, Manager, Design Operations & Technology, Workday

From the Design Operations Summit website:
Today’s problems are often yesterday’s solutions—quick fix solutions often perpetuate the problem or circumvent them completely. How can we identify the right opportunities for DesignOps & ensure the processes or programs that emerge are successful? We’ll take a system-dynamics approach to map out the process, flows, and operational models of an organization. By combining this strategy and building technology that focuses on automation, orchestration, and measurement, we can achieve the speed, scale, and quality goals of any organization.

He is going to discuss two key themes – picking your problems, and picking the right techology to support our work.  He leads both technology and operations teams.  Workday is a cloud-based HR solution, and their global UX team is over 100 people now.

He joined them in 2013 from small start-ups as an international designer.  He wanted to shake things up, break the rules.  However, it’s hard to break rules when they are not very clear, or not there – that makes it hard to rebel.  What policies, procedures existed?  Those questions eventually led to the formation of the DesignOps team.  They wanted to spread the word, and move fast in the right direction.  They had room to explore, iterate.

They have program managers and designers, engineers and devops – a lot of random roles.  They have to bridge to whatever teams they are working with.  What did they learn from that process?  They needed to support the growth of the business.

One day one of DesignOps, they had to move fast and cover a lot of ground.  Systems help create order, and make sense of the scale of the problem.  One way to manage traffic is to raise the price of parking, for example.

The design team created the original asset, but they were the furthest away from what the users saw – they didn’t own what was shipped, and there were many other teams in between.  Devs were split across many repositories, and the change management would have been onerous.  Instead, the design team buit new assets from scratch, until they had a lot of them, all in a single tool.  Now the devs had access to a modular, single source of truth.  And in turn, this resulted in designers being responsible and accountable for those assets.  Mistakes were made, and they learned along the way.  Over time, decisions became more systematic – thinking through how the whole catalog of assets would be affected.  All teams were able to work more effectively as a result.

There are so many ‘Swiss army knives’ that do a lot of things, but don’t do anything well.  Teams and processes will change, responsibilities will change, and other teams will change too.  They tried to build some tools of their own, including a project management tool that would integrate with what PM was using.  For research teams, the tools are outdated.  How do we make the work easier?  Could we use technology to index the data better?  How to manage legal / privacy concerns for their multimedia data?


In mountain climbing, there is nothing casual – everything needs to be planned, from the route, to the supplies, to who is participating.  Everyone benefits from that intentionality.  So, take your time, plan, and find a way.

1 Comments on “Operationalizing DesignOps”

  1. Pingback: Design Ops 2018 – Recap | Natalie Hanson

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: