My path to DesignOps, from consultancies to in-house

I knew design was being taken seriously when the firm where I worked, Hot Studio, was acquired by Facebook, joining a wave of design acquihires. Around the same time, Accenture acquired Fjord, Capital One acquired Adaptive Path, and Nurun acquired Odopod. Large organizations realized that one way to quickly scale teams was by acquiring design firms.

One thing all of these design firms had in common was a staff who knew how to work with creatives and clients, and who could manage projects efficiently. Through these acquisitions, the role of DesignOps was introduced into larger organizations, which demonstrated just how valuable design operations can be when strengthening product teams.

Margaret Stewart, VP of product design at Facebook, embraced this opportunity by ensuring there were several DesignOps members on her team—including me, during the Hot Studio acquisition and transition. Today, there’s a growing DesignOps team of more than 40 design program managers at Facebook.

Jasmine Friedl, formerly a product designer at Facebook, is now the director of design at Udacity. Here’s how she recalls the integration of the role of DesignOps at Facebook:

---

While our leaders saw the value of design, many parts of the largely-driven-by-engineering company had a learning curve to understand how we were more than just pixel-pushers. The role of design program managers was crucial in that: to set expectations, get the right people with the right skills on the right projects, scope phases, and manage those expectations to delivery. We saw this first become a pertinent part of the ads organization, and later the design organization as a whole, where design program managers facilitated, organized, prioritized, and wrangled people, events, and initiatives on everything from product to culture.

Jasmine Friedl

Udacity

While our leaders saw the value of design, many parts of the largely-driven-by-engineering company had a learning curve to understand how we were more than just pixel-pushers. The role of design program managers was crucial in that: to set expectations, get the right people with the right skills on the right projects, scope phases, and manage those expectations to delivery. We saw this first become a pertinent part of the ads organization, and later the design organization as a whole, where design program managers facilitated, organized, prioritized, and wrangled people, events, and initiatives on everything from product to culture.

After some time at Facebook, Pinterest called me. Bob Baxley was head of design, and he wanted someone to help steer the design ship and run operations for a small team. While it was very much a to-be-defined position, we both knew the DesignOps role could make the design team operate more efficiently, and allow the designers to focus solely on design. After four years in this role, I’m excited to share what I’ve learned about what DesignOps can look like in an organization.

Getting buy-in for DesignOps

Adrienne Allnutt and Kalee Dankner discuss how LinkedIn approaches Design Ops, from sharing work out to other teams to building cross-functional relationships.

Because not everyone is familiar with the role of DesignOps, introducing it into your organization can be a challenge. You’ll want to prepare an explanation of the role and how it benefits your organization.

DesignOps makes teams run more effectively by letting designers focus on design while leaving everything else to the operations team. Many organizations expect their designers to wear many hats—project manager, cross-functional partner, creative leader, and logistical coordinator. However, these additional roles reduce the time your designer can devote to your product and users.

While it may take some convincing to hire for this role, the ROI will appear quickly. Teams will be better organized, leadership will gain a better understanding of what makes their teams tick, and cross-functional teams will have more visibility into—and a better understanding of—the design process. This creates better organizational awareness of design, and mitigates misconceptions that “designers design in a black hole” or that design projects take too long.

---

Many organizations expect their designers to wear many hats—project manager, cross-functional partner, creative leader, and logistical coordinator. However, these additional roles reduce the time your designer can devote to your product and users.

Meredith Black

Pinterest

Many organizations expect their designers to wear many hats—project manager, cross-functional partner, creative leader, and logistical coordinator. However, these additional roles reduce the time your designer can devote to your product and users.

Some tips for DesignOps buy-in:

Do the research

Talk to your heads of design, product, and engineering (and any senior leadership within your org you have access to) to assess opportunities available in the current product teams.

Here are some possible conversation starters:

• Do you have visibility into what the design team is working on?
• Do you know if the team is working well cross-functionally with product and engineering colleagues?
• Does the team have clear and actionable goals they are driving toward, and are they meeting them?
• Are there regular design critiques or feedback sessions?
• Are the product manager, engineer, and designer aligned with what’s shipping?
• Is the team meeting deadlines?

