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.

Team Meeting on October 15, 2014

Every group member was present.

To be done

1. Redo design from feedback from previous evaluation
2. Prototype
1. Manual prototype, acting it out, record interaction 
3. User testing - we each need 1
1. To be completed on 11/2
4. Presentation - 
1. To be completed by exercise 6

Feedback that we are using to change part of our design:

1. Expense. The evaluating team was concerned that giant touch screens are very expensive, can break easily, and will not last a long time. Solution: large plexiglass over a digital screen that children can push on. Basically this: 
   
2. Instructions: How will they know what to do? The way we are solving this is still up in the air. One idea is that the user’s presence is sensed by the game. The second idea is to have a start button around the tree like so:
   
3. Here is another image from our ideas of our game flow from the meeting:

We will meet on 10/22 to work on the prototype. We will meet on 11/2 to do user testing. 

Seminar 2 Reading Notes - Petter Janse.

For this seminar we were suppose to read three chapters about Ideation, Refinement and Prototyping. I think the content this time was a lot more interesting and suited for our project than the first seminar. The only thing I do not understand is why this seminar was not 1-2 weeks earlier, before we did the ideation exercise. Reading and discussing the theory before doing it in practice makes more sense to me than first doing it, and then learning about it.

None the less, the first chapter is about creating ideas for your project. It talks about the importance of brainstorming to get your project started and how it should be done most efficient. Something I noted though, is that the book says the brainstorming should not be made in words, but by sketches. Why is this? And why did we not follow this in the course? In our exercise we brainstormed ideas by writing them down. Another approach of ideation is what the book calls brainwriting which we also did during the exercise, though we called it something else. The idea is that someone starts with a basic idea, and then pass it on to the next person in the group that add something to it, and then pass it on. By keeping this chain going the idea will grow from something basic to a more detailed idea with the help of the whole group. 

Chapter 6 also mentioned how to later try to filter out some ideas that might not work. This can be done by creating design principles, which is a sort of requirements that the ideas must pass to be accepted. In our project this was not as important since we did not have a many ideas to start with to filter out. But we did manage to eliminate some of them with the principles. For example when looking at the user group as an requirement we concluded that the GPS idea (as mentioned in previous blog posts) were really not intended for our user group and hence more or less discarded. 

Chapter 7 goes deeper into the refining of your ideas. Some constraints are suggested to further filter out some of your ideas. But what would normally be the biggest constraints in a real project; time, money and technology we have all been told to not focus so much on, as long as the project is not completely unfeasible.

For the matter of direct or indirect manipulation our project has a very simple interface and will only use direct manipulation. The user will hear a sound and then press the screen which he think the sound came from. It does not get much more direct than that. Instead the biggest problem we will have to solve is that of affordances, how will we make it visually obvious how to use our sound room? While the idea is really simple, to push the screen you hear a sound from, a screen do not have the regular indicator that it is a button. This is something we have discussed a lot but still not found a good solution to.

Another thing that is mentioned in the literature which has played a big part of our project is the matter of feedback. We concluded early in our project, during the museum visit, that the feedback in a lot of their stations was very poor. Some simply because of slow computers, but others because of design. The book describe the delay between user input and the device output as latency and divides it in four stages, going from immediate (0.1s) to disruption (over 10s). One of the games I played at the museum made you answer a question and if you answered correctly a text block with information would pop up that you were expected to read. To ensure that the user would actually read it, the station locks, making you unable to press any buttons for as long as it would take to read it, hence creating an disruption. This was a big deal to us and we put it as one of our pain-points and decided our sound room should always have immediate feedback.

Because our project is so simple in practice, a lot of the laws mentioned in the book will not actually be relevant for us. For example Fitt´s Laws describe how buttons should look and be placed in a graphical user interface, making them easy to target and click. But the only "buttons" we will have are the actual screens with the animals. Hick´s law and the magic number seven describe the best way for a program to handle the presentation of multiple choices, as well as never having more than seven elements to keep track on. Again, in our sound room this will never be a problem.

The Poka-Yoke principle states that you should stop anything that can go wrong as early as possible (if you can not stop it from happening to begin with). However there is not much that can go wrong in our game. The worst case scenario is that the user do not understand how to start the game and play it. Concerning the start of the game we have had some discussions in the group of what kind of controls would be best used for this. Some people have suggested a button, while I am suggesting that it should be automated by motion sensors. My reasoning is that automating the process eliminates one thing that can go wrong (above principle), that the user do not understand he should press the button to start, or he might not even see it. I have tried to motivate the use of sensors with Poka-Yoke as well as Tesler´s Law of the Conservation of Complexity which states that it is good to move complexity from the user to the system to make it easier for them.

