torsdag 15 oktober 2015

Selection of Hi-FI prototyping tool

Our lo-fi design has very limited user interaction -- just a touch screen button to request a changed route to visit the Skeppsholmen wharf.

Hence we realized immediately after a short discussion that the hi-fi prototyping tools suggested in the excersice instruction was unlikely to be relevant. Further study of Flinto and similar tools revealed that they were good for simulating click based interfaces.

Hence we decided to ignore the button interaction and focus on animating a boat over a map in Powerpoint. This gave a decent prototype with a rather small effort. We wanted more though. A button that changed routes for the boat and a sign telling when the time until the boat reached next wharf.

Further discussion over realistic options with reasonable options resulted in two very different tool candidates; Powerpoint and Unity3d.

Powerpoint pros:
  • Very easy to make simple animations.
  • Easy to learn.
Powerpoint cons:
  • Requires script programming to do more. We can stretch the limit without stretching by adding animated GIF images, but then we are out of option.
Unity 3D pros:
  • It is a full-blown game engine. Easy to make advanced animations, including physics with colliding and bouncing objects.

 Unity 3D cons:
  • Hard to learn. The only thing making Unity 3D a realistic option was the fact that all team members had previous knowedge. We were familiar with the tool from a mandatory graphics course previous semester. Hence the average design team should think twice before using this option.
  • Very tempting to add advanced features, including chunks of C# or Javascript code since the tool is full of features and easily adds code snippets in an object oriented graphical user interface.

Our decision was to use both tools in parallell and compare them. The prototype part of the team work was thus run in two tracks. Vincent focused on the safe, but limited Power Point track while Mårten focused on  the riskier Unity 3d that might not deliver any result at all in reasonable time.

  • Power Point delivered  an OK but limited prototype with a good animation in Hi-Fi class.
  • Unity delivered a good and very flexible prototype in Hi-Fi class. It was signignificantly more work though. The list of small bugs and desired features did also grow faster than it was cleaned though.

lördag 10 oktober 2015

Group post: Evaluation of a peer team's prototype

Summary of feedback from formative evaluation by a peer team acting as expert evaluators.

We performed evaluation by two different methods:
  1. Expert evaluation, where we followed the session's course material containing a checklist to consider: Intended User group, "the feeling", interaction and overarching structure, primary/secondary functions, design/composition, help/support and presentation sketches.
  2. Heuristic Evaluation, using Nielsens Rules of Thumb as heuristics.

Then we presented our findings as feedback to the peer team by sitting down together and explaining as much (or as little) from each point as was required for them to understand our finding or suggestion.

fredag 9 oktober 2015

Group post: Feedback From Expert Workshop Evaluating the Design

Summary of feedback from formative evaluation by a peer team acting as expert evaluators.

The peer team used two different methods.
An expert evaluation considering the areas:
User group, "the feeling", interaction and overarching structure, primary/secondary functions, design/composition, help/support and presentation sketches.

Heuristic Evaluation, using Nielsens Rules of Thumb as heuristics.

The report is a list of key points they noted for relevant items while running through each process.
  • Obvious to see it  value and usefullness for the primary (tourist) persona.
  • Weaker case for the secondary (daily traveller) persona. No proof that it lacks value for this persona, but we should present more evidence of value if we want it to be convincing.
  • Plain solution. Easy to understand.
  • Fulfills a need.
  • The user will stay as long as they need the information or stay interested. There is no obvious goal, rather an optional information screen.
  • (Hard to quantify the benifits in an objective way.)
  • Very clear what the interface offers.
  • Consider adding info about the boat's properties; like accessability, restrooms, size etc.
  • Plain and clear.
  • Just a secondary feature listing the real-time timetable, since there is a real-time table at the wharfs already.
  • Design. Lots of options to consider and experiment with: Zoom level, fixed or changing zoom, 2D/3D, different view directions, picture-in-picture with multiple zooms or views.
  • Is the location really the best one? Looks good in the presentation, but will it compete with seats or reduce number of people who can stand in the area when crowded? Visibility when several people are on the boat?
  • Nice design. Blends well with the environment.
  • No need for help functions or instructions.
  • The lo-fi prototype looks great. Provides good info how it is intended to look.
Protocol from the actual feedback session/presentation by the peer team's representative:

Note for seminar 2, Marcus

Chapter 13 tells us about evaluation and what it means. Why, what, where and when to evaluate is the basic to ensure that the customers gets what they need. These terms are quite self-explaining but necessary. Evaluation is how to improve and understand an existing design for a user and how to enchant the experience. A product can be compared for improvement or made to fill the demand. Usually the requirement are low at start and designers have to rethink and customize for the user in order to improve.

When the prototype is done, the next step is to test the design in different environment.  This can be done in tree ways. “Controlled settings involving users”, “Natural settings involving users” and “Any setting not involving users”. “Controlled” are often done in laboratory or other controlled areas, “Natural” in public areas, and the “Any settings” are focused on predicting the user’s behavior.

In chapter 15 we are introduced to different evaluation methods. One is called heuristic evaluation and are done with designers and experts role-playing as users to predict and interact in different ways and understand the flaws in the design. Another method is walkthroughs, which simply evaluate in a specific order see if the design meet any user problems. 

Question: Should your evaluation be done with a fixed number of people or include as many as possible? 

tisdag 6 oktober 2015

Notes for seminar 2, Mårten Norman

Evaluation Framework


Usable is basic. Pleasing and engaging are expected too by users and should be seen as the new baseline for serious product design. Evaluation gives real information for design and marketing decisions rather than just opinions.

What and When

 Evalutation can be made in all development phases. Low-fi or low-tech prototypes can be evaluated early to ensure that further design and development resources are spent on things that matter for the user. It can also be done on a full working system to verify desired properties and also to ensure compliance with regulations and certifications.

Formative evaluation means there is still a chance to adapt the product to findings, while summative evaluation is more like a grade after the fact -- this is what we got.

Where and setup

Location and settings depend on several factors. Some characteristics may require a laboratory to capture or are too dangerous to capture in a real setting. On the other hand, real life observation is less distracting to the people studied than lab observations.

Evaluation without users can be used for predicting how users will act and may get insigths when it is hard to involve real users. The product may be secret or there is no person with relevant experience of the intended product.

Usability testing

Usability testing is a more formal evaluation of the ability to use the system to perform a particular task.

Evaluation without users

Heuristic evaluation

Nielsen et al developed a formal method for heuristic evaluation where the actual user activity is replaced by a set of heuristics, rules adapted to the context, that should be fulfilled to yield good usability and experience. The method is well researched and tested with different numbers of evaluators --> a handful of evaluators are good but a dozen is better.


System developers can formally walk through typical scenarios in a group session to simulate user's needs and behaviours.

Question: How is usability testing relating to the other evaluation methods?

Note for seminar 2, Vincent Wong

What is evaluation? Evaluation is an integral part of the design process, where for example a system is evaluated throughly. Evaluation focuses on both the usability of the system and the users experience when interacting. The reason behind evaluations is plain and simple to enhance the system and have a further understanding of how users or potential users perceive the design. There is four pillars which keeps the evaluation roof steady, the why,what,where and when. "Why evaluate?",
"What to evaluate?", "Where to evaluate" and "When to evaluate?". There is no need to go in depth of these four pillars as the title is pretty much self explanatory. However there is also three broad categories of evaluation, which depends on the setting, user involvement and level of control.
1. Controlled settings involving users: The users activities are controlled and measured/observed to test hypotheses.The main method are usability testing and experiments.
2. Natural settings involving users: Unlike controlled setting the user is not restricted or controlled here, the user is free to do as he/she pleases. The main method is usually field studies.
3. Any settings not involving users: Since there is no users in this method the researchers predict,critique and model aspects of the interface to identify the obvious usability problems. There is a lot of methods, for example inspections, heuristics and walkthroughs to name a few.

What is Heuristics and Walkthroughs? It is inspection methods carried out by experts role-playing the users, meaning that no users has to be present.
Heuristics: Experts role-playing as users evaluates the user-interface elements guided by a set of usability principles known as heuristics.
Walkthroughs: Just as the name suggest, walkthroughs are basically a method where developers walk through the design noting the problematic usability features

Question: What is the most effective evaluation method, with or without users?

Notes for seminar 2, Staffan Sandberg

