InVision Presents

DesignOps Handbook


by Kate Battles, Meredith Black, Dave Malouf, Collin Whitehead, and Gregg Bernstein (editor)

DesignOps is the key to scaling digital product design teams with more efficiency. As companies mature and invest in design, they need to operationalize workflow, hiring, alignment between teams, and more so designers can focus on design work while someone else takes care of the rest. Learn how creating these centralized services and systems helps grow integrated, high-functioning teams at the best companies in the world.


Go to Chapter
Introducing DesignOps
AMPLIFY THE VALUE OF DESIGN

Operationalizing process and efficiency in digital product design helps to keep designers focused on design. DesignOps Summit and IxDA co-founder Dave Malouf shows you how DesignOps keeps design aligned with the business.

Go to Chapter
Go to Chapter
DesignOps scenarios and models
MODEL STRUCTURE

When do teams know it’s time to add DesignOps? Dropbox’s Collin Whitehead takes you through key flags to recognize, including blurring roles and scaling issues, and different models to use when planning your DesignOps team.

Go to Chapter
Go to Chapter
Putting DesignOps into play
RUBBER MEETS THE ROAD

Once teams know it’s time for DesignOps, it’s important to get buy in and understand where to begin. Meredith Black, who built the DesignOps practice at Pinterest, guides you through starting, staffing, and hiring for DesignOps teams.

Go to Chapter
Go to Chapter
Team coordination
DESIGNOPS IS A TEAM SPORT

By definition, DesignOps teams are collaborative, coordinating between many different levels, roles, and projects. Fitbit’s Kate Battles explores how to establish strong cross-functional partnerships, socializing DesignOps, and more.

Go to Chapter
Go to Chapter
ResearchOps
BUT FIRST WE RESEARCH

A close cousin to DesignOps, ResearchOps should also be on your radar for improving your design team’s process and output. IxDA co-founder Dave Malouf walks us through people, business, and workflow considerations that make up ResearchOps.

Go to Chapter
01

Introducing DesignOps

AMPLIFY THE VALUE OF DESIGN


by Dave Malouf, DesignOps Summit and IxDA

I’ve always been on the fringe of people in the design community who love how design works more than they love designing. Throughout my career as a designer, I have leaned more toward process over practice, and in some circles I was made to feel like a pariah because of my fixation on semantics (resulting in my last name being affectionately turned into a verb by colleagues: “maloufing”).

This focus on process took me to Queens, New York, in November of 2017, where I joined nearly 300 people to learn, share, and work on formalizing a new aspect of design practice management, DesignOps. The DesignOps Summit marked a turning point, as design operations had begun to emerge across the design industry. But for me, it was also the culmination of a very long, personal journey through design.

What makes design valuable

Let’s go back to the start. Back in 2005, I took classes in a design school for the first time. They were continuing education courses in industrial design, and through them, I was awakened to what design really is, and what properties make design practice so uniquely valuable: serendipity by design, a culture of interruption, and deconstructive creativity.

Serendipity by design is the cultural core of a design studio. In a pre-digital studio, everyone’s work is externalized, visible, and transparent. This means that ideas are juxtaposed purposefully, passively, accidentally, and serendipitously. These forced interactions that give light to new ideas are core to how design works.

The culture of interruption is vital for design to reach its full potential. These interruptions come in the form of instruction, criticism, and comparison, to name a few.

When designers envision a rough idea of a whole system, only to tear it apart and rebuild it, they engage in deconstructive creativity.

These three properties of design practice contribute to a high-functioning design team with quality outputs. Add to that, the advent of user-centered design, and design practitioners also function as chief advocates of human understanding and empathy within an organization.

From design school, I moved to an industrial design studio and then to a design teaching position in the industrial design department at the Savannah College of Art and Design. That experience introduced me to systems design thinking in service design, and design for sustainability.

What I didn’t realize was that while on campus, immersed in the properties that make design so valuable and unique, the agile approach to software development was subsuming those very practices. I knew of agile, but I wasn’t prepared for its impact on the design world.

Anti-agile, pro-design

Agile is an iterative software development approach, where cross-functional teams collaborate to set requirements and solutions for a given project. As explained in the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In those five short years while I was on campus, agile became the norm in product development, much to the detriment of designers. What I saw was design practice taking big steps backwards—vision, exploration, deconstruction, associative thinking, and interruptions were suppressed in favor of working the way developers work:

This subjugation of design to engineering in agile makes sense for engineers, as agile fit their culture. Further, agile methods have led to great outcomes, making it hard to refute their value. Companies like Amazon, Google, Netflix, and Facebook were poster children for agile method success. Designers were in the uncomfortable position of acculturating into the agile mindset lest their positions become irrelevant.

