Navigation schematics

The upper navigation schematic illustrates the layout of the fourth and final prototype, and the nether is very similar to the third  we developed after having finished the extreme and usual prototypes. We erased quite a lot of functionalities when developing tour final prototype as we felt the former ones were't very focused on the accessability problems for our target group in the museum exhibition we really were aiming to address. The final prototype is much clearer in what it aims to do and is much easier to use for our target group.

Interactive Prototype - Second Version.

Following the think-aloud evaluation and presentation of our interactive prototype, we have had a group discussion on what to improve for our second interactive version. We also made a more extensive research on elderly and their use of technology, more precisely smartphones (see here)

The main problem we encountered during our field-test of the prototype was navigation. Our main idea of a "navigator" showing where in the app you are, seemed to confuse the users and it was quite obvious that we had features that stole attention from the main functionality and made the navigation in the app more confusing.

Therefore we decided to remove our "navigator". After a long discussion we also came to the conclusion to completely remove the "Menu" bar. This way we not only removed additional buttons and features like "About the museum" but we also improved the app. Even though we would have liked to keep the features, there was no way of doing this without using screen-on-screen composition. Something that both the literature and our own observations pointed out was something that made the app less user-friendly for our primary persona,

After this decision we put our focus on making use of more interface metaphors, placement of buttons and removal of as much text as possible. Taking into consideration that if a screen is too 
"busy" it will be difficult to process the information.

So first we removed text on the buttons linked to main functions. Eg the "tillbaka" button is now instead a universal camera icon. This will not only emphasize the main function of the app (audio-guide) BUT since our app is horizontal in style going back one step equals going back to the camera screen.
We also changed the "more about this" to a universal book icon. The reason we chose to keep this function despite that our target group may be prone to bad eyesight, is because a screen is well lit, and if necessary when creating the final product the text could be made larger.
These are the two main functions our app provides, therefore no additional decoration is needed so as to avoid confusion.

Instead of a Menu we decided to add a "Settings" button (universal icon) only available from the camera screen. The only available settings are Language and a replay of the animation video. There is no need to be able to access this from any other screen, since we treat this as our "home" screen. You will immediately notice if the language is wrong or if you don't remember how the app works.

In the end we opted not to include any auditory feedback. Since it's an audio-guide it might lead to confusion if other sounds start playing. We discussed using vibrations as tactile feedback, but again this might distract or confuse the user. What happened? Why did it vibrate? Did i do something wrong? are just a few questions we could think of when creating a scenario with tactile feedback.
We feel that since each button is connected to one clear function it is easy to notice what changed in the app when the button is clicked. We feel this gives enough tactile feedback.

Link to second version of our app!

Theory: The Elderly and Smartphones

We found that researching literature on how elderly people interact with smartphones was very giving, but also that it was a surprisingly small field of study. Older people inexperienced with smartphones is  becoming a smaller group of people day by day and therefore the field seems to be considered with little interest. This, and the large differences in lifestyle between elderly in different parts of the world make it hard to find relevant literature as much research is conducted in USA and China. Still, here we present some of the findings that we have used to make decisions during our process.


The article Motivations and obstacles to smartphone use by the elderly: developing a research framework summarizes  findings from different studies. For example, it lists a few very obstructing features in mobile applications. This has helped to make it clear what we has to avoid in our design. One primary obstruction is the physical limitations common to older people that can complicate smartphone use - impaired sight, motor skills and finger dexterity. Also, cognitive abilities can be a problem as it is sometimes hard to recall and/or process the amount of information on screen. Therefore distracting and superfluos elements have been cut to a minimum in our prototype. Moreover, the article hints that several studies show that visibility and usability should be connected – the most used functionality should also be the most visible.

We attempt to address these issues in our design by strongly linking visibility and usability, for example by designing large buttons with clearly readable text. This is thouroughly explored in the article A Study of Pointing Performance of Elderly Users on Smartphones where size and spacing is shown to closely influence task completion. Audiotory and audio-tactile feedback is shown to be very positive for elderly users (though only tactile feedback is detrimental to this user group). Therefore, we will try to implement audiotory and tactile feedback in our application. However, the main issue is shown to often be of cognitive character. That elderly seems to not find navigation as easy and intuitive as younger people has since become a whole field of study in itself. Our app is very easy to use in this regard.

One article that explores navigation systems is Mobile interface design for low-literacy populations. Though literacy levels in Sweden are generally very high, we found this study very interesting as it thoroughly explores how users with a previous low level of contact with smartphones react to different navigation strategies. The study inspired our more linear navigation as errors seem to be fewer in this type of navigation, and we decided (as stated in the 6.1 Design Recommendations) to “start every action from the same location” – in our case the HOME (photo) screen. This study also provided very hands on background to some other desicions we had previously debated. For example, once HOME screen is reached our app, out maximum path length is very short – just 2 steps. Therefore we opted out of a HOME button and instead implemented a BACK one. The study also mentions scrollbars as a new phenomenon to most participants in the study, but one that most learned how to use very quickly, and so we decided to implement this in our app even though we previously had wanted to limit ourselves to clickable functions which we believed to be more intuitive.