During our last meeting we realized there were a lot of details that we had not discussed yet for how the game is going to run. What happens if a kid hits the right screen? What happens if a kid hits the wrong screen? What happens if he does nothing at all? As to not miss any steps I decided to create a Task flow to simulate everything that can happen during a run, how the program should react to it, and what happens when it does. This is not a final product, but rather to be used as an overview of the system while working on it. I think it will help a lot.

The last chapter is about prototyping, something we are just about to start in our group. As we are aiming for as little text information as possible we will instead use sound effects and animations. The book gives a warning when using sound effects, that the user might grow tired or even annoyed of them after hearing them too many times. But this is more of an issue for a program that the user will use for a long period.

At the moment we are planning to do a low fidelity Wizard of oz manipulation. Meaning that we will simulate the finished product by manually controlling the prototype. We will use big posters with the printed animals on them and place them in a circle to "create" our sound room. The members of the group will then stand behind the posters, ready to play the sound (with a mobile) of the animal, as well as a happy or sad sound to give feedback whether they pressed the correct screen. Our hope is that the use of this together with a test group will get us answers to some questions that we have not been able to agree on, such as the starting of the game.

Seminar 2 Reading Notes - Jessie Pease

The reading for Seminar 2 had the bulk of information necessary to complete the design process. 

Chapter 6 taught us about Ideation and Design Principles. This chapter would have been much more helpful to read before our brainstorming process for the last two weeks.

Ideation can be broken down into a series of steps:

1. Warm-up
1. By this, they mean literally warm up your brain, hands, and mouths. In order to have a successful brainstorming session every group member need to be mentally, physically, and emotionally present. 
2. Set a Time Limit
1. Without a time limit, brainstorming can feel like a lengthy, tiring, and never ending process. By setting a fixed time, you can have a sprint of ideas. 
2. When it comes to brainstorming, things to focus on are:
1. paint points, opportunites, process moments, personas, and metaphors
2. I really liked the different exercises they suggested for us to complete:
1. Brain writing, Break the rules, Force fit, Poetry, Questioning, Laddering, Swiping, Bizarro world
3. Organize Your concepts:
1. Label and sort by criteria
4. Creating design principles
1. This is where you finally sit down and write down the concrete design requirements and potential solutions
2. This comes after the crazy mumbo jumbo of creativity above
3. These principles should be pithy, memorable, cross-feature, specific, a differentiator, and non-conflicting. 

Chapter 7 was all about refining your brainstormed ideas. I will review the things I found most applicable to our team’s design problem. 

1. Affordances: This is appearances. How does your design look? Does it imply how a user would interact with it? The appearance needs to be contextual and cultural. 
1. This is one of our biggest issues because we don’t want to put written instructions on our game, so our design must be extremely innate. 
2. Feedback: Latency is a huge issue and often frustrates users or makes them have user errors. 
1. This is also one of our biggest pain points from our interviews. Our latency needs to be immediate, which means it needs to be .1 sec or less. More than that will cause children to lose complete interest in our game. They will likely be confused. 
3. Hick’s Law: The number of choices and how the choices are presented determines the amount of time it takes a user to complete a task and make a decision.
1. This is very applicable to our game. If we gave the children too many choices for animals after they hear a sound, then it will be too difficult and they will feel defeated when they take a long time to get a correct answer. That being said, if there are too few choices, then it will be too easy and they will lose interest. 

As we continue to develop our game, it will be crucial that we also use a site map sort of thing so that we know what happens with all the different use cases. Site maps focus on initiation, activation, and updates. For us we need to focus on start, correct answers, incorrect answers, end, winning, and many more cases. As we build our site map it could be helpful to create a story board or task flow to show off these use cases. 

A large portion of this chapter talks about wireframes. Wireframes are extremely useful when it comes to websites and applications, but I think it would be very difficult to explain our game using a wireframe. It would be a lot more words than images since there is only one way the game is set up. 

Even though we aren’t making a wireframe, and it is very complex, it does pose a lot of thoughtful questions and things to think about such as:

• non traditional inputs, gestural interfaces (how do your users move? how will they interact with it?), and presence. 

Presence is something we are dealing with at this very moment. We are trying to decide whether or not we want the users to be sensed when they enter the game area in order to automatically start the game or not. The section about presence brought up a few important questions like: Will they feel like their privacy has been violated? Will they understand why they are being sensed?

