Designers radically believe that Design can solve anything.
Say it with me:
“I’m a designer; I radically believe that Design can solve anything.”
I work with designers that have many different titles. Some design visual interfaces for people with functioning eyeballs. Others design ways for machines to talk to each other. Still others design how employees celebrate important career milestones.
I radically believe that Design can solve anything—Including the experience and impact of designers at my company, Keap.
I believe that our designers deserve to take joy from their work, grow as much as they are able, and have an ever increasing positive impact on our company. There’s a lot that rolls up into that, which means there’s plenty of work to be done! Turns out, there’s a name for this focus: DesignOps.
Like DevOps, MarketingOps, EmailOps, and other -Ops roles, this is about improving a strategic aspect of our business. At many companies, this role comes with a management title and people management responsibilities, but here’s how we’re doing it at Keap.
DesignOps is Design Thinking for Organizational Change
When taking on a DesignOps initiative, we go through a Design Thinking process to solve problems for designers.
We research our users to uncover pain points and areas where we can provide value. These users could be designers, product managers, directors and sometimes executives or others.
Like customer research, this looks like surveys, interviews, ethnographic research, and usability studies. It also helps to gather baseline quantitative data if it’s available.
We often use this research to create empathy maps or journey maps for our “users.”
Next, we’ll list out the pain points we uncovered and rank them by effort and impact. We select the specific problem we’ll solve and define the measures that we will use to determine whether and to what extent we were successful.
Like product research, we’re looking for value metrics—Things like adoption of a tool or process, sentiment, and attrition. We’ll also look at performance metrics and costs. We’re careful about how we measure these because often we’re dealing with people here, not interchangeable parts of a machine.
To begin ideating, we’ll get a group together to explore a variety of solutions to the problem. Instead of UI sketches, we might sketch out seating charts, or org designs, or document layouts. Or we might explore a hiring journey or the hardware procurement process. This is where we’ll diverge on lots of ideas, then converge on one or two to prototype.
This is just Design Thinking applied to something other than user interfaces. Do you see yet that Design can solve anything?
We figure out the leanest way to prototype your possible solution to your problem. Instead of building a new process complete with hooks into Jira or Slack, we’ll try the process once or twice manually. Instead of rolling out a tool change to the entire team, we pilot it on one project or with a small group for a short period of time.
To test, we’ll record the results of the pilot or prototype, then determine how to improve it before a larger rollout. Often, we communicate the results of the experiment out to the organization and move forward.
Our work is never done! We pick a time—often right away—to begin work on the next version of the solution. We polish it until the potential impact of further iteration no longer outweighs the effort required. Then, we move on to another meaty problem.
The Designer Experience is a Product
When I started writing this, I didn’t intend this little article to be a treatise on the Design Thinking process. But the more I think about it, the more it fits. Any DesignOps initiative I’ve taken on has worked this way. That includes our Design System, designer onboarding process, and aligning on a standard tool stack. It all starts with listening to your people and empathizing with them.
Turns out that the Designer Experience is a product that needs design like any other product or experience. Who knew?