Chapter 13 is all about how and why we evaluate our design. If we start with the ”Why, what, where and when”. We evaluate to make sure that the design meets the exact needs of the customer, that’s the number one priority. If this isn’t fulfilled our requirements might not been good enough or we just have to rethink the design. What we evaluate can be many different things, like how easy this product is to use compared to the other options available on the market. The first step of evaluation can take place in a laboratory to make sure that the requirements are met, then we can move on to a natural environment etc. When do we evaluate? If the design is a brand-new concept it has to be evaluated more often to make sure that it fulfills the user's requirements. Since our design isn’t a brand new concept I think we can get away with evaluating once, since we have a good idea of what the user requires by looking att similar designs on the market.

Case study evaluations take place in different settings with different amount of control. We could apply this by letting a person from our usergroup use our design to get from A to B and then ask how easy it was, if it was fun etc.

So this chapter basically goes through why it’s important to evaluate, and i completely agree with that statement, if you don’t evaluate you have no idea if the product reach the requirements.

Chapter 14 mentions different evaluation studies that take place in different settings, like controlled and natural. Usability testing is a type of evaluation which usually takes place in a controlled environment where you can measure the time it takes for a user to complete a task and how many errors was made etc. This is interesting to do so you can see how easy and effective your design is. Different kind of experiments can also be done to validate hypotheses etc.

Chapter 15 is about evaluation methods based on trying to understand the users by heuristics or via remotely collected data.
Heuristic evaluation is when a expert uses the interface and i guided by different usability principled know as heuristics. The expert can for example go through the process of adding a friend on a social network many different times to identify the usability problems.
I think that an expert roleplaying as a user is a great final step in evaluating to make sure that nothing is missing or misleading in the design.

Question: How do you decide if the design is good enough?

Notes for seminar 2, Martin

In chapter 13 we are introduced to the concept of evaluating your prototype. They go through why, what, where and when you should do your evaluation. The "why" is pretty much self-explanatory. We need to evaluate our product prototype since we need to know if it will make it out on the market. What to evaluate depends on the main goal with the final product, but a product could have more than one main goal. For example a cell phone needs both to have a functioning software that is easy to use but also a good design so that people want to be seen with it. Where to evaluate depends on what is being evaluated. There is something called "in the wild studies" which means that the product is being evaluated in its natural environment.  When to evaluate mostly depends on the product. If it is a new product on the market then the evaluation should take place after the requirements has been established and the first sketches has been done so you can see early in the process if the product is worth continuing working on.

There are three main types on evaluation. These are "Controlled settings involving users", "Natural settings involving users" and "Any settings not involving users". The names speaks for themselves what the different types are. For example a controlled setting could be in a lab and a natural setting could be in the jungle. The third types is usually when the creators try to predict what usability problems that needs improvement.

This principle can be applied to our project when we our done with our model and have our first prototype working so that we have something of value to evaluate.

The 15th chapter is an extension of chapter 13 and is also about evaluation. More specifically about evaluation methods not involving direct contact with users but more in a way of using heuristics to predict the users' performance. This is especially good when you don't have the ability to test your product in reality.

Heuristic evaluation is evaluation made by experts where they use different principles to check if the product fulfills these.

Question: Can a whole evaluation be done by not involving users?

söndag 4 oktober 2015

Design idea from exercise 3

Our idea from the exercise was to create a big screen at the wharf and on the boat. The screen at the wharf would show how the boat is moving right now and how many people the boat is carying at the moment. The amout of people on the boat would be displayed as different colors. Say that the boat is almost full, then it would turn red on the map. If the boat is almost empty then it would be green on the map. So, the scale would go from green to red (yellow would mean half full). This map is also tracing the amount of people at each station, which is noted the same as the amount of people on the boat.

The map shows the route which the boat is currently moving in. If the boat is not stopping at "Skeppsholmen" then this route is marked gray on the map so that travellers know that the boat is not going to stop there.

The screen on the boat is similar to the one at the docks. That screen also shows the position of the boat but it also show how much time there is left until the next stop. It doesn't have any function for showing how many people that is on the boat right now. This would be useless since if you are already on the boat you can see how crowded it is by looking around.

Here is a sketch of our prototype:

This idea was brought up when we did the collaborative iteration. We thought that collaborative iteration worked the best for us when thinking about new creative ideas.