Propose a plan

Propose a set of essential tasks that DesignOps could help contribute to.

For example, DesignOps can help a product manager operationalize a roadmap, make sure that the team has proper kick-offs on projects, and ensure a design QA is scheduled prior to a major product launch.

Recommend the role

Recommend to your leadership team that you would like to hire someone into this DesignOps role to tackle the opportunities surfaced in your research—someone who will develop a long-term plan to scale operations on the team.

Keep leadership involved

Invite your stakeholders to interviews, and keep them involved throughout the interview process.

Spread the good news

Update your stakeholders on successes and the impact this hire is making in this role. You want to make sure leadership sees the positive outcomes this role creates.

Staffing for DesignOps

Staffing for DesignOps will depend on both the makeup of the design team and the culture within your organization. Some design teams might appreciate tenacious and driven people running projects, while other organizations might require a lighter touch.

Regardless of the situation, there are some universal qualities and skills to look for in a DesignOps candidate:

1. You want someone who can build cross-functional relationships while representing design, and who understands the design process. These relationships will necessitate understanding the product development process and product engineering principles.
2. The role calls for excellent project, time, budget, and resource management, and an understanding of different project management ideologies (like waterfall and agile, among others)
3. Finally, this role calls for calm in ambiguous and changing environments

One size doesn’t fit all. It’s okay to take the qualities above and get creative, which is something I did when I hired two candidates from an organization outside the typical design path—the United States Navy. Both had experience navigating a large organization with different types of people and multiple missions and goals. In my case, the qualities and experiences perfectly aligned with our team’s needs.

How do you screen for these qualities?

Most hiring processes begin with a recruiter or hiring manager initiating a phone screen with the candidate. I usually ask that the phone screen include a few ops-specific questions, like “What are your strengths when it comes to operations?”

Another way I determine organizational fit is to ask the candidate to describe whether they enjoy variety and change, or a more regimented day with clearly defined daily tasks. If the phone screen goes well, set the candidate up to speak to future collaborators—designers, of course, but also consider representatives from engineering, research, writing, and product management.

Each interviewer should take careful notes, as you’ll all want to debrief after the last chat. Compare notes and determine if the candidate aligns with your team, your project management needs, and demonstrates the skills to work both cross-functionally and closely with the design group. And be sure the entire team is excited about working with this potential colleague!

A yearlong plan for integrating DesignOps

Day one

Now that you’ve hired this person, you want to set them up for success. On day one, welcome your new hire onto the team, perhaps with a special event. At Pinterest, we used a weekly Wednesday coffee event called “Fika,” where a colleague would bring in a treat they discovered from Pinterest, to create a calm and welcoming environment.

Week one

With day one out of the way, the rest of the week should allow your new DesignOps hire to build relationships within and beyond the design team. Set up 1:1 meetings with the right people for your new hire, and encourage them to learn how design works in your org, what designers need help with, and what opportunities there are for this new hire to help.

Month one

Now that your hire has made it through week one intact, for the next couple weeks, they can start exploring how to make the design team operationally efficient.

Year one

What follows are a few initiatives for your new hire to focus on based on the needs of your organization. Covering all of the recommended areas will take at least 6–12 months to implement, and will most likely take the work of more than one person.

Throughout this first year, make sure you’re tracking the performance of this role and communicating it—this will allow colleagues across your organization to see the value of the role, and will allow you to build a case for even more DesignOps hires.

---

DesignOps doesn’t just help the design team—it benefits all parts of the product organization.

Meredith Black

Pinterest

DesignOps doesn’t just help the design team—it benefits all parts of the product organization.

A menu of DesignOps initiatives

Resourcing

Align your headcount to your roadmap by thinking about resourcing: who should be doing what and when?

• Develop a template or guide to help identify the strengths of each designer on your team and how they can best contribute to different types of projects
• Audit whether the design team is set up for success—are designers on projects that suit their skills and strengths?
• Meet with design leadership each week to ensure that company priorities are being suitably staffed

Program management

Begin to shape the design process by instituting communication and collaboration protocols.

