The DesignOps Starter Kit — 10 essentials for starting a DesignOps practice

Photo by Jo Szczepanska on Unsplash

My DesignOps Story

This year, I became a Principal DesignOps Manager for the Citrix Product Design team. It was exciting for my managers and me. It was our first official DesignOps role and it gave me a career opportunity that I’ve been waiting for.

For context, we have 60+ people in our product design org and we support three main product areas. Supporting those areas are designers, design managers, researchers, and program managers. In my role, I’m not aligned to a specific product area, rather I support the org as a whole. Since I’m the only one in my role, I currently report to the head of program management.

In the time I’ve been in this role, I’ve learned quite a bit. I pulled together a “starter kit” for what I think is essential in starting a DesignOps practice. Some of the essentials might not be as obvious — some of these snuck up on me and I wish I knew about them earlier!

The kit includes three parts:

• Starting essentials
• Tools to help you
• Tools to help others

I hope these tips help or inspire you if you’re considering DesignOps at your org. If you’d like to talk about DesignOps or think of other essentials, I’d love to hear from you!

Starting Essentials

1. When defining projects, identify ones that will give you wins!

When starting a DesignOps practice, the org is investing in DesignOps and you! This might feel risky to them, so you want to ensure them that this was worth it!

Create projects you feel confident that you can accomplish. When my managers and I were planning out my first steps, we had a list of projects in mind. We picked the ones that aligned with my strengths and ensured I felt good about them. With any project, there’s no guarantee of success. But I wanted to make sure I wasn’t tackling the impossible from the start. At the end of the day, I wanted leadership to say, “We’re so glad we did this. Let’s keep DesignOps, maybe even grow the practice.”

For example, I had projects around improving our products’ accessibility and localization. As a product designer, I specialized in these topics. With that familiarity, I was confident I could help level up our org.

Top tips

• Identify gaps in your org, but leverage your strengths (e.g., operationalizing processes)
• Think about what you’re good at — how can you apply that at scale to a larger initiative?
• Don’t take on too much (e.g., one project per quarter)

2. Think metrics from the start

As you kick off projects, think about your metrics. People will want to know how you’re successful. You’ll want to know how you’re successful. You’ll also want to know if you need more headcount.

Top tips

• Think about the UX outcome. From there, identify the metric that can help measure that outcome. Jared Spool talks about UX outcomes in favor of business outcomes. In some ways, UX outcomes are the center of DesignOps’ success.
• Consider existing opportunities or what metrics the org is OK collecting. Rather than create a whole new survey, there might be a survey you can piggyback on. Sometimes orgs can be sensitive to survey fatigue and they might not be OK with a survey. And as always, you might have to be mindful of the tools and data you’re collecting.
• Consult the user researchers on your team. Sometimes coming up with metrics can be challenging. Whenever I need help, I consult a few user researchers to help gut check my ideas or to provide suggestions.

3. Think horizontally

It’s important to think about design org-wide initiatives, not smaller focus areas. You can even stretch a bit more and think more broadly beyond the design org. For example, how do others think of design and work with the design org?

In my case, I used to only work within one product area. I had to learn more about the other products, their teams, and their dynamics. When implementing org-wide processes, consider how it affects everyone. You might need to adjust or work a little harder to earn their trust.

When thinking horizontally, ask yourself:

• What can everyone benefit from? Where can we provide consistency? For example, everyone can benefit from file and folder structure. If anyone on the team needs to find something, they know exactly where to go.
• Am I truly being inclusive? It’s important that you’re not creating solutions that aren’t inclusive of the whole org. I use a checklist that includes locations/time zones, product areas, and disciplines. This helps ensure I’m thinking inclusively.
• What are product-agnostic opportunities? For example, improving accessibility and localization is something that applies to all products.

4. Decide on the decision-making responsibilities

This is something that I learned the hard way as my projects became more complicated. Our team gets along well, so decision-making comes organically. We only have minor differences in how we approach things. Yet, this isn’t always the case when it comes to high-stakes efforts.

Consider before DesignOps, others used to make the decisions you’re making now. Collaborate on who’s responsible for making decisions and/or providing feedback. The earlier there’s alignment on expectations, the easier complex projects will go.

Top tips

