Final Presentation

Yesterday we had our final presentation with our Exercise group A.

Here's a link to our final presentation on Prezi. We felt really strong and were excited to get second place in our group :)

Final Presentation Link

User Testing Summary of Think Alouds

We learned early in the semester that usability testing and user testing in general are extremely important and beneficial to the design process. Especially as engineers, it is crucial that we test our designs and our products with users unlike ourselves. For our group, children were the target group, so children are who we tested our product with.

Something we kept in mind while testing was the definition of usability from Jan Gulliksen's lecture:

"the extent to which a product can be used, by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use."

Also, from James McConnell's guest lecture, we liked a few of the canvases he presented for personas and user testing. We decided to use the user testing plan canvas. 

Detailed Summary of User Testing/Think Alouds:

Our users ranged from the age of 7-10. Each of the children were accompanied by their parents. We did our user tests on Sunday, November 2, 2014 right outside the entry to the Natural History Museum between the hours of 15:30 and 17:00. It was about 5 degrees celsius outside. The sun set at 15:50, so it was beginning to get dark.

Observations of User Tests broken down by aspects of Usability:
Effectiveness:
- The users did not realize there was a start button. If they did, they did not press it with their foot.
- The users did not realize that the monkey (aka Drakis the stuffed dragon) was climbing the tree and gaining one point for each correct answer.
- None of the users read the descriptive text about the animal on the panel.
- The children's parents encouraged them when they were correct, incorrect, or unsure.

Efficiency:
- The users responded well to instant feedback which in our case was "ding" for correct and "buzzz/urghh" for incorrect.
- The users seemed to follow the guided instructions quite well.
- The children were mostly logical with process of elimination, however we did note that it would make things better if the screens could be greyed out. This would prevent user error.

Satisfaction:
- When a user did not know the answer, they often seemed uncomfortable. We hypothesize that the reason for this was because 5 people were staring at them.
- The difficulty level seemed just about right, although one child did say, "Va svårt det var!" when he walked away with his father. We definitely don't want the game to be easy, and the difficulty did keep him engaged!

The reason we noted all of those details above about the environment of our user testing is because it was not a typical environment where the game would be placed. Inside the museum it was quite noisy, and we did not want to disturb anyone, so we did our tests outside. Because of this uncomfortable environment, many users did not explore as much as we had hoped. Our theory is that given a typical museum setting where a user is more comfortable, the user will most likely spend a little more time in the game an around the exhibit.

Based on our user testing, we did change some aspects of our game for our final product. Those can be noted here.

Expert-/heuristic evaluation debriefing

In the following we elaborate on the steps and measures we took in order to incorporate the feedback, which we received during the expert-evaluation.

Questions

1) Omitted: due to the fact that our design is not subject to budget restriction and as we strongly believe that an implementation of the system at a reasonable-price is feasible.
2) Incorporated: we already thought of security concerns regarding the panels before, and decided to use safety glass plates instead of touch screens.
3) Incorporated: in favour of our target group we decided that playing the game as a couple is sufficient.
4) Incorporated: we converted the touch screen into a big panel "button", as suggested.
5) Omitted:  we decided against levels.
6) Incorporated: after the feedback we defined 30s. as the time for one round and tried it out during the user testing, which turned out to be sufficient.
7) Omitted: we could not identify any suitable use case for a moving floor.
8) Incorporated: we added an introduction (i.e.; a voice recording) at the beginning of the game.
9) Incorporated: we added voice feedback (e.g.; "perfect, nästa", "rätt", "fel", ...)
10) Considered: a handicapped person will need assistance from an adult.
11) Incorporated: we did, a rope from the top not make a final decision how the monkey climbs the tree.
12) Omitted: dependent on question no. 11, and we decided against the monkey falling of the tree at the end. 

Suggestions

All suggestions were directly incorporated into our design and prototype.

Team Meeting on November 4th, 2014

Today (Tuesday 4th Nov) we've been discussing what we need to finish before the final presentation this Thursday.

