Our design - Prototype to Final

Our design started to take its final form after the Expert and Heuristics evaluations. We now started to sketch on our prototype as seen in the blog post:

http://f5slattarna.blogspot.se/2016/06/look-how-far-weve-come.html

We used Invision as our tool to design the prototype.

Although we didn't set out to use an evaluation framework like DECIDE, and despite the linear progression of the course's exercises, the nature of the design process forced us to go back and iteratively re-evaluate our work and assumptions — especially the Exploration of questions and Determination of goals. Coming at these iterations with different assumptions and from new angles enabled us to triangulate our users and their needs.

Since the course didn't go beyond a basic (though high-fidelity, and without much horizontal or vertical compromise) digital prototype, it didn't have enough interactivity to meaningfully apply any GOMS model or investigate Fitt's law. We also didn't do any dedicated gathering of statistics from our users or evaluators in form of questionnaires or such. Which in turn means that nearly all of the data that informed our iterations was qualitative.

Furthermore, although we recognize the usefulness of user-centered design and making the users active stakeholders — especially in the face of having our assumptions changed/expectations managed by both the interviews and the think-alouds; what actually transpired was mostly what we'll humbly refer to as genious design. But an argument could be made that we were ourselves prospective users of the final product. This is especially true in the case of group members who had not been present during the creation of the app, who gave the group feedback from walkthroughs which resulted in several new functionalities being added.

We used pen and paper for our low-fidelity sketches, and used InVision as our prototyping tool for the final prototype. The GUI for the app reuses established mobile interface norms. 

An example of the iteration process for specific icons is seen in this blog post:

http://f5slattarna.blogspot.se/2016/05/creating-our-train-icon.html

Our train icon combines similarity of the train shape with an analogy between available seating and colour (green is free, red is occupied). We also use the arbitrary but commonly established symbolism of a pointing arrow for "exit".

http://f5slattarna.blogspot.com/2016/06/proposed-changes-to-physical-metro.html

Our updates to the stations are static, but of course the users can interact with them — by choosing to read/look at them and choosing how much of their information they take in.

Here is a short summery of what the final design does:

• Add more points of interest to the exit signs.
• Make sure that all exits are color-coded.
• Use color coding to show the different exits on maps on the stations.
• Make the color coding clearly visible to the commuters, use lines/dots/arrows to guide them to their desired color.
• The lines/arrows should guide users to their destination, improving the general people flow and reducing crowding.
• Integrate the color coding system in the SL-App, it should tell users what exit color they should take.
• On bigger and more complicated stations, add extra detail to the color-coding system, (inspired from Hong kong), using letters or letter-digit-combinations (A1, A2, etc). Same colors should be together however, to make it easier to find for the users.
• Also let the SL-App tell users where they should sit on the train. It should inform
• Where to sit that is closest to your exit
• Where to sit if you want to avoid crowds.

Look how far we've come...

Design process starting from field studies.

To sketches of app and of adjustments to physical metro stations.

To a finished prototype! Click it!

Seriously, click it and check out the interactive prototype!

Summary of Think-Alouds

Everyone used a similar usability test on the prototype in form of answering:

Find the way from T-Centralen to Södermalmstorg using the prototype.

Some main comments from the think- alouds were:

-          App is clear. But there might me some frustrating excessive confirmation.

-          The crowding information should be on the platforms as well.

-          The red and green text should only be green at the word “red” and “green”.

Some of the most emotional reactions from the users of the prototype was that it was working or dong things for you that the “real” app does not. Maybe the prototype was too simple in to get focus on the main features.

The tests was done in a fast mention and without any longer breaks which might indicate that the app doesn't require the highest level of counciouss decisionmaking that interferes with spoken language that Gulan mentioned on his lectures.

The users understood quickly that the trains indicated crowding information but not in which way. The question mark, showing further information of the train icon, was in some case spotted and used but in others not used.  In the case where it was used the reaction was that it was understandable.

For our final design we should probably change the information in the app based on the feed- back and also change the symbols used for lines and exits (discussed in the “övning 5”).