Finally, chapter 8 is all about prototyping. In criticism, I would have liked if they pointed out specific prototyping tools. Although this may outdate their book, it could be quite helpful to hear what an expert thinks about specific tools. 

Luke Wroblewski gave some specific advice about prototyping that are very applicable to our design: 

• use audio cues sparingly 
• instructional text is rarely read
• visual design shows importance and relationships between content
• personality of the design should reflect the designers
• common mistakes overstatements of visual contrast, too much emphasis on everything (basically simplicity is good!)

When making a prototype, there are different types. Ours will likely be a low fidelity prototype because we do not have the resources to create our large technical game. When we do testing, we can try A/B Testing. I think it will help us make our final complicated design decisions. One of our problems for testing is because our sub group is children, and we might have a hard time getting children to test our product, we might have to use some heuristic evaluation of our final prototype. 

The end of the chapter spoke about agile development. Agile development is not something I am familiar with because I normally work on Security and Privacy engineering teams. If I ever work on a design team, it is now helpful to know how the agile development works. 

Questions:

- Is it always necessary to make a wireframe?

- Did we do waterfall development for our project?

Seminar 2: Reading notes (Thomas Ziegelbecker)

Summary + Reflection

Chapter 6 elaborates on the gathering of design ideas (i.e.; concepts), which process is also called brainstorming or ideation. The main priority at this stage is to find as many concepts as possible (diverge first), where the authors recommend to use paper and sketches, rather then digital devices and textual description. We already applied a few of the guidelines and instructions, mentioned in this chapter, in our brainstorming session. For instance we adhered to the brainstorming rules, or we used pain points as a starting point.  This refinement / converging (defining the details) of those ideas is the contents of chapter 7. In this chapter the authors recommend to use constraints, laws and principles (Fitt's Law, Hick's Law, George Miller's Magical No. 7, Tesla's Conservation of Complexity, Poka-Yoka) as guidance when doing so. They also mentioned that affordances (feedback and feedforward) are the key to a successful design, which is what the designer should provide to the user in order to allow for the best mental model which promotes a deep understanding of a product. For instance, one should follow Standards to reduce the need for the user to learn new things, according to the authors.

The second part of the chapter was about elaborating on terms such as frameworks (metaphor, posture, structure), States and Modes (flow of navigation). In terms of framework I found the functional cartography interesting as I think that we can use it for our project. States are important, because by defining them we get a clear big picture for the prototype. 

The rest of the chapter was about documentation (Sketches/Modes, Storyboards, Tasks, Use Cases, Mood Board, Wireframes) and when and how to use them. In our project we already used Sketches, Use Cases and a Story Board (Scenarios), where we will incorporate the chapters theory. 

The very last part was about Controls and the differentiation between digital only and non traditional forms. The latter and the issues, which arise from it, will definitely be a of interest to us in later stages. 

Chapter 8  was about interface design and the transition from the design to the actual prototype (low- vs. high-fidelity). In our case we agreed on building a low-fidelity paper prototype. 

The last part of chapter 8 covered testing and gave tips of how to conduct a product test in the right way. For our project we incorporate two central tipps, which are setting up a test lab and writing a test plan.   

Questions 

• Do you really need to not use technical tools? 
• When to apply which way of documenting? 
• Do you always need a wireframe, do you always need to have Mood Boards, etc.? 
• Does the way of documentation depend on the kind/size of the project? 

Seminar 2 notes - Johan Lindeberg

After I read through the chapters and wrote down my notes, I had a discussion with my group, and realized the chapters are not the same in the 2006 edition of the book which I have. I hope it does not matter too much, as there were still a lot of good information.

I found quite a lot of interesting concepts readnig thorough these chapters, although not too many that are applicable for our project. The real-world examples made the concepts easier to grasp, and almost all of them were quite interesting, such as Gmail with Google talk where engineers made a proof-of-concept, while designers made sketches and mockups changing the by engineers created modal interaction, into a less obstructive one. The case study also related back to what was previously discussed about visual design in the chapter, such as having new chat messages pop up in high contrast for higher awareness of the user. 

Something I never thought about is that the "save-button" in almost all applications are shown as a floppy disc, although younger people today probably don't even know what a floppy disc is, it's hard to think of a symbol which could replace this.

