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”).

Think aloud

The task during the think aloud was to, using the prototype, find the fastest way to travel between T-Centralen and Södermalmstorg using SL transportation, and where in the train one should be located. The test subject was Per, a 18 year old high school student.

Transcript (translated from Swedish) Ok, so I guess I click the SL app. And type the place I want to go in this field? [the user enters the locations in the prototype] Hmm ah, this route seems good. [the user selected the first route]
So, red line to Norsborg. Ohh, what does this train show? [the user clicks around a bit on the train, hitting the explanation button] Ah so it shows how crowded the train is. But why is the arrow not on the green part? [user looks a bit confused at phone, until he read the remaining explanation text] ok... that's good I guess, but what is the pink exit? [I show the user the image of leaving the train] pink arrows! So they take me to the best exit, if I follow them, I guess closest to where I want to be? Cool!

Q: why did you select the first route so quickly? Isn't that usually the first one arrive? At least in the app I used

Q: So you missed the explanation of the arrow first, how come? Well I was looking for what the train colors was, and their explanation was in bold color, so I think it just got my attention first

Reflection: The user quickly found his way around in the app, which was very good. It took a bit of time to get the explanations for all of the information on the route screen, however this should only be a problem the first time. The user found the experience very familiar to other applications, which enabled him to reuse trained behaviors from those context, like immediately choosing the first route because it is the fastest.

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.

Individual notes - seminar 2

Today, tech industry is obsessed with metrics - every decision must be evaluated, every change is A/B tested, and hard numbers are king. I've often wondered how useful this data-driven approach is in practice, since they often only collect quantitative data, and does not focus as much on the reasons behind the numbers

Therefore, I found it interesting that the book takes up other approaches than using technology to evaluate designs on your target group quantitatively. Measuring usability using e.g. interviews and think-alouds can give additional context to the feedback from the evaluation that helps understanding

On the other hand, collecting quantitative data from the use of the product when it is actually has the upside that it more accurately reflects how the product is used in the intended setting. Collecting qualitative data could interfere with the user in its testing of the design, which may bias the results.

I found that heuristic evaluation was very interesting. My view of usability was that it can often be counter-intuitive, since elements of a design may interact with each other in ways that are not obvious. However, using heuristics such as Fitts' law seems like it could provide useful information despite this. So while it is very hard to evaluate usability without getting feedback from users, heuristics could have great use with when testing certain properties.

My question for the seminar is: in what ways can we collect qualitative without interfering with the user, to avoid introducing bias.

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

Reskollen

There is no official mobile application for travelling using SL for the Android operating system. Instead there are a large number of inofficial applications. The one with the highest rating in the Google Play Store is Reskollen, published by KTH student Mårten Wiman.

When starting the application, the first screen displayed show the next departures from the station closest to you, together with the distance to the station. This information is updated in real time. This screen also display the delays of every vehicle.

In the same way as the bus stop signage, the application distinguish between the information gathered in real-time and the scheduled times by display minute counts for real-time information and exact time for scheduled times. I really like this design concept, since my most common usage when travelling is my commute to and from school, meaning I already know what line to take. In this case, I’m only interested in the times of the next departures.

Another neat feature is that is contains its own built-in travel planner. The built-in planner also works when offline, something I’ve found very useful when in the subway, where data coverage is scarce. I’ve also found the planner to be more intelligent than the one provided by SL.

My favourite feature of the application is the ease of use - one notice that a lot of time has been spent in making the application easy to use. For example, on the main screen where the next departures are displayed, there are also two text fields shown - from and to. When two locations are entered into these fields, the application will immediately display the next trips between the locations starting now. This is probably the most common use case, and displaying it so prominently and automatically searching for trips when the locations are entered minimize the number of presses needed to get the information I want - a design philosophy that seem to permeate the application.

Field study, interview transcript - Johan Sannemo

I performed my interviews at T-centralen during early afternoon, to avoid the crowded rush.

My first interview was performed with a woman in her late 20s, studying for a medical profession.

How often do you travel by subway?

Every weekday, from Sundbyberg to T-centralen (blue line), and then from T-centralen to Slussen (red/green line).

What is the worst that could happen on the subway?

A terrorist bombing, or some other similar event.

What do you like about the subway?

The frequence of departure is very good.

What do you think works perfectly about the subway?

The night and weekend schedule covers my needs perfectly

What information do you miss in the subway?

Don’t know. More information about the “resegarantier” during delays. It would be nice if it was easier to know what exit I should take, when I’m going somplace new.

Why do you use the subway instead of travelling by car?

I don’t have my driver’s license yet. If I had my driver’s license, I wouldn’t use the subway as much (possibly when going to party, since I

What bothers you about the subway?

The turnstiles. Especially when people try to pass through them by going behind me. Makes me feel really uncomfortable and scared, especially late at night. The turnstiles themselves also feels dangerous.

How’s the environment on the subway around TC/Slussen?

It’s way too crowded. Sometimes I don’t even get on a subway because of all the people.

How do you occupy yourself when you travel?

In general I use my phone. If I travel with someone I know, I talk to them.

My second interview was performed with a male high school student.

How often do you travel by subway?

I commute several times a week, mostly using the red line to T-centralen.

Why do you use the subway?

It’s both cheaper and more environmentally friendly than traveling by car. I don’t have a car either. For shorter distances I mostly walk instead.

What do you like about the subway?

It’s a very fast and convenient method of transport. It has a good reach.

What’s most important for you when traveling by subway?

That my trip is not delayed.

How do you find the environment in the subway?

I like the design of the platforms in general, so I’ve never really had a problem with the exterior environment. I’ve never felt unsafe in the subway system, except during an occasional trip late at night.

What do you usually do when you are waiting for the subway, or during the subway trip?

I often sit and play around with my phone. Sometimes I do my math homework.

What’s the worst part of travelling at T-centralen?

The crowdedness! There is so much people, especially in the morning and early evening.

Do you use the SL app?

Yes

What information in the app do you find most useful?

The real time information. I find it very useful to know if a train is delayed or not.

The interviewees were informed about the context of the interview. The interviews were recorded typing on a laptop, which the interviewee were then given a chance to read through the typed notes to add additional context or clarifications.

In general, a big problem is the crowdedness at the stations. A product to decrease the crowdedness without having to increase the number of trains departing would be a good area to focus on. Both of the interviewees use their phone a lot in the subway, so a mobile application could be useful.

Notes: reflection on readings for seminar 1

The central pillar of user-centred systems design is to involve
the users of a system to a high degree. Many times, especially
in government or enterprise projects, it is the case that a system
is designed in a very rigid fashion, with some experts giving
requirements and the development team then implementing these
requirements independently of the surrounding organization.

The article (Key Principles in User-Centred Systems Design) is basically a guide to how to avoid this class
of failures - involve the user! Do not only design with the user
in mind, but make them part of the process. It suggests three
things that from my own experience is most important when trying
to achieve this goal:
- have the end user participate in the design and development process. They have the domain knowledge you may lack
- make prototypes, early and often. Agile development with many iterations is a good combo.
- usability expertise is a thing, use it. Programmers and the population use computer systems differently.

But how does one do when involving users? Gathering data from users
to apply in the design process isn't easy. During prototyping and
iterating on the prototype, direct user feedback can be gathered
and used. In the planning phase, I've found interviews to be a good
way at identifying problems to tackle. During the MVK course, we've used
rather structured interviews when collecting requirements, which
has worked well.

Another of the main techniques for gathering data, using questionnaires,
is harder when trying to identify requirements, but is good when determining if a change introduced to a system is good. However,
questionnaires must be carefully designed not to introduce biases.
There are biases both in how we answer certain question (for example
on how it is worded, where in the questionnaire the question is), and
getting a good random sample - maybe a certain group refuse to answer
questionnaires in general, skewing the results.

Automatically observing the users when utilizing the system (indirect observation), is a common technique nowadays.
We attempt to describe how the system is used in terms of small, logable actions
taken by the user. There is a big potential for biases though, and mistakes arising from optimizing the wrong thing (can an increase in the use of a UI language selector result from both a good and a bad change?).

My question for the seminar is: how do we reduce biases in the different data gathering techniques?