DesignOps is all the rage these days. Unfortunately, a quick search on the term brings up radically different meanings. When I talk about DesignOps, I’m aligned with Kate Kaplan’s definition in her post at Nielsen Norman Group.
Definition: DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.
In other words, DesignOps is design operations—all of the elements and components required to support, enable and deliver on the design team’s efforts. (I include research, but not development, as part of the design team.) However, DesignOps is becoming a term of art: specifically associated with the notion of rapid design iterations a la DevOps. In this article, I will use the term Design Ops (two words) as a short form of design operations to distinguish it from the industrialization of design denoted by DesignOps.
Design Thinking is all the rage these days as well; a quick search on that term returns a variety of definitions, frameworks and approaches. In this article I use Design Thinking to mean the activities in service of delivering a design solution (excluding development).
If we really believe in design thinking as a framework, why aren’t we using it as the basis for as much of our operations as possible?
Which Design Thinking Framework To Use?
I use a variety of Design Thinking frameworks, depending on my goal or my audience. In general, when I work with management, I use the UK Design Council’s Double-Diamond diagram (UKDCDDD). It illustrates the ideas of divergent/convergent processes, the problem/strategy space vs. execution/tactical space and the notion of a decision point.
I use Owen/Kumar/Sato (OKS) framework (created originally at the ID-IIT) to easily illustrate the variety of user experience (UX) activities that occur in each quadrant. The four-square format also allows me to easily show how upstream activities connect with and feed downstream activities.
In any event, I modify their labels to show that the four phases map back and forth.
In the context of Design Ops, the OKS model supports a wide variety of elements:
Scoping an engagement
Managing and tracking effort on an engagement
Decomposing an engagement into specific activities
Hiring new team members
Developing team member careers
Connecting UX engagements with other disciplines (playbook)
Measuring an engagement’s outcome (KPIs)
Some of these might seem controversial or provocative, but I’ve implemented almost all of them, except one. I’m still working through how to establish KPIs based on a DT framework.
Scoping an Engagement
I’ve written extensively on using Design Thinking in service of scoping work in a five article series at UXMatters.com. In brief, I use the “4D” design thinking phases (Discover, Define, Design, Deliver) to segregate activities. I then assign costs to each of those activities. During the process of scoping a new engagement with my stakeholders, I review each activity in the context of its design thinking quadrant. I use this approach to help clarify to stakeholders how activities build on one another, reducing the mystery of the proposed work.
Managing and Tracking an Engagement
I use the same documents and approach throughout the engagement to manage the effort. The documents clearly display to stakeholders the progress of (and amount of spent on) the project to date.
But I also use the design thinking phases to help manage and track individual team member assignments. This takes the form of a Kanban-style board.
In the board shown above, each engagement is a row, and each team member is a column. Within each intersecting cell, a team member places a grid representing the OKS Design Thinking framework. The team member then places one of four push pins (representing a 4D activity) in the quadrant of the grid.
Each pushpin represents 20% of the team members’ time; at most they should have four push pins on the board. Notice, for example, the lower rightmost grid in the detail above: it has three red pins and one yellow pin. In this case, the team member is spending about 60% of their time in the Definition phase and 20% in the Design phase.
By scanning the columns, anyone in the organization can quickly see what a team member is working on and what phase of that work they’re in. Similarly, by scanning the row for an engagement, a stakeholder can immediately see who is working on it, and what phase of the design thinking process it’s in.
This visualization renders the design thinking framework in another way. The Key displays an aggregate indication of the design thinking phases in which the entire team is spending its time.
The push pins “double-encode” what phase the individual is working in. Their color and position within the grid identifies the design thinking phase: blue=Discover, Red=Define, and so forth. But the Key also reveals the whole team’s level of effort in aggregate across all of the engagements. The fewer the remaining pins, the more the team is working in that design thinking phase. At a glance, stakeholders can tell where the organization as a whole is focusing its efforts.
Decomposing an Engagement
The document I use to scope and manage an engagement requires that I decompose it to its smallest parts. Again, see the UXMatters articles for all of the details. In brief, each quantized activity in the scoping document represents a unit of work a team member will be performing. By reducing the engagement to its smallest constituent parts, I can identify what resources may be required. Not all team members can do all of the quantized activities. If an engagement requires a specific activity for which I have limited resources, I may need to hire a contractor, or negotiate with the project lead to adjust the schedule.
Hiring and Developing Team Members
I apply the 4D framework when I define a job, and when I work with team members on their career development. I start with the usual skills matrix most organizations use, but I modify it to conform to the 4D framework. I expect team members to be proficient in a variety of skills, distributed across the 4D landscape.
For hiring, I look across the entire team to see where our skills gaps may be. Alternatively, depending on the strategy that’s driving the hiring, I identify what skills will be required. I then write the job posting accordingly. I use the same tool as part of a toolkit for team member career development. Each UXer is asked to self-evaluate on a scale of 1-5 their expertise on each skill. I also evaluate them, and we compare notes.
In our discussions, we focus on the skills in which our respective evaluations differ by more than one point. In some cases, we adjust our numbers. Perhaps the team member has been too self-critical, or perhaps I’m unaware of skills they have. We then look at where their skill gaps are with respect to where they want to be. We use the matrix as a guidepost to identify training opportunities as well as to track their progress.
Aligning UX Work With Other Disciplines
The most obvious place to use a Design Thinking framework is in describing the UX team’s work and process. But simply showing how the team works in a DT framework fails to show how the team works with others in the organization. I use both the UKDCDDD and the OKS model as part of a UX Playbook. See my series of articles at productcraft.com for details.
The key points in those articles include:
Design Thinking can be a powerful way to improve desired outcomes for the product teams if it is well socialized. Everyone involved in an engagement needs to understand who is doing what activity when
Design Thinking occurs at different scales. At the macro-scale—the scale of an entire program, for example—DT helps teams think laterally or prune as appropriate. At the mega-scale—when teams need to validate a problem, or define an epic, for example—they use DT to focus in.
Measuring UX Performance (KPIs)
All of the above I’ve used over the past several years to great advantage. Applying DT within the operations of my department has made it much easier to integrate UX into an overall operational system. But Ops is all about measurements and numbers. As leaders we are asked to identify Key Performance Indicators (KPIs) to be held accountable for our work.
Can DT be used in some way to support a KPI? I have proposed a way to address that question but haven’t had a chance to test or implement it. If we believe that by moving through discovery, definition, design and delivery we produce better outcomes, what measurements would support it?
Should we measure the number of cycles (completing the 4Ds) a team member (or the team in aggregate) goes through? Would we be able to show that teams who went through more cycles created better outcomes?
If we believe that moving through discovery, definition, design and delivery produces better outcomes, what measurements would support that belief?
Should we measure whether a team (or team member) hit all of the OKS quadrants during an engagement? Would teams that touched all four quadrants deliver better results than teams who didn’t?
Perhaps the measurement focuses on how well a team or team member uses the tools within each quadrant. Or maybe the KPI is about how effective they are in both identifying the right tools and applying them.
This topic is very much still a work-in-progress for me. What are your thoughts? I’d be interested in learning more about how you’ve approached DT and KPIs. I will be exploring the idea further with my teams and give an update of what I learn.