When our class began the assignment to redesign the CapMetro app (app for the public transportation system in Austin), I think we all wanted to make the app simpler to use. But simplicity means different things to each of us, whether it’s making an app that does just one thing very well or adding different functions to help users. This week I worked through the design again to refine what I mean by simplicity. In this iteration, the overall concept for my version of the CapMetro app centers on 3 sections: “Find a Ride,” “Pay Fare,” and “Account,” with a chat function as an equally important but less-visible component.
After several sessions of feedback, critique, iteration, and user testing, I’ve heard a lot of opinions about what people would like in the app I’m redesigning and not all of it is consistent (which is to be expected). So this week it was time to be selective in what to focus on for this iteration of wireframes. Some things I worked on included the following:
Increase fidelity. Last week, some people missed aspects of the functionality represented in the wireframes because it was hard to tell what was a graphic element and what elements indicated actions.
To address too-low fidelity, I put the screens in a phone silhouette and gave buttons dimensionality. It’s not beautiful, but users can understand what it does. I also tried texture on a screen to indicate a hidden screen underneath. Simplicity isn’t necessarily visual minimalism. In this case it’s more intuitiveness of function.
Rethink the navigation structure. In an effort to make screens as simple as possible, I was creating confusion by hiding sections of the app behind a hamburger menu in iteration 2. Paradoxically, my efforts were making things simpler to look at, but more complicated to use. At this point in iterations, we should be focused on use as much as possible.
I took away the hamburger menu in favor of adding a button to the home screen and adding a global button to “chat” up in the header. The additional button on the home screen still isn’t my favorite solution, but it’s actually simpler to have three buttons and no hidden navigation than two buttons with hidden navigation.
Particularly look at the “Routes” screen, in which users could select which bus to take after entering their starting points and destination. In my previous iteration, low fidelity created confusion around how to use the screen, and the information presented was unclear.
I minimized the information presented on the Routes screen and indicated more information with an arrow. It looks less like a “dial pad” now. I will continue to rework this to get the right amount of information presented when a user gets to this section of the flow.
Think about the payment method. In last week’s user testing, some participants were unfamiliar with the scan functionality I adopted to pay fares. In last week’s in-class critique, it was suggested that since the metaphor was backwards (usually a passenger has a ticket, which can be scanned, rather than the passenger scanning something on the bus) it might be confusing.
This goal will continue into the next iteration. I’m still thinking through the best and most intuitive way to make the scan system work.
For the next iteration, I’ll use feedback from tonight’s in-class critique and outside user testing to continue to simplify the app both visually and in terms of usability. The full set of this week’s wireframes can be seen below (click to view larger).