Here’s what I saw in this culture optimized for engineers:

  • Designers isolated from other designers, and not working out in the open
  • Design as a production role instead of a strategic role, with designers often asked to perform superficial visual cleanup
  • Design hiring practices based on engineer hiring practices
  • Designer career paths being mapped to engineering career paths
  • Design tools misaligned to the tasks at hand, as well as design tools chosen for integrations with developer tools rather than design functionality

In my first job after leaving SCAD, I was in the awkwardly-titled role of head of interaction design at Rackspace. This was my first “design operations” role, where my job was to make design—meaning my designers and our product outcomes—better. I discovered that the metrics of success for our partners in development and product management differed from those of design, leading to the shipment of subpar products. And therein was the problem: developers and product managers measured success by whether a product shipped on time, and not whether the design satisfied user needs.

In my role with Rackspace, I learned about DevOps and Lean Startup. DevOps is the practice of aligning software development, system operations, automation, and more to allow for continuous integration and deployment for the purpose of continuous learning. Lean Startup mitigates business risk by focusing on small, tightly-scoped bets, called experiments, that lead to determining whether a product direction is valid or not.

The combination of the DevOps and Lean Startup methodologies made people see agile in a new light, and agile product development cycles started to incorporate learning and quality. Speed was no longer the goal, but rather a byproduct of automation. Learning iteratively and learning quickly were brought together.

Everything changed for me in 2014 when I was first introduced to dual-track agile. This added discovery to the agile method; while one track focuses on delivering the value of an idea to users, a separate track is dedicated to actions based on learning. Dual-track presented questions about the role of the designer: how exactly do they work with their peers in this environment, and how could this new framework allow designers to incorporate their own methods of discovery and exploration?

The answer: add yet another track. I created tri-track: parallel to and integrated with discovery and delivery is a third track, understanding. On this track, we align on a strategy for building the “right” thing based on user needs and team insights.

Given my exposure to DevOps and my close working relationship with IT operations, it was a natural next step for me to christen tri-track as a new “thing” called design operations. Though it was still a very loosely formed idea when I developed it in 2014, I felt I was onto something.

Since that point in 2014, I’ve been on a journey from the loose idea of design operations to the legitimate practice of DesignOps. Along the way, I discovered peers with whom the idea of DesignOps resonated, and their stories resonated with me as well. This journey culminated with the DesignOps Summit.

Why DesignOps now?

My mission for the practice of DesignOps is to amplify the value of design. Design as a practice requires a singular focus on the operations that maintain the best interests of design and an organization’s business.

From my conversations with and observations of a host of organizations around the world, I’ve come away with four core factors contributing to DesignOps-oriented leadership roles and practices as design teams mature: scale, people, expectations, and inclusion.

Organizations are scaling at every turn:

  • Teams are growing larger
  • Companies are opening new offices (and forming distributed teams)
  • Design teams are supporting more parts of an organization
  • Companies keep spinning up new business units
  • Design solutions are growing in complexity
  • Organizations are integrating more and different types of design practices
  • The tools used for design become more complex in proportion to the systems being designed

People are a priority:

  • Great designers are a rare commodity, and they know it. This makes recruiting more difficult than days past
  • Product organizations are growing more complex, which makes structuring teams difficult
  • Design isn’t a job you just show up to. Designers need to be developed, advanced, promoted, rewarded, and recognized

Expectations are sky high:

We want our flying cars, meaning we expect that better experiences should have arrived by now. We insist on better design and better design outcomes.

Diversity and inclusion take work:

Diverse teams are great for design, but getting there isn’t as easy as saying, “Let’s hire more diverse people.” People need training and practice to work on diverse and inclusive teams, and this requires coaching that’s new and different than that of previous generations of design organizations.

So, what is DesignOps?

Operations are the elements that facilitate high-quality instances of those activities with minimal friction. Operations includes the tools and infrastructure required to complete the activity. Using the taxi example, a taxi service requires an automobile, fuel, and roads. The meter, map system, and dispatcher all make up the ecosystem of the taxi experience.

Like a taxi service, design practice requires a collection of balanced activities that support the work.

We talk about craft in design—sketching, pixel movement, and critique. But more generally, craft is how we create the plans for the forms and shapes we imagine will solve problems and create positive change.

These crafts are usually encapsulated inside of methods. Any given method can use different crafts to target the same success.

Finally, methods fit specific processes. Processes communicate the shared path to achieve success. The classic “four Ds of design” are an example of a process: discover, define, design, and deliver.

DesignOps, then, is everything that supports high quality crafts, methods, and processes.

