Project Summary

This is it, we have arrived at the end of the course. It is now time to look back on what we have accomplished the last couple of weeks. It all started with five individuals, all getting together with a goal to make a good product, but we were not quite certain where we would start, nor where we would finish.

At our first group meeting, it quite quickly became obvious that the entire group wanted to make an app of some sort. However, we were not quite sure which group of visitors we wanted to target. So we sat down and brainstormed - we scribbled down every single group of visitors we could think of, and what sort of an application would be suitable for that group. We came to a conclusion that tourists were a target group that had a lot of potential, and a group we figured we could make something useful for. Hence, we decided to make an application targeting tourists.

Next up was deciding what functions the app should have. We figured that the absolutely best way to get an understanding of this would be to conduct actual interviews with tourists at a museum. As a group we wrote down a bunch of open-ended questions which were designed to get as much information as possible out of the interviewees without putting words in their mouths.

During the previous reading seminar we had learnt a lot about how to make observations of target groups. We decided (apart from conducting interviews) that using the method “Fly on the wall” we would manage to get a lot of information from tourists, without having to interfere with their visits.

From the interviews and observations we got an understanding of what the tourists felt was lacking in the Swedish museum scene. For instance, the tourists felt that it was difficult gathering information on how to get to the museum. They also felt that the exhibits lacked information - that the small amount of information on each exhibit just wasn’t enough and it was not available in other languages than Swedish and English. This forced them to take tour guides if they wanted to know more about the exhibitions.

It was also at this point we decided that we were going to design our product having a user-centered design in mind. In hindsight, we realise that we should have made several more user tests in order to completely establish what the users’ needs were, and how we could accomplish that with a result as good as possible. User-centered design, meaning that the focus of the entire design process should be the user and the user’s needs, is something we half-heartedly followed, but would have liked to accomplish even more. Many decisions that were made during the design process were made by ourselves, which indicates that we had some sort of mix between both user-centered design and genius design.

At this point we felt that we had gathered somewhat insufficient information, partly due to the fact that five interviews does not really make us see the whole picture. We decided to do some further research online. It became very obvious, however, that the information we had gathered held true all over the world, which convinced us that we were on the right track.

The next step was to create personas and scenarios. This would work as a tool in order to fully understand our future users and what situations could arise that required our app. We created two different personas, as well as two different scenarios for each persona. This entire part of the design process was very rewarding because it helped us concretize the project. It was also at this time we created pain points, which is a method of determining where to put the focus by prioritizing different problems. What needs were there, and how could we fulfil them for our users? As a group this is where we finally got a clear picture of what the final product should be able to do - it made us share the same vision of the product.

We now knew what product we were creating and the functions it needed, but we had to come up with a design. Once again we put our heads together and brainstormed. During that week’s exercise we created two different designs - one which was extreme and crazy, enabling us to think outside the box, and one which was a bit more conventional. After the exercise we created yet another design. We took the best from each individual design and put together a “Final design: draft 1”. This was something close to what we wanted, but we understood that it would have to go through several iterations in order to become as good as possible. We also created a prototype which was somewhat interactive. For the time being we were quite happy with the product, so we took it to the next exercise and got some feedback from another group.

The feedback we received was very useful to us, because we now knew what could be improved. For example we got the feedback that it could be made a bit more intuitive by changing the order of our menu, that we could change the layout of some things and so on. All this was something that we took with us to the next group meeting where we improved our product having the feedback in mind.

At this point we also had a reading seminar where we read about different “laws” that could be applied to our product. After the reading seminar we also implemented user tests to see what actual users felt about our product. To read more about this step of our process, see our last blog post.

And here we are - the final presentation is tomorrow, and we have yet one iteration of our prototype to show the exercise group. We are, as a group, very content with what we are going to present. We feel that it has been very useful to learn about all the steps that are involved in a design process, and understand that this is something that can be applied outside the university. But we are aware that there is a whole lot more to learn, and we are eager to get out there to learn and design more things.

Think-aloud summary

To test our application with users who haven't used the application before, we created a couple of test scenarios so that they could try it out and we could observe and see how easily navigated the app was. We told the users to do a think-aloud, meaning that they say everything they think when they take action and make a decision while navigating within the app.

The first screen the user is met by in the app is a screen with a bunch of flags, which represent the language in which the app and all the information will be in. Directly after choosing a language (by clicking on a flag) [intuitive to click flags, no text], the user is taken to the Exhibitions screen. This was a little confusing to a couple of users, so we're thinking of adding a sort of Welcome screen after the language selection, so that the users are introduced to the application properly.

The first task was "Using the application, how would you do to find your way to the museum?" So after choosing their language, all of our users pressed the three lines in the upper left corner, signaling that there is a menu to be reached. Here, we had a couple of different results where some users pressed "Museum Map", or "Info" instead of "Get Here", probably because the word "map" was in the title - something they were looking for. We might have to rethink our titles to better match the initial thought of the user.