• Create a short (30 minutes should be enough), weekly visual status review with your design leadership team. This will allow everyone to quickly go through each design, spot any overlaps on projects, ensure the product design is up to design spec, and ultimately solicit approval before launch.
• Carve out weekly dedicated studio time for designers to catch up with other designers. For designers embedded on cross-functional teams, this is an opportunity to talk about projects, share designs with someone outside their usual cohort, and contribute to developing a strong design culture.
• Schedule weekly design critiques for each design team. These critiques are an opportunity for peers and design leadership to review work, provide feedback, and maintain high design standards. As the DesignOps program manager, your responsibility doesn’t end with scheduling the crit, but includes set-up, ensuring designers are ready to present, and following up with clear and actionable next steps for each designer.
• Deliver weekly status updates to and beyond your team. At Pinterest, we send out a visual status document every Monday morning that lists what everyone is working on and shows design comps from each team. This keeps our design org of 60 people up to date on what other designers are working on, and also serves as a guide for our cross-functional teams to understand what everyone is working on.
• Establish credibility and become the source of truth for your team. Once in place, the preceding items will lead to this happening. Courtney Kaplan, head of design program management at Facebook, describes herself as “the human Yelp. People come to me when they need answers.”

Team onboarding

If you’re putting DesignOps in play, you’re likely increasing headcount. Demystify the onboarding process for everyone by creating documentation and protocols.

• Develop an onboarding doc for new designers and design team members. Make this a team effort—this doc should include everything you and your colleagues wish you knew when you first started. Think about things like file saving and naming protocols, master calendars, email aliases—even where to grab a bite to eat.
• Pair up new designers for training and meeting other members of the organization, when you have two or more new design team members starting at the same time. This shared experience can be the foundation for building tight bonds and a strong culture on your team.
• For a larger organization, consider scheduling design-specific onboarding in addition to company onboarding. Work with your hiring team to build a curriculum that sets your new hire up for team and org success.

Team morale and education

A design team requires inspiration, collaboration, and continuing education. Establish how you can facilitate both individual and group growth.

• Plan team offsites to get your designers together at least once per quarter as a team. This doesn’t have to be anything more than ordering (a lot of) pizza, stocking up on LaCroix water, and procuring a soccer ball. The important part is that everyone gets together and teammates have a chance to bond.
• Provide educational opportunities for the team by hosting experts who can level up everyone’s skills. This could be a class on how to use a complicated bit of software more effectively or a presentation of a case study by a respected peer outside the organization. If possible, extend an invitation to the local design community by hosting events like Creative Mornings or AIGA Design Week.
• Schedule regular design speakers for lunch brown bags or coffee hours.
• Make time to take your designers on inspirational field trips. If your team is distributed, signal that this is an acceptable use of company time and encourage your designers to find nearby inspiration.
• Hold a monthly all-hands meeting for the design team. Curate this to include a mix of education, presentations of work in progress from designers, any updates you might have for the team, and some time for folks to get to know each other.

Strengthen team bonds

Pinterest’s head of brand, Sadia Latifi, came up with a variation of “Inside the Actors Studio” where she does background research and asks interesting questions about a designer. It’s been so well received that I started doing my own version at our product design all-hands meeting.

Here’s how it works:

1. I choose one member from the team and ask them to introduce me to their mother, a significant other, or a friend.
2. I email that person a series of questions, and we review the answers with the designers in front of the whole team.
3. Sometimes this even includes baby pictures and prom photos. It’s the best part of the all-hands for everyone.

Budgeting for design

To advocate for the design organization, you’ll want to understand how design fits into your organization’s larger financial picture.

• Meet with your finance team to understand how the company operates. You’ll want to know about accounting systems, the fiscal calendar, team budgets, and how headcount is allocated.
• Share this information with your design leadership team—everyone should understand the financial constraints and opportunities.
• Track all design team expenses, and establish approval processes for expense requests. For a large team, you might even provide each designer with a discretionary budget for the tools they need to perform their work.

Supercharging your DesignOps program

Let’s jump forward in time. The team is running smoothly, and you have a good sense of everyone’s needs. Now it’s time to think beyond design critiques and budgeting.