To illustrate, let’s imagine you’re tasked with completing hand-drawn wireframes. What do you need to accomplish this task?

Well, you need tools, like a collection of drawing apparati. Maybe this is a #2 pencil, or perhaps a Staedtler .5mm roller. You might want to incorporate different colors and even different thicknesses. A ruler or a set of stencils might help, too. You’ll also want something to write on—a sketch pad, maybe a with a printed grid. You have many options, but you’ll need some tools.

You’ll need infrastructure to support your drawing. A desk and adjustable chair will help. If you draw often, a tilting desk that reduces stress would be nice. Where do you keep your collections of drawings—how are they organized and found later?

Let’s back up and ask even more questions: how do you even determine what to draw in the first place? Who decides your workflow? When you’re done, where do you submit your drawings, and who decides if they’re good enough? How is “good enough” defined? What if your drawings require corrections: who decides this, and who performs the corrections? These questions could go on and on.

How many people really need to work on these drawings, and how are they organized? At what point do you decide to hire more people, and how are the new people brought into the organization?

How do you get paid for your drawings, and when can you take a vacation (and for how long)? What type of governance is in place for time tracking, or for engaging with customers, or for grievances between parties when there are disagreements?

Together, tools, infrastructure, workflow, people, and governance is operations.

Finally, how we manage our particular operations is our culture. These are the values, principles, and mission that drive an organization.

How DesignOps works

A DesignOps practice is made up of three overlapping lenses, or areas of focus. These areas overlap, but the specific overlaps and practices are often influenced by the leadership at the time the DesignOps practices were put in place.

My introduction to the work of DesignOps was through the lens of Business Operations. My executive leader at Rackspace had a keen eye for how important business operations was to his team’s success. I saw him in as many meetings with finance, IT, and procurement as I did with marketing, product, and engineering. He took change management seriously, which manifested in a very strong communications channel for the team.

This business focus advantaged our team over others at my company. We got Macs when no one else could, and tons of whiteboards. We were able to reserve studio space. We had a special career track with HR, and more. A focus on business operations leads to the budgetary and political capital to facilitate design. In a DesignOps organization, a chief of staff is commonly in charge of business operations.

Another area of focus in DesignOps is People Operations. In my career, I saw what a difference having a defined and clearly communicated career path could mean to a design team. Conversely, I saw how an organization’s “one size fits all” approach to employee development can deflate team morale. Design teams need the support, rituals, and defined expectations that a dedicated focus on people operations can supply. Community leaders or practice leaders often run the people operations in a DesignOps organization.

Lastly, Workflow Operations is an area of focus that I sometimes call “Product Lifecycle Management Operations.” A program manager is typically tasked with this area of focus, which focuses on the flow of production within design and research teams, and on the integration of design practice with the other product lifecycle roles—development and product. Systems that support project intake, assessment criteria, and project management of design, tools, and infrastructure all fall under this lens.

In the next chapter, DesignOps Scenarios & Models, Collin Whitehead shares details about the unique operations models in place at Dropbox, right after he presents some scenarios when DesignOps might make sense for your organization. Later, look for Meredith Black to talk more about the operations that support design at Pinterest in Putting DesignOps into Play.

Dive in

This DesignOps Handbook presents the unique experiences, best practices, and lessons learned from leading DesignOps practitioners at some of the most design-forward companies in the world. DesignOps is both emerging and emergent. We authors don’t necessarily have all the answers, but we do have a strong set of principles and perspectives that we hope become valuable to you and your design organization.

05

ResearchOps

BUT FIRST WE RESEARCH


by Dave Malouf (DesignOps Summit, IxDA); Conclusion by Meredith Black (Pinterest)

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.

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

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.

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.

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.

About the Authors

Aarron Walter
VP of Design Education

As the VP of Design Education at InVision, Aarron Walter draws upon 15 years of experience running product teams and teaching design to help companies enact design best practices. Aarron founded the UX practice at MailChimp and helped grow the product from a few thousand users to more than 10 million.

He is the author of the best selling book Designing for Emotion from A Book Apart. You’ll find Aarron on Twitter and Medium sharing thoughts on design. Learn more at http://aarronwalter.com.

Eli Woolery
Director of Design Education

Eli is the Director of Design Education at InVision. His design career spans both physical and digital products, and he has worked with companies ranging from startups (his own and others) to Fortune 500 companies.

In addition to his background in product and industrial design, he has been a professional photographer and filmmaker. He teaches the senior capstone class Implementation to undergraduate Product Designers at Stanford University. You can find Eli on Twitter and Medium.

DesignOps Handbook
DesignOps Handbook