We continue to make iterations for our mobile banking app wireframes. Much like my last blog post I performed usability testing on complete strangers. This time, however, I tested with five individuals instead of three and I focused mainly on the overall navigation of the interface. Last week, as mentioned in the previous post, I focused on a specific flow: Scheduling a payment.
I felt that in that round of usability testing I scratch the surface of the navigation problems by identifying certain issues regarding poor affordance of certain features and issues with prior experience coming into play. I moved around certain button and considered hiding a few things within the hamburger and decided to hold off on changing more until doing another round of testing.
Usability Testing Round 2
Instead of focusing on the flow of the “Scheduling a Payment” feature, I used that flow to instruct my users to examine each screen they were on in the flow and verbally describe each feature they see. IN this round of usability testing I used my same flow but on each page I would give them short, simple tasks like: locate the menu button, locate the transfer button, locate the amount being paid, locate the “go back” button, etc. These tasks were all listed out on a document and the user was instructed to go through them on each page. They were instructed that they should not move on until they believed they had successfully located each icon or feature correctly as instructed on the page. Through this method I received very rich feedback that was not limited to a distinct flow. Users were highly encouraged to verbally say what they liked or disliked about certain aspects of each page which lead to suggestions and conversations after each test that I ended up implementing into the app’s design.
The Home page is the center of navigation for the app. The app is designed so that the user has access to frequently used features as soon as they open the app. The two things I changed on this screen was the location of the menu button and the name of “Bill Pay” to “Pay/Request.” Many factor came into play in my decision to shift the Menu button to right side of the screen. I decided that because of many struggles like not being able to have a “Go back” icon and a “Menu” icon on the same screen due to the proximity of them, that I would mitigate this worry by simply putting it to the right. I got direct feedback from a user who said, “…my bank has this [the hamburger] on the right side.” This contributed to my decision in part. Afterwards I went to look over many other banking apps and found that many of them, in fact, placed there on the right side of the screen, perhaps for the same reasons.
Bill Pay vs. Pay/Request
A simple but powerful change was completely re-creating the “Bill Pay” page. I received feedback that this page was confusing and many felt that the sections were unnecessary. I decided that I wanted the usability to foster a quick, on the go type flow to it much like Venmo, Cash, and Mint. The feedback I received that many of the sections like, Send Paper Check, Recent Spending, and My Contacts were unhelpful, plus this idea that I wanted it to be quick app resulted in the omission of these pages. I chose to make a screen that provided these simple buttons that give a straightforward navigation to a variety of functions.
“I don’t know what I’m supposed to do here.” One change I decided to implement, because many users found this screen to be confusing, was the initial “Schedule Payment” screen. The screen made people feel they had been dropped into a feature with no direction of where to go. I used this as an opportunity to implement the newly designed top nav bar with the hamburger and top navigations still visible. I also used a tutorial “toast” that appears upon first use in the app that tells the user what they need to do to get started.
A big question that was brought up in our class critique last week was, “Where does the app take you after the “Your Payment Has Been Schedule!” screen? It didn’t make sense to just drop the user back in the “Pay/Request” screen because there was nothing there that showed them what they’ve just done. There is this idea of wanting to re-confirm what they just did. Not many of my users mentioned this but I attribute that to the idea that they were just happy they finished the task. After one of my user tests I ask the user if she had any thoughts about things I left out. She said that, “…is there a place that I can edit this payment?” At the time I said there was, but it was in the original main screen on Bill Pay, now renamed to Pay/Request. I took that feedback and decided combine the screens Schedule Payment and Recent Spending. This simplifies the app and makes it easier for the user to view and edit payments by having it all in one place.
Informational Architecture Map
There were not many changes to the information architecture map, just the ones to my changes in screens. I also omitted “Profile” in the map because the bubbles nested under it were, “Alerts and Notifications,” and “Messages.” I ungroup them and just have the two under the menu drop down. I anticipate more changes to the map after next the round of testing.
I plan to step up my usability testing by recruiting more people. I went from three to five people in these first two rounds and I would like to have up to ten. I am confident in how the navigation is turning out even though I know it needs more work. I will branch out my testing to different flows and try prototyping in a different way to see what that method brings.