Though a heavy lift, a product design system is a worthwhile investment of time and resources. A design system enforces standards and gives everyone a common language and starting point.

Shifting from digital to physical, a workshop program offers designers a dedicated space to perform special activities. At Pinterest, we have one design program manager dedicated solely to running our workshop—a room that teams can book to run design sprints, kick off projects, or work through a tricky problem.

The workshop provides an opportunity for designers to move into a new environment and run an IDEO-style workshop to generate new ideas, work through problems, and return to their project teams with clear and actionable next steps.

Final thoughts

Establishing DesignOps is just the start of this work. You’re going to need to make sure this role remains top of mind within your organization by keeping the lines of communication open within and outside the design org.

It takes work, but share team and individual wins with stakeholders, and gather the stories that demonstrate the value of DesignOps. If a project would have fallen through the cracks, or a product launch went off without a hitch, or the team has gotten better at communicating design feedback, it’s on you to share this high and low.

Champion this role. DesignOps doesn’t just help the design team—it benefits all parts of the product organization. Be deliberate and thoughtful as you put DesignOps into play, and keep in mind that there is no right or wrong way to do this—it’s all about what’s best for your design org.

At this point, you know a ton about DesignOps. And the fundamentals of DesignOps are transferable to thinking about research operations (ResearchOps). ResearchOps gets its own chapter here for two reasons. First, it’s tightly related to design. Second, research calls for very specific approaches to people, workflow, and business operations.

The mission of research

Research helps gather data from inside and outside the organization to derive actionable insights that drive both strategic and tactical decision making.

The data that feeds research comes from a variety of sources:

• User research
• Ethnography
• Interviews
• Remote and in-person moderated and unmoderated testing
• Journaling
• Participatory design
• User activities (purchases, usage, site, and app analytics)
• Market research
• Analyst reports
• Support and sales logs
• Customer interviews

Organizing research activities to discover insights—and then making those insights actionable—requires attention to many operational concerns. This is especially true as you scale your research organization and your org as a whole.

In this chapter, we’ll discuss the considerations and special needs unique to user research, as well as how it intersects with design and other parts of the organization.

---

Research helps to gather data from inside and outside the organization to derive actionable insights that drive both strategic and tactical decision making.

Dave Malouf

IxDA, Design Ops Summit

Research helps to gather data from inside and outside the organization to derive actionable insights that drive both strategic and tactical decision making.

People operations

The difference between the people and community operations for DesignOps and ResearchOps is organizational structure. Though there are many ways to organize research in an organization, the context and makeup of your team will determine the right path.

Some questions that might help you shape your research structure include:

1. Is research a practice unto itself, or is it practiced by people tied to other functional roles (like design, product management, or development)?
2. Who leads which types of research activities?
3. Do researchers plan and execute all the research for the benefit of others?
4. Do designers and product managers lead their own research initiatives?
5. Who do researchers report to?
6. What other types of research does the organization conduct—market research, data science, and analytics?
7. If market researchers or data scientists are conducting research, who do they report to?
8. Does research function as a service agency to the entire org, or are individual researchers assigned to specific teams?

The different answers to these questions changes both the people operations (PeopleOps) and ResearchOps contexts. To illustrate, let’s imagine a scenario that will allow us to create a scaling team structure:

You’re the head of design for a growing and maturing design team. When you joined, the design team was eight-people strong, and the team lacked a dedicated researcher—all the designers did their own research.

Now the team is up to 10 folks, and you’re ready to start adding dedicated research practitioners. You need them to:

• Scale design research, especially in areas that are horizontal to all products
• Operationalize research so designers can more efficiently and effectively do the research they were already doing
• Evangelize and coach research, analysis, and synthesis methods to make results more accurate and actionable

This first person you hire is a lead researcher. This is a senior role that will convert to a manager in a short period of time. This hire might be at the management level now, but wants the challenge of building a research organization from the ground up and is willing to be an individual contributor for a short while until more headcount arrives.

The lead researcher’s first hire will most likely be a junior, focusing on partnering with designers for their larger vertical research efforts, and for managing discrete aspects of the ResearchOps process.