Individual think aloud

Assignment and user

Find an itineries from T-Centralen to Södermalmstorg and try figure out which part of the train that is most fittingly to travel in and also how to find the exit closest by Södermalmtorg.
User was Hanna 24 years old studying social science and travels daily between Slussen and T-Centralen where she transfers to another train. She uses iPhone and have never owned a smartphone running Android (which is the OS in the prototype).

Translated notes

- I'll start by opening the SL-app i assume (Taps the icon)
- Then I'll first write the origin of my travel (Taps the "my position" field)
- Okay this was weird the text both T-Centralen and Södermalmstorg appeared in the text fields. I guess this has something to do with this kind of prototype..? Anyhow I'll continue

- I have some options of suggested itineries, I want this one (Taps the travel)
- Here is some new stuff. Hmm. Green usually indicates where one wants to be at, therefore I'll be placing myself in the green part of the train. (Points on the train displaying crowding information)

- No wait there's a small pink arrow here. That color is the same as the text instructiong me on which exit to take, that's where I'm suppose to stand right?! But is that in the front or in the back of the train? Hmm. I'll clock this questionmark and see if it provides any info. (Clicks (?)-symbol)

- Aha so this tells me how croeded the train is. I get it, obviously here I'll have to choose between having a seat or be close to my exit. 

Reflection

I'm happy with the result of the think aloud the behaviour of the user was corresponding very well to how we'd expected. The familiarities with the already existing SL application makes navigating a breeze if you are already familiar with that it seems. The tester never went silent during the assignment either which indicates that the app doesn't require the highest level of counciouss decisionmaking that interfears with spoken language that Gulan mentioned on his lectures.

Seminar 2 - Summary

Recollection of discussed topics during seminar 2

• We have learned the importance of evaluating, but sometimes it is hard to user-test something beforehand (scale, patents, secrecy). We also discussed ways to circumvent this.
• For testing our own design, we could use testing in the wild: adding markers and prototypes to the SL stations, and have people try to accomplish tasks (getting from A to B while using our prototype app). This would be testing in a natural setting involving users.
• We could use people from Copenhagen (which has a similar system in place) to heursitically evaluate our prototype and tell us what they feel are the good parts and bad parts of our system when it is adjusted to Stockholm.
• We could also take Stockholmers to Copenhagen and let them see what they like and don’t like about that system, and see how they compare it to stockholm.
• This would be be a kind of triangulation: we see the problem both from the perspective of users who have used it for a long time, and users who are using it for a first time. Their combined heuristics would give us a better view of the actual good and bad sides of our idea.
• Also, Opportunistic Evaluation is a thing that we can actually, practically do (not assuming infinite resources etc). We could even ask the group we’re presenting to what they think, since they are almost surely users of the public transportation. We can also interview people in the subway and present our design to the, ask what they think.
• We discuss how we should evaluate the different parts of our designs, since it is quite broad. It might be good to evaluate each part on its own, ut we also need to evaluate the whole together since we need to know how well the prats cooperate.

Seminar 2 - Individual notes

Evaluation

I was intrigued by how many different factors and methods that comes in play when evaluating. Surprised that it’s such a big area in interaction design. I thought on forehand that the most common way of evaluating a product today must be analytics using the data of natural setting involving users because most tech made today is connected and thus can feed user data to the designer. It became clear that’s not the case. I believe that think-a-louds, which is a controlled setting involving users, provides a lot of useful information to a designer. Unfortunately, the results can be somewhat non representative because the part of the brain that’s responsible for decision making is also used for speech, high level of cognitive awareness, meaning that when the most interesting decisions are made the user is most prone to be quiet. 

As seen in the chapter of data gathering usability testing also might provide both quantitative and qualitative data. The first might be given by keystrokes, mouse movement or the time to complete a task. Qualitative might collected semi structured interviews for example. It’s important though that when interpreting and presenting the data one should be aware of that results might be influenced, a test conducted in a lab says little about how users will interact with the design “in the wild”.