Reading about ambient devices, and the example of a parking structure where the outside of the building indicates how full it is inspired me to try and incorporate something like this in our own design project, maybe in some way we could have the floor / walls of our "Circular sound room" to guide users. 

The examples regarding the BBC website and Amazon really showed how multitasking could be done well. On the BBC site, pages you visit more frequently gradually shows a darker blue color, which makes the website easier to navigate. And Amazon with their functionality of "People who bought this also bought.." and "What did users ultimatley buy after viewing this product?".

"BBCi and Amazon made completing tasks in the future easier and more
interesting for users, and that's something worth designing. Note, too, that
users don't have to set preferences or tell either of these sites what they are
interested in doing. The sites learn this from behaviors their users are already
engaged in. The onus isn't on users to customize their experiences; the sites
themselves are smart enough to do it. They multitask."
from Designing for Interaction, on Multitasking

The author also brought up that these changes work so well because they are subtle. Microsoft's Clippy from the earlier Word versions is a great example of unsubtle multitasking. I don't think I've ever heard anyone praise the functionallity of Clippy.

Question: Is there some way to make our project idea adaptive, or make use of multitasking?

Seminar 2 Reading Notes - Alexander Hoffmann

I also had the wrong edition of the book. But the concepts from there are quite fitting as well for the design process at out recent point.

It was explained how to come up with concepts using creative methods like Brainstorming. We used the pain points to start from and developed some ideas that were quite open(diverging). Even though we didnt read the chapter before the seminar we used the suggested way of only paper sketches.

For the Layout of our product we have something quite simple in mind. Since small children have to understand it few elements and clear placing of them is important. The flow of the animations has to be that way too. By using colors and sounds to indicate right or wrong answers we can easily and immediately show the result of the input and they will perceive it through the sound even if they dont look in the right direction at that moment. To keep it simple we will stick to the most basic type of controls: buttons.
By using general Icons that are well known (standards) we dont have to use words and that is good as well since the children dont have to read.
Presence is important as well. our system could start when someone enters the room and does not reset until everyone is outside.

Designing for connection: since our machine is local and could be connected to the internet it could comprehend a lot. but the question is what is useful. maybe repeating the difficult questions more often would be one use of memory because our users are changing all the time. (Adaption)
the other ways (customization and personalization) are not helpful because of the multi user aim of our product. same goes for flow, since our users will only spend a short amount of time with the product it will be limited to maybe start with the easy questions so every child gets the purpose of the game.
The guidelines for creating adaptive products are very useful for the more detailed design of our product. With those principles in mind we can provide a better fit of our game.
We will include some kind of ambient technology to express that the system is running but the game has not started yet. This way it doesn't look dead but users will notice the change when it actually starts.

Expert-/heuristic evaluation

This post gives a brief summary of the expert-evaluation, which was conducted according to the schema provided in the exercise slides.

Questions

During the evaluation the following questions were raised by the other team: 

1. The proposed design could be expensive! 
2. Safety concerns regarding the screens. 
3. What if large groups use the solution? primary / secondary functions 
4. Touch panels can be worn out! 
5. Are there levels? user group 
6. What about the speed of the game? 
7. Does the floor move? 
8. How will someone understand the principles of the game? 
9. How should the player know how to interact? 
10. What about handicap people? primary / secondary functions 
11. How does the monkey move up the tree? 
12. Does the monkey drop at some point?

Suggestions

The other team made the following suggestions (the number in the bracket is the question which is answered by the suggestion): 

1. Use a button instead of panels, which is more affordable (1,2,4) design/composition 
2. Speakers should be in the tree design/composition 
3. There should be an introduction before the game (8,9) design/composition

General  

Besides the questions and suggestions it was clear to the other group for whom we designed the game. However, they were concerned with whether children would understand how to interact with the game (the feeling / interaction / help). Nonetheless, they agreed that the kids would probably stay and return if the game is challenging enough.

Preparing my part of the presentation

We are the group "Swedish blondes", and we are gonna take about 10 minutes to tell you step by step what we have done so far in our project.

Our first meeting was right after the group had been created, at exercise 1. This exercise was mostly about getting started with the project and brainstorming some ideas. We talked a bit about what people wanted to do and then decided to choose children as our subgroup.

When deciding a museum, our first thought was Tom Tits, as it looked like the most fun in the list. But after talking about what the goal of our project should be, and deciding we wanted to focus on improving the fun and learning possibilities for kids at museums we switched to Nordiska museet. We figured that Tom Tits would already be plenty of fun for the kids, and it would be better for our project goal to choose a more normal museum and then turn it into fun.