A research team might start out as part of the design organization, since the designers already practice research in their work and likely come from a traditional UX background with a healthy respect for qualitative research. Alternatively, research might work as part of a data science group, or parallel to design, or as part of a product management team.

Once the team is large enough, the design research team might even run parallel to both design and product management. At scale, this team might run parallel to the entire product organization as a new “Insights” department that includes data science and market research.

For the purposes of this chapter, we’ll assume research is part of the design organization as we discuss operationalizing research.

With a structure in place, the next consideration is the ratio of researchers to the rest of the organization. Let’s jump ahead three years:

There are now 25 designers across 15 product teams, each with its own product manager. Each product team may have at least one scrum-based agile team of eight people. To serve this product organization, you spin up a new design research team made up of the following people:

• A manager of design research
• Four senior design researchers, two of whom handle qualitative methods (interviews, ethnography) while the other two tackle usability issues
• Two junior or associate design research generalists—likely recent graduates

This team is about one-third the size of your design organization, but you will need to adjust this based on capacity planning, how extensive your research initiatives are, and how much non-user research your design research team needs to be doing (quantitative studies, analytics, market research, and analyst reports).

Physical and virtual space

Research and design share a lot of the same space parameters. Both want workshop spaces with whiteboards and room for Post-its. Both want a flexible space that can be reconfigured to meet their needs with minimal effort. And both require space that can be reserved for the length of a project and possibly beyond. Physically, it should be easy enough to “get a room,” so to speak. Virtually, there are plenty of tools and systems that can facilitate research when team members are not in the same room.

Physical

One space unique to research is the usability lab. A lab calls for equipment that needs to be selected (measuring, recording, and communication devices), a space architected into a proper test environment (proper lighting and sound set-up), and ongoing maintenance to keep everything humming.

Eventually this might call for a lab manager who keeps the space in tip-top shape and administers all the equipment. A lab also serves as a storeroom for equipment like cameras and microphones that are used both in the lab and the field.

Along those lines, you might require a mobile device lab stocked with different devices and configurations of software and hardware. This is especially true if you maintain legacy platforms.

Lab time is coveted by researchers, so you’ll need a system for managing access. While first come, first served on a shared calendar can work, you’ll likely need to implement some evaluation criteria based on project priorities.

When you bring folks into a lab, you need everything to run smoothly. Your lab manager or tech support might need to be on standby in case of any unanticipated glitches. And don’t forget to be hospitable—where will visitors wait for their interviews or tests? Will you provide drinks, snacks, or lunch? The user experience extends to the lab.

Virtual

For research that doesn’t take place in a lab or dedicated space, you might use services like Optimal Workshop, UserTesting, UserZoom, or Validately, among others. These are paid platforms that allow you to run a mix of moderated and unmoderated tests of interfaces, scenarios, and content. You may also use data capture software like Mural, Optimal Workshop, AirTable, Smartsheets, or others.

Note that you’ll want someone to keep track of which platforms you’re licensed to use, and when those licenses expire. Similarly, you’ll want to track which platforms you no longer use to avoid recurring charges that eat into your research budget.

Some usability testing teams simply rely on video conferencing services. However, you might want to juggle more than one conferencing service—many enterprise organizations don’t allow individuals to install their own apps on their work computers. Keep this in mind if your research will require you to speak to members of an enterprise organization, and have conferencing options in mind.

Workflow process and tools

The biggest parts of operationalizing research revolve around workflow and tools.

Project intake

You’ll need to give your team a transparent intake process for the evaluation and prioritization of projects. This ensures that everyone—stakeholders especially—can see the right projects are prioritized based on sound business reasoning.

The people who request research don’t always know exactly what they need, so your intake process might require a discovery process. Discovery is often run against a template that frames the criteria required for moving a project to a planning stage.

Recruitment

Participant recruitment, scheduling, and incentive management are probably the hardest things about user research. How do we get people to invite us into their homes or offices or workspaces, where we can observe them performing the activities we want to design for?

Participant database

Around your fifth or sixth usability test, you start to see the need to manage your subjects in a database. Any spreadsheet works; I prefer Airtable because it’s incredibly easy for creating relational tables that mesh lots of different data and metadata.

Why a participant database?

