Let’s say you’re undertaking a big research project: one that requires a lot of data-gathering and synthesis.

You’re managing the whole process of research. You want to get your team involved, because you can’t do all of these things alone.

What’s the best way to delegate research tasks?

What tasks should you offload?

Here are the ones that one tends to offload the most often:

• Running customer interviews that require a 2nd person to transcribe summaries of each session.
• Analyzing hundreds, or even thousands, of behavior recordings to determine long-term trends.
• Sifting through customer service inquiries, whether in a strictly-research role or on the front lines.
• Watching usability test results and writing up a quantitative analysis of the trends.
• Running heuristic evaluations.
• Checking out with a dummy credit card on a variety of browsers, operating systems, and platforms.

What’s the common thread, here? Gathering and processing data. In each of these, you’re either creating or poring through large data sets, and trying to indifferently report what’s happening in them.

The jobs of synthesis & hypothesis creation should always fall to the researcher and optimizer. Those are the most strategic and deeply involved tasks that have the biggest implications on the final design. Project leads and high-level consultants should always have final say in the most important task for any business: defining what the customer experiences.

How to delegate anything

Now, let’s talk about how to delegate literally any task ever. Delegation doesn’t come naturally to people, but it’s pretty easy to get the hang of.

The basic unit of delegation is called a standard operating procedure, or SOP. A standard operating procedure is a step-by-step guide for completing a task, along with anything to watch out for.

Here is a step-by-step guide for creating an SOP of your own:

1. Do the task. For example, you’ll watch a few behavior recordings.
2. Write the SOP while doing the task a second time, pausing to take screenshots and clarify any “gotcha”s.
3. Hand the SOP to the person doing the task.
4. Have them do the SOP once, then review their work. Offer any guidance if necessary, and update the SOP to reflect the guidance that you provided.
5. Let them do the thing into perpetuity.

All SOPs should be compiled into a long-form research guide as a shared document, so the rest of the team can refer back to each SOP as they perform new tasks, and so SOPs don’t remain siloed on one team. (I prefer Dropbox Paper for the purpose.)

One of the guide’s SOPs should be a step-by-step process for maintaining the guide, along with clear statements who maintains the guide and how often.

That’s it. You can use this how-to for delegating tasks to a VA… or for spreading the workload of research around to your other team members. This is exactly what we do to delegate both research and operational tasks at Draft every single day. And you can follow this process for anything.

You’re here to research, though, so let’s go into some more detail.

Critiquing large-scale data

When you have multiple people making sense of large, disparate sets of data, you run the risk of someone drawing different (or, far worse, inaccurate) conclusions than the rest of the team.

In a perfect scenario, you want your team to impartially and rationally report what’s happening in the data. But there is no such thing as a perfect scenario, and you’re going to run into issues where novices are unsure how to talk about what’s happening, and so report something that looks useful, but could in fact mislead the project.

The most reliable solution to this problem is to make two people look at every set of data. But that doubles the workload, and is not always feasible.

If you can’t have two people look at every set of data, check in on everybody’s progress midway through. Ask them to ping you when they’re about half done, and see if they’re making the right conclusions based on the data they’ve been given to analyze.

Ask questions on what they were thinking as they’ve gone through the process, treating it like a critique. Remember, though, that they may be new to this, and they may be venturing their time for free, rather than working on other projects.

Synthesizing others’ work

Let’s say you now have 5 different agglomerations of data, and you want to come up with some design decisions.

Quantitative aggregation of these data should be easy. If you have a bunch of different data tables, sum them together, calculate the average and standard deviation, and take these figures into account when coming up with a new design decision.

Qualitative synthesis is much harder. If one of your 6 data sets is radically different from the others, sit down with the person who compiled that information, and dive into what they analyzed. Does their thought process bear out what the research actually gathered? If not, you can probably safely view their findings as an outlier when coming up with a new design direction.

Remember that synthesis isn’t about confirming the beliefs of other team members, or fulfilling their agendas. It’s about finding out what your customers think, and creating a design that best meets their needs.

← Back to the Blog Check Out Draft’s Store →