To enhance the museum visit for children we first needed to know what they actually thought about their visits, and if there was anything in particular they liked or disliked. Another important question was which their favorite museum is and why. We were hoping to find a pattern among the things they liked and work with that. From these interviews we did come to some important conclusion that would shape the rest of our project.

• kids want to interact
• kids like big things 
• kids like to move around

Whenever we asked a kid about his favorite museum and why, they would tell us about some fun interaction they remembered. Likewise, the worst parts of a museum was those with little interaction.

We also learned that kids are impressed by big things. Size matters! The dinosaurs, the blue whale skeleton, and the huge panorama movie Cosmonova. So we felt that we too wanted to make something big for our project, rather than just a smartphone app or even a touchscreen table as was our first thoughts.

Finally we noticed from the interviews and observation that kids like to move around. Even an interactive station will only keep them interested for so long if they have to stand still. We felt that if we could include some movement it would be great.

Design Process Documentation

Brief Recap on Basic Idea, Target Group, Personas and Scenarios

The ideas we collected during the first exercise were rather broad and not targeted at any specific group of museum visitors. At the end we summarized the results of our brain storming session in our first blog post. However, most of those ideas revolve around one common pain point that most museums share, which is the lack of interaction. In later stages this turned out to also hold true for the museum of our choice (Naturhistoriska Museet). Thus, our basic idea was to make the museum visit a more fun and educational worthwhile experience.  

After coming up with random ideas that might tackle that problem, we decided to start from scratch rather then to try to solve unknown problems. This was also the moment when we decided to first define a target group in order to derive known problems and pain points. At the end we picked school children as our target group, as they seemed to be the most challenging and interesting to us.
After the interviews we refined our target group's age from 4-14 to 7-12 years, according to a variety of experiences we made during the interview process, which can be found in our group State of the Art Analysis analysis, as well as in the single interviews.

• Group "State of the Art Analysis"
• Interview Johan
• Interview Alex
• Interview Jessie
• Interview Petter
• Interview Thomas

We decided to do two separate personas for our project, which are complementing each other. 

• Primary: A child, Jakob (10 years old)
• Secondary: A mother, Maria (41 years old)   

In short, both of them can be described as active, ambitious and enquiring. Furthermore, those personal traits are the reason why they are also quite tech-savvy. More Details about their background and personality can be found in the following blog post: Personas and Scenarios

Moreover, the scenarios mentioned in this same blog post also reflect the pain points of our personas, which in turn more or less represent our target group. Those pain points are: 

• Not enough interactive activities
• Too long text descriptions
• Slow interactive software
• Lack of feedback
• An exhibit is closed
• Lack of information on their website
• Not enough information about the topic   

The two highlighted pain points are the ones that are the most important to our design proposal, as we believe that the others can be easily solved by the museum, by investing either money or effort.    

Design Proposal 

In order to get to our design proposal which approaches the highlighted pain points we needed both the third exercise, as well as a group follow up meeting.
In exercise three we first took the two pain points and played the "Yes, and.." game with both of them. 

Too long text 

Not enough interaction

Even more interaction

After which we designed the following three ideas.

Commercial Idea - "A game"

The first idea is a game, where a quiz decides which animals punches the other. However, after reviewing the idea within the whole group it occurred to us that fighting animals might not be a suitable solution for kids. This aspect then got changed to animals that gain something instead of punching each other. Thus, instead of animals fighting the idea came up that it could also be a monkey who gets a banana for each correctly answered question. At the end this game tries to enhance the experience with text and by that more or less tackles the first pain point - too much text. 

Crazy Idea - "Movements and Sounds"

The second idea is more concerned with interaction, where we thought of either a game that is controlled by movements or by making sounds. 

In terms of movement we thought of a game where one could try to immediate the movements of animals, which could be fed with general information about the animal.

The other part or second idea was to have a game where one has to imitate the sounds of a certain kind of animal. After reviewing this idea it was soon clear that the first one might be hard to do combine with educational content, while the second one might be very noisy, especially if several players play this game. During the idea review process it immediately became clear that we as a team focus more on the sound part of the idea and decided to change the "imitation part" to be a "match a sound to a picture" part, as it then is easier to control the noise level of the game.  
We also thought about smell, but    

The Third Idea - GPS Tracking 