Exercise 3 Brainstorming in group

During todays exercise we tried three different brainstorming methods. Collaborative iteration, word assosiation and paralell design.

We started with collaborative iteration, the first design idea was an app which would keep track of your position durring the ferry ride. After a few steps it had expanded with many features like seeing the routes on a map and being able to press the route you want to take, the time it will take for you to get to the boat, being able to purchase a ticket in it, being able to keep track of how many people there are on the ferry and at the different stops in real time. Down below you can se a basic sketch and paper prototype of the design.
Collaborative iteration

The next ide we had was to have a display on each stop and ferry, on which you can se the route, current position and next stop etc. It's much like the idea above but withouth the requirement of an app. It's ment for our tourist persona who want to get a quick overview on where the boat will go, withouth first having to find and install an app.
Here you can se a rough sketch on where the screens will be placed and what they will show.
Collaborative iteration

The next brainstorming exercise was word association, where each person combined three different words from a list, one object, one design action and one attribute. We didn't realy iterate on any of these since we were quite happy with the results in the previous brainstorming exersice and the words we had to choose from didn't really fit our ideas.
Word association

The last exercise was parallel design, we devided into two groups and picked one Pain pont, one Persona and one Scenario. We had two different ideas and decidet to develop on the design for our persona Rita who need to find a place to eat and only knows german. The idea with the app is to see all the different locations to get food on a map and being able to filter out different options depending on your budget etc. Because she only know german we thought about including a feature to take pictures of signs and translate them into the prefered language. Which would be handy when trying to order food from a menu at a restaurant etc.
Parallel design

torsdag 1 oktober 2015

Groups Secondary Persona



Oscar Nilson is a 32 year old office clerk who works at Abba The Museum and lives in the suburb, south of Stockholm. He lives together with his girlfriend and dog.

After a traffic accident three years ago with his Motorcycle he became paralysed from the waist down and is now dependent on a wheelchair to move around freely. Getting in and out of the wheelchair is a process Oscar usually avoids.

After the surgery during the healing process Oscar spent most of his time watching anime and has now become fond of it.

At work he is a careful perfectionist who loves to organize papers. He hates to make mistakes and to be late. Stubborn as he is he still loves to cruise around with his trike(MC) which he bought after the accident.


Scenario 1:
Oscar has to work late, but there is a new anime release this very day. He won't be able to buy it after work, so he decided to pick it up during his lunch break. 

Goal: Buy the Anime in Gamla Stan, eat lunch and get back to work in one hour.

Scenario 2: Just arrived at Slussen on his way to work at Abba The Museum. He is a frequent commuter and knows the route, he prefers the newer boats where he can move around without leaving the wheelchair and ask someone for help to get over obstacles.

Goal: Get to work in time without leaving the chair.
Pain points
  1. Obstacle free path: 1
  2. Language: 5
  3. Finding his way: 5

Groups Main Persona



Rita is a 73 year old German woman. Former chef and lives in the northern part of Germany, in Rostock. She was raised in a poor family in former Eastern Germany. Her dad served in the German navy and was a boat entusiast, which he brought on to his family. In year 1962 she began studing vehicle engineering with orientation in ship mechanics at the University of Rostock. While studing at the university she worked extra as a chef at a fast food restuarant. After two years she dropped out of school to become a chef full time. She opened her first restaurant in 1977, which she still owns today.


Rita is a proud grandmother of a three year old boy and a nine year girl, kids to her divorced son. She usually spends her days cooking. She is a very positive person and tries to live each day as her last. Since she is retired. She has lots of time to spend at traveling and exploring new things.

Scenario 1: Just arrived at Slussen on her way to Vasamuseet through the boat line. This is her first day in Sweden. She just left the boat and has a large roller bag with all her luggage. Her plans are to leave her luggage at a hotel on Skeppsholmen and then continue to Vasamuseet.

She knows about the Vasa ship but has no tickets or detailed information how to get there. She just trusts here GPS and what she can learn by surfing the web and asking friends on social media.

Goal: Visit Vasamuseet

Scenario 2: After the visit at Vasamuseet, back to slussen/gamla stan to find a restaurant for dinner.

Goal: Eat dinner.

Pain points

  1. Obstacle free path: 4
  2. Finding her way: 1
  3. Language: 1