• A pool of customers who have opted in to research projects makes it quick and easy to recruit participants and provides you with a better response rate than contacting people you have no information about
• A database helps track schedules and incentives
• In a system like Airtable, I can track participant information across multiple projects to build a richer analysis of each person
• Finally, tracking participants ensures that we don’t go back to the same customer too often

Engagement tracking

An engagement is a single session (a usability test, interview, etc.) that a team has with a user or customer during a project. Engagement management is similar to project management, on which we add a layer of engagement data to track.

These are the engagement data points I recommend tracking:

1. Project information

The project information is analogous to what you’d find in typical project management—project name, project description, current project status or phase, research type (exploration, generative, evaluative), research methods, expected project duration, budget, and team.

2. Engagement information

All of the above could be managed in a project management tool like Trello, but this system doesn’t readily extend to the additional engagement data points we want to add or link to.

For each engagement, we’ll want to state (or link to) the project name and participant (who is ideally in our participant database!). If we could get the participant data out of a company Salesforce account, even better, as this would likely include contextual information like the participant’s company, role, and tenure at their organization.

As for the actual engagement, we’ll log the date, location, and duration of the engagement, as well as who was there and what their role is. Be sure to note where the engagement took place (lab, field, somewhere else), and which of your products or services this engagement related to (if any). If you took photos or collected artifacts, be sure to link to those assets, as well as your own notes.

Speaking of assets—consider how these are stored and shared. Every engagement offers an opportunity to add visual and audio documentation, which should be connected in some way to your engagement tracking system.

Data curation and consolidation

---

A repository of research data prevents you from the Groundhog Day scenario of repeating the same queries and answering the same question.

Dave Malouf

IxDA, Design Ops Summit

A repository of research data prevents you from the Groundhog Day scenario of repeating the same queries and answering the same question.

One of the biggest issues a scaling research team faces is that the data is everywhere. In Seeing the Elephant: Defragmenting User Research, Louis Rosenfeld recounted the fable of the blind men and the elephant. In this story, a group of blind people are near different parts of an elephant, trying to guess what animal it is based on what they can feel. Individually, they can’t understand that it’s an elephant and fail to identify it. (Personally, I always thought the smell would give it away…but that’s just me.)

The fable illustrates that when trying to understand an enterprise organization, the data comes from many equally relevant sources: marketing, sales, support, product management, usability tests, analytics, data science, and, of course, user research. Each source comes in different formats, from different lenses and points of view, and via different data collection methods.

Repositories

To ensure your research synthesis has considered the entirety of the problem space, it’s important to aggregate all of these data sources. Not only does this provide you with the complete picture and minimize that your insights are offbase, but it prepares you to answer critiques of your findings from those versed in those various data points.

A repository of research data also prevents you from the Groundhog Day scenario of repeating the same queries and answering the same question. When you store data, and make it easy to access (with help from solid metadata), you make it easy to find and reuse existing information.

Insights

Researcher and author Tomer Sharon believes that the most valuable deliverable from a research organization is not the data, but the insights that are generated from that data. To him, the ability to create and share credible insights across an organization is how a research team generates the most value.

Many teams have tried to create insight repositories that are widely accessible to their respective organization. Some examples include Mosaiq by Nasdaq and Polaris by WeWork. Additionally, products like Aurelius, Reframer, Nomnom, and Dovetail seek to fill this niche. Other organizations seek to solve for this by repurposing wikis, blogs, or visual spreadsheets like Airtable.

Synthesis

It isn’t design (or research) until there are Post-it notes, only now those post-its might just as easily appear on a screen as they do on a wall. Remote and distributed teams are becoming more common, as are digital tools to create common research artifacts like canvases, affinity diagrams, and other synthesis methods for teams separated by time and location.

If you’re thinking of operationalizing research, think about the processes that lend themselves to documentation, decision paths, and archiving. While IRL whiteboards, notes, and giant rolls of paper are great for collaborative research, digital whiteboard spaces offer advantages like commenting, history, and photo insertion… not to mention templating, version control, and easy access to older files.

---

If you’re thinking of operationalizing research, think about the processes that lend themselves to documentation, decision paths, and archiving.

Dave Malouf