The third idea was to track the movement of people at the museum to get visual information of how they move and thereby what parts are more popular. To do this every person (that wanted to participate) would have their movement tracked, recorded and then displayed on a map of the museum that can be seen on either a smartphone or one of the touchscreen maps inside the museum. The map show the museum with its art pieces and how people have been moving around. It would also indicate where people have spent more time, since when you stand still your track keep getting thicker. When combining the tracks for all people you could then tell if people have just walked past one art piece or if people tend to stop and look at it. The picture below show a mockup of how a room could look on the map, with tracks of people and how they have moved around the five pieces that is in the room. You can also tell that blue stopped for a long time to watch the bottom right object.

During the idea review process we also talked about heat maps that can be created based on the tracking and which can be used by the museum to adapt exhibitions, according to certain patterns. However, at the end we all agreed that this is hard to be used in order to improve the museum experience of kids.

The Combined Idea

After going through all the advantageous and disadvantageous of those three ideas in the exercise, we combined all the ideas in a group follow up meeting. 

The final result is a game where a player has to match different animal sounds to projected pictures of animals onto a big circular interactive wall. The wall in this case is used to shield the rest of the room from the noise of the animal sounds. We also decided to let the lower part of the wall open, so that people from the outside can see the movements that are going on inside. This should accomplish two goals. First, to increase the interests of people from the outside and second, to make it a lighter instead of a dark room. 

One round of the game would look like the following: 

A kid goes into the circle and sensors recognize that new players joined the game, lights are changed accordingly into a more fitting environment (e.g., jungle, sea, etc.).  

The child stands in the middle of a circular room that is not closed, but open at two opposite sides.

Directed Speakers start to make one animal sound after the other. The child starts to run to a picture on the wall that matches the sound of the animal. If it is the right animal both, an animation and changing lights indicate the correct match. There is also a tree in the room where a monkey sits at the very bottom. After the kid matched his first animal and sound pair correctly the monkey starts to climb up. For each correctly matched sound the monkey climbs higher up until it reaches the top, where a banana waits for the monkey. This is when the game stops.

During the kid is playing the parents read more detailed information about one particular animal (e.g., where it lives, or what it eats, etc.) every time the child matches a sound and an animal correctly. The texts either flash below or above the animals, while the animation for a correct match is played.     

Different parts of the first three ideas that were considered/integrated for the final design : 

• Game (Commercial, Crazy) 
• Interaction using your body (Crazy) 
• Score and Feedback (Commercial) 
• Lights and Sensors (GPS)

The following sketches try to capture how we imagine the room: 

and finally, the amazing Team and Drakis (doing all the hard work) our new friend that we found in one of those lovely seminar rooms. 

  

Group meeting: Personas, Scenarios, Pain points

Meeting
Today we met at the KTH library to prepare our work for the exercise on Thursday. This work consist of making 2 personas, 2 scenarios for each persona, and a table of pain points.

Discussion about personas

Our primary persona will be a child, and since we have quite a lot of information from interviewing parents, and as parents are in close connection to their children, we decided to make the secondary persona a parent.

Work to be done before next meeting
Since we did not have time to finish everything before people had to leave for lectures we decided to split up the work. Each person is responsible for creating some part of the work.

Alex: Scenario where the mother wants her kid to learn.

Petter: Scenario where the mother wants her kid to have fun.

Jessie and Thomas: Scenarios of the kid wanting to have fun.

Johan: Finalize the personas.

Until next exercise Johan will make slides for the personas, and the rest of the group will add slides with their respective scenarios.

Personas

Primary
Name: Jakob Eriksson
Age: 10
Hometown: Stockholm, Sweden

Background
Jakob lives in Stockholm with his mothers Maria and Julia, and his baby sister Anna. On his free time he likes playing ice-hockey during winters and football in the summers. When he's not playing sports he likes playing Minecraft, either on his stationary PC, or his iPhone which he is quite experienced with using.

Personality

Jakob is shy, likes to learn new things and is easily amazed. 

Today

Since Jakob has a day off from school today, his mother Maria decided to take him with him and go to Naturhistoriska Riksmuseet. It's the third time he's going there and he is really excited to go again. 

Secondary
Name: Maria Eriksson
Age: 41
Hometown: Stockholm, Sweden

Background

Maria is living together with her girlfriend Julia in Gamla Stan, Stockholm. She works as an accountant at Handelsbanken. She studied Industrial Managment at KTH in Stockholm. She loves her family above everything else, and enjoys spending time with them whenever she can. 

Personality

