Raw notes from seminary 1

Interviews gave us only quantitative data, but this is ok at the start of a project. It will be necessary to, later in the project,

Setting goals is an important part of the start of a project, the chapters indicated that you have to know what you want to get out of, for example, the interviews.

Data Gathering

Data gathering was presented and the different methods for doing it. Variations on Interviews, Questionnares and Observation.

Discussion about data gathering techniques, and that there are other ways of learning about the users than the mentioned three Discussion about Observing, and specifically “insider observing”. It’s a good way to learn by first-person perspective, but not always possible to achieve.

We can avoid poeple trying to please us with theur answers by not having them know they’rebeing analyzed. For example, using indirect observation or pretending not to be an interviewer but a participant.

Data Analysis

Data analysis was presented later, which was how we should interpret the data we gather and draw conclusions from it.

The chapters talked a lot about different kinds of data, how to analyze each kind, and which data gathering techniques resulted in what kinds. Differences between functional and nonfunctional requrements, and that it’s not always necessary to distill specific functional requirements. Qualitative feedback can be used to ground presented results in realify, and add life to them. Is can also be analyzed more broadly by grouping or tagging the data, and analyzing the resulting groups.

Shame that a lot is missing in the book: data gathering from forums or users submitting bugs (this is moslt later in product stages), a lot to get from there.

Establishing Requirements

Establishing requirements was then about what we should do with the insights we’ve gathered. It was also about presenting these insights to the stakeholders etc and finding out about what is best for this project.

WIth infinite resources, we could use the data that SL gathers about how people use the subway and when they travel. We could isolate the people travelling at rush hour, and contact those with interviews or invites to observation experiments. If we want to test some ideas we have, we could invite people to a artificially contructed testing environment, or even stress-test it with huge amounts of people. A method we could use is developing a questionnary that we would print on flyers, and hand out on the subway (and then collect). This way, we would get a lot of quantitative answers, but of ourse, the design of the questions is crucial. A downside to this is that, if we focus on people travelling as rush hour, it might be hard to get answers from them because they are in a hurry (and it might be easier to perform the study at a calmer time of day).

It might be possible to, by way of analysis, extract some quantitative data from the interviews performed. One could for example try to approximate people’s stance to a certain subject.

Seminar 1 - Individual notes Niklas Lindqvist

This is a short summary of the chapters regarding data gathering, data analysis and establishing requirements

The first chapter is about Data gathering, where different techniques is explained and discussed. The main gathering techniques for interaction design is interviews, questionnaires and observations.  One of the most interesting parts from the chapter is the five issues that are broth up. These five issues should be taken in account for a data gathering to be successful. In the sub chapter about the interviews we learn the importance of how to construct an interview and how it might affect the result. To choose a Focal group that you want to make a product for and not choose a Focal group that likes your product is clearly shove in this chapter.

In the following chapter the difference between quantitative and qualitative data and analysis. Quantitative data could be summarized to a data that can easily be described in numbers, where qualitative data is data that include descriptions, quotes from interviews, images and more. Also that one data gathering techniques can result in both types of data. This got me thinking, should we maybe expand our data gathering method with questionnaires and more observations?

How to analyse the gathered data is described in different methods, where I find the sub chapter about analyses of qualitative data and the three methods: Grounded theory, Distributed cognition and Activity theory the most interesting due to my personal gathered data being of a qualitative typ.

In the last chapter, establishment of requirements, we learn that it is important to set up requirements for the project such as required gathering, required analysis and in our case required presentation in the form of who our presentation needs to be clear, and just to our ides. 

Seminar 1 - Individual notes

This first seminar will be about the early stage of the project, for instance, the data-gathering process in the form of interviews, questionnaires and observations. These are all good methods to utilise when focusing on user-centered design as they all involve the people that will eventually use the product.

When we want to establish the user requirements of the product it's a good idea to use more than one technique, which is known as "triangulation". This way we are able to work around the strengths and weaknesses of the different techniques. If possible, we want to gather our information as a part of a field study so that we can talk directly to/observe our core demographic. 

Interviews are a form of qualitative data-gathering, where we can utilise an unstructured form, where the questions are open and our goal is to explore more thoughts and insights that the interviewee might have. Or we can use a structured form where questions are not as open, almost like a questionnaire, but we where we still have connection to the user.

When processing the information we can look for recurring patterns in both the qualitative and the quantitative (questionnaires) data. At this stage we do not have a specific product in mind, rather, we are trying to establish the requirements of the user. As this project is an iterative process we can always come back to the data-gathering step with more closed question to evaluate more specific product ideas. 

My question for the seminar is about something I encountered when interviewing people, how do we avoid them giving us "the right answer" (something they think is important to our studies) when gathering data.

Seminar 1 - Individual notes

As is to be expected, the readings helps us in the early stages of our project, mainly by describing different ways of collecting and analyzing data and establishing user requirements.

