Assignment #2

Assignment #2

POVs & Experience Prototypes

Define - Ideate - Prototype

TEAM ASKSIMPLE ZHENYANG L.

PENG-HSUAN L.

LUKAS G.

MIKE T.

NICOLE S.

Introduction to

Human-Computer Interaction and Design, 2016 NATIONAL TAIWAN UNIVERSITY

Table of contents

1. Problem domain 2

2. Initial POV 2

3. Additional needfinding results 3

4. Revised POV(s) 4

5. Best HMVs 5

6. Three experience prototypes 6

7. Most successful prototype 12

1. Problem domain

We chose the problem domain in Education and Learning. Education and Learning is a constantly evolving field, where teachers and students are constantly looking for ways to improve the way knowledge is spread to the younger generations. In this problem domain we agreed that we had many frustrations in the classroom, which incentivised us to specifically focus on the studio theme: frustration in the classroom.

We also focus on online classroom in addition to physical classroom. Classes are not only taught in physical classrooms anymore, online alternatives also exist. One might even say that physical classrooms are starting to move towards classes exclusively taught online, due to scalability and convenience. These online classrooms are not fully mature yet and might bring even more frustrations to students and teachers, which is why we also want to explore this part of our studio theme using contextual inquiries.

2. Initial POV

We identified the following initial point of view from our previous assignment:

We noticed that both students who took both types of classes or just one type have a common frustration. We conducted additional needfinding based on this point of view.

We also focused our new interview questions on bringing online and offline classes together, since both types of students have more or less the same frustrations in a different context.

3. Additional needfinding results

We chose the following people for our additional needfinding (see the table below).

We chose people with different educational levels (high school and university), as well as students with experience in online and offline courses. We specifically focussed our questions on class interaction, like questioning and answering in class between students and teachers.

Interviewee Nationality Type of class Where?

Vanessa Germany Offline Skype

Nicholas Italy Offline/Online Dorm

Valerie Singapore Offline Skype

Chau Australia Offline Skype

After analyzing the interview, we were surprised that many students want to ask and answer questions anonymously. From the previously mentioned surprise, we formulated the following insights: Most students are rather unconfident in the questions they ask, as well as answering the questions that the teacher asks. We concluded the need of having the possibility to ask and answer questions anonymously in class (both online and offline).

Another insight we gained from our interviews is the wish for more collaborative problem solving in class, some students expressed the wish to receive help from fellow students when wanting to ask questions in class. This insight contradicts one of our previous finding in the last interview round, in which one interviewee mentioned trust issues when asking fellow students to answer his questions. This is probably due to the small interviewee sample size, due to the time constraints of this project.

4. Revised POV(s)

Starting from our initial point of view (See section 2), we derived additional three point of view from our additional needfinding. We used it either to refine our initial point of view, or derived new ones

5. Best HMWs

Starting from the previously identified POVs, we derived several HMWs (“How might we…”) using the techniques presented in class. Some examples of our HMWs are listed below.

HMW…

POV 1 (Main aspect: Students’ confidence)

… make the student more self-confident?

… create the students’ desire to participate?

…. protect students from embarrassment?

… make question asking/answering a game?

… make students care less about questions being answered or not?

POV 2 (Main aspect: Latency)

… make the waiting time for answers valuable?

… highlight/prioritize questions and answers?

… eliminate waiting time for answers?

… eliminate the need for answers?

POV 3 (Main aspect: Collaboration)

… create collaborative answers?

… make sure that collaborative answers are correct?

… make a classroom a sharing community?

… create parallel teaching and question-answering processes?

After an evaluation of the many generated HMWs, three main HMWs were considered most important and thus selected for the further process:

1. HMW protect students from embarrassment?

2. HMW highlight/prioritize questions and answers?

3. HMW make sure that collaborative answers are correct?

6. Three experience prototypes

Prototype 1:

The main assumption for this prototype was that students do not want to reveal their identity. Thus, the application does not ask for the user’s real name during the registration.

Also, we assumed that people still have to register for the service before using it.

Moreover, we thought that introducing the function of upvoting and downvoting questions would be a very useful feature for most students.

Prototype 2:

With this prototype, we assume that people like simplicity and anonymity. We omitted any registration to use the ease of use. The teacher has to make a room, and students can join the room during the class. The session will be trackable by QR code or ID, to make it more intuitively. We assume that the teacher will see the prioritized questions, and try to these prioritized answer the questions during the class. We also assume that fellow students will try to answer each other’s questions. As final check, TA’s or teachers can check those answers. We also assumed that the questions will be self-moderated.

Prototype 3:

People want to view best threads. People want to view their own threads. One forum per week. People would like to browse through each thread, vote, and make comments rationally most of the time. People are used to sliding from one side of the screen of a phone to bring up the function menu of an app. The assumption we make here is that people will have a more focussed small social environment to get their questions answered.

