Iterating to awesome: How to do Usability Testing
In this week’s blogpost, I am going to describe my process for iterating on my Navigation and Information Architecture Map and the wireframes for the TD Mobile Banking App. This builds on two previous blog posts; the first was on my process for creating the original concept map and the second was for my process on developing the wireframes.
In this post, I am going to discuss and present:
- Usability testing
- Revising the Navigation and Information Architecture Map
- Revised wireframes
- Next steps
Last week, I developed my wireframes using a process that hinged on imagining a flow through the application that would help well-defined characters achieve a goal. This week, I set out to see if real people could achieve those goals. To do this, I first created a digital prototype using Sketch and a plugin called Craft that links my wireframes to Envision. Then, I went out into the field to find at least five willing participants, primarily in local cafes. Last, I looked back at the data I had accumulated and found the top three design issues that I wanted to revise.
I knew that in order to get feedback on the usability of my application, I would need to present participants with a low fidelity prototype. One recommendation I received was to use a paper prototype. However, I decided to try and learn how to create a digital prototype since I know that people in industry do this. The process was arduous. It made me think more about each step of a user’s flow. Questions like, “What will happen if a user does not fill in a field properly?” or “What sequence of screen would a user most naturally flow?” came up. I also had to learn the idiosyncrasies and limitations of Craft and Envision. I thought that the time spent on this part of the prototype development was worthwhile because I thought that organizing a paper prototype would be overly onerous, especially when working with participants in real time.
Once the digital prototype was developed, I set out into the field to find willing participants. I had six predetermined tasks: checking a balance, transferring funds to an external account, paying a friend, setting up a new alert, paying a bill, and depositing a check. I wrote each of these tasks down on a separate sheet of paper so I could hand them off during the testing session.
I also prepared myself to follow the Think Aloud Protocol. The steps in the protocol involve first, telling the participant what they are about to do and that once testing begins, all I can say is, “Please keep talking.” I tell the participants that I want to hear what they are thinking as they attempt the tasks written on the sheet of paper. The Think Aloud Protocol is based on a theory that people can explain how they solve problems and that though it will slow down task completion, won’t have an impact on potential task completion. As participants will work through the task, I will take notes and record what they say so I have a reference for later synthesis. I also had my participants fill out a SUS score which is their rating of the application flows. My hope is that as I iterate on the wireframes, the score will go up.
A key takeaway from usability testing with a digital product was that a lot of the feedback I got was actually about the limitations of Envision. People got stuck on different screens because Envision is limited in how systematically accurate a user can interact with the product. I also found greater success when users could test the product in its appropriate environment, a mobile phone, and not a desktop computer. I also found that digital prototypes are limiting because they constrain how a user can walk through the application since the sequence is pre-determined. When doing this again, I could of course make a screen and flow for every single way a user can walk through the application, but I think that user a paper prototype may allow for more user control and thus, I can get even better data.
Some key takeaways from my first round of usability testing using the Think Aloud Protocol was that when I write the tasks, I should give users more information about what they may need to enter into each field. I also found that having a setting where I could clearly hear the participant is super important. I sometimes struggled to write good notes because of this. It was also challenging not to step in and help sometimes because Envision made it hard to tap on a field and move to the next screen. I would sometimes end up helping a user because it was just too frustrating for something that didn’t help me get any useful information. Also, after getting feedback from 5 people, I had confirmation that getting many more participants to try the application would not add to the accuracy of what I would learn. I saw patterns emerge already and can imagine that anymore than 10, I would not learn much more.
Of course, I was also able to garner some key issues that I would want to fix in my prototype. They are documented below.
There were two key revisions I made to my concept map. First, I wanted the concept map to reflect the complexity of the application system. My first map was too simple. A future software engineer would have a lot of potential to make up user flows because so many details were missing. So, this necessitated a complete overhaul of my concept map. Second, the concept map would have to reflect the revisions I made to my wireframes.
In order to do a complete overhaul of the map, I started fresh. I went through three paper sketches, getting feedback from classmates on clarity and hierarchy. I made sure that I had different shapes to reflect different kinds of screens and operations. Squares represent places a user goes to. Ovals represent the functions you find in each of the “places”. Circles represent the flows a user takes to accomplish the function. Working through this process made me have a much clearer idea of all of the screens I currently have as well as the screens I still need to develop for a complete application. The feedback I got from my classmates helped me to make a better visual hierarchy. At first I made the ovals a much thicker line weight but this confused my classmates because it made them more important than they should be.
In order to reflect revisions that I made to my screens, my concept map includes a shortcut to get to the main functions a user may want to apply to an account. Also, redoing the concept map made me realize that my I never included a way to logout of the application in the original wireframe set. It also helped me to see what screens I would add a home link to for a user to get to restart faster.
Below are the revised wireframes. First, I highlight the key screens that I revised based on the top 3 problems I chose to revise. Second, I present all of the screens. In addition to the revisions I listed above, I also revised a several other elements. I did these revisions based on what I learned from the critique session in class.
The other revisions were:
- Graying out a button if it should not afford clicking if all required fields are incomplete
- Changing the titles of buttons to more accurately reflect what they do (ie changing “Deposit” to “Another Deposit” on the success screen for deposits) or to be more natural (ie changing “Return Home” to “Home”).
- Adding a logout option on the main menu
Next week, I plan to build out my application according to the concept map. I will also do usability testing. But this time, I want to focus on particular flows and to get feedback on buttons and font.