The second task was to find information about the dinosaur with the longest neck. Our users' reactions here were pretty much the same. They clicked the menu button, and then "Exhibitions", chose the dinosaur exhibition and found the one with the tallest neck by looking at the pictures of the different exhibits. We also had a user that said that he would either do it this way, or by going to the museum map (which he accidently went to during the first scenario) and selecting the dinosaur exhibition. One user went to the menu and pressed "Info" at first, only to see that the link didn't go anywhere at the moment, but then went for "Exhibitions".

The third task was to change the language of the application. This is where most people had difficulties, as they would go directly for "Settings" in the menu, instead of the direct link "Language". This is probably because most people are used to finding those kind of options within the settings, and not directly via the menu. We talked this over and we're thinking of maybe keeping the intuition from the very first language selection screen, and making a flag in the menu instead of the title "Language". Not only is it visually compelling and intuitive - it also helps users that accidently chose the wrong language at first to find their way back to the language selection menu by only having to interpret icons on their way.

The fourth and final task that we let the users do was to try and find their way (imagining that they were inside the museum) to a specific exhibition. At this point, most of our users found their way to the menu and then "Museum Map" at once, seeing as they had been in the menu a couple of times already so they had learned what they could do from there. Some tried to find their way by going to “Exhibitions”, but later realized that it didn’t work and that “Museum Map” was the way to go.

All in all, the think-aloud sessions was a great way to test our application out and see how other people react when they use it. We have come to the conclusion that we have a couple of things that we can improve and implement in our design, hopefully making it easier to use.

Some of the users expressed a need for a return button to make the navigation easier. This is something our critics also mentioned at the last exercise and of course we have taken it into consideration. We haven’t made any final decisions about it yet, though, because we are still discussing whether we should have an actual button for it or if it should be a motion, for example swiping the screen from left to right.

What can we take from these user tests, looking at the different “laws” that we learned last week? Well, first of all, every single user directly understood that the 3 lines was the menu, which is because it is (in today’s society) intuitive that a menu will look like that, and that makes it a so called standard.

We also incorporated Hick’s law, since they had a limited amount of options on whatever screen they currently are on, it felt like the users found it easy to point to the menu (since it is one of very few options), and then navigate from there - once again because there are a limited amount of options. The menu currently has six options, which Hick’s law says is good (that it is easier to navigate two menues of five, rather than one menu of ten). It also follows “The Magical Number Seven” that it is easier for the human mind to remember options of seven (plus minus two) - and guess what? Six is right in that range!

One thing we can look further into, based on the user tests, is Tesler’s Law of the Conservation of Complexity, which basically says that everything should be dumbed down as much as humanly possible to avoid confusion. There was some confusion when it came to things such as getting to the museum and getting to a specific exhibit. So we need to look into how we can make those options even simpler.

Reading Seminar 2 - Adam Nyberg

This week’s reading had a lot to do with how to take your design from a concept to prototype with much focus on fine tuning during the process. Much of what is discussed in the chapters is something our group has worked on, or at least touched, but there is also a wide variety of techniques I feel we should use as we continue our work. When working on ideation, or how to concepts are to be executed, we should definitely look into affordances, how intuitive the design feels before using it, and what feedback should be given and when.

There are some things I wish we would have done better before we created a final design but I hope at least that we might be able to still make use of them. One of these is the use of metaphors which I feel could really give our design a unique touch. Another technique I would like to get started on is a moodboard. By using a moodboard we can collectively define how we want our design to “feel”, another aspect that can set it aside from other groups’ designs.

In the near future I feel we should start applying techniques from the chapter on prototyping. We have started on a prototype already, but we have just been creating it “on the fly” and using our own experiences. At our last presentation we presented a sort of low-fidelity prototype so I don’t think a high-fidelity prototype is far off.

Question for the seminar: Is Hick’s law something we should take into account for our design?

Reading Seminar 2 - Marcus Frisell

The chapters we read this week was mostly about concepts and how to create them. We have already gone through multiple iterations of design concepts but maybe not reached all the way. There are several different methods we could try to refine and better our ideas and concepts and to do so we can’t skip steps on the way. We have to go through the whole process. From strategy to research to observation, analysis and so forth.

A way of creating concepts that I think most people, if not everyone already have tried is brainstorming. When you brainstorm you come up with multiple ideas, most of them are not very thought out but that’s not the point here. The purpose of the brainstorm is to generate as many ideas as possible as fast as you can. More ideas gives you a broader view and feature-set of the concept.

When we went through this face we didn’t really know about all the different approaches and ways to improve our concept and therefore we missed some, possibly, critical information and ways to analyse our ideas that we probably should take into consideration. We went from brainstorming to refining to prototyping. We should probably do, as Niklas said, take a step back and take a closer look at what we have accomplished to see if we can improve our concept some more.

Some things we should have in mind when we prototype in a detailed manner is both Fitts’s- and Hick’s law.

Fitt’s law determines how fast the user can accomplish tasks when moving from a start location to a target location. This law is determined by two things, distance between the points and the size of the target. A bigger target is easier to hit and therefore makes it easier for the user to navigate around.

