Summary of readings inb4 Sem1

The main points of the reading seem to be the early stages of a project, for example, data gathering, establishing requirements, making theories about users (use cases) and presenting your data.

Many techniques for gathering data are presented together with their flaws and strong sides, but the main ones were questionnaires, interviews and observation. Questionnaires are good for gathering mainly quantitative data, and might not fit best at the very beginning of a project since it's harder to formulate concrete and useful questions without first having analyzed your demographic with other tools. Interviews and observation might be a better fit since they allow for more qualitative data gathering, and interviews are also easier to perform. Interviews additionally have the advantage of not taking the interviewee out of his natural environment. There were also many detailed tips on how the interviews should be performed, but many boiled down to simple common sense. 

A technique mentioned for minimizing bias and false conclusions was triangulation, in which one is supposed to analyze the data from different perspectives or through different theoretical frameworks. If the conclusions still held true, that would be a good argument for them being representative of reality; otherwise, they might have sprung from biases or faults inherent to the methods of analysis used.

Having access to large amounts of data, for example from automated observations (indirect observation) of usage of a website or an app, a way of analyzing that data might be through the framework of Activity Theory, in which one tries to reduce the human interaction with a system to small, individual "activities". This might help to show where these "activities" distract from each other or are hard to perform, however, it might not always be clears exactly how interactions should be subdivided into these activities.

Another important topic is understanding and interpreting the given requrements for a system, but since these are not always clearly defined, it's often "part of the project" to establish the requirements. Several techniques are presented, in which generally the data gathered earlier is compiled and interpreted into various forms. For example, use cases, personas or scenarios can be used when presenting the established requirements to the interested audience (say, users or stakeholders), each having their different upsides and downsides. One reason for using personas or scenarios might be to "add life" to a requirement report and make it more relatable for the audience. 

A question I'll like to discuss is: "How do we avoid the user trying to please you with their answers?", as that is something I experienced heavily when conducting the interviews.