Usability testing: how I used paper prototyping

This week, I did my second round of usability testing. I revised screens according to what I learned from critique and from testing and then, made my concept map reflect the changes I’d made. If you recall, in last week’s blogpost, I said that I would build out some more of my flows and try testing with a paper prototype instead of a digital one. I met those goals and learned more about how I want to do my testing next time.

In this week’s post, I am going to discuss:

  • Paper prototyping
  • Improving visual design
  • Revising the Navigation and Information Architecture Map
  • Revised wireframes
  • Next steps

Paper prototyping

Last week, I used a digital prototype to do my usability testing. I found that there were some challenges to using this to test. It didn’t always work, often frustrated my participants, and constrained what I could learn because users could only follow the flow as I had set it. Paper prototyping had none of the same challenges.

I found that paper prototyping to be a better way to get the feedback I wanted. I didn’t have to spend much time building the prototype. If I continued using the digital prototyping application, I would have spent hours making new links since my wireframes were revised since the first time I set up the links. This means it’s pretty simple to get out there and get feedback. A significant challenge was managing the paper as my users clicked on each screen.  I was simultaneously shuffling papers around as well as taking notes. However, this really only slowed down the process and didn’t change the data I would have gotten.

Of course, my participants didn’t think the app was real. Whereas when I used the digital prototype, my users thought that they were using a real bank app. But, I do not think that changed the validity of the feedback I got. They may have appeared skeptical at first, but once they began they would tap the paper (or not as sometimes there would be significant wait time as they tried to figure out where to go).

A participant completes a task with a paper prototype
A participant completes a task with a paper prototype

I also only focused in on three flows this week, alerts, paying bills, and adding contacts. I did this to narrow what I would learn. One significant take away was 60% of my participants do not use their banking application for these functions. One even said how novel it was to think that the bank would send notifications.

During critique, I had asked my classmates to give me feedback on visual design.  Therefore, in addition to the revisions I found during testing, I also changed how the wires look. Below are the three main problems I fixed this week.

Test documentation second-01 Test documentation second-02 Test documentation second-03

Improving visual design

Since starting the program at AC4D, I have found visual design challenging. I never had training in graphic design so in addition to all the skills I am practicing, I am trying to learn how to build effective and aesthetically pleasing screens. In order to get better at visual design this week, I took two practical steps. First, I printed screens of other banking apps and then traced on top of them. This helped me to get a sense of size and space. Second, I found more screens and uploaded them to Sketch. I traced them there to gain a greater sense of accuracy when it comes to the sizes and placements of objects on a screen. I used this process to help me redesign many of the screens. I will also have to follow through and continue to redesign screens in future iterations. Below, I have placed the old and the new homescreens side by side.

new vs old

Revising the Navigation and Information Architecture Map

As you saw above when I showed you the top three problems I found during testing, I had to change some of the architecture behind my wireframes. I had to make a new connection between contact information and alerts. I also had to delete and add in functions. I noted how challenging this can be and wondered how I can modify the map more effectively. This week, the changes weren’t significant. I can imagine that changing as I move forward with my iterations. I will have to brainstorm ways to efficiently modify such a large, complex map in the future. Below, you can see my revised map.

Revised Concept Map 2

Revised wireframes

In addition to the above-mentioned revisions, I also changed all of the buttons so they look more realistic. I also changed the top bar so it would include a menu option on every screen and so that the text was consistent and centered. I have included a few individual screens to highlight the changes I have made. Below that, you can see my revised flows as well as the new flows I added this week.

Revised menu screen
Revised menu screen
Revised notifications screen
Revised notifications screen
Revised bill pay menu screen
Revised bill pay menu screen
revised login flow
revised login flow
revised bill pay flow
revised bill pay flow
revised change bill pay flow
revised change bill pay flow
revised check balance screen
revised check balance screen
Revised alerts flow
Revised alerts flow
Revised deposit flow
Revised deposit flow
Revised (plus new) quick pay flow
Revised (plus new) quick pay flow
New settings flow
New settings flow
Revised transfer flow
Revised transfer flow

Next steps

Next week, I want to get feedback on larger systems issues. Do my flows all fit into the same user interaction dynamic. Namely, do my flows feel consistent and part of the same application. I also want to build out more flows. In these past few weeks I have been learning about services other mobile bank applications offer. I wonder how I might integrate some of these into the TD bank mobile application.