Hick’s law explains the time correlation between decisions and number of choices they have. Interestingly users makes decisions faster in bigger menus than multiple smaller ones.

These are things we didn’t consider before that we probably should implement into our concept.

An interesting question i think is: In which ways can we simplify design to please users?

Reading seminar 2 - Linn Lahtinen

The content of this week's literature was mostly information about different methods and approaches you can use during a design process, covering almost everything from ideation to prototype and development. There was many new concepts and terms I have never heard about before and reading about it all made me realize that there are a lot more things to think about when you go through a design process than I could have imagined.

The first chapter covers brainstorming, how to do it and how to keep it organized. It tells us to be open-minded, not to think rationally because every idea counts in this stage, and that you should document and save all ideas. I think the most important point, though, is that it’s hard to come up with ideas when you’re forced to, and therefore ideas often come when you’re doing something else. Because of this it is good to always carry something you can write down your idea on with you when you’re in a brainstorming process of a project.

The second chapter, which is about refinement, contains a lot of the new terms I mentioned earlier. I can’t help to feel that the meaning of many of these terms are really simple and obvious, it’s just the fact that you haven’t had a word for it before. There is of course also concepts I’ve never thought about before and I can barely even understand now. But overall, I think all of it is very helpful and educational, and that it makes the design process easier and more palpable.

The last chapter of this week's literature is about interface design and prototyping. As mentioned in the chapter, there is a lot to think about when making a prototype. For example, there is several different types of prototypes, such as low-fidelity and high-fidelity prototypes. It’s not only important to choose what kind of prototype you want to make, but also to make the testers understand so that they can focus on the right things. At the end of the chapter something called agile methodology is brought up, which means that you take a big task and break it into smaller pieces. I think this is a great way of working and that it can not only be essential for our project, but also for tasks in everyday life.

My question is: Which non-traditional inputs could we include in our design?

Reading seminar 2 - Niklas Gustavsson

Reading seminar 2 - Niklas Gustavsson

This weeks reading seminar was about creating concepts (through brainstorming for example), refining your concepts using different “laws”, documentation  and a plethora of other ways of doing this, and then lastly about prototyping.

We have already gone through the brainstorming part, where we as a team sat together and went through a whole lot of brainstorming. We were all familiar with this concept seeing we have read a course very similar to this one, so we all got it done - and got a whole lot of concepts out. The thing we did differently was that we subconsciously did the second part, the refining - without knowing about all these laws and storyboards and such, and we went straight to the prototyping part. Now that we have more information about (researched) facts about user design, we might have to take one step back and go through all the laws as a group, and refine our concept a little bit more.

One law that stuck out to me was Hick’s law, about how many options a user processes, this one is essential for us seeing we are designing an application with several options. We might have to reconsider where we want to put the options in order to not confuse the user, or give the user to much information at once. The magic number seven is something we could use. In this process we should also use a wireframe, which I felt was essential in a software type product.

And after we have gone through all of these steps, we need to go back to the prototyping (which we already started on) in order to optimize and let people test our product. User tests are really important, as it shows our product in use - and a user will be able to tell us what works, and what can be tweaked upon. And once we have that information, we could do several steps over again, to eventually do another user test - to optimize our product. Something like this:

When we did the prototyping last time, we went straight for the high-fidelity prototype, and I feel that this one is the one that suits us the most - it does not take a whole lot of time, and it represents our software better than a paper version or a physical version. And once we have done more prototypes and user tests, we might move on to an even higher-fidelity prototype with an actual web-based application.

Question for the seminar: How do you know which one of the concepts you get from brainstorming to pursue?

Reflection for seminar 2 - Erik Forsberg

Going through the chapters, there are a bunch of different techniques that we are using in our process, but also a lot that we should look into even more. The Method Design that is mentioned in chapter six seems like the logical choice when starting out and it is also what we have been doing, as we're trying to put ourselves in the shoes of the user, but to do this, we have to have a good understanding about the user (your persona). This is also why we do research and interviews, and then try to use them as a base for our design choices. Something that I believe can take our design work and prototyping to the next level is the use of our pain points. We need to know what to focus on when brainstorming for new design elements and ideas. I believe that there is a myriad of opportunities to be explored and to express our creativity and innovation when it comes to our pain points.

Another thing that I believe our group could benefit from, is to adapt to a more Agile methodology meaning that we should break down our tasks into smaller pieces of work so that we could distribute them among the group members and really focus our energy in a good way. Sometimes having two or more people focusing on the exact same problem can be too much as the ideas could clash and stop the workflow. Discussing process moments within the group and then distributing the work is what I believe is the way we can really advance in this project.

One more thing that I thought was really interesting was Fitts's Law, stating that the time is takes for a user to reach an element is determined by the distance to the element and the size of the element. This is something that I believe we can use in our design, as a simple and intuitive UI is a very strong component in an application.

The question I'd like to discuss during the seminar is: How can we use ambient audio cues to enhance our application?