Working Out-Loud Through Design Choices
Over a 7-week period, I am designing the screens and architecture of a mobile banking application to help people confidently manage their finances. I am particularly inspired by designing for recent US immigrants and refugees, and I plan on designing an application to help connect these groups to financial resources, such as Mission Asset Fund and the International Rescue Committee’s loan program. Above this, I aim to design a simple and intuitive application that will help overcome language barriers. By designing with more challenging use cases in mind, my vision is to create an application that will be simple and delightful for a much larger subset of the population.
Last week, I focused on creating the initial touch-points for my application: the landing page and a guide to getting started. Then, I prioritized flows for check deposits and credit history building – two elements I found in my research to be particularly important for people who are new to the United States.
This Week’s Feature Focuses and Testing Approach
This week, I decided to take a step back and develop strong flows for functions that satisfy the primary user goals: logging in, checking your balance, depositing checks, and transferring money between accounts.
Rather than building out the complete toolkit before seeking user feedback, I focused my efforts on the check deposit function, and then I executed three think-out-loud user tests that took my testers through the login and deposit pages.
Think-aloud-testing involves giving the user specific tasks to complete with no additional guidance. Simply and continuously asking the tester to “please keep talking” prompts him or her to express their reactions as they first experience the elements of your design. The method provides unfiltered reactions and highlights disconnects between your intentions and how your design communicates to users.
Think-Out-Loud Testing Findings
My primary takeaways from these think-out-loud usability tests, outlined below, informed my design modifications in my next iteration.
Takeaway 1: Moving seamlessly from one step to another is of paramount importance.
The word choice and visual layout of my deposit screens made sense to my testers, but they weren’t able to get to the next input prompt how they thought they should. The navigation design held them back. This caused my testers to second-guess what the screen was asking of them, and it confused and noticeably frustrated two of them.
One of those testers, Kristen, experienced a significant, negative critical incident when trying to move from her account selection to the deposit amount. I designed the navigation so one would need to tap on the account tab to collapse it before moving on, but all three of my users wanted to be able to tap right into the amount box to move forward.
Not helping Kristen through this 40-second challenge was the most difficult moment of my first round of tests. She looked distressed and nervous that she was failing, and her frantic taps were not moving her anywhere. I reminded her that we were testing the application, not her, and a rush of relief flooded over her – visible in her tone and body language. Yet, it still took some time before she happened upon the solution to her problem. This incident dampened Kristen’s enthusiasm and confidence for the remainder of the usability test. After this, I couldn’t wait to go fix the navigation. This is a simple fix that, left unaddressed, could discourage users into not completing the task and achieving their goal.
Takeaway 2: Only set defaults when there is little-to-no deviation from that default.
Defaults work for prompts like “when do you want your money?” – Most people will want is as soon as possible. When there isn’t an obvious choice, however, the default may obscure the fact that there is a choice to make.
I initially designed the check deposit page to list “Checking” as the default account in which to deposit the check. I wanted to watch my testers explicitly make the “Savings” account selection, so I instructed them to do so with the prompt “ Deposit a $250 check into your savings account.” The account selection was then the third choice the user had to make in the flow, so I assumed it would still be top-of-mind. However, since “Checking” was pre-selected, all three of my testers immediately moved to the second input on the screen: Amount.
Selecting the account in which you would like your funds is a relevant decision for users, and therefore it should be an explicit choice, rather than something users are encouraged to gloss over. This is a straightforward, yet important lesson that I carried forward in my next designs.
Addressing Takeaway 1 and Takeaway 2 with Screen Revisions:
Takeaway 3: Don’t take the “simple” flows like the Login for granted.
All of my tests got off to a rocky start with the unclear login flow. There were a couple navigation steps that should have been more evident, but I failed to address these nuances in the last version, assuming that the flow was so familiar that they would be intuitive enough. This was a great lesson in diligently thinking through each tap someone makes on the screen.
Next Week’s Plan
For my next round of think-out-loud usability testing, I plan on putting together a more comprehensive prototype of the application’s menu items and key flows. This will help me observe how people work through the system and pinpoint pain points in my information architecture.