We were first aiming for having 10 animals for the presentation, however since we only had 8 back-boards for our animal pictures we only used 8 while testing the prototype at Naturhistoriska last Sunday. We've decided on staying at 8 animals, as it felt like more animals would just become too hard / confusing when we tried it out.

Changes to the prototype
The children who tried our prototype at the museum did not really notice the tree nor our little plush animal (Drakis) climbing up it to reach the top. To make it more obvious what the goal of the game is we decided to record and switch out the first sound that plays when a player hit the start button. Previously
"Vilket djur låter så här, tryck på rätt bild"
"Which animal sounds like this? Touch the right picture"
Now
"Hjälp Drakis att klättra upp för trädet och nå bananerna! Vilket djur låter så här? Tryck på rätt bild"
"Help Drakis climb up the tree and reach the bananas!

Make two double-sided frames with one side green and one side red, to hold in front of the pictures when the player touches the correct / wrong animal. (For more feedback).

Presentation-plan:
Prezi presentation by Jessie Janse and Alex (up to 7 min)
Prototype presentation (Everyone) (3-5 min)

To do

Jessie, Janse and Alex finishes the presentation. Practice to be concise and don't babble. Keep it short!

Thomas: reads through the blog posts we've written together (not the personal notes) looking for errors. Everyone correct errors.
Get cardboard from Pedro to make green/red frames.
One blog post for feedback, one blogpost for feedback elaboration action.
Change the dates!

Jessie: User testing blog post, bring brown colour pencils, create reset button. Get the bananas. Other groups feedback.

Johan: Walk through the forests söder om söder with a machete in search for green leaves. Put the leaves on the tree trunk. Record new "Help drakis climb the tree" sound for soundboard

Alex: Switch out the sound on the soundboard that Johan records and sends to you.

Team Meeting on October 27, 2014

Alex, Jessie, Thomas, and Petter met in Room 4523 in the D building from 15-17:30. We worked on building our prototype (which is a low fidelity prototype with wizard of oz manipulation). We decided to go with this type of prototype since our solution to the museum challenge is a large game for children aged 7-12. We constructed most of the prototype, but there are a few things left to be completed:

Tree:
- Leaves for top (Johan)
- Bananas for top (Jessie)
- Color the trunk brown (Jessie)
- Drakis for Tree (Jessie)

Side Panels:
- Finish information for panels (Thomas)
- Translate the missing text panels into Swedish (Petter)
- Print out panels (Thomas)
- Glue A4s on the panels (Thomas)
- Get 2 more poster boards (Jessie emailed Pedro)

Sounds:
- Download sounds and make playlists (Alex)
- Record Swedish instruction (Johan Lindeberg)

I'd post a picture of what our prototype looks like so far, but that would ruin the surprise.
We will head to the Natural History Museum on Sunday (11/2) to do user testing!

Team Meeting on October 22, 2014

Today we had another group meeting. Four of us met in a study room at KTH while Johan who is currently in Germany was available through chat.

The goal of the meeting was to decide all the details of how our sound room will run (process flow), as well as discussing the feedback we got from the other group in the latest exercise and use this feedback to finalize our project design. With the project design finished we will also be able to decide how to create our prototype, which will be the goal for our next meeting.

From previous meetings the task flow of our sound room looked like this:

Changes: During the meeting we made a couple of changes. First of all, instead of playing an animal sound once every 10 seconds, like suggested earlier, the sound will loop continuously for 30 seconds (or until the right animal is hit). Hitting the wrong animal no longer makes you lose the round, you can keep tapping the screens until you hit the right one. The only way to lose the round is if you have not yet pressed the right animal after 30 seconds, in which the game will continue to next animal. The new task flow can be seen here:

MISSING

Another thing that was added, as can be seen above, is some voice information during the game. This is to ensure that the kids know how the game will work and what to do. This was one of the feedback critiques we got, that the kids might not understand what to do when they enter the sound room. 