When lacking real user’s heuristic evaluation is the way to go. It seems that the set of heuristics is great guidelines to see whether the design is meeting demands of good interaction design. Doing this before releasing might save lots of time. Fitts’ law describes, in a mathematical manner, the time it takes to select objects on a screen and thus need no users at all and can still be motivating major design decisions which I does seem really useful.

Question: What evaluation method would be the best for our design nr.2?

Design step 1 - Collaborative Iteration

Choosen painpoint: Worried when train stops and no reason is given

We choose one painpoint and wrote it on a piece of paper. One member of the group started with an idea that could solve the issue at hand, summarized it on a post it note and stuck it on the paper with the pain point. The next person expanded the idea and in the same manner summarized the essence of it and stuck it on the paper. When everyone had done so we discussed how this chain of solutions and designs might come togeather and visualize what such design would look like. We also tried to keep in mind the earlier interviews and what reqierments the conceptual design would meet.

The white paper is the painpoint in focus in this blogpost

The first idea was to give commuters better information on the cause of delay and which alternative itineraries throgh the existing SL-application. After a few steps it took a different turn to screens in the subway. We made this sketch and low-fidelity prototype on paper.

Quick sketch

Jan Gulliksen mentioned on a lecture of his that he’d been involved on a project involving railways in Sweden and informed us that in most cases the driver of the train doesn’t have the information about the delay but just a signal to stop. By reducing the chain of information and let the available information at HQ, from technology already in place, be presented imideatly to the user in a familiar format to them. The red dot indicates delays and the numer is estimated time before solved. The screen also lets user easily orientate themselves where they’re on the line and which stations are coming up. This way of visualizing the railway, including delays, amplifies human cognition because it's enabling users to see patterns and easily detect anomalities.

State of the art analaysis - Summary

Doing our state of the art analysis’ we had a broad perspective to try gather as much diverse and useful insights posible to what might be useful for our own project. This made ofcource that common ground for all of them was hard to find but a few topics that was brought up in most was regarding information.

            What information are available for the user?

            Is the information easy accessible?

            Is it well presented?

            Is it useful?

A repeated opinion during the interviews was the frustration when forced to make a choice without any information i.e. when there’s major delays, should one wait for the train or try an alternate itiniary, if so which one? Two of the state of art analyses regarded interaction design based on real-time information and both have shown good results in user satisfaction. The information is often times already acessable for the designers such as precise locations of transport because necessary technology is already in place. The issue lies to transform the data to a user oriented purpose. The most critical information for users must be accurate and easy aviable.

It might also be fair to compare the SL app to more generalized travel applications such as Google maps. What SL lacks is the integration of other means of travel such as riding a bike to the train and when leving the train show a map to the destination wished for. To make the app useful doing things that naturally combines with travel might increase satisfaction with the app.

State of the art analysis – Thony Price

During the interviews, and also during my own experiences with SL, a common complaint is the lack of information when traffic is not running by the schedule. It puts the user in a situation of making a choice, staying on route or alternate the itinerary. This brought my thoughts to an application I used when I spent time in Gothenburg; “Where is the bus?”

http://www.vasttrafik.se/#!/Reseinformation/mobila-tjanster/var-aer-bussen/

The makers of the application, Västtrafik, are the same company that provides the transportation services in the region. It is a separate app to the itinerary planner and instead of showing the estimated time (time tables) it shows the position of the bus/light rail. It works like this:

1.     Open the application – it locates the closest station or bus stop to you.

2.     You choose the route, direction, mean of transportation.

3.     Press “Find”.

4.     A map shows yours, the stations and the bus’ position.

Because all vehicles in public transportation was already equipped with GPS due to the “arrives in x minutes signs” the implementation of this application was more a matter of transparency of the data at hand at Västtrafik. In the Appstore the main critic is that in a functional transportation system one shouldn’t need to ask where’s the bus at. Among the user that rates the app high most says that is solves the situations where there previously was a frustration due to the lack of information.

