Desk research is another name for secondary research. Broadly speaking, there are two types of research activity: primary research (where you go out and discover stuff yourself); and secondary research (where you review what other people have done). Desk research is not about collecting data. Instead, your role as a user researcher carrying out desk research is to review previous research findings to gain a broad understanding of the field.

Research can generally be split into two categories:

• Primary: observations in the field, conducting interviews, usability tests, collecting surveys, diaries
• Secondary: desk research

Carrying out desk research is a critical first step, for at least three reasons:

• If you don’t know what has gone before, you won’t know when you’ve discovered something new.
• You’ll sound credible when you get face-to-face with users and stakeholders. If you’ve not done this “due diligence”, you’ll ask dumb or irrelevant questions and may find your participants cut your sessions short.
• Failing to do preparatory research is disrespectful of your participants’ time. You may get less than an hour with a user of your system. Do you really want to waste half that time understanding the domain issues that you could have covered elsewhere?

The Venn diagram describes the context of use: your users, their goals and the environments where the action occurs. The best kind of research is where all three of these dimensions overlap: field visits that focus on your users trying to achieve their goals in context. This kind of research is so specific and relevant to your project that it may be hard to find, so don’t get discouraged if you can’t turn anything up in this area.

But there is potentially useful research in the other areas of overlap on our Venn diagram. This falls into three broad areas:

• Research about your users and their goals, but that was not carried out in context. This kind of research will take the form of surveys, customer interviews and focus groups.
• Research that addresses the goals your system will support and the environment it will be used in, but doesn’t tell us much about users. Examples include call centre or web analytics.
• Research that uncovers information about your users in their environment, but that may not address the goals that your system will support. This will take the form of field research by teams who are designing a product for the same kinds of user but to meet different needs.

The most likely place you’ll find this kind of research is within your own organisation. But you need to be prepared to dig. This is because research findings, especially on agile projects, are often treated as throw-away by-products that apply to a specific project.

So within your organisation, you should:

• Talk to your stakeholders. Get to know the product owner and understand their goals, vision and concerns.
• Examine call centre analytics or web analytics (if there is an existing service).