6.2 Creation of the prototypes

As we tried to design different prototypes and explore a broader idea spectrum, we decided to create the first draft of our prototypes, mainly sketches, individually before our group meeting. Like this, we were not influenced by each other and were able to come up with different approaches to find a solution for our need. The main idea behind our prototypes is to provide a platform in which students can submit questions and answers to ongoing class at university, in high schools or online classrooms. The following pictures show our first prototypes and sketches that we discussed in more detail.

Prototype 1:

In this prototype, there was more focus on the design of the user interface as well as the login and registering process. The app provides

Prototype 2:

This prototype shows a solution that uses a QR code to enter a specific part of the app (in this case one specific classroom). Students can either create classroom or use the QR code to enter a classroom. When being in a classroom, the student can see, ask and answer questions and also upvote and downvote questions. A focus was put on the navigation through the app by using a menu bar.

Prototype 3:

The shown prototype was merely designed according to the idea of a exchange forum or platform. It includes swiping functionalities and its focus is on the workflow through the app. The app uses threads that represent a specific lecture and the corresponding questions for this lecture.

6.3 How did you test the prototype?

In order to test our prototype, we were looking for an independent potential user which is familiar with the topic (Frustrations in the classroom) but unfamiliar with our specific ideas about the solution.

Through personal connections, we were able to motivate one fellow international student (who is not taking the HCID class) to test our prototypes. We started the test by explaining the topic of our research and mentioning the need that we would like to provide a solution for. Afterwards, we showed the participant our prototypes, one after another, and quickly described their main functionalities. In order to avoid a distortion of the results, we tried to explain as little as possible so that the participant can use the

The following images give an insight into the testing process:

In order to capture the best insights and ideas gained from the prototype testing, we made a short transcript of every prototype test and also took a video of the testing.

Like this, we were able to better analyze the new aspects that became clear during the testing phase.

6.4 Learnings & new ideas after testing

Prototype 1:

While the user interface seemed to be intuitive for the test participant, features like scrolling through a course list to find one’s own courses seemed to trouble him as he thinks it might take too long to find the right course. Furthermore, the participant liked the idea of having an upvoting function, however, he criticised the downvoting option as it might indicate that a student submitted a bad question (“There are no stupid questions”) which can be discouraging for some users. Moreover, the testing person suggested that the teacher should have access to the real identity of the users in order to avoid any misuse of the forum. Also, he thinks that it would be a good idea to let teachers create the rooms for their own classes instead of a creation through e.g.

the university administration.

Prototype 2:

The test participant wanted more sessions tracking than in the prototype. He did like the idea that the session is easily created. He thinks that for a better experience, the sessions should not be only trackable by QR code, but stored in the app as well. It would be better if the session was trackable by course. So a QR code would be

was criticized again. It would be better to only vote when there is interest in the question posted by others. The thing that he liked about this prototype is the that it is easy to create question and answer session, without it being connected to some official school system. The teacher should be responsible to use the app, not that of the school.

Prototype 3:

For Prototype 3, the threat boards were a nice feature according to the test participant.

Some problems that were mentioned during the test was the design of the topic or threads, as it was not sure whether they represent a question and an answer or something else. Moreover, the test participant did not know how to answer a question in the prototype and he did not like the sliding menu option. From testing this prototype, we gained new ideas such as adding the option to sort threads by date, coloring teachers’ answers differently and maybe give credit or better grades to students who answer questions correctly.

6.5 Assumptions review after testing

Prototype 1:

The assumption that it is best to not have the users submit their real names was proven not to be the best choice as abuse of the app could be avoided by exposing the students’ real names to the teacher. Also, the assumption about the downvoting option was invalid (See 6.4).

Prototype 2:

The assumption of simplicity was too simply. The test participant wanted to have some degree of session tracking options, instead having a QR code for each session, which would make it confusing for users. The assumptions made on that the students would prioritize questions and answers where more or less correct, but the anonymity functionality was too much anonymity for the test participant. The teacher should know who performed well in class, so it should be anonymous between students, but not for the teacher. He also had doubt about self-moderation, some people might troll if the scale of the classroom is too big.

Prototype 3:

While the participant likes the board of titles of threads, he can’t easily know that a thread correspond to a question and its answers. Also, the participant isn’t used to sliding from one side of the screen of a phone to bring up the function menu of an

7. Most successful prototype

After testing all our prototypes, we asked our testing participant for his opinion and a ranking of the different prototypes. As all prototypes had their flaws and advantages, the participant could not easily decide on one specific prototype but finally chose prototype 2. We deemed it the most successful prototype, due to it being the most liked prototype. In our further development process, we will take this prototype as the basis to which we will add the advantages of the other prototypes and eliminate its flaws.