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

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

We are about to start our first iterative cycle of design-evaluate redesign, at least I assume it will be the first of several. It is important to evaluate so we can be sure that our software is usable and is what users want, and it has shown to be less expensive to continuously evaluate the design than to fix problems that are discovered after the system has been launched (of course, expenses will not be a problem in our case). In the book, they mention how software and web designers are prone to assume everyone else can use their product just because they can. I believe this could be especially true for our group since we all can identify with our relatively broad target group and therefor on some level designs a product for ourselves.This can be prevented by methods such as user evaluation and think-alouds. Studies have shown that people nowadays expect more from a product than just for it to meet the exact needs of the customer, for instance simplicity and elegance that makes products a joy to own and to use. The latter is especially hard without user involvement in the design process and evaluation. Usability testing involves measuring the performance of typical users on typical tasks. Satisfaction can be evaluated by continuing with the interviews and questionnaires. There has been an increasing trend towards observing users while they interact with the product in the intended settings, which could vary a lot from if they were observed in a laboratory. These kinds of tests could be hard for us to perform depending of which design we choose and what kind of prototype we can make (we can’t for instance make a prototype of a glass wall between the platform and tracks that people can interact with during their usual commute). In our case it might be easier to use heuristic evaluation which aren’t dependent on the users’ involvement to the same extent.

Is there a way to test our 3rd design on the users?

State of the art analysis

I decided to get inspiration from a country famous for their trains - Switzerland.
Why do people love Swiss trains? They're always on time. It's also incredibly easy to go by train in Switzerland since they have a fabulous app, SBB Mobile (top reviews from both andrioid- and iPhone users).

SBB Mobile is a very extensive application so i'm going to focus on what seemed like the most important subjects according to the interviewees.

Delays-
SBB mobile gives you live updates on delays, and if a delay affects your planned journey it gives you a notification. You can also set up a profile with your most visited stations and you will get notifications if something happens that affect them.

Crowds-
SBB-Mobile has the usual information about timetables and you can find your fastest route in much the same way as in the LL application. But SBB combines this with information about how much people are on/is expected to be on the trains. They do this simply and effectively by showing different numbers of little stick-men next to the connection.

Connactions-
Another feature that the SL-application doesn't have is information about all the different stations. You can search on any station and everyone has it's own page. On this page you can find much of the information people mentioned missing in the interviews.
Information about connections from the station other then by train (including parking spaces, bike renting and "carsharing")
Station plan (!!) which several interviewees asked for, that shows all the different exits from the station and which one is best to take depending on where you're going.
It also has information about stores, restaurants and pharmacies nearby which I thought was pretty nice but is probably not relevant for a commuter in Stockholm.

What's most interesting about the SBB application is that it is far easier to handle than the SL-app despite containing so much more information. It has a simple design, everything is divided in categories and "themes" and the buttons has explanatory pictures. It's easy to use as simply a route planner (like the SL app), but it is also easy to customize it by building on your profile and adding preferences.

Interview - Transcript

How often do you commute and which route do you take?

Almost every day between Enskede and SU.

Why do you use the subway and not car/bike etc.?

It’s fast, mostly on time and good for the environment.

What’s most important for you when you’re on the subway?

That it’s on time and that there’s not too much people.

What do you not like about the subway?

When it’s too crowded.

What’s the worst thing that can happen on the subway?

That it’s really, really crowded, so you can’t even move.

What do you like the least about T-centralen and Slussen?

All the people. Especially when you’re trying to change train or go up the escalators.

So how do you feel about the environment? Safety/comfort?

It’s usually fine but people can be loud and rowdy.

What do you do to pass the time when you’re commuting?

I listen to music.

Where do you stand on the platform when you’re waiting?

On the side I need to be on when I get of the sub.

Do you use the sl-app and in that case, for what?

Yes, to find the fastest route. And information about delays. And to find busstops.

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.

Seminar 1 - Individual notes

As is to be expected, the readings helps us in the early stages of our project, mainly by describing different ways of collecting and analyzing data and establishing user requirements.

Interviews are advantageous in the beginning of a project as they don’t require too much prior knowledge in your chosen field. You can make them unstructured, with several follow-up questions to utilize the particular thoughts and experiences of each interviewee. They can also be held in the surroundings in question which gives you the opportunity to make observations. Questionnaires are useful if you have identified what specific information you require and need a larger quantity of data from a wider range of people.

 It is usually a good idea to “triangulate”, using different methods of gathering data and finding the key similarities. It is important to use different frameworks and different data-gathering and data-interpretation techniques, since these will affect what user requirements we extract, and constantly refining and revising these requirements. The gathering and interpretation of data should preferably not be done only once but several times in an iterative process.

The article about UCSD confirms the importance of making the design process both an iterative process where each iteration includes analysis, design and evaluation. They stress the benefits of active user participation; continuous interviews, observations and evaluations by the end user, and also domain experts, during the design process. A way to make this as effective and instructive as possible is simple design representation and early prototyping; from an early stage making multiple sketches, mock-ups and simulations, preferably of several design alternatives in parallel, that are easy to understand for the users as well as the design team. 

My question is how we, in the best way, can include the end users continuously in our design process?