Final Prototype

We found the Unity prototype quite time consuming and hard to complete in the short amount of time before our final presentation. So we decided to modify and finalize our user interface in Photoshop for a more clean, sophisticated and more integrated looking design.

The following screen will be located on the ferry:

If the user touch/press the grey "button" the ferry will go via Skeppsholmen before arriving at Djurgården. We also took inconsideration of the feedbacks and evaluations and improved the indications and informations. As seen above we introduced a "Go via" hand icon to further indicate that it's a touchable action, we also changed to route indication to distinguish from current and optional route which is also informed in the information bar down at the bottom.

If Skeppsholmen is touched, the route changes and Skeppsholmen turns green.

Then there are some problems during certain hours of the day, if the boat is marked with A in the time table, there is a certain route to travel.
Boat marked with A:
Skeppsholmen - Slussen route: Travel via Djurgården before arriving at Slussen.
Djurgården - Skeppsholmen route: Travel via Slussen before arriving at Skeppsholmen.

If you are at Djurgården on your way to Skeppsholmen, this is the interface you will face. It is easy to understand, since the text on the top is pretty self-explanatory. The route also changes to green, but with 45% opacity which makes it not as visible as the current destination( Slussen), but still visible enough.

Final evaluation of prototype

To evaluate our prototype we began with presenting the prototype to an usability consultant (an expert in the field of HCI), who performed a heuristic evaluation on spot. We used the feedback we got to improve our user interface in the best way possible. The recieved feedback comments from the expert:
Negative

• No indicator which tell the current route
• Bad choice of coloring, hard to distinguish
• Unclear button interaction

Positive

• Easy to understand the purpose
• Outstanding design
• Simple solution to a problem

The next evaluation method we used was think-aloud. Here we evaluated our prototype in action by having a non-expert test it to see how the ordinary users could handle our prototype. This is what we got:
Feedback

• Nothing that indicates the button
• Bad choice for the colors on the different routes
• No text that tells if the boat goes via Skeppsholmen.
• Hard to distinguish gray and green.

RCA for Problems to See Posts Before Cirka September 24

I had some problems to find some of my older posts when following up a comment from the formative feedback.

This ended up as a Root Cause Analysis aka RCA, since I followed up the feedback was that the evaluators missed a transcript that I believed was there. And I did also not find the post, until I learned that Blogger just shows 40 posts on the first page. Then you are supposed to click the link "Äldre Inlägg" slightly hidden at the bottom of the very, very long page.

Problem:
Indications that at least some people fails to find some posts on this blog.

Root Cause:
The Blogger user interface (main page) puts a strong focus on the most recent posts. Older posts are deferred to secondary pages that are easy to miss.

Remedy:

There is a setting for numbers of posts on first page. I have just changed it to 400 (and later changed it to 400 days, rather than pages). This has not resulted in all posts listed on the page, but the link menu to the right to older posts does indeed cover all of 2015 and all posts appear to be linked from there.

Long Term Solution:

Major changes to the Blog design or evaluate new blog platform. Not relevant in this timeframe.

High Fidelity Prototype using the Unity 3D Game Engine

Video of the Hi-Fi prototype made in the Unity 3D engine.

Below is an interactive Unity3d Prototype. It requires the Unity3D web player plugin and will offer you to an install it if needed. The main difference between the movie above and the interactive prototype is that you are free to click the button for Skeppsholmen whenever you like. Then you may find the less frequent use cases that we decided to not model, following Pareto's principle to concentrate on the few details (popularized as "20% of the work") with most impact and ignoring the massive number of details that remains for perfection.


The only direct user interaction is the button that requests a trip via Skeppsholmen and updates the route and boat animation accordingly.

The following points from the think-alouds and peer/expert-feedback sessions has been implemented:

•  A separate "button" for adding a stop at Skeppsholmen's warf since the previous solution was too hard to recognize as a button.
• More distinct colour plotting the route.
• Distinct marking of the actual chosen route for the ferry.
• Direction for the ferry.
• Text changes to (via Skeppsholmen) at button press.
• Button press gives a distinct response, by update of button text, route on the map and destination text.

The work on this Hi-Fi prototype resulted in further findings by ourselves, and informal feedback collected from friends, peers and family during the process:

• Even a simple map animation gets complex when a route may be changed by user input at any stage in the animation.
• When is it too late to request a visit to Skeppsholmen?
• The alternate route is not visible. It should be visualized and explained properly.
• It is very hard to draw the line between prototyping and product design when using a tool that is powerful enough to work in a final design.

In retrospect, it maybe was a poor choice to use a production level tool like Unity for prototyping. We did indeed not find any better tool, but the ability of Unity to handle advanced improvement made every suggestion into a decision wether to improve or not. Spend time on improving presentation details or time on higher level holistic design while we still are in an early phase and can make drastic changes?

Think-aloud, Group summation

It is clear that our first prototype is confusing for the users. The major problems were that the screen was not well informed to be interactive and the information for another route was missing i form of text. The test users were i different ages and at least one problem was common among them all. The good thing is that the problems are not so many and the test users was not so experienced with traveling on the boat.

Some of the problems:

• Not so good color choise.
• Not obvious that you have to/able to press Skeppsholmen on the screen.
• When you go via Skeppsholmen the text do not change to "via Skeppsholem".
• The green and grey travel pattern is impossible to understand. Must clarify.

We knew that we needed to improve it in a way so that it is easier to understand. We evaluated the feedback to perfect the prototype for the final presentation.  

Think aloud, Marcus

I did the think aloud on a friend. He is not from Stockholm and have only been on the boat once. At first he didn’t understand the prototype by only looking at it, but after I explained a lite about it he started to understand what he was looking at. I told him to imagine himself on the ferry and that he was going to skeppsholmen from slussen.  It was not clear that the screen was interactive so the grey area was confusing. Both the route and the boat symbol was pretty understandable. He thought that the screen could be a little smaller.

The design is good but not perfect. It is both confusing and unclear that about information and interaction. The interaction button need to be well informed and the route change. The person in the information both could also help to instruct and inform the users. Maybe change the route color since it hard to see.

Think Aloud Martin

To do my think aloud evaluation I asked my mom to try to use our prototype. She said that the idea was good but it was unclear what purpose it had from just looking at it. It needed to be improved so that it would be clear to everyone how it is used. She imagine what it would be if she was a tourist and was trying to use something similar abroad. First of all she didn’t know that one could press on the screen to get the boat to change direction and pass by Skeppsholmen on the way to Djurgården. Our prototype didn’t have any text that showed the function.

One thing that we could improve with our prototype is to add an information box that the user can make the boat pass by Skeppsholmen by pressing on Skeppsholmen on the map. Since the main purpose of the prototype is the interactive part where the user communicates with the captain by clicking on the map, we want this to be clear for everyone. Another thing to improve with the prototype is to make labels for the different routes, which makes it clearer of which the current route is. As of now the prototype does not display the direction that the boat is going in. This could be improved by adding arrows along the route that point in the forward direction. 

Think Aloud for Lo-Fi prototype, Mårten

I interviewed my son, evaluating our lo-fi prototype using the Think Aloud method. He was selected due to similarity to a tourist --  young enough to just have tourist level familiarity with Slussen and Djurgården, while still old enough to travel by himself.

He was assigned the task to go from slussen to Djurgården, but make a short visit on Skeppsholmen on the way. Then look at/interact with the Lo-Fi prototype printed out on paper, imagine it on a wall and describe how he interprets it.

Notes:

• Why is it 1 min on one paper and 15 min on the other one?
• Why is there no wharf on the close side of Skeppsholmen?
• The green and grey travel pattern is impossible to understand. Must clarify.
• More optimal if he could take a short trip to the near side of skeppsholmen, do his errand and take a short trip on the other side to Djurgården.
• Will the boat turn back to slussen directly from Skeppsholmen? Very messy to tell how the boat goes between the three warf's, what order and if it's the same boat or need to wait for the right one.
• Does the boat wait at the Skeppsholmen warf or should I check the schedule for a later trip? Can I do that at Skeppsholmen?
• Do I have to wait long for the next boat at Skeppsholmen? Then I migth be better crossing the bridge and go for a bus or tram.
• No comment about the "button area" of Skeppsholmen. When asked --> Isn't that a forest?
• Is there a bus to Skansen at the Djurgården warf?

Transcript from the think-aloud session.