Summary of our Think Aloud Evaluations and future improvements

We used the Think Aloud Evaluation assignment as an opportunity to thoroughly evaluate our current prototype, and for further improvement. The evaluations we did focused on testing both the design and implementation of the current features in the app. The goals with our evaluations was to assess the extent of our prototypes functionality, and level of customization. Another important goal of these evaluations was to identify specific problems in our app.

The Think Aloud Evaluations were carried out through making people click around in our app while speaking out aloud about their thoughts as they navigated. At the same time, we observed the users and noted their reactions and actions while we judged how well our design supported the intended task, Audio Guide. We also took careful notice of the problems that occurred. In the end of every Think Aloud Evaluation, we asked the user to summarize their experience of our app, and what feature that made greatest impression on them. Throughout this process, we found out what features of the app that already worked as we expected, and what features that did not work as well as we thought. This was a very helpful step in the iterative process; we could actually observe the users and follow their thoughts and actions while using the app. Thus we found out why some of the features were not user friendly.

To summarize the result form our Think Aloud Evaluations, our prototype proved to be relatively easy to use in general; especially the Audio Guide functionality were correctly interpreted. However, there were also many features that could be made more user friendly. According to our tests, there were some navigation problems in our app. Almost all users tried to click on not clickable icons/images/decorations. It was obvious that there were confused by what icons were buttons and what icons were decorations. This is something that we have to improve! We need to simplify our design, remove distracting features and decorations that does not contribute to our main Audio Guide function, and make sure that no icons can be misunderstood.

For instance, we could use more interface metaphors instead of explaining texts, change the colors, text sizes and localizations in our application to make sure that the most essential buttons/features are emphasized on the screen. We also need to make the app more horizontal, decreasing the amount of pop-up screens and depth in the app caused by the vertical screen-on-screen compositions. One idea of doing this is to remove some of the additional features. As our tests showed, the more features our app had, the more complicated and difficult to manage it became. Since the main functionality is the Audio Guide, other additional functionalities like "about the museum", "menu", etc that are not directly related to the main functionality should have reduced attention, or even be removed. Consequently, the main Audio Guide function will be even more enhanced.

Improvements - using evaluation feedback

After the exercise, we sat down and discussed the feedback we got from group number two in order to improve our prototype and start working on an interactive version using the "PrototypingOnPaper"-app.
A few of the improvements suggested we didn't include since we felt they were not user-friendly for our target group or took attention from the main functionality (audio guide) of the app. The following functions are the ones that we chose to include or change:

• Introduce a rewind button - If you loose focus and miss what is said, it will be easy to replay it. One click should rewind a fix amount of time. If the person by accident holds in the button it will still only rewind "one step". We made this decision based on observations that some elder accidently push the screen for a longer duration rather than one fast "touch".
• The "Mer info" button should be a popup instead of a new screen - If it is a pop-up it is still clear where in the app you are. Less windows to transverse. The pop-up is closed with the user friendly "X" in the upper right corner
• Add a progression bar - non clickable! To know how far into the audio-track you are. It is important that we make the design of it "flat" so that it doesn't look like it's clickable.
• Flags instead of text - Intuitive metaphore and this way there will be less text to read.
• Animation "How to use" - this makes is easier to use independently. Now you don't have to ask someone to show you how it works.
• Instead of arrow, use button with camera icon. - OBS only when the arrow means "go back to camera screen" This makes the app more horizontal in style and it's more clear and easy to understand where in the app you are moving to.
• Menu bar available from all screens - Makes the app easier to use since now there is less transversing over several screens in order to reach for example settings or additional information.

Link to preview prototype.

A small note: since this is only the first draft, and we drew on paper, the buttons and text is not very well visible. Of course this will change during the next iteration step. :)

Evaluation on Prototype.

Since our last meeting when we sat down and decided on what features and functions to keep, we have built a simple low-fidelity prototype to bring to the exercise to be evaluated.

For the time being there are only clickable options in this app. We have yet to include swiping motions in such a simple (and intuitive way) that we feel is user friendly for our target group.

After making an extensive presentation explaining our functions and ideas, group number 2 gave us examples on what to improve. 