• Be explicit on decision points and feedback points. In project briefs, I’ll list out responsibilities for decision-making and feedback. This is a good opportunity to use a RACI chart, but they usually make my head spin. Definitely use something that works for you.
• Try a decision framework. I’m working on a framework to help identify the decision process for projects. If it works well, I’ll be sure to write an article about it.
• Look for opportunities to reduce decision fatigue. Before DesignOps, others were making all the decisions. DesignOps can handle some of those decisions now. If we can ease some of the decision-making, others can focus on those decisions that need their input!

This is the decision framework I’m experimenting with.

Tools to help others

5. Start small; scale up

Scaling something across the org can be daunting. And in a design org, we all know it’s rare to get things right the first time. Starting small, then scaling our efforts, buys us some time. We can experiment, iterate, and fine-tune things before implementing them across a large org.

When I was a design manager, my team needed a way to articulate work and their capacity. I introduced the idea of story pointing design work and pitched it as a pilot. I let them know that if things went wrong, we can pull the plug and try something else. If it went well, we could share our process with other teams so they can benefit, too. The team was more willing to try since it was a pilot. Things went well and our director wanted to scale this to the other teams. Because the pilot went well, more teams were willing to try this new process. They felt that if this worked for one team, they could see it working for theirs.

Top tips

• Create pilots where you can. Pilots can scale and people are more OK with pilots!
• If you can’t pilot, then get as much feedback as you can from users, stakeholders, peers, and so on. Sometimes time isn’t on your side and you have to go at scale from the start. A quick gut check from others can give you the feedback you need.

6. Document everything — in the moment works best

People will be curious about DesignOps! They’ll want to see progress, gain understanding, and learn more. Documenting everything is a great way to provide transparency. Everyone can dig into details on their own time. Yet, documenting can take up valuable time you might not have.

I used to be someone that took my own notes, then tried to clean them up to share out later. But, as you know, later never comes. And if I did have time later, I would rather spend it doing something else than cleaning up notes.

Out of necessity, I started documenting things on the fly. This worked out well for two reasons. First, I was able to generate notes once. Second, people could visibly see what I was documenting. We could ensure we were all on the same page. If I captured something incorrectly, we could discuss and ensure alignment.

Top tips

• Take visible notes at meetings. This is something that stuck with me from Meeting Design by Kevin Hoffman. If you haven’t read it, it’s an excellent book about running better meetings.
• Leverage tools like kanban boards, shared spaces, and playbooks to document things. Your documentation doesn’t always have to be in a document format. They don’t need to be perfect either. They just need to be a place where people can get the info they need.

7. Communicate — everything

Since DesignOps is an emerging practice, you’re working in somewhat uncharted territory. Also, people will be as excited as you! They might not fully understand what you’re working on or how you’re doing things. People have different mental models of DesignOps. They might have ideas based on a podcast they heard or an article that they read. In my time as a DesignOps team of one, I do quite a bit of advocating for the practice.

In some ways, I’ve become somewhat of a DesignOps spokesperson. Whether I wanted that to be part of my job or not, I have to keep that in mind. I’m responsible for building trust and alignment behind the DesignOps practice.

Top tips

• Communicate as much as possible and in different formats. Different formats resonate with people in different ways. Some avenues I use are design shares, email, Slack, management syncs, and team meetings.
• Things that seem uninteresting to you, might be very interesting to others! For example, I had created our governance model for our design system. After I shared it, I moved to other things that needed my attention. But the directors wanted to take a closer look at our 1–1s. It made sense, this affects their team and products. It was important for me to work with them on the details and nuances so they could feel confident in the process.
• Provide opportunities for questions and answers. Communicating isn’t only about announcing information. It’s about hearing questions or concerns and being available to address them. Wherever I can, I provide space for questions — in the Miro board, at meetings, hosting office hours, etc.
• Be approachable — remember you’re the spokesperson for DesignOps! People are curious and you want to support their curiosity. During official Q&A sessions, I don’t always get questions. But people recognize how open I am, so they approach me later.
• Have 1–1s with stakeholders to provide that open line of communication. This is vital. I have 1–1s every other week with the main design org stakeholders. I use the time to ensure I’m supporting their needs and they, in turn, can support mine. Org-wide change is difficult so it’s helpful to get alignment across at this level.

Tools to help you

8. Create templates on the fly

I spend a lot of time communicating and forging working relationships. I use templates to help streamline my workflow. For me, a template is anything that’s reusable. Examples include diagrams, checklists, team lists, notetaking formats, playbooks, presentations, frameworks, and more.