Think-aloud evaluation, Staffan Sandberg

I did my think-aloud evaluation on my father since he was the best fit for our main persona, he has used the ferry before, but it was a few years ago so he has almost the same mindset as a tourist visiting Stockholm.
I gave him a scenario of him standing at Slussen with the goal of taking the ferry to Skepsholmen. I showed him our prototype and told him to tell me what he was thinking while looking at it, I also told him that the screen was located in the queue while wating for the ferry to arrive. The image he was looking at was the first one in our blog post called "Prototype".

The first thing he said was that the green dot is our current position and the red one is probably the ferry. Then he said that it seems like this ferry will go to Djurgården (green line) so i'll wait for the next one which will go via Skeppsholmen. I told him that the ferry won't go via Skeppsholmen unless you tell the personnel and that it was a touch screen. He then pressed at Skeppsholmen and i switched to the second image in the "Prototype" post. He then said that he was unsure if the ferry would go via Skeppsholmen since the text still said "Djurgården" and not "Djurgården via Skeppsholmen" which is typical on SL-screens. He also pointed out that the green and gray line look quite similar.

This made it clear that we have to improve on a few things:

• "the red dot is probably the ferry".
• Not obvious that you have to/able to press Skeppsholmen on the screen.
• When you go via Skeppsholmen the text do not change to "via Skeppsholem".
• The green and gray line look quite similar.

I think that think-aloud evaluation is a great method to find where users get stuck and don't know what do do next. Since they always have to say what they think you can later figgure out why they thougt something would work a certain way and improve the design. A drawback is that it's not always easy to say what you think, users may do somethig, can't explain why and just move on.

Think aloud Vincent

For my think aloud evaluation I asked my younger sister to interact with the screen, I told her to imagine herself as a user standing at the wharf at Slussen on her way to Djurgården, but she has to go through Skeppsholmen for a quick errand first. Since our prototype is not functioning as it should as it only shows pictures and animation, not an interactive one, she didn’t grasp it at first. So I told her that this is only a prototype for demonstrational purposes and not a functioning one at all.  She then realized that the grey thing hovering Skeppsholmen were actually a button to change the route, but she told me that the different colored lines were a little misleading since subway lines uses the same method to differentiate between different lines.

I realized that our design is great but is in need of a slight modification, such as a better indicating button of Skeppsholmen, maybe even information telling passengers to click on Skeppsholmen if that’s the desired destination. The colored trajectories should be modified as well as it could confuse commuters, an easy solution is to add a dashed line for the route which is not being used.

Prototype

Here's a few pictures of our Power Point based prototype, This prototype will be placed both at the stations and ferry.

As seen on the picture above Skeppsholmen has a grey thing hovering over it and the route is also grey. The grey thing is actually a button, if pressed, the button will turn green and the route will then also change.

Placement on the boat.

The position of the screen on the ferry as of now will be placed on both sides(hallways).

The screen on each station on the otherhand should be placed right before you get onboard the ferry. Above is just an example of where it could be placed.

Seminar notes during 2:nd seminar group discussion

What to do if we had unlimited time for evaluation.

Make lo-fi prototype on paper.
Evalutation without users, Walk through with team to do some homework to remove glaring usability problems before talking to real users.

repeat
  Perform real-life evaluation. Ride the boat and show lo-fi prototype to potential users asking for feedback.
  Improve lo-fi prototype
until no obvious improvements found

Make heuristic evaluation of the refined lofi prototype and improve if necessary.

Make a first prototype using off the shelf hardware and standard software like Unity or Unreal.

Lab evaluation of extremely advanced graphics. Particle animations, advanced wave animations, bird flocks and other eye candy. Does it make any difference in user perception or is it just worthless bells and whistless?

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.

Result:

• 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.

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.

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? 

Notes for seminar 2, Mårten Norman

Evaluation Framework

Why

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.

Walkthroughs

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?

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

Groups Secondary Persona

Oscar

Background:

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.

Personality:

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.

Scenarios

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

Background:

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.

Personality:

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.

Scenarios

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

Pain Points and Opportunities for the Personas

Pain points summary

The ferry ride and experience is rather smooth but we are able to identify some intressant problems:

•     Language. Several passengers neither know Swedish nor English that are the two most likely languages to be supported in Stockholm.
•     Finding the way. Many passengers are in Stockholm for the first time. They do not know by heart where the ferry landings are. And onboard, they are unsure where the ferry is going to land and when.
•     Obstacle free path. For people with problems to walk or having luggage on wheels, it is inconvenient or even impossible to negotiate obstacles on the way to the ferry, while boarding and onboard the ferry. Even if the ferry staff offers support, it is desireable to not be dependent on people to be available and willing to help.

Ordering of Pain points for the main persona

1.     Language. She only knows German and is very unconfortable when she is unable to communicate in fluent German or read information in German.
2.     Finding her way. She has never been in Stockholm and she has not prepared by looking at maps -- she just expect it to be easy in such a small country.
3.     Obstacle free path. She has a roller bag. She can lift it, but it is inconvenient.

Opportunities for the main persona

•     She has a personal device and is confortable using it. There is a built-in SIRI-like AI assistant and she likes it since it follows her orders without questioning them. That is also her prefered interface, since she can use it without holding a device or looking at something.
•     There is open access to database and servers with information about Stockholm and public transport.

Ordering of Pain points for the secondary persona

1.     Obstacle free path. He is on weels and can at most leave the chair for short walks.
2.     Language. No problem. He is a Swede in Sweden.
3.     Finding his way. No problem. He is a daily commuter.

Opportunities for the secondary persona

•     He has a personal device (smartphone) in his pocket and a wireless connection to a swipeable screen on the chair. He is convenient using the screen without picking up the phone.
•     There is open access to database and servers with information about Stockholm and public transport.

Tools Used by this Team During the Project

This is a live document that may be updated at any time to reflect new tools we start using or realize that we use without thinking about it.

To be considered as a Cultural Probe for KTH students in 2015. Most of the tools are ubiquitos. They just exist, are easy to pick up and the team has not spent significant time evaluating tools. Someone just suggest a tool that should work. If nobody offers a better suggestion we go for it. If it fails, we can just dismiss the tool and try another one.

Virtual tools

• Viber. Social app for the phone. Allows the team to chat 24/7 and share photos. Fundamental part of working as a virtual team. We are five members in the team, but have separate schedules and just 20% of our KTH time allocated to this particular course. We have physical meetings about twice a week, but social media allows for maintaining work pace betwen meetings.
• Blogger.
• Google Drive. Common store of work documents, images and other material that does not fit on the blog (or need refinemnet before going to the blog). Good integration with Google docs.
• Google docs. Collaborative writing and editing of work documents. Each team member works on his own laptop even when we sit in the same room, allowing us to discuss the same document and change it live without having to ask the editor to do it or change seats to change the editor role.
• E-books and other online information sources, including the DH2620 webpages on KTH social.

Physical tools and artefacts

• Plain post-it notes. Still one of the most effective tools for interacting in a physical meeting and for brain storming.
• White-board. Still effective, see post it notes above.
• Laptops and cellphones with wireless interne. Team members has access to all tools both during meetings and at home or on the move.
• Mobile phone's camera. General documentation tool (photo, video, audio) always available.
• Physical book. Still competitive for reading large amounts of text and quick shortcuts to references with post-it markers. Does also offload the computer, phone and PDA screens since the book is a separate "device" not taking up valuable screen space.

Group's Summary of State of Art Analysis

People

 The people riding the ferry was a mixture of:

• Tourists visiting Stockholm and travelling between tourist attractions. They are generally considering the ferry ride as a pleasent tourist experience in itself.
• People living in or near Stockholm on a leisure ride. They are similar to the previous group but have more background knowledge and experience of Stockholm than the average tourist.
• Locals travelling to work or from work. The ferry is an effective part of the local transport system between Slussen and Djurgården, and people live or work at Djurgården too.

Infrastructure

SL Public Transport System

Most of the public communication in Stockholm is operated by SL and part of an integrated system. There is a common website, the ticket system is coordinated and there is a common search-box-oriented real-time travel planner. The planner is available on both web and in apps, and provides customized information for travelling between any locations in Stockholm.

SL does also sell tickets in their app, removing the need for a card or printed ticket.

The Boats 

The boat operator is a subcontractor to SL with a fleet of several boats of different age. All boats have restrooms and may carry wheelchairs, bikes and luggage. The new boats offer better wheelchair accessability and restroom access though.