I enjoyed the application a lot both information wise and user design wise. I believe the more information available the better as long as it’s not presented in an overwhelming way therefore it’s clever to have it as a separate application in my opinion. The first screen of the app also spells out something like “Where !:@#%!! Is the bus?” which lets the design show that Västtrafik is understands those annoying moments of commuting. The map us also of a design that resembles to earlier user map-apps and therefore is easy to use.

To summarize I think this application makes a good job utilizing the technology already in place and is a good example of iterative design building on an understanding of the users perspective.

Field study/Transcript – Thony Price

This interview was carried out on my way to school because my route passes through the stations of interest, Slussen and T-Centralen, this was during the morning rush about 8 am. This gave the best odds to find a participant fit for our population, daily commuters. The interviewee at hand would also be a probability sample which supposedly gives more generalizable data.

The question we had prepared was designed to be open and useful in a semi-structured way with space follow up questions. I took notes as fast as possible during the interview and as soon as it was done filled in the gaps and clarified thoughts that was hard to transcribe during the interview. This is the result:

Population check: How often du you commute and through which regions?

Everyday, bus from Orminge to Slussen and Slussen to T-centralen by subway.

Do you use the SL-app? To do what?

Yes, I do. Use route planner, really often.

What’s most important when you travel by the subway?

That I can rely on the planned route.

What’s your worst-case-scenario when commuting?

Major delays. Because when making plans, meetings, airport-check-ins you must put your faith in SL’s hands and pray. If they’re late it can have big consequences or lead to mych frustration.

What do you like about the subway?

That most part of the time it works flawlessly.

What information du you miss?

Better info on connections, when I switch from bus to subway or vice versa I always need to check the SL-app to know if I should hurry or not to minimize my waiting time.

How about the environment/comfort/safeness on the sub?

I like it, especially the SL-helpers that usually work on the bigger stations and also the camera monitoring.

Why are you commuting and doesn’t travel by car for example?

It’s the best option both concerning time and price when compared to go by car.

How do you occupy yourself during the commute?

I read books or prepare work.

What is the worst characteristics of Slussen/T-Centralen?

In T-Centralen it’s insanely crowded most times and a bit dirty.

What annoys you the most and why?

High prices because, yeah it's pricy! And delays because you depend so much on it to be on time.

What should be done about it?

SL needs to buy better trains and if there’s a delay I want to know right away, alternative routs would be nice or that the route planner changes the route to a better option. 

Before our ways parted I asked for premission to share the answers and luckily my wish was granted, this of course is smarter to do before asking away..! 

Seminar 1 - Individual notes

The first reading seminar concerns the first steps of an interaction design project; data gathering, data analysis and establishing requirements.  

To obtain good data there’s three main techniques; interviews, questionnaires and observations. Often more than one technique is used to validate results of some inquiry by exploring similar results, also known as triangulation.

Interviews can be unstructured (using lots of open questions and leaves room to explore insights from interviewee) or structured where questions are usually closed and has options. I’d say the best is somewhere in between collecting both quantitative data and a more what motivates those answers, qualitative data. Questionnaires was an especially interesting section; interactive web-based questionnaires have some great benefits although the main problem is the difficulty of obtaining a random sample of respondents.

To process the gathered data the method varies with the technique used for collecting. From audio and video there’s possible to extract both qualitative and quantitative data. The latter is easier to transcript and present as graphs or similar. For qualitative data on the other hand one must first identify recurring patterns or themes to be able sorting the data.

In chapter 10 the authors point out the importance of establishing requirements. There’re two main aims; understand as much as possible about the users and secondly to produce a set of stable requirements that form a sound basis to start designing. Doing a proper foundation for the project is both cost effective and professional because what a “customer” think/mean/says they want may differ.

To establish requirements, it’s a good idea to discuss both functional and nonfunctional requirements. It’s often intuitive to use scenarios, which is described as an informal narrative description in the context of use.

My question to the seminar: How can one minimize the effect that our data gathering technique has on the respondents?