Maria is very ambitious, intellectual and adventurous. She likes to spend time with her children, especially when she's helping them to learn new things. A true Apple fan, she knows her phone and Macbook in-and-out, but whenever she picks up her girlfriends Nexus 5 or is forced to use Windows she is quite clueless.

Today

She took the day off from work to take her children to Naturhistoriska. She wants Jakob to learn something new and have fun on his day off.

Scenario 1, mother want her kids to learn. (Alex Hoffmann)
Maria heard about a new exhibition in the Naturhistoriska Museum so she took the day off to go there during the week when there wont be as many people. The new exhibition is supposed to be specially directed at children so she hopes Jakob can learn a lot there.

On the internet page of the museum she takes a look at the map and decides to combine the visit with an older exhibition about prehistoric animals and humans because Jakob loves the Ice Age movies.
In the museum they first visit the older exhibit. There are a lot of life-sized animals and huge skeletons. Jakob is impressed by the size and asks what all the animals are. Maria tells him about the animals and the world back then while they pass through the exhibition. Jakob always runs to the next pieces, amazed by the size and new images. Maria has the feeling that he is learning a lot in that room but there have been only plates with more information for her, nothing interactive for Jakob.

After that they go to the new exhibition. As expected its quite empty so Jakob can run around from one to the other. Maria doesn't have to explain a lot because everything works on its own. Jakob is able to interact with everything and learns by doing so. Maria thinks that more information about the things he is doing would be better though. This exhibit is more of a playground with a theme than a exhibition. While Jakob is at another piece she tries out one of the pieces with a display because probably there is more information to get. But unfortunately it is just a very simple game-like series of pictures without real content. She thinks that this room is too much to play around and too less information and learning.

When they leave she wonders if the combination of those two exhibitions would be a good solution. She also needed a better way than plates to get information for herself. Then she would have been able to explain even more to her son. Jakob was really happy with the visit, he had a lot of fun and says he wants to come back . So at least his interest in museums is strengthened.

Scenario 2, mother want her kids to have fun. (Petter Janse)
Maria has taken the day off to take her two children Jakob and Anna to the Naturhistoriska museum. She chose this day because there is a teacher day at the school so both her children have their day off and need someone to take care of them anyway, so they might as well get a fun day together out of it.

When they arrive at the museum they find a map that shows that there are two floors with exhibits. She also sees that the dinosaur exhibit is closed for renovation, something she did not see any information about when she visited their homepage to find the opening hours. She is disappointed because she knows Jakob love that exhibition. Instead they decide to start with the first one on the entrance floor. This is an exhibit about "diversity of life" with a lot of stuffed animals, and there is not much to do other than look at the various animals and read the names of them. Both Jakob and Anna quickly gets bored and tell Maria that this is no fun. Maria understand that just watching stuffed animals and reading their names are neither very fun nor interesting for children of their age.

Maria sees a employee and asks him if there isn't anything more suited for children of their age. The employee answers that there is an exhibit one floor up with a lot of fun interactions that is suited for younger guests such as her children. Maria and her children leaves the diversity of life exhibit and moves upstairs to "the human animal" one instead. Here there are plenty of interactive activities such as; can you jump as far as a rabbit, can you hang from a tree as long as a monkey, or remember as many numbers as a chimpanzee. The children love it, and Maria is happy that her children are having fun.

But Maria also wonders why some exhibits, especially the human animal, have so many and great interactive possibilities where other exhibits are just plain watch and read. She feels the museum visit would improve if more exhibits had similar interactions as an alternative to that.

With this scenario I bring up three of the problems from the pain point table. The lack of information on website, an exhibit being closed and the lack interaction being boring for children.

Scenario 3, kid wants to have fun. (Thomas Ziegelbecker)
It is Jakob’s day off from school on this sunny Monday.
Today he wakes up very early, because he is really excited about the museum visit to “Naturhistoriska museet”, which his mother Maria promised him. However, it is not the first time for Jakob to visit this museum, as he already went there twice with school and he really enjoyed both of his visits. One of the reasons for that is their new exhibition, called “the human body”, which Jakob likes the most as he thinks it is the most fun.