The boat landings are generally manned by a combined ticket and information office. Probably an extra service to help tourists.

Personal Devices

Personal devices are still a moving target. How many carried a smartphone with apps five years ago?
Just the early adopters. Will apps be mainstream in five years or will the phone have an AI that makes apps redundant? The early adopters are already running SIRI, an AI that isn't that good, but maybe at the same level as apps was five years ago.
 
Smart phones and apps are frequently used by people at the boat and while waiting for the boat.

State-of-the-Art analysis. Marcus

The first thing to do was to find where you could read about the ferry that goes from slussen to djurgården. The www.sl.se did not provide enough information in my experience to help people travel by boat. The most optimal solution and the best way to find all the information was at www.waxholmsbolaget.se. Almost everything about the ferry could be found there.

When we came to the ferry station, I took some indirect observation that the only information to be found was how you buy a ticket. It seems that you could ask about the time schedule or destination at the information desk but otherwise it was fairly empty.

Overall I think that the system can be improved and more suited for people that don’t travel that much. An example is when the tourist was getting interviewed. After the interview he ask where the ferry would stop. Which seemed pretty obvious for us.  

State-of-the-Art analysis, Martin

To get information about the boat you can go to the website for the company that handles the boat which is called “waxholmsbolaget”. This website has pretty much all the information you need about the boat. The website has its own travelling planer which I think needs improvement, because when I tried to make a travel search the box where you should put in the information about where you are travelling from didn’t have any alternatives to choose between which the box for the destination has. Besides that, I think this is a good page for information about the boat. It contains everything from information about the boat's history to the current time tables.

Since the boat is included in the “SL travelling system” you can get information about the departures and arrivals on the SL website. This website can give you information how to travel from point A to point B anywhere within Stockholm county.

Both these websites have their own apps. I haven’t tried the waxholmsbolaget app yet but the SL app I am very familiar with. For most part it works fine but in some special cases it can give another travelling way other than the optimal (which most people are looking for) or give too short time between stops so that you miss the next bus or train because the previous was late.

When we went to the boat to do the interviews, there were information booths before the entrance where you could ask questions about buying tickets or similar. I think this is mostly for tourists, because “Gamla Stan” is a very popular place for tourists and some may walk around there, accidentally walk past the wharf and find themselves wanting to go on the boat. Thus it is good for them to find information at the spot.

State-of-the-Art analysis, Staffan

From the interview responses that we got it became clear that the tourists were using a physical map to navigate around the city, instead of a mobile phone. This might be the case since the tourists were in the age of ~70 and a map might be more familiar to them. 

The regular users of the ferry used their phones all the time and by walking through the boat and doing indirect observations, it became quite clear that the majority was using their mobile phones so I decided look into the different options available on the mobile platform. There are two main apps you can use to find the route from Slussen to Almänna Gränd. The first one is called “STHLM Traveling (SL)”, the second one is called "Google Maps". I also did some research on the company "Waxholmsbolaget" which owns the boats and managed to find their app on the Google Play Market.

Waxhomsbolaget's app

 Waxholmsbolaget's app lists all the different routes you can take by boat, one thing to note is that it lists all the routes and not only those that can be paid with SL's Access-card. On the waxolmbolaget’s website you have the option to switch between SL routes and non SL routes but not in the app. When testing the app I didn’t manage to get the route from Slussen to Allmänna Gränd, the destination could be set to both locations but not the start position. This caused a bit of frustration and is definitely a functional requirement that isn't fulfilled. This bug might be temporarily or just on my version of Android.

The SL app works fine, I can enter my starting position and destination and it gives me the info i need for getting from A to B. Down below you can se a use case of someone who will travel from Slussen to Allmänna Gränd.

 Google Maps interface looks like this if you want to travel from Slussen to Allmänna gränd.

Google Maps gives an overview of the route on a map which is very handy if you are new in town, if you also have GPS-connection you can se where on the route you are as well . You can also choose the method of transportation.

SL's app was the only one of these which showed the ticket you need for the trip.

For tourists, Google Maps seems to be the most usefull one since they might be new in town and it's the app which is most similar to a physical map.
This could be a non-funcitonal requirement, that our solution should look and feel like traditional map.