Think aloud evaluation summary

The think aloud evaluation were performed on a smartphones or tablet devices. The prototype is an app made in the program flinto (posted as the first prototype earlier, including the flinto file).

In all cases the user was direct observed in a controlled environment. The reason here was to catch any user-friendliness and expose issues that can be improved for the final version of the prototype. Direct observation is the most convenient since we have limited time and we get very upfront feedback on how the app is used by different users.

Summary 

Except for any annoyance in the login screen (you can only press the login button) most of the test people reacted to the big statistic table in the home screen. The user doesn't understand what it does or why is it there. To understand the purpose of the app, the user needed a short explanation of what the app really does. Since the home screen is the most important part of the app, the buttons seems to need to be more self-explanatory. Also the "Buy Ticket" button is very big and it might mislead the user to do the things and understand the core idea of the app. 

Here is the Home Screen of the first version of the app:

Final Design

This our final design. We decided to rework the design based on feedback, so this is our second high-fidelity prototype iteration.

On top we have wheels that fill out based on how many trips you have left to unlock a ticket. For example the left one is a three day ticket. When you reach that limit you will not pay more than that during a three day period. This will also be reflected on the “Next Travel Cost” label. It will be set to 0 kr for the ticket period. The “Current Ticket” will also be upgraded so you easily can identify which ticket your are currently traveling by. You can also swipe left and right on the circles for additional tickets but the most relevant tickets will be displayed by default.

After doing Think aloud evaluations we recognised that a lot of design problem revolves around numbers not being presented in an easily understandable manner. We also got feedback on graphical elements not being very intuitive. We took this to heart and discussed a lot about how to order information and how create intuitive labels. We continued developing our product and with the modifications applied the image to the right is our current high-fidelity prototype. We believe that we made great improvements but there is always room for additional iterations and fine polishing.

Our target group are sporadic travelers and their problem being that it is sometimes difficult to determine what ticket saves you the most money. Sporadic meaning that they now and then travel less than the amount that justifies buying a monthly card. Our system makes sure you pay the absolute least amount while still being adapted to the SL set pricing points. With our application the travelers choice problem is entirely resolved and presented in a intuitive and appealing package.

Additional features

Login screen that will appear on first setup. It is required in order to connect to Mitt SL so the app can access personal traveling information.

First statistic screen displays travel amount over several months. So you can easily track how much you are traveling and when. The bars indicating how much you payed that month. You can swipe left and right to find the month you are looking for.

Second statistic screen shows on which day you bought a ticket and it also displays which period an unlocked ticket is available for.

You can swipe left and right here as well to show different months.

Ticket details show the user additional information on expenses. So the user can easily keep track of what cost what amount so that there is absolute transparency in every transaction that is made.

Settings will contain things like language options, billing method, etc. It also allows the user to logout and switch account.

Test cases

We made some test cases to simulate the use of our 'pay as you go' payment method, and how it should work given certain situations. We tested three different users during a month, all sporadic travellers that had to gain by the use of our product. The three different users are represented as each worksheet down in the left corner (on Google Spreadsheet).

What is the data representing?
The spreadsheet helps to visualize the use of our product on specific users. The user is given a cost per travel based on the current price for SL credits ('Reskassa') and then given specific travel zones to travel between (SL have different costs for travelling between different areas). The spreadsheet then calculates the difference between if you would have payed ONLY by SL credits, or if you bought a monthly ticket compared to using our product,.

Case 1:
The first user was given the zones A to B, which correlates to 37.5 kr per travel. The user managed to archive a 3-day ticket during the first three days, and then another 24-hour ticket later during the month. With the use of our app and getting these tickets, the user saved 105 kr (if he/she only had bought SL credits), or saved 220 kr (if the user had bougth a monthly ticket).

Case 2:
The second user was given the zones A to A, which means 25 kr per travel. The user managed to archive a 7-day ticket in the first half of the month. The user saved 50 kr (if he/she only had bought SL credits), or saved 190 kr (if the user had bougth a monthly ticket).

Case 3:
The third user was also given the zones A to A, which means 25 kr per travel. Here we tried to demonstrate how the app continuously is checking backwards for possible new tickets. Unlike our previous examples, this user started traveling in the middle of the month. He/she managed to archieve a 3-day ticket before the end of november, but continued to travel during the start of december, and therefore reaching the cost limit for a 7-day ticket. The user saved a total of 40 kr during november and 135 kr during december (if he/she only had bought SL credits). Or saved 35 kr during november and 55 kr during december(if the user had bougth a monthly ticket).

