from research to requirements: user need tables

There is a lot written about qualitative user studies but in my eyes there is few material out there which helps a practitioner to apply the methods. Even the more practical works depend on a large team and lots of time and resources. So the interested designer or researcher may decide to skip formal user studies. But I think there is a need for doing that in order to have a valid foundation for discussing possible features and how they must play together.

Because of the difficulties a practitioner may face when attempting to do user studies, I was pretty happy when I recently found the research of S. Kujala, a researcher whose research deals (among other fields) with methods for user studies. The research uses multiple case studies in which several methods and involvement of industrial partners is used to determine suitable methods of gathering and analysing needs and generating requirements for the product be be created.

In the suggested method, data is gathered as usual in
interviews and observations with focus on predefined critical topics (e.g. context of work, existing tools etc.)
In addition two other complementing methods are suggested:

  • Think-aloud usage of a (possible imaginary or prop-like)  product
  • The "interactive feature conceptualization": Items and Processes the user mentions in the interview are written on sticky notes; the user that is asked to arrange the notes in a system meaningful for him/her.

The interesting point for me is how the data is analysed. There is already a kind of pre-analysis existing: The categories from the main interview and observation. However, this structure was not very practical, so Kujala e.t al. developed an interesting tool, called "User Needs Table". (I hope my depiction is coherent with the authors suggestions; This is a description of my understanding of it)

It is aimed at bridging the gap between user studied and user requirements. The table has two columns, one for the tasks of a sequence, one for problems an possibilities associated with this task. In Kujala’s work they especially serve the construction of use cases which can be easily derived, since sequence and possible problems are linked together in the user need table.

I found the suggestions and the research design very interesting and useful. Neither does that author do an exclusively theoretical analysis of methods nor a quantitative comparison of  »treatment groups« using different methods (whether the latter would be any practical may be questioned). Instead the research is based on several case studies building upon each other. This, I find, is a very useful approach to develop empirically based and practical methods – and I have rarely seen such an approach. The most literature I read on qualitative methods is rather theoretical, so I think such a empirical and practical approach should be praised.

What remains unsolved for me is still a better and more practical transition from data to an analysis. As far as I understood, the user needs tables are created after the first report has been written. The predefinition of a focus is an important step, but at least I'd love to have a analysis methods beyond that.

Nevertheless, check out Kujala’s Papers, they are really interesting and illuminating and contain useful information on why the methods are designed the way they are:

Example user need table for a file upload to a learning management system (created for illustrative purposes, so it is not based on a 'real' project of mine)

Task Sequence Problems and Possibilities
Step 1: Selecting an “area” to which the upload belongs to (e.g. study group) Problem: The difference between the private file collection and the public files is frequently misunderstood.

Problem: For teachers who manage only one course, it is seemingly useless work

Step 2: Choosing a file Problem: The folder structures on the web portal and the local computer may be not the same; disorientation can occur.

Problem: Without instant feedback, Users may upload files twice

Step 3: … … (etc.)