After the family arrives at the museum Maria asks Jakob what he wants to do first. Even though Jakob visited the museum twice, he does not instantly know. Maria, a little bit confused, then asks him what he can actually remember from his last visits.
So Jakob starts to list a few things including, the human body, the cinema, the dinosaurs and the hall with the big skeletons.
Therefore, Maria checks the map and suggest to start with the big skeletons and the cinema, as both are downstairs.
Before they reach the skelletons, they have to cross a few other rooms. For instance, rooms full of minerals, or ships. Although Maria believes those rooms to be interesting Jakob does not like them at all and seems to be very bored when Maria stops at some random ships. Jakob considers those rooms to be boring, dull and no fun at all, because he just does not know what to do in there. After a while he tells Maria that there is too much text and no activities for him. Thus, Maria hurries up and they finally get to the room with the big skelletons. Jakob’s mood improves instantaneously and he is really impressed at first, but that does not last for long and so they go to the movie. When they reach the last room Jakob is really happy and he gets really excited again.
Jakob really enjoys the small little games in the last rooms. They are way more interactive than the little games on the touch screen in the previous rooms. Those games took very long to react to his input and he did not really understood the aim or purpose of the games. He always looked for feedback at the end or some kind of incentive to solve the quiz question, but nothing happened at the end of the games. Thus, he always losses his interest in them very quickly.
The games in the last room are totally different, they are more physical and respond way faster. Jakob really enjoys to explore all the different human parts which he can either touch, read and or even smell.

At the end Jakob wonders why not all rooms could be more like this last one. Explorative and fun!
Maria noticed that Jakob really likes the last room the most, as this room was also the one room with the most kids inside. So she asks Jakob why the last room is so much better than the others. Jakob answers that this is because it is not ordered or as clean as the others. There are no plates but whole tables that you can also touch. The room is also more colourful, chaotic and lighter than the others. It’s more like a living jungle, he says.

Scenario 4, kid wants to have fun. (Jessie Pease)
Today is a Friday in October, and Jakob does not have school today. He quickly wakes up and runs downstairs for breakfast. His mom said they were going to do something fun today! As he sits at the kitchen table eating his müesli and fil, his mom gives him 3 options of things to do for the day. 1. Go to the park. 2. Go to a movie. 3. Go to the Natural History Museum. He screams "tre!!!" He knows that if he goes to the Natural History Museum, it's like going to a park and a movie in one trip. Jakob, his mother Maria, and his sister Anna pack up the car and drive over to the museum. Jakob has been to the Natural History Museum before, but only with his classes in school. Today he can do whatever he wants!

As they enter, Jakob runs over to the dinosaur exhibit. As he approaches, and his mom jogs behind him, they notice that the exhibit is closed. His face goes from :D to :( in half a second. Luckily because Jakob is only a ten year old little boy, he moves on quickly and starts to jog to the large underwater animal exhibit. He remembers that there were big animal bones there too! When he arrives, he looks at the various animals hanging and behind the screens. He gets bored pretty quickly. He goes over to some of the interactive parts of the exhibit and presses the buttons, but he hates reading, so he just keeps walking. He goes through the entire exhibit in less than five minutes.

Jakob normally goes to the museum with other friends, so they play games with each other and run around. "Why is the museum not as fun today?" Jakob says to his mom. She looks at him with a concerned and sad look on her face, shakes her head, and says, "I don't know." She suggests that they go see the movie playing in 15 minutes at the Cosmonova. They buy tickets and get in line for Sea Rex 3D, which is the movie that combines both dinosaurs and underwater animals.

After the movie, Jakob runs out and says that he loves dinosaurs so much that he wants a plush dinosaur stuffed animal from the gift shop. Maria feels bad that Jakob was sad earlier, so she buys him and Anna both a stuffed animal.

After the gift shop, Maria takes Jakob up to the Human Animal Exhibit, but there are 350+ people in the exhibit, and they can't see anything. It is too crowded. At this point, Anna is getting tired and needs a nap. Jakob is hungry for lunch. They decide that they have had a fun time at the museum this morning, and they head back to the car.

On the way home, Maria asks Jakob, "Did you have fun today?" and he replies, "Yeah!!!" He follows that excitement with, "But mom, it was not as fun as last time because I got bored in the big animal exhibit. I wish I could have played with the toys in the human exhibit too. The movie was the best part because it was big and flashy! There were lots of sounds, big animals, action, adventure, and it was in 3D! I wish the whole museum was as cool as the movies." Overall, Jakob is very happy with the movie, the new dinosaur plushie, and the fact that he got to run around the Natural History Museum again.

Pain points




Issue/Opportunity	Primary Persona	Secondary Persona
Not enough interactive activities.	1	2
Too long texts descriptions	3	3
Slow interactive software	1	2
Lack of feedback	1	4
An exhibit is closed	2	3
Lack of information on the website.	5	2
Not enough information about the topic	4	2