• Text should be more well visible (tydligare)
• Use flags instead of text for language selection (or a combo)
• Information about how to use the app in form of an animation or short video
• Welcome text: "Welcome to the Museum of Medieval Stockholm" or similar.
• In the animation, inlcude a picture of what to scan and where it is situated in realtion to the showcase.
• Insted of having an arrow when it means go to the photoscreen, use a picture of a camera. In other cases, use the arrow or write "Tillbaka".
• The "menu" bar should be available from all screens.
• We need to use more interface metafors in our application, Ex a questionmark, available from every screen, that leads to a help page, where the animation/short videio of how to use the app is also available. Also maybe a button for settings.
• A "rewind" button, When you press it once it rewinds 10 second of the audio.
• A progression-bar that shows how far in the audio-piece you are. Both remaing time and passed time.
• the "more about this"-button should just be a popup, not a new screen. When you press this the audio is paused. There is an X in the top right corner that minimizes the popup. So if the user wants to play the audio after closing the popup, they have to press play again.

We are planning on continuing this iterative process of evaluation and development by considering all and applying some of the feedback listed above.

Group Evaluation of Parallell Designs

During today's exercise we discussed our two versions of parallell design. We made many decisions and came to good conclusions about how we want the prototype to look. The design is going to be both customized to the Museum of Medieval Stockholm, as well as simple so elders will understand the product easily. We took the best parts of each design and came up with a list of things we wanted to include in our product.

• There should be a language setting that is a one-time setting. It should be accessible when you start the app for the first time after installation. This is because we don't want the users to see the same screen over and over each time they open the app. However, it should be possible to change the language within the apps settings-menu. 
• Menues are rolled out on parchment-rolls when the user clicks the button for the menu. When the parchment-roll is rolled out there should be a small arrow pointing upwards that when you click it rolls up and closes the menu again. This is manily a esthetic design property to make the app fit to the museum of Medieval Stockholm. 
• There should be only ONE "menu"-button at the op of the screen. However, within the menu there should be more clickable buttons that lead to "more info about the exhibitions", "about the museum", settings". These buttons should also be placed pretty far apart so the user doesn't accedentally click the wrong button. This might be especially common for our target group since elderly people can have coordinations isses with fingers.
• When a picture/symbol has been scanned the audio track should be played automatically on a new "now-playing"-screen. This is because we want the app to have as few clickable options as possible, for the sake of the people of our target group, who may not be used to clicking around much in applications on smartphones. On this "now playing"-screen there should of course be a title of something like: "Now playing: XXX". Other things on this screen should be a "PAUSE"-button, a "BACK"-button that leads to the HOME-screen, a "MORE ABOUT THIS"-button that gives additional information about the exhibition the user is hearing about. 
• At the bottom of the screen there should be a small picture of a knight that helps the user understand where in the app they are currently at, since we want our app to have several levels. When moving deeper into the app the knight should move to the right. 
• On the HOME-screen, the focal point of the camera should have an outline that matches the objects on the wall that is going to be scanned. This makes it easier for the user to understand where/how they should hold the smartphone in order to scan the symbol on the wall.
• The colors and buttons in the app should be customized to the middle ages to make the app fit well to the Museum of Medieval Stockholm. However, they should be quite discrete so they don't take away the attention from the buttons that acctually have a function within the app. 

  

Parallell design session

During this exercise we worked with parallell design, so we divided our group into two smaller groups and each group started working on separate designs; one regular and one "wild and crazy". The regular one was created by Alva and Sofia, and the "wild and crazy" one was created by Carolina and Lovisa. 

When we created our design we thought it was important that the prototype would be easy to navigate, to fit our target group. We also tried to find research that would help us make a prototype that is user friendly to our target group. As mentioned in the research article "Motivations and obstacles to smartphone use by the elderly: developing a research framework" (link here) it is important that the main function of the product is the most central and visible one. So, for our product, whose main function is an audio guide, it is important that the audio guide function is easily found and that other, less important functions are there only to emphasize the audio guide function. Another essential thing that the article adresses is to make the application horizontal, with few levels of depth. According to the source, eldery people often have issues traversing multiple menu levels. So remembering where to go is a common problem. Therefore, our prototypes are mainly of horizontal design. 

Regular design

Besides the features mentioned in the research above, we also wanted our regular prototype to include large buttons and large text, since elderly people commonly have physical obstructions, such as coordination of fingers. The most important buttons on each screen should also be the most emphasized ones. We also thought about different interface metaphors, such as color coding different buttons to put extra feature on their different functions. For example, a red "pause" button and a green "play" button, since those colors are often associated with labels such as "stop" and "go". We used neutral colors, such as blue and light yellow for the buttons that were not the main functions for the application. We also used interface metaphors for using symbols instead of text on a few buttons in our prototype, for example an arrow for the "play"-button (se picture below). We also wanted to have small amounts of text on the screen, since the article mentioned above specifies that elders often experience difficulties with busy screens, i.e. too much presented at once in menus/on screen. 

