Reading Seminar 1 - Individual notes, Sofie

Chapter 7 Data Gathering

This chapter describes how to collect data, from the planning phase till how you perform the interviews or observations. I think that one of the most important things in the planning phase is to set goals, what do we want to achieve with the data gathering. When we know what we want to achieve, then it’s easier to know how to do it.

We wanted to gather as much data as possible, because we didn’t know what type of product we wanted to develop. Therefor we did interviews on the station included in our route, and we wanted to have prepared questions to start with, and then ask questions on the answers we got. There are different ways to record the information like taking notes, audio or video, we chosed to use audio recording and transcribe the interviews afterwards, which is needed according to the literature for detailed analysis. In the literature they describe criterions for the different techniques of recording, and according to them our technique is inexpensive, flexible and relatively unobtrusive. The reliability of the data is high, but we have to take in consideration that the background noise on the platform could muffle what is said.

Their are different types of interviews, it could be unstructured, structured, semi-structured or interviews in a focus-group. And I think we could say that we planned to do some kind of semi-structured/unstructured interview because we said that we should be prepared to continue on new topics, and we wanted to generate rich data. In a semi-structured interview the interviewer starts with pre planned questions and then probes the interviewee to say more until no more relevant information is forthcoming.

After reading the literature again I would say that it is really important to have well planned questions, and that they should be short, neutral and simple. Then you also have to choose if you want to have them open or closed, I would say that open questions gives you more qualitative data, and closed questions is good if you want to have quantitative data and are planning to do many interviews.

In this chapter they also describe other ways of gathering data, for example with questionnaires or observations. We are going to use observations later in controlled environments, think-alouds and also direct field studies, like state-of-the-art.

The chapters ends with the tip that it is good to combining different techniques, and that it results in a more reliable dataset, and that is something to keep in mind for upcoming projects when we don’t do it part-time in a course project.

Chapter 8 Data Analysis

When you start analysing your data there are some initial processing steps for each of the methods. For interviews or raw data is the Audio recordings, and these can give us both qualitative and quantitative data. Examples that they give for qualitative data is responses to open questions and the respondent’s opinions. Examples given for quantitative data is Age, job Role and so on, and also responses to closed questions. The processing steps are transcriptions of recordings and expansions of notes.

Quantitative data is easy to present, and therefor I think it is easier to convince stakeholders that the new product we want to develop is needed, when we can show it with graphs and diagrams. It requires more job with qualitative data as I understood it. You first need to identify recurring patterns or themes, then categorizing the data and find the critical incidents. When you are analysing the qualitative data it is also important with the goals of the study, to know that you are finding what you need for your research.

Chapter 10 Identifying needs and establishing requirements  

In the beginning of this chapter they are describing why it is so important to actually identify the needs of a customer or user. The kernel of the problem is lack of communication, and that we don’t speak “the same language” I think. The customer explain something, that is understood in a totally different way, and in every step in the producing chain something changes, and the customer then receives something that they did not order, they paid for something else, but actually what they needed no one thought about. That is why communication and observations is so important when it comes to developing applications.

They are discussing requirements, functional and nonfunctional and this I recognize from software development, where we always talk about these two different types of requirements, and according to me we have to start looking at the functional ones in the beginning of the developing, and after some iterations we start with the nonfunctional ones to suit our target users.

After that we already gathered data, which we use to identify needs we start brainstorming for innovations. They recommend to have participants from a wide range of disciplines, so it is good that we have group participants from three different fields of studies. They also give tips about how to perform brainstorming, that it’s good helpful to use warm-up exercises like using word games or continuing each other's sentences. And some obvious things that the book tells us to have in consideration is that we need to keep record of the brainstorming, not banning “silly stuffs” and try to sharpen the groups’ focus.

To identify needs and establish requirements we can use Scenarios, which is described as an informal narrative description. And it describes a person's activities or tasks, and this allows exploration and discussion of needs and requirements. It also describes the context of use.

They also point out that storytelling is a natural behaviour and it is easy to convince stakeholders that something is really needed by telling them a scenario.

Use cases is also mentioned, and I think it is mostly used in software development, it describes the interaction between user and system, and you can show it with a use case diagram. It is helpful to figure out how the system should respond to different inputs from the user, so that the user can reach his goal with using the system, for example taking out cash from the ATM could be a goal, and depending on that the user types in our does with the ATM, there will be different outcomes.

The last interesting thing in this chapter is the hierarchical task analysis, and I think that we could use it if we want to design an application that for example sells tickets. Then we need to break down the tasks in smaller tasks in order to buy and use the ticket. This is easy to represent graphical, and it reminds me of Work-Breakdown structures in project management, where you want to finish a task, but for that you have to finish smaller sub-task to complete the initial task.