We’ve made it to the last week of Q2 at AC4D, and to our last iteration of our project; redesigning the CapMetro app. The CapMetro app is used by riders of the CapMetro public transportation system here in Austin, and allows users to purchase and use tickets, find routes, see schedules, and more. Over the last 8 weeks, we’ve created, tested, and revised our designs for the CapMetro app 6 times in our Rapid Ideation and Creative Problem Solving class. Since it’s the last week, I’d like to review the process, what I did, and what I learned over the course of this quarter.
Each week, we created concept maps to describe and illustrate the overall idea of how our redesigned apps work, and how the pieces of the app relate to one another. At week 1, we mapped the existing CapMetro app. This was the app as I saw it:
Because I perceived the app as overly complicated and confusing, I wanted to start from the minimum capabilities that would still allow riders to buy and use tickets, plan a trip, and take care of the administrative stuff needed to handle ticket purchases (such as storing credit card info). Secondarily I wanted users to be able to reach a CapMetro representative with problems or questions. The final iteration and concept map maintained these goals, as you can see here:
While the concept map maintained the usage goals I originally set, the manifestation of these capabilities changed drastically in the wireframes. To iterate my wireframes each week, I followed this process:
- Re-sketched wireframes based on selected issues from user testing and in-class critique the previous week (more on that below). I preferred to sketch out ideas on paper before investing the time creating the graphics in Illustrator.
- Revised existing or created new wireframes in Illustrator. Each week, we would learn how to increase the fidelity a little bit, to make it look more like a real app, which gave users more clarity in testing.
- Performed think-aloud testing with paper wireframes. In this type of testing, I would approach people I didn’t already know and give them tasks written on a piece of paper to see if the app would allow them to complete these tasks or if there were moments of breakdown and confusion. I would ask them to think out loud as they navigated the app by pressing or swiping the paper cutouts of my wireframes. I played the part of the very slow computer, and once a participant pressed a button, I would put the next paper “screen” in front of them until they felt they had completed the task given to them. With recorded feedback from testing, I could choose the issues I wanted to pursue in the next iteration, and ignore comments I felt were really edge cases.
- Held an in-class critique. In class, typically the students would get 10 minutes each to lead a critique of their work, with questions to focus the comments. We would capture the comments and then, as with user testing, decide which issues to pursue.
And then repeat.
Through the iterations, I saw 2 main changes in my work. One was the expansion of the app to include more and more necessary capabilities for people using the app in different situations. The other was the increasing level of visual fidelity.
As I mentioned, I wanted the app to be simple—much simpler than the current real-world product. Starting from my own experience as a bus rider, I pared the app down to what I felt was the minimum viable product. Through user testing, I was exposed to a variety of people who needed the app for different tasks or who had different preferences for how information was presented. For example, I wanted to avoid using maps, but many people need them to feel oriented. This made it necessary to expand the app to include many capabilities. Additionally, no individual screen should have too many capabilities on it, or it becomes confusing. The combination of these factors led me to expand the app. While it is less simple in terms of the number of screens, my app became simpler to use for the rider. Below are excerpts from the 8-week evolution of my wireframes. I have indicated the focus for the week on each iteration, some problems found, as well as fixes that increase fidelity at each pass.
Wireframes by Week:
Focus: At week 2, after spending week 1 on concept maps, I made my first ever wireframes. Using my concept map, I focused on the payment method first. The existing app has a use-ticket capability. When you use a ticket on the bus, an animated screen shows up on your phone that you simply show the driver. Some drivers will make you tap the screen so it turns from blue to red. I suppose that’s to verify that it’s not counterfeit. However, there’s no scan mechanism or anything on the bus to show when a person uses the ticket, or on what bus. My idea was to put a barcode on the ticket machine receiver each bus, and then use the app as a scanner to scan the barcode. This way, the cost of the ride could be deducted from a rider’s account and CapMetro could capture information on use of the ticket.
Because it’s cheaper to buy longer-duration passes (eg, 7-day pass versus a day pass), I created a “punch card” system on this first iteration. If you rode a certain number or times, your next ride would be free. This was visually very confusing for everyone.
Issues: The punch card system was too confusing. The barcode system was generally well-received, although the technology is not really good enough yet to make it a convenient solution (imagine standing at the front of the bus and the app won’t scan).
Fidelity: Very low. It was more important at this point to start thinking of the app as a system than as a beautiful artifact. Even with low fidelity, user testing was successful in rooting out issues with the design.
Focus: The use-ticket capability necessitates an “account” for the rider to which he or she can add money.
Issues: Typing in the amount a rider wishes to add is a little awkward, and invites mistakes such as accidentally typing in a symbol instead of a number.
Fidelity: Very low. The imperative for this iteration was to flesh out several flows, and so I ended up with a greater quantity of screens, but not better quality screens. Since this was iteration 2, I was ok with that decision.
Focus: I moved away from the ticket flow and concentrated on building out the “find a ride” flow. How would riders find buses and select the right route for them? Additionally, I increased the fidelity to make clickable elements more explicit. In prior user testing, the flat, low-fidelity style sometimes confused people as to what they could push.
Issues: I had resisted using maps, and at this point through critique and testing I found that maps were important to people.
Fidelity: Low. I experimented with putting gradients on buttons which is not pretty, but it did help clarify usage in user testing.
(No iteration, it was Thanksgiving!)
Focus: Increase fidelity and rethink the “find a ride” flow. In this iteration, I added maps that took up the whole screen and took out the screen with numbered steps. Instead, each step of the ride could be seen on the map. Again, this made more screens for me to create, but was easier for users to understand in testing.
Issues: I focused on the “find a ride” flow at the expense of the “account” section. Users found the account section confusing, leading me to concentrate on it in the next iteration.
Fidelity: Medium. With the help of my classmates and an in-class guest, I was able to make this look a little more like a real app.
Focus: The account section. Instead of making the user go through the “My Information” screen to get to “Fare Balance” and “Payment Methods” I separated the 3 flows out once a user hit “Account” on the home screen.
Issues: The overlay confirming that a user’s account has been updated only covered part of the screen, leading to user confusion over which “Done” button to hit.
Focus: I needed to increase fidelity so it looks like a real app. This week, I made minor changes to the account section and spent some time trying to make just one screen high fidelity.
Issues: At this point, much of the app has been built out, but there are still several circumstances that are unaccounted for. I decided it would be useful to go back to thinking up scenarios—or little stories about how users would need to use the app, in order to fill in those gaps. When I revisit this project as a portfolio piece, I will start with scenarios to make sure my system is comprehensive.
Fidelity: Medium and Medium-high.
In revisiting this project at a later date, my goals are to continue building my capacity for systems-thinking. Focusing on different parts of the app to smooth out issues is fine, but the app must work as a whole and every possible screen must be accounted for. Additionally, I would like to continue building my graphic design skills so that I can create high-fidelity wireframes and other deliverables.
The complete set of this week’s wireframes can be seen below. Thanks for following us through the last 8 weeks of iterations!