"Wild and Crazy" design
 It is quite difficult to decide what functions to keep, when your primary persona doesn't have much technical knowledge regarding apps. In practice this means that the difficulty of navigation is directly linked to, if the prototype is of horizontal or vertical design.

After a long discussion mainly regarding the problem space, we decided that in order for us to fully embrace the "wild and crazy" design, a person from our target group would be more like our secondary persona (more technical), so that we could add one or two extra levels of depth in comparison to the "regular" design.

What should it look like?

That being said, we still tried to keep the interface metaphors relativly simple/universal so as not to compromise the usability.  For example we still make use of the typical "play" and "pause" buttons, but instead of making them overly clear eg green and red buttons, we choose to design them as medieval shields instead.
In this prototype we have a menu "scroll" at the top of the screen from which you can access different type of settings, information about the museum's exhibitions etc. Our intention is that when clicked, this menu will "roll out" as if you're reading a parchment roll.

 For our color palett we tried to use colors associated with the medieval times, eg light brown, purple, beige etc BUT we made sure that the background colors were of the the lighter type so as not to make the concept too dark and dreary and enable easy navigation (well visible buttons).
Since this version has more "layers" than the regular design, we though of a sort of "navigator" at the bottom of the screen. So when you move "deeper" into the app the navigator moves further to the right. And when you go back to a previous screen, it moves to the left.

Building.

Notes for seminar # 2 - Alva

For this seminar, the focus of the reading material was on prototyping and evaluating prototypes.

In order to eventually create a first design, it is important to first gather requirements that the product needs to fulfill. You need create an initial conceptual model, a model that takes interface methapors (metaphors that help the user understand the product), interaction types (which support the user’s activities?) and interface types into consideration.

A prototype is an early model that tests a concept or process. There are mainly two different ways of prototyping; low-fidelity prototyping and high-fidelity prototyping. There are pros and cons with both of them, and depending on what developing stage you are in, you should be careful of which to use. A low fidelity prototype has low development cost, so it is often possible to create multiple designs and chose the best features from each of them to use. However, low-fidelity prototypes are often not very detailed, thus they cannot be used for error checking. High-fidelity prototypes are more developed prototypes with more specified and complete functionality, very close to the final product. Since their functions and appearance are highly specified, they can be used for experiments and tests. The user can actually look and feel a high-fidelity prototype as this kind of prototype often have a physical design and is a concreted model of an earlier less specified prototype. It can be applied in scenarios to model situations that can test the usability of the design. The negatives sides are that high-fidelity prototypes are more expensive and time consuming to develop, thus they are also harder to alter if there is something that needs to be changed. High-fidelity prototypes are also not effective for requirement gathering. Consequently, they are not suitable to be used in an early stage of developing a product.

Evaluation is driven by questions about how well a design or a particular aspect of a design satisfy the requirements set for the product, and if the design offers appropriate user experiences. Mostly, is is about doing tests based on experiments and field studies that evaluates the design’s usability.

Question to discuss: How can we evaluate our current design in the best way? And how do we know if our current design meets the requirements we have set for our final prototype?

Notes for Reading Seminar 2

One very important part of developing a product is evaluation, which the book summarizes into four points. The first is called “quick and dirty” which means that designers informally get feedback from users or consultants to confirm that their ideas are in line with users’ needs. The second is called usability testing and gives information that is used to calculate performance times, identify errors and help explain why the users did what they did. The third is field studies which helps increase understanding about what users do naturally and how technology impacts them.

Another important part when developing a product is to use the right methods, i.e. the combinations of techniques used to develop a product. There are five categories. The first is observing users, which is commonly done by notes, audio, video, and interaction. However, there is a challenge for evaluators in how to observe without disturbing the people being observed. The second is asking users – an obvious way of getting feedback. Interviews and questionnaires are the main techniques for doing this. The third is asking experts, which is relatively inexpensive and quick to perform. In addition, experts frequently suggest solutions to problems. The fourth is user testing, where data is collected so that performance can be analyzed. The fifth and final is modeling users' task performance.

The book also bring up a term called the DECIDE framework, which is a list of things to think about during evaluation. The list consists of the following points:

• Determine the overall goals of the evaluation.
• Explore the questions that need to be answered to satisfy the goals.
• Choose the evaluation paradigm and techniques to answer the questions.
• Identify the practical issues that need to be considered.
• Decide on the ethical issues and how to ensure high ethical standards.
• Evaluate, interpret, and present the data.

A final thing which is good to think about is to draw up a schedule for your evaluation study in advance. You should also do one or several pilot studies. This helps to ensure that the study is well designed and likely to be successful.

My question: if you find it difficult to find access to the user group, how do you get feedback on your prototype?

Reading Seminar 2 - Notes

