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!

Proposed changes to the physical metro stations

Not all solutions are digital. Accompanying our app are these proposed changes to the physical metro stations:

The signs on the platforms (and at the entrances, not shown in picture) should include colour codes for the exits they inform of (the triangles). They could also incorporate more nearby locations of interest.

 

 Exits shown on maps should also have the colour codes. The encoding should be consistent between stations, for example always having pink exits in the forward direction of the trains toward one end station.

 Here's an early attempt at guiding the passengers to their exit. Can you spot all the flaws?

1) Guides on the ground won't be visible during rush hour when the platform is crowded. 2) Guides leading out from the doors will cross over each other ad nauseam. 3) A line of undirected guides might be seen by a traveller who then proceeds to walk in the wrong direction. 4) Round coloured guides is the established symbol for the metro lines, which would be confused with exits.

Crowding information for the oncoming train could be shown to everyone on the platform. (The picture is from a KTH study that tried doing exactly that.)

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.