RAM process for requirements gathering for research applications

[aranas]

This PR is aiming to create some documentation on the RAM process around requirements gathering for academic projects

• draft guidelines for how to draft good user research questions.
• add RAM learnings & experiences from applying this to research applications

[dingaaling]

• With team, identify target users (ideally specific teams at organisations, otherwise generate user personas)

[dingaaling]

(seems like a missing piece before conducing user research and defining user journeys is clearly defining who are the users/early adopters?)

[dingaaling]

• What features or aspects of the MVP are you planning to test?
• What decisions will be made from the outcome of the user research?

[dingaaling]

Thanks for starting this Sophie - it looks awesome! I've added a few suggestions directly into the PR via single line comments, but a high level question: is the purpose of the question asking method you've documented about understanding the user and their context (which seems more about user research rather than requirements gathering around specific needs around an MVP)?

My suggestion is to augment this with a section on methods more focused on the latter.

[aranas]

is the purpose of the question asking method you've documented about understanding the user and their context (which seems more about user research rather than requirements gathering around specific needs around an MVP)?

Aha! so I think this is a key question! I used the term "usability" to stay ambiguous :)

I'd like to posit that in the iterative prototyping approach, there should be no true difference between the two. If we build an MVP early to iterate often, the MVP is built on an incomplete understanding of users by definition. We start with a basic concept of the user need and a few requirements, but as we go about gathering more specific requriements, we also continue to discover gaps in our understanding of the user and need to be open to re-introduce exploratory questioning. If we focus too narrowly on specific features at that stage, we might miss asking why a feature should look a certain way.
Assuming that we can first gain a complete understanding of the user and their context and then in a separate step focus only on requirements gathering, would slow down the process and risks that we start building an MVP too late and with many untested assumptions.

And to make this even more topical: I think this may be a key consideration in working with academic research outputs, where there is often a lot of knowledge about the user needs already but those were not necessarily collected with a focus on any application more specifically.

So my question in turn is: What would be the key differences between a section focusing on user research vs a section focusing on requirements gathering and why is it important to you to separate these stages?

[dingaaling]

Interesting! Realising my prior assumptions are the following:

• Most research teams do not have a good understanding of user needs or who even their users are (unless users are other researchers)
• Scoping or building an MVP for hypothetical users and hypothetical user needs is a waste of time

So my approach would be to start with building user understanding through questions like those in the Ethnographic Interview before any MVP roadmapping or development begins. To me that is essential "pre-work" but I'm realising that this may be a bit of a chicken or egg question for us - what comes first the MVP or the user?

[aranas]

Scoping or building an MVP for hypothetical users and hypothetical user needs is a waste of time

Yes, that sounds very reasonable. So, some pre-work around the user should always be the foundation to build the product on.

This then leads to the question of :
when are we satisfied with our user understanding before moving on to mapping out an MVP?
Is there maybe a set of questions that we can collect that outline the minimal necessary information before one should move on to more feature-based requirements gathering. I think having a list that helps guide this transition would be extremely helpful!

I have updated the doc with your suggestions @dingaaling and I have added a list of questions into the "decision" section that could guide this decision.

There is another statement that I am reading in your earlier message implicitly:Are the categories from the Ethnographic Interview maybe most useful during broad user research and less so during more specific usability testing?
If so, what guide is best suited for more feature-focused requirements gathering? Any thoughts?

I think asking super specific feature focused questions like: "Which color palette do you prefer on this plot?" carry a danger to focus interactions too strongly on the what instead of the why. This risks the prototyping to become more transactional and less collaborative.