Interviews are advantageous in the beginning of a project as they don’t require too much prior knowledge in your chosen field. You can make them unstructured, with several follow-up questions to utilize the particular thoughts and experiences of each interviewee. They can also be held in the surroundings in question which gives you the opportunity to make observations. Questionnaires are useful if you have identified what specific information you require and need a larger quantity of data from a wider range of people.

 It is usually a good idea to “triangulate”, using different methods of gathering data and finding the key similarities. It is important to use different frameworks and different data-gathering and data-interpretation techniques, since these will affect what user requirements we extract, and constantly refining and revising these requirements. The gathering and interpretation of data should preferably not be done only once but several times in an iterative process.

The article about UCSD confirms the importance of making the design process both an iterative process where each iteration includes analysis, design and evaluation. They stress the benefits of active user participation; continuous interviews, observations and evaluations by the end user, and also domain experts, during the design process. A way to make this as effective and instructive as possible is simple design representation and early prototyping; from an early stage making multiple sketches, mock-ups and simulations, preferably of several design alternatives in parallel, that are easy to understand for the users as well as the design team. 

My question is how we, in the best way, can include the end users continuously in our design process?

Notes: reflection on readings for seminar 1

The central pillar of user-centred systems design is to involve
the users of a system to a high degree. Many times, especially
in government or enterprise projects, it is the case that a system
is designed in a very rigid fashion, with some experts giving
requirements and the development team then implementing these
requirements independently of the surrounding organization.

The article (Key Principles in User-Centred Systems Design) is basically a guide to how to avoid this class
of failures - involve the user! Do not only design with the user
in mind, but make them part of the process. It suggests three
things that from my own experience is most important when trying
to achieve this goal:
- have the end user participate in the design and development process. They have the domain knowledge you may lack
- make prototypes, early and often. Agile development with many iterations is a good combo.
- usability expertise is a thing, use it. Programmers and the population use computer systems differently.

But how does one do when involving users? Gathering data from users
to apply in the design process isn't easy. During prototyping and
iterating on the prototype, direct user feedback can be gathered
and used. In the planning phase, I've found interviews to be a good
way at identifying problems to tackle. During the MVK course, we've used
rather structured interviews when collecting requirements, which
has worked well.

Another of the main techniques for gathering data, using questionnaires,
is harder when trying to identify requirements, but is good when determining if a change introduced to a system is good. However,
questionnaires must be carefully designed not to introduce biases.
There are biases both in how we answer certain question (for example
on how it is worded, where in the questionnaire the question is), and
getting a good random sample - maybe a certain group refuse to answer
questionnaires in general, skewing the results.

Automatically observing the users when utilizing the system (indirect observation), is a common technique nowadays.
We attempt to describe how the system is used in terms of small, logable actions
taken by the user. There is a big potential for biases though, and mistakes arising from optimizing the wrong thing (can an increase in the use of a UI language selector result from both a good and a bad change?).

My question for the seminar is: how do we reduce biases in the different data gathering techniques?

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.

Seminar 1 - individual notes

I have a few years experience of working with and around interaction design, therefore — unsurprisingly and somewhat reassuringly — this week's reading did not offer any major revelations for me to reflect on. But I will endeavour with the spirit of the exercise.

The material deals with data gathering, data analysis and requirements discovery, presented in that order and suggesting a work process in that same order. This order is also reinforced by the course project (so far), wherein we first gather data about a group of persons at a "journey-location", and most noteworthy is that this group is chosen for no business or even product-developmental reason, and then we do state-of-the-art analysis of what they might or ought to interact with in relation to the chosen journey-location, still with no concern for business or product. The aspiration is to discover the needs of the group at the journey-location, and from that come up with a design which meets their need, which is interesting though somewhat lofty.

A more practical situation to become accustomed to would be that of the start-up team who knows where their development skills and domain knowledge lies, and from it they agree what product they can make, and therefore have a product-centric approach to gathering data about potential users of their product, then analysing that very relevant data to discover what their product needs to be. Another approach could be that of the business, which has investment in (or at least funding for) a specific business plan, and therefore has a business-centric approach to gather data and so on as in the previous example.

This is of course an iterative process, where better understanding of product leads to better understanding of users and vice versa. Hopefully the project will allow for at least one such repeat iteration..

The literature focuses on ways to gather data that are easy to label and put in a book — interviews, questionnaires and observations, of which the least covered and probably most available and used in software development are indirect observations of usage stats (including A/B testing), and to some degree observations in controlled environments (such as inviting users to the office to be observed when using the product, or sitting with a user at her workplace). There are no assumptions of pre-existing expertise, or of really "becoming a user". (Direct insider observation suggests observing other "real" users as a spy, rather than being a real user and focusing on whatever real users focus on.)

The literature offers well considered approaches for design, such as user-focused design

