Day 2–How to Define and Maintain a DesignOps Roadmap

di1

—  Hello DesignOps. I plan to share with you how you can define and maintain a DesignOps roadmap for your  initiatives

 

— First, a shout out to all conference staff and attendees for whom English is second language

 

di2

— I’ll provide the agenda for the session and examples for DesignOps initiatives

 

— I’ll then explain who does management of DesignOps and five steps to define a roadmap

 

di3

— We all probably know NNG definition of DesignOps, which focuses on amplifying design’s value and impact at scale, through a focus on people and processes

 

di4

— We usually use the definition above informally to improve the underlying circumstances  for the design org, to increase the chances of good design

 

di5

— What does such initiatives look like?
  • I’ll go through design initiatives at some of my past employers

 

di6

—  Project 1: I’ll go through an overview of Miro’s design process, a big diagram of how projects run horizontally and vertically
  • Includes suggestions for deliverables and how to get there
  • Outlines how peers will collaborate and roll-outs
— To give overview of the initiative structure, I will talk about the goals, teams, metrics, and duration of the initiative
  • Initiative: Goal to align work between product teams
  • Team: DesignOps and several process-minded designers
  • Duration: Several months to get to certain state and rolling out

 

di7

— Project 2: Another initiative was a project tracker for Miro to help design  managers to plan design work in quarterly planning cycle
  • Kept track impact of extra design projects as well as details for scope
    • Planning and tracking for work
  • Tracker supported Design Managers in tracking work, and in execution phase through updates done by individual designers
  • Done through a team of Design Managers and DesignOps
  • Duration: One week research and one week build, and quarterly adjustments implemented

 

di8

— Project 3:  We created a bot in the Miro slack channel to capture and resolve bugs. It included,
  • Specifying type of bug and location of bug
  • Based on answer JIRA ticket would create

 

di9

— So bugs discovered faster and improved and track recovery time and see chart demonstrating creative versus resolved items in play
  • Tool specialist, Design Manager, and Design Ops team built
  • Duration: 2 weeks for building the bot and 2 weeks for dashboard

 

di10

—  Project 4: Had invited outside speakers for presentations (including Peter Merholz)
  • Goal to build shared culture of references and terminology across the design team
  • Team was DesignOps, along with speaker suggestions by designers and researchers
  • Duration: Ongoing with quarterly presentations
— Can give lot more examples, but hopefully you got the idea of what it is all about

 

di11

— So who does the management of these initiatives?

 

di12

— I’ll refer back to DesignOps 101 for both the DesignOps mindset and the DesignOps role
  • Mindset similar to people who maintain wikis and think how workflows are organized
  • People who have DesignOps on job description, and time dedicated to DesignOps initiatives
— Have such a team will have people doing the DOps, if no team, leverage people with mindset

 

di13

— Can now dive into the DesignOps roadmap

 

di14

— Five things for initiatives
  1. Inventory: Continuously see what we have from internal and external sources
  2. Prioritize: What to focus on with stakeholders and operations peers.
  3. Distribute: Defining the scope and teams
  4. Coordinate: Ensure progress, report, and adjust scope
  5. Measure: Prove the impact of DesignOps and Design
— Anything left in this process will focus on helping execute initiatives
  • What it can look like in practice and theory

 

di15

— Start with the inventory of initiatives out there, with the following process:
  1. Listening tour to interview stakeholders and radiating from design. Identify what issues thre are and give them a name
  2. Consider the impact of the issue and removal
  3. Leverage global DesignOps community to see what solution is
  4. Define projects that can lead to solutions to designer problems
  5. Once initiatives set-up, add structure

 

di16

— In practice, looks like this:
  1. Update list of issues, seen in your design org
  2. Think of potential DesignOps initiatives that solve them

 

di17

— See the above result with DesignOps initiatives

 

di18

— Step 2 Involves prioritizing and figure out initiatives which are both urgent and important

 

di19

— You always need to start with some initiatives and do others later
  • This requires buy-in from stakeholders and you will need stakeholder help
— Prioritize using goal of design org if such a system is not in place

 

di20

— Rank initiative in support to goals and see if it makes sense to start with the initiative

 

di21

— Long list of DesignOps initiatives and rank the ones that support most of the goals

 

di22

— But maybe there are ones you can start right away
  • Big tabular format above can act as a reference point

 

di23

— You can put this prioritization into a roadmap template

 

di24

— Here’s a schematic version of roadmap template for Now, Next and Later Horizons
  • Goes through each initiative and exercise, and which goals are supported

 

di25

— Here’s the format we used at Miro
  • Goals are linked in green

 

di26

— Step 3 and 4 focus on distributing work and DesignOps need help with domain experts like culture builders to execute initiative
  • Need others and give others chance to contribute and  have good design operators
  • Helps if contributing to DesignOps is part of the performance review
— Activities are writing a brief with each initiative an confirming with stakeholders and having them approve time, if they are not part of team
  • Encourage collaboration of team and progress

 

di27

— To summarize these steps, write a brief for all design initiatives

 

di28

— Examples of design initiatives summarized via brief are above
  • Title #ux bug robot– automatically route design bugs to relevant team
  • Goal: improve recovery time
  • Outcome: design org can fix bugs in designs faster
  • Stakeholders: design leaders, QA, IT
  • Team: Tom, Dick, harriet
  • Coordination: team meeting & progress report every Wednesday at 10:30 AM

 

di29

— More DesignOps are suddenly in the process, going back to our chart

 

di30

— For Step 5, metrics allow you to communicate progress and allow you to tell data supported stories

  • Metrics  track progress toward goals and design org metrics
— Your responsibility to help track these metrics and DesignOps metrics with stakeholders to track

 

di31

— The best metrics for  your org, depend on your org
  • Use the list above as inspiration only

 

di32

— After you define DesignOps metrics, you create a dashboard that shows progress continously and per goal have a few DesignOps initiatives to change

 

di33

— Focus on finding a percentage value to change, or some numerical result

 

di34

— Roadmap can serve as dashboard as well, and can update specific number as well
  • Once done, can archive it and then continue to track

 

di35

— If time left, we can still execute initiative, but continue to iterate, ideally quarterly and tweak almost weekly and out of the now circle
  • Move others from inner layers to outer layers

 

di36

— So that is how I suggest you managed DesignOps initiatives for best impact to designers and org

 

FAQ
  1. How long to get from inventory to measurement and how long to step execution?
    1. Inventory took three months and shareable roadmap took time, along with interviews
    2. After that, weekly tweaking and regular sharing with formal updates
  1. What to do when no DesignOps manager initiatives, who to talk to?
    1. Have ear on ground with all peers and ops-folks supporting product managers
    2. Designers themselves are big contributors to generate initiatives
      1. Risk of becoming designer’s psychiatrist, but you can figure out what their biggest problems at all and do need to be addressed
  1. Found DesignOps shifts on emerging needs. How to manage communications on shifting needs?
    1. Tough, as org politics are tricky and changing priorities happens
    2. Review roadmap with design leadership
      1. Helped that I didn’t report to head of design but to head of product excellence– and could say no to design leadership
      2. If you can put yourself in position where you don’t have to listen them, it helps, but trust is pretty good to have.
  1. How to balance tradeoffs between DesignOps, roadmap, and emerging needs of org?
    1. I was one step away from product directions. If priorities shifted, and I was in areas in product needed new or more attention and planning would shift mid-quarter
    2. Mostly matter of tracking with ear on the ground that things were coming along and figuring out how to support them with alternative org charts and what could or could not be done.