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