IxDA, Design Ops Summit

If you’re thinking of operationalizing research, think about the processes that lend themselves to documentation, decision paths, and archiving.

Business operations

As you can imagine, for each topic mentioned in this chapter there are a host of decisions that require expertise outside the domain of the average researcher. The legal team needs to draft participant releases and non-disclosure agreements, while procurement can help secure your equipment. You’ll want to make the security team a partner if folks will be entering your building to visit your lab, and IT will be a valuable collaborator in connecting systems (and keeping them connected!).

The research team will need a liaison to work with these other parts of the organization to create and amend processes, rules, and tools that allow the research team to meet their unique goals.

Legal

Legal considerations abound throughout the research process. Your legal team can help with NDAs, participant release forms (which allow you to record participant pictures, videos, and audio), and vendor contracts. These contracts might be with recruitment services, facilities, and software vendors.

To that last point, you’ll want to collaborate with procurement and your IT team about software licenses and agreements.

Legal can also determine if any of your proposed processes break any company rules (or laws, or tax restrictions) around incentives and gifts.

Procurement

When it comes to research, there are many expenses: hardware, software, furniture, vendor services, and participant payments, to name a few. You’ll want to find a way to work with your procurement team that allows research to remain lean and agile in a high-velocity working environment.

This usually means collaborating on ways to remove rules and gain permissions for people to make their own purchasing decisions. For example, it’s much easier for a researcher to simply buy a gift card as participant compensation, rather than go through a procurement process that was designed to buy gift cards in bulk via purchase order.

IT and security

The IT department supports the installation and maintenance of software and hardware for the entire organization. You’ll want to discuss all your technology plans with both your IT and security teams to make sure that what you have in mind won’t conflict with other part of the technology stack, and that anything you propose can be secured.

You might also need IT resources to set up the services that facilitate research, like cloud resources for storing assets or server software that sits behind the company’s firewall. For testing and interviews, work with security to make the user experience of entering the building easier for participants. By establishing a plan and partnering with other parts of your org in advance of what you need, you can remove impediments and lay the groundwork for future proposals.

Final thoughts

This chapter is not meant to be a comprehensive description of everything that goes into ResearchOps. After all, the practice is evolving every day. But the information here is tightly connected to DesignOps, and can help kickstart discussions around how to work with ResearchOps.

The interconnection between design and research—as well as with other parts of the organization like business operations (BusinessOps) and people operations (PeopleOps)—increases efficiency, communication, and output, and allows everyone to work as a unified front in collaboration with stakeholders.

Closing remarks from Pinterest’s Meredith Black

While the four authors of this book have played some part in pioneering the role of DesignOps within our industry, it’s now up to you to pioneer the role within your own organization. It’s time to take all of the information you just learned and put it into play. It’s time to build your team. It’s time to show your organization how DesignOps can make an impact.

---

Your mission for DesignOps is to amplify the value of design. Bringing in the right people at the right time, and providing clear responsibilities and workflows, liberates your designers to focus exclusively on the user experience.

Meredith Black

Pinterest

Your mission for DesignOps is to amplify the value of design. Bringing in the right people at the right time, and providing clear responsibilities and workflows, liberates your designers to focus exclusively on the user experience.

Have you ever heard of an athlete being asked to coach herself, play in the game or competition, and then follow up with the athletic organization about how many tickets were sold and how much money was made from concessions? That doesn’t happen. Let’s take a note from the wide world of sports and acknowledge that one person shouldn’t do it all—it takes a well-rounded team of different talents to succeed and thrive.

My advice as you put DesignOps into play is to hire smartly, integrate slowly, and plan meticulously. As your organization grows and scales, so will your team. Think of your DesignOps team as the chameleon in the company, always changing to support the growth and changes of the business.

There is no one way to make the perfect DesignOps team. Just like with design mockups and early stage concepts, the role of DesignOps will need to be nurtured and taken care of. There will be feedback, there will be iterations, and—most importantly—there will be small and large wins that will motivate you to keep going.

The most exciting part about DesignOps is that you can be involved in creating a practice that didn’t exist five years ago. You are at the inception of a new role that you get to help shape.