Then we talked about the details of the scoring system. Since there are 10 animals you can get a maximum of 10 points, one point for each animal you have correctly identified. The amount of points you have are displayed on the tree in the middle. We also voted on whether to start the game by using motion sensor or a button, and it was in favor of a button. The button will be located on the ground around the tree, as seen in this sketch below. The tree will also have a reset button, in case you for some reason want to start over.

Finally we decided the layout of the screens. From top to bottom there will be a text box with some short information about the animal. This is mainly for adults to read, or read for their kids. As we have seen in earlier studies of our user group they are not very interested in text information. Below the text will be the picture/animation of the animal, and at the bottom of the screen the name of the animal in big letters.

Our next meeting will be the 27th of October. Then we will create our prototype as well as practice our wizard of oz presentation for the following user testing.

Reading Seminar 2 - Summary

In the reading seminar we went through the three chapters in chronological order and discussed the different concept quite in a loose manner. The main points of our discussion will be briefly summarized clustered by their respective chapter.  

Chapter 6 - Ideation and Design Principles

We already had conducted our brainstorm session before we had to read chapter 6, 7 and 8 for the reading seminar. At this point it has to be remarked that it would have been more beneficial for us to read the literature first (Theory first!). However, retrospectively we adhered to the brainstorming rules mentioned in chapter 6. We also used techniques mentioned such as brain-writing (yes, and...), swiping, as well as we used pain points as a mean to kick-start each brainstorming round.

Chapter 7 - Refinement

In our discussion related to chapter 7 we identified money and technology as the only two constraints that do not apply to our problem, whereas all the other constraint stated in this section apply.
Related to chapter 7 we also talked about the laws and principles of interaction design, were we came to the conclusion that our design follows the principles of direct manipulation. 
Moreover, we believe that keeping affordance in mind when designing the prototype is an important thing, as this concepts drives us towards and design that is as intuitive, simple and obvious as possible (i.e.; using the right shape, color, etc.). In terms of feedback and feedforward we classified our design / solution as that has to provide immediate feedback, particularly as response time is one of the pain points that we try to tackle.

When we came across the mental model and the different laws such as Fitt's or Hick's law we all believe that most of those laws can not easily be applied to our design. The only laws that we might use is Tesla's law (i.e.; shifting complexity from the user to the system), as well as Poka-Yoka (designing the task flow such as that errors become impossible).
Furthermore, we all agreed that we can't use standards or frameworks, simply because there is none, as we do not create a software in the classical sense.

In terms of documentation we depicted sketches and storyboards as our primary means to document the design. Another technique we want to make use of is task flow diagrams, which inherently also contains use cases (but in an non descriptive manner). Additionally, we also thought about creating a wireframe in order to convey the concept of our interaction principles in more detail.

Chapter 8 - Testing

In chapter 8 we found an important technique for us, which is called A/B testing.  During the first round of sketching and designing we were occasionally faced with different design options. Hence, for such situations we can use A/B testing in order to let the user decide which way works best for him or her. When we spoke about the testing chapter we all agreed that we will follow the guidelines and create a test plan, as well as we will set up a test lab.

When talking about prototyping we decided that a low-fidelity paper prototype would be the most suitable for our project. In order to be able to modify our prototype and by that add some kind of interaction we also want to make use of wizzard-of-oz-manipulation.

Regarding the development style we think that we are going to develop in an agile way, as we meet on a regular basis in order to meet short term milestones.

Questions

Q1: brainstorming - sketches? 
No, not necessarily, depends on the project

Q2: wireframe, is it necessary with every project? 
We came to the conclusion that a wireframe is not a mandatory for every project.

Q3: are tasks and use cases related?
Yes, in the sense that task flows kind of contain use cases.
But use cases are a more detailed or "descriptive" explanation than tasks or task flows, whereas task flows are a more pictorial approach to describe a design.

Q4: When to use which mean to document a design?
Hard to answer/generalize, depends on the size and nature of a project
But for smaller projects it might be enough to only use sketches and storyboards, whereas for bigger more complex projects/products it might be beneficial to also use task flows and wireframes.