When thinking about your product and what you want to develop, it’s very difficult to just ask people what they want without pointing them in the direction of your own ideas, however if they use something, they fairly quickly know what they DON’T want. This is one of the main reason why prototyping is so very important.

   But before we start prototyping we need to have a sound understanding of our users, their needs and what goals our product should fulfil for them. The best way to do this is to observe the users in question and perform an evaluation, to ensure that our product is right for the users.

   First we need to break down and determine the overall goals with our product, which our evaluation should address. Secondly we need to break down the “Why do people want this?” question into several more pinpointed sub-questions. “Is it because of this/that?” This will give us the opportunity to test or confirm ideas, making the evaluation more detailed.

   In order to answer these questions we need to study the users in question.  Choosing evaluation paradigm and techniques is not easy. What may seem most appropriate may take too much time or cost too much. Sometimes the best solution is to combine several techniques.

   Usability testing is one way, but it should be pointed out that this environment is strictly controlled by the evaluator. We also need to take special care when forming the prepared task the users should perform, and how long it should take. The number of users are typically too small for a statistical analysis and the results are mainly quantitative.

   If we want more qualitative data, field studies may be a better option. But the problem here is how to observe without disturbing. Environment may or may not influence data which in turn may not be 100% reliable due to it sometimes being verbal. But compared to usability testing you will gain invaluable insight into how users “naturally” use our product.

   Both of these techniques raise several questions about practical issues. Such as what users are “typical” for our product? What type of equipment should we use? What type of environment should we study etc. Also don’t forget to analyse all these questions with time and budget constraints in mind.

   Of course if you do interact with users, ethical issues may arise as well. Common practice is to keep the users well informed and assert anonymity (no personal info will be shared unless permission is given). It is of vital importance that no person is identifiable through the research notes!

   Last but not least. All your data need to be thoroughly analysed. Is it reliable? Will it produce same (or very similar) result if the test was performed at a diff time but in the same environment? Does it measure what it was supposed to? Does the environment have any influence on it?

   All this is needed BEFORE we even start to think about our conceptual design or prototype AND it is something that probably will be used several times during the iteration cycle for the prototyping.

At early stages of development, it’s important to hold discussions and review meetings. It enables you to get diff perspectives and in case of low-fidelity prototypes, rapid feedback from colleagues. Also, informal feedback from users early on may prove invaluable when developing an interface metaphor or interaction paradigm.

   If you reach high-fidelity prototyping again it’s important to note the DECIDE framework. So that the prototype still is in line with the users’ needs.

Depending on what type of feedback you want on your product, sometimes it might be better to have a high-fidelity prototype with a horizontal prototyping rather than low-fidelity prototype. For ex if you want feedback on a design for an interface.

Question:

What would be more efficient for usability testing of an app, evolutionary- or throwaway-prototyping?

Notes for Reading Seminar II

Chapter 11 - Prototyping

Using for example scenarios and prototypes to simulate the user experience of our product will help us to reflect over basic user needs during our development pocess. Low fidelity prototyping fits our project the best; it is flexible, cheap in manufacturing effort and easiest if we want to iterative over both our conceptual and physical design. During this continuous iteration, we have found that the scenarios are very handy to apply. They really boost our discussions. We have also been disucssing the fuctionalities of our product and how these are related, so the initial conceptual model is well underway.

Chapter 13 - DECIDE framework

The DECIDE framework for evaluation describes how to go about evaluation of our system.

First we need to figure out what we want to find out from our evaluation - why do we want to evaluate? Then we must break down our questions (about users, their attitudes to the problem we are trying to solve and so on) into subquestions, to properly be able to explore these in our evaluation. Later we must choose a method to carry out the evaluation in a practical and effective way. Time resources, setting, number of participants - all of these must be taken into account.

Handling people is something of an art, as ethical issues always arise. Therefore, it's very important to properly inform the participants in any activity of what's logged and what may be publicized. Protecting privacy is important.

Lastly, all information can be analyzed, interpreted and presented. This information is what will help us to renew our designing process, so this is perhaps the most important part of the evaluation. However, faulty evaluation methods will inevitably reslut in falulty data and interpretation - so we should be very thorough.

Chapter 14 - Natural Setting Evaluation

This chapter first discusses evaluation in controlled (lab experiments) vs. uncontrolled (field studies) settings. For example usability testings can vary a lot depending on the location of the study. Testing mainly generates in quantitative results such as how long it took to complete a task, while observation of a user can generate more qualitative data. Field studies are very important, as they show us how our product would actually be used 'in the wild'.

Question

A more controlled situation, or less? How good should our physical prototype before we ean evaluate it with live participants instead of simulating scenarios? Is a more, or less, controlled situation better in our case. (And how do we effectively manage our time?)

Scenarios and PainPoints

PainPoints:

Issue/Oportunity	Primary Persona	Secondary Persona
General information about the museum	4	2
Easy to use application	5	3
Chance to get additional info outside the exhibition.	3	4
Translation to other languages.	2	5
Track progression in exhibition	1	3
Offline mode.	2	4
Exhibition in-depth material	3	2