(building what the users need) and activity-focused design (building what's needed to do the activity), but it should also mention practical considerations e.g. working with what you know, as when designing tools for other developers (as in any API) or when the developers are users and develop what they want to use (as in most open source software). Or the very common "accidental design", which starts out with no design, for the sake of curiosity or development in itself. Only later, if ever, are the edges rounded off for easier use — and such has been the design approach for much of the world's technical innovations, and most if not all high art. (Cf. the KTH insignia "Vetenskap och Konst".)

I was amused by the revelation that the think-aloud protocol is an established technique, something to do consciously, rather than what inevitably happens when you draw interactions on a whiteboard or demo a product/mockup :)

My question for the seminar is how to overcome the Dunning-Kruger effect? — In re-evaluating what one has learned so far about the product/users, in feedback from users/experts, and in those with greater business authority over the design (e.g. managers, executives, shareholders…).

Seminar 1 - Individual notes

The first reading seminar concerns the first steps of an interaction design project; data gathering, data analysis and establishing requirements.  

To obtain good data there’s three main techniques; interviews, questionnaires and observations. Often more than one technique is used to validate results of some inquiry by exploring similar results, also known as triangulation.

Interviews can be unstructured (using lots of open questions and leaves room to explore insights from interviewee) or structured where questions are usually closed and has options. I’d say the best is somewhere in between collecting both quantitative data and a more what motivates those answers, qualitative data. Questionnaires was an especially interesting section; interactive web-based questionnaires have some great benefits although the main problem is the difficulty of obtaining a random sample of respondents.

To process the gathered data the method varies with the technique used for collecting. From audio and video there’s possible to extract both qualitative and quantitative data. The latter is easier to transcript and present as graphs or similar. For qualitative data on the other hand one must first identify recurring patterns or themes to be able sorting the data.

In chapter 10 the authors point out the importance of establishing requirements. There’re two main aims; understand as much as possible about the users and secondly to produce a set of stable requirements that form a sound basis to start designing. Doing a proper foundation for the project is both cost effective and professional because what a “customer” think/mean/says they want may differ.

To establish requirements, it’s a good idea to discuss both functional and nonfunctional requirements. It’s often intuitive to use scenarios, which is described as an informal narrative description in the context of use.

My question to the seminar: How can one minimize the effect that our data gathering technique has on the respondents?

Field study/Transcript - Niklas Lindqvist

The interview tool place during lunchtime at T-centralen Stockholm. I would describe the environment as less crowded than usual which was pleasant for the sake of the interview.

As we previously decided, in exercise 1, our focus group was every day travelers I tied to look for someone that did seem to know where they were going and at the same time not to be in a hurry. I found a young man, a student it turned out, who was willing to answer some questions about Stockholm’s Underground system.

The goal of questions was to determine what the everyday travelers experience as satisfying with the Underground and also what they did not like about the current situation of Stockholm’s underground.

The questions that we had prepared was Open questions and as neutral as possible, with follow-up questions to get a more in depth data and hopefully some interesting observations done by the travelers. When I decided which prepared question and in what order I followed Robeson’s suggested order in five steps.

The following questions was answered:

-         Demographic tests: How often do you travel by the underground and in which areas?

4 times a week, both ways. I travel between Uppsala and Stockholm.

-        What do you usually occupy yourself while in the underground?

I usually read a book on the commuter train, in the subway I always listen to music, if I don’t travel together with someone I know.

-         Do you use the application from SL?

Yes, but only if I don’t know the way. I don’t have to check it every day since I already know the times for my trains.

-         Which information given in the app do you use the most?

The time of departure, and rout for when I don’t know the way.

-         Which information do you miss out?

Which exit I’m supposed to take. Doesn’t show on the app.

-         What do you think about the environment on the underground station?

At T-Centralen I think it’s too crowded. There is always like two streams of people that collide with each other. I usually enter the train close to the exit, even thou it’s sometimes more crowded.

-Why?

Because I don’t want to collide on the way to the middle of the platform

-         What parts, if any, do you like the most about the underground?

It’s cheap in compared to car and other ways of traveling. Also it fits my travel rout perfectly.

-         Do you have any nightmare scenario when traveling by the underground?

When the train is so late/cancel that I don’t arrive in time for an exam or presentation.

-         Is there any information given on the platform you like in particular?

The signs and the time of arrival.

-         Is there anything you think works perfect on the platform or surrounding areas?

The swipes

As I carried out the questions myself I took notes during the interviewee’s answers and a short time after. Afterwards I also checked that the interviewee agreed with the notes that I had taken so that no misunderstanding had been done. 

Test

Hullo! 

Bacon ipsum dolor amet sirloin short ribs boudin ribeye ham turkey frankfurter jowl pork chop hamburger andouille tail picanha bacon. Tail kielbasa ribeye capicola spare ribs. Chuck capicola biltong landjaeger. Pastrami landjaeger spare ribs shankle drumstick. Cow shankle prosciutto, filet mignon pork belly pork chop pastrami drumstick. Meatloaf andouille bresaola, ribeye capicola swine bacon flank ground round cow pork picanha.