When I use templates, I can spend more time on content and info sharing. For example, I love InVision’s use of Maslow’s Hierarchy of Needs to describe design system maturity. I repurposed that model to explain our maturity levels for our different efforts. It’s a nice way to show where we are and where we can aspire.

Some examples of how I’ve repurposed the Hierarchy of Needs pyramid

Templates can go beyond tangible tools and diagrams. I use Lisa Welchman’s digital governance framework from her book Managing Chaos. The framework includes policies, strategies, and standards. While her book centers around digital governance, her framework applies to governance in general. I use it any time we need to explain the foundations of our efforts. Some examples include our design system governance, how we run Innovation & Planning (SAFe phase), and as the basis of how we communicate.

Top tips

• Find anything you can reuse; make it reusable for you (and others).
• Iterate and evolve, then share templates so others can benefit, too.
• Have a collection of assets to quickly jump from. I’m in Miro throughout the day, so I have a board that contains all my most used or favorite diagrams and templates. It takes the legwork out of things, so I can dive into content.
• They don’t have to be masterpieces either! Scrappy is fine! Templates don’t have to be perfect, they only need to work for you. Many of my templates are checklists of sticky notes. At some point, I can refine them, but for right now, they get the job done.

Example of a playbook — I started with one and the format worked so well, that we have over a dozen and others are using this format, too!

9. Create a backlog

Creating a backlog helped with my sanity. At the start of this year, I had four major initiatives (one a quarter). People heard about them, which inspired them and they wanted me to do more. While it’s all exciting, I needed to focus and ensure the success of the DesignOps practice.

Also, I noticed people started to understand DesignOps in their own special way. I would get a lot of, “Doesn’t DesignOps include [random task]?” or, “Isn’t [random task] Michelle’s responsibility now?” Sometimes the answer was, “Yeah, probably, but I’m so busy right now.” Sometimes was, “Oh heck no, that’s definitely not a DesignOps thing.” And sometimes, no one was sure.

Creating a backlog can help you and others pace and define the DesignOps practice.

Top tips

• Create a shareable backlog. My backlog is a kanban in Miro. People can add project ideas to the backlog and they can see how I’m making progress on the other initiatives. They can open a card to deep dive and see its progress.
• Review the backlog. It’s a good habit. I noticed several small things can group into a larger effort. Sometimes, things can join existing projects. Some might be initiatives to consider for next year’s strategic planning.
• Look out for yourself! As DesignOps people, we love helping people and making sure things happen. This can come at a cost to us, so definitely keep an eye on your capacity and sanity. Focus on your goals for the year, because you want to ensure DesignOps is a successful practice. I went beyond my four projects for this year, but it felt more controlled. The backlog helped me get a sense of what I could and couldn’t take on.

10. Keep learning and growing

Peers might not be as readily accessible, but you’re not alone in this emerging field. There’s a whole tribe of operational problem solvers. Many of them have or are tackling similar challenges to you! This is nice because you don’t have to reinvent the wheel every time; you just need to find the wheel that fits your car.

Top tips

• Seek inspiration — Slack communities, Medium articles, webinars. A few of my favorites are the DesignOps Assembly Slack and The Rosenfeld DesignOps Community monthly calls. For Medium, I usually search “DesignOps” to see what new articles surface.
• Observing is fine, but engaging is even more helpful! Everyone in the community is nice and supportive.
• If you’re into books, here are some of my favorites for DesignOps: Managing Chaos (Welchman); Org Design for Design Orgs (Skinner & Merholz); Meeting Design (Hoffman); Gamestorming (Gray, Brown, Macanufo)
• Talk to other Ops people at your company. If you’re from a larger company, there’s likely dev, sales, HR, business, or product ops. They might not align with DesignOps, but they may have insight into navigating processes within the company.

You’re ready!

I hope you find these ten essentials helpful if you’re starting a DesignOps practice. As you evolve DesignOps at your org, the biggest thing you can do is celebrate team wins.

DesignOps is a lot of change management and change is hard — especially in these past 19 months. We’ve had change and pivot in ways we didn’t want to. So celebrate when you can. Sometimes it can be a “Go team!” message on Slack and other times it can be a virtual party with prizes. Celebrating is a great way to build confidence and trust in the DesignOps practice.

Please reach out if you try any of these essentials! I’d love to hear how they go. Also, comment if you have questions or other essentials to share.