Scale: 1-not very important, 5-very important

Scenario 1 (by Alva Liu): Ulla-Britt and José become separated at the medieval museum. Unfortunately, José’s (internet stops working about the same time) phone does not have any service at the same time. What should José do? What can Ulla-Britt do?

Goal: UB and José want to find each other again.

It was a Sunday afternoon and Ulla-Britt and José decided to visit the Medieval Museum of Stockholm. They took a nice walk along the Queen’s Street there and since Ulla-Britt have been there before, they found the museum without any problems.

At the museum, José followed Ulla-Britt to the reception where the receptionist showed them a new information/navigation tool they could use to get to know more about the different exhibitions. The receptionist told them that the tool was a replacement to the previous Audio Guides that the museum used. Ulla-Britt was at first quite sceptical to this new tool, but José was excited to try them out, especially since they had translations in English.

After having the functions of the tool explained to them, they continued to the locker room and left their coats there. Then, Ulla-Britt and José entered the first exhibition room. José was very fascinated by the different showcases and stopped to get to know each of them more by using the new tool. However, Ulla-Britt moved along the different exhibitions faster, and soon she had moved along to the second, much larger exhibition room. When José was finally done with the last showcase and went into the second room, he suddenly realized that he no longer was accompanied by Ulla-Britt. He started to walk around in the museum, looking for her, but soon he was lost. Unfortunately, when José finally decided to call Ulla-Britt, he discovered that he did not have any service on his phone because the Medieval Museum was underground. He was just about to find another museum visitor and ask for the way to the reception when remembered that the new tool had a navigation functionality. So he went to the closest exhibition and scanned the tool there, and with the help of the tool, he could find his way back to the reception. At the reception, Ulla-Britt was already waiting for him. Relieved that they had found each other again, they continued their museum visit.


Scenario 2 (by Sofia Jacobsson): Ulla-Britt is visiting the Museum of Medieval Stockholm with her two grandchildren Elsa, 7, and Daniel, 3.

Goal: She wants to know how to walk to the museum from the subway, whether the museum offers a guided tour specified for children, and if she will be able to walk around with the stroller in the museum.

It is the day before the museum visit and Ulla-Britt is at home, preparing for the visit. She tries to search the internet for information about how to get there and uses Google as a search tool, since it is the way one of her sons showed her how to find information about things. She finds the location on Google Maps, however, there is no description of how to walk there. There is only a map that points to the correct location. Even though Ulla-Britt has been to the museum before, she does not quite remember how to find its exact location. She knows it is beneath the ground so she wants to find a full description of how to get to the entrance of the museum. Last time she visited the museum she experienced difficulties when walking from the subway-station to the museum because there weren’t enough signs leading to the entrance. She does not want that to happen again now that she has her grandchildren with her.

Ulla-Britt uses Google search tool again and finds the museum’s website. She is confused about where to click to find the information she needs. Ulla-Britt finds information about some kind of program or application that is downloadable for her smartphone, which can give her information about the museum. However, she does not understand how to get the application onto her phone and gives up on that method. She goes back to the computer and the museum’s website. She then sees a symbol which could represent some kind of location and presses the picture on the screen. Now, a detailed description with information about how to walk there. Her first task is complete.

Her second mission is to find information about the guided tours at the museum. She tries to navigate her way around the website for information but after 20 minutes of not finding anything she gives up. But since Ulla-Britt is quite stubborn, she need to find this information and decides to call the museum. She finally receives the information she wants and her second mission is complete.

Her final mission is to find information about whether she can walk around with a stroller in the museum. This information is quite to find on the museum’s website, and she finds that it is possible to use a stroller in the museum.

Her final mission is to find information about whether she can walk around with a stroller in the museum. This information is quite to find on the museum’s website, and she finds that it is possible to use a stroller in the museum.


Scenario 3 (by Carolina Westlin): Jose is on one of his monthly visits, and he and Ulla are discussing what to do during the weekend. Ulla suggests that they visit the medieval museum again, since they had such a great time last time. Jose likes the idea but he doesn’t want to go if there is nothing new in the exhibition. Ulla starts up the app that they downloaded last time to find information about the exhibits.

The app seems much more complicated now that it’s not connected to the audio-guide system. There is a lot of information and a lot of reading to do, which Ulla finds difficult on the smartphone screen. She also has to click and swipe a lot, yet she can’t seem to find the information she want. After several trial and error, and some help from Jose she finally finds the info, and is happy to see that there in fact are some new temporary exhibitions.

Just when she closes the app, she remembers that they need info on how to get there because she doesn’t remember exactly what bus to take. Too tired to go through all that hassle again to find more info. She asks Jose to go to the website of the museum. Where it’s clearly stated on the first page.

Since they thought that the audio-guide part of the app was very helpful the last time, they rely on that it will be just as good for these new exhibitions, so they don’t have to stress to be in time to any guided tour.

When they arrive at the museum, the receptionist asks them if they know how the audio-guide works. Jose says yes but Ulla is insecure, after the encounter with the app earlier that morning, so she wants a short repetition. She also asks if it works the same way for the stationary and the preliminary exhibitions. The receptionist states it does but that the reception might be bad, so if they want they can use offline mode. Unfortunately this will give them less info, but it is all available in the app and can be replayed later. The guide on how to do that is in the app. Ulla want as much information as possible, and she also want some additional info on the stationary exhibit that she missed the last time, so she says she’ll be fine and they continue on into the museum.

When they get into the museum, Ulla is listening to some of the showcases in the stationary exhibition without problem, but as soon as she moves on to the stationary exhibition, she starts to experience problems. The playback stops working, halfway through the info. She starts to look for the offline mode, but again has troubles finding the right page. After a while she gets tired, and looks around for Jose to help her. He’s nowhere close by so she returns to the receptionist to get it fixed and then happily continues the exhibition.

When Ulla meets Jose at the end of the exhibition, she asks him if he didn’t have any problems. He says he did, but that he managed to figure out how to turn on offline mode through the guide that the app provided. But he makes a comment as well that maybe it should be placed so that it’s is easier to find.

Scenario 4 (by Lovisa von Heijne)
Ulla-Britt and José are visiting the museum together with Ulla-Britt’s grandchildren. Both grown ups have previously downloaded the app so they can listen to the audio guide, but the children who are three and seven years old, do not have phones and are a little bit too young to use the app even if they would have had phones. The children are instead climb the stairs and exploring the environments in the museum the situation is starting to be trying. As José doesn’t speak Swedish very well it’s hard for him to help, especially since he also wants to listen to the audio guide.

What he can do is either stop listening and go adventuring with the children, try bring the children in and make them interested in what he’s trying to listen to, or ignore the children and just listen by himself. He puts down the phone and goes after the children, to find them on the top floor of a recreated medieval building where families can rest. He sits down, with the phone in hand and the three year old starts showing interested in it. He turns on the screen and the girl starts poking at the screen.

Luckily, the app plays the audio guide even though the phone is used for other activities. So José and Elsa sit down and José continues to listen while Elsa can play a game and the seven year old goes to find Ulla-Britt. (José doesn’t really understand this but figures seven is old enough to move about by yourself.) In the end, the three year old I pretty tired and falls asleep. José takes control of the phone and sits down with the sleeping girl, continuing to listen to the app where he is sitting down as he had used the offline function and downloaded the audio guide playlist from home.

Primary and Secondary Personas

Primary Persona

Name: Ulla-Britt Andersen
Age: 68

Ulla-Britt Andersen is a kind, soft-spoken person with authority, who used to work as a teacher. She is currently 68 years old and have been retired for 3 years now and lives in a medium-fancy house about 20 minutes from central Stockholm. Her husband, Arne, died of cancer several years ago.

Ulla-Britt grew up in one of the more fancy suburbs to Stockholm. She was the youngest kid in the family and also the only girl. Her mom did not work, she was a stay at home mom. However, her dad worked as a teacher too, and it was from him that Ulla-Britt got the inspiration to become a teacher.

Ulla-britt and Arne had three kid together, two boys and a girl, and she now also have two grandchildren. She completely adores them. Elsa who is 7 years old and Daniel who is only 3.

After Arne died, Ulla-Britt felt that the big house became a bit empty. During this time her neighbours cat got kittens, and on a whim she decided that is was a good time to make room for a new member in the family. She named her new kitten, with fluffy grey fur Findus. Now, Findus is no longer a kitten anymore, but already 8 years old.

Now that Ulla-Britt is retired, she no longer have the noicy kids around her all day, and this makes her feel pretty restless. She tries to fill her days with different things to do to keep busy, for e.g. cleaning the house. She feels comfortable being occupied, and when she has to little to do, she often sits down and read a book or newspaper, solve sodukus and cross words. She thinks Scrabble is the best game ever invented.

Being this restless makes har always search for new things to learn. This is one of the reasons she likes museum so much. Even though it might be a subject she's familiar with she has the mindset that there are always new things to learn. This way she thinks of herself as pretty well educated.

Even though she likes to learn new thingsm she has never really put any effort into learning the new technology. She uses the computer if she has to. For ex to pay bills or send emails. And it’s basically only thanks to her previous job that she knows how to use google, word and have a limited knowledge of Power Point.

She does also have a smartphone, whith the main uses being calls and texts. Now in previous years she has learnt how to use the camera, in order to document all the adorable things her grandchildren do. The grandchildren are also the main reason that she has a facebook account, even though she's not sure how to use it.

Ulla-Britt speaks swedish, english and also spanish. She speaks enough spanish to move around in Spain without issues.

Secondary Persona

Name: José Lopez
Age: 64

José is a carefree, life-loving character currently working at a smaller company in Spain that he was one of the founders of, as a civil engineer. He is currently in charge of different projects of international character but sometimes he also takes on projects within the buisness development area.

José has grown up in a small rural town in the south of spain. Both of his parents were hard working, and rarely at home. As the oldest of 3 siblings he was often left in charge of the house when his parents were away. This taught him to work hard toward a goal in your life, but his parents also taught him that education is of utter importance.

Taking this to heart he worked heard to get a good education. Being a very social and generally happy person, he had a certain way with people and this naturally lead him toward the civil engineer career, mainly focusing on international relations.

José married quite young and due to his line of work, he and his wife travelled and moved around a lot. Later when they had kids they continued to travel. This resulted in his kids now living all around the world. José and his wife went seperate ways several years ago (on good terms). A few years later he went on a busness trip to Sweden and it was during this trip that he met Ulla-Britt.

The two has been a couple since then, and José regularly travels to visit her. He's starting to learn some Swedish, and Ulla-Britt knows some Spanish, but the nature of his work has made sure he's god with the English language so they mostly communicate that way.

Thankfull due to his high position in the company, he is now able to work only half-time in preparation for his retirement.

Having grown up doing a lot of physical work, Jose still doesn’t feel completely comfortable with sitting behind a desk all day. That being said, he loves all the new technology. Not only does he find it intriguing that the development has rushed forward in such short amount of time, he also loves that it makes his work a lot easier.

Keeping in touch (or getting in touch) with his international clients has become less of a problem over the years.

To let of some steam after a long day at work, Jose does wood-carving as a hobby. He also likes to take long walks but some days he just likes to relax in front of the TV.

José has the latest smartphone, and a laptop that he carries with him everywhere in case he needs to work or call one of his children. He's very at home with technology and likes to personalize both his computer and his phone. He is currently trying to teach Ulla-Britt how to use skype, so that they can talk more often :)

José speaks spanish and english and knows a few basic swedish words and scentences but not enough to move around in town.

Primary prototype's features

We decided that Audio Guide would be our prototype's main functionality. This decision was mainly based on the fact that The Medieval Museum's Audio Guide was very expensive and not working according to interviews with the staff. Furthermore, an Audio Guide would help us solve many of the problems we identified in the problem space regarding our target group and contemporary technology.

We also decided that the audio guide should be available on smartphones and tablets in an application since they are cheap to maintain and easy to download. Moreover, through our interviews, we found out that many elders do have smartphones, however, they did not use it for any advanced tasks often.
It is also easy for the museum to buy a few cheap tablets to lend out to people if they do not have a smartphone.

For the next session, Parallel Design, we needed to decide upon the most basic features, a.k.a the visibility of our prototype.

The features our low fidelity prototypes should have are:

• A scanning screen: We decided that the Audio Guide function should be initiated by scanning a QR-code. Thus, we need to have a camera/scanning screen.

• Play/Pause screen: When the code has been scanned, the users need to be able to pause or play the tape again. We wanted some kind of play/pause screen that managed this. 

State-of-the-Art Analysis - Group Summary

We visited the Medieval Museum of Stockholm for our interviews and state-of-the-art analysis. The aspects we have analysed are Light and Sound, Video monitors, Audio guides and Nationalmuseet@ - an audio guide app belonging to the exhibitions at Nationalmuseet.

Good tech implementations

• When having a well lit space at a museum it is easier for elderly people to read the exhibition texts. This means they can access the information which provides a better visit at the museum.
• With customized lights and sound the visitors also have a more realistic museum visit.
• Audio Guides are effective since they can guide a lot of people at different places in the museum at the same time, which a human guide obviously cannot.
• The Nationalmuseum@ audio guide app benefits the users in the regard that they can display the guide in different ways - as text, audio and sign language
• An audio guide app is beneficial its capacity to include extra information abut the exhibition, and the possibility to include interactive functionalities regarding the exhibition
• Video monitors provides a possibility to convey easy to access in-depth information

Technical implementations with room for improvement

• It is not possible to ask Audio Guide devices questions the way you can to a human guide. And it is generally more difficult to interact with an apparatus than a human being.
• An audio guide app (such as Nationalmuseum@) is not very accessible to people without phones, such as the elderly or children.
• An app targeting elderly people needs to have a larger font and utilise icons and colours in a much clearer way than Nationalmuseum@.
• Video monitors have to be height and sound adjusted to not be physically straining
• Relevance of video monitor content in relation to the exhibition was unclear at times - they did not successfully interest people in the material.