DEPRECIATED — User research evidence in feature requests

The SecureDrop template for feature requests includes a section titled User Research Evidence. This page explains how to complete this section.

What is "user research evidence"?

Methodically sound evidence produced by user researchers, or developers following specific user research methods in-line with UxR best practices. Below are examples of anecdotal evidence, by an early contributor enthusiastic about UX but not himself a skilled practitioner.

By user research evidence Loic meant any observations or insights obtained via interactions with SecureDrop users that can support or justify the need for your feature request.

Interactions with users can happen directly and indirectly:

• Some examples of direct interactions with users:

  • Planned user research activities such as interviews, contextual enquiries or usability studies.
  • Conversations with users in person (at conferences or events) or remotely (e-mail, Gitter, forum, etc).
  • Experiences from maintaining a SecureDrop instance or providing support for their maintainers.
  • Experiences using SecureDrop for sending or receiving documents.

• Some examples of indirect interactions with users:

  • Published research (reports or academic papers).
  • Conversations with people who have interacted directly with SecureDrop users (e.g. talking to people who provide support to SecureDrop maintainers).

Why user research evidence?

Many of the features and changes we suggest are based on assumptions we make. Those assumptions don't materialise out of thin air: they come from our knowledge and personal experiences. Sometimes, our assumptions will be correct, but oftentimes they are not, simply because the scope of our knowledge and experience cannot cover all aspects of using software as complex as SecureDrop. Also, because users appropriate technology, they make it theirs, and use it in ways the makers of the technology never expected.

In order to truly ensure SecureDrop solves real problems and needs, we must engage with its users in meaningful ways.

What am I supposed to write in the "user research evidence" section?

You only need to answer two questions:

1. What is the observation or insight prompting your feature request?
2. How did you collect it?

Here is an example (please note that this example is completely fictional and made up!):

• Observation or insight: journalists using SecureDrop seem to struggle to identify which documents have already been read or dealt with by colleagues at their news organisation.
• How did I collect it?: on Friday April 6th 2018 I attended a presentation at the Foreign Press Association in London. I had a conversation with a couple of journalists working for a media organisation that happens to use SecureDrop. They commented on how they came to understand the importance of SecureDrop, but also told me about some of the challenges they experience with it. One of them was the fact that there was no way of signaling to other journalists that you had taken ownership of a certain document, which led to some confusion and duplication of effort.

What happens if I don't have any user research evidence?

If you did not collect any user research evidence, it's OK to say so. Try to explain the rationale behind your assumption, and just add "no user research evidence yet".

We will help you validate your assumption with SecureDrop users.