https://docs.google.com/spreadsheets/d/1sWlAnjZAKxomG9BQveli0L42RZ3eqGnM41Bv1l7qGKs/edit?usp=sharing

Meeting 12/11

During today's meeting we mostly discussed the usability goals of our prototype, what do we actually wanna include in the prototype of our application? Some of us felt as though the application in itself was a bit cluttered, and so we opted to refine our previous designs and our established functional requirements.

What we want if for people to use the "pay as you go fare" alternative. We want the users of our application to feel satisfied knowing they're saving money. The more you travel, the lower the cost, and if you travel sporadically, you won't have to worry about overpaying by buying the wrong kind of ticket. The user experience should be simple. Therefor, our new application will only include one of the three options previously presented, a payment system charging you at the end of each month, either through direct debit or invoice.

Another functional requirement we've opted for is to redesign the stats presented in the application, also in order to better the user experience. Instead of including ticket recommendations, this part of the application will include statistics of your travels. How much does each travel cost? Am I currently traveling for free? How much will I be charged if I keep traveling in the same pattern? Questions like these will all be answered.

The basis of our payment system is the SL Access Credit fee. Every time you travel, this amount will be registered to your personal account. Let's say you travel two times on the first of december, two times on the second of december and four times on the third of december. During each travel, a fee corresponding to the SL Access Credit amount will be charged to your account. Consequently, these three days of travels all add up to a total of 300 SEK, but by using our application our service will recognize that it would be cheaper for you to only be charged the amount of a 72 Hour Card, costing only 230 SEK. Since you didn't know you'd be traveling a total of eight times in this short amount of time, there would have been no way of you knowing that buying a 72 Hour Card, instead of paying for each trip separately, would have saved you 70 SEK. But My SL does.

Other than changing the name of our application to "My SL", no more changes have been made.

Think Aloud Evaluation

The direct observation was performed in a controlled environment on a person well accustomed to the usage of smartphones. During the evaluation, every action was spoken aloud, as they should be.

The evaluation began with me asking the person to explore the application freely. Given only these instructions the person signed in by simply tapping the login-button, no questions asked. I conclude that this particular screen is very intuitive. 

Having the home-screen at display, the person commented on the information present. The comments were mostly about the statistics, saying that the histogram needed numbers to convey the information more clearly and that the green bar needed something along the same lines in order to serve its purpose. In regards to the ”Autogiro” headline, the person thought it would be better to rename it and use the name ”To Pay”. All of this information implies that this screen must be redesigned.

Next, the person, by accident, opened the statistics-screen, being surprised when doing so. Clearly, we have to make it visibly known that the stats presented on the home-screen are clickable. The person thought that this screen was pretty understandable though, only leaving comments on the maximum/minimum cost headlines. ”Does ”Maximum cost” mean that I only can be charged, at the most, 100 kr a day?”

The person found the last two screens to be intuitive.

Following the evaluation, I conducted a one-question-interview, asking about the overall impression of our application. In short, the answer was that the application seemed a bit messy, it was including a lot, maybe a little too much.

I agree. Our application include more than is necessary. If a feature isn’t crucial, it should be discarded. Simple and clean is the way to go.

Final prototype sketches

These are some sketches made for the final prototype. Here we test how our data should be presented to the user. We chose circles for their ability to present data in a rather small area of the screen.

Meeting + exercise 4/11

After our meeting previous day, we divided the work so that a few in the group started to work on the layout for our mobile application the same evening. The images that were created and made into a prototype by using Flinto are presented in a video in a previous blog post (http://group-d2.blogspot.se/2015/11/first-prototype.html).

On this meeting we mainly tested the prototype and had long discussions about the design choices and new ideas about how the layout could be developed. We all liked the outcome, but we thought that maybe there were a little bit too much information and statistics on the main page. We also formed a power point for our presentation and prepared for what we were going to say. Here are our slides:

The feedback we got from the presentation during the exercise was really good! Some of the reactions was:

- Clearifying questions about the main idea and the features
- Some of these features already exist in SL's applications
- Maybe we could incorporate our ideas into being features of one of SL's applications, it might not be neccessary to create an entirely new application.