Testing UI Hypotheses in the Field: Wells Fargo Mobile App Redesign
When Chrissy first assigned us this user testing project she told us to block out hour-long chunks of time with participants to go through the scenario flows of our banking app redesigns. I have six flows and couldn’t imagine why in the world it would take a whole hour to do these simple tasks. I was VERY wrong. On average it took me 60 minutes to get through half of my workflows. It’s surprising how value can be assigned to almost anything when it is being investigated. Users seem to put a lot more thought into simple digital actions when they see how it relates to their everyday interactions with technology. And they aren’t shy to spend an hour talking about it.
In testing my research hypotheses I came across some consistent pain points and several takeaways. I will focus on 2 in this post.
- Language Matters.
- Users should be able to make the decisions they want to as early as possible during a flow.
Language should always infer the action that can be taken by performing a task. This becomes difficult when you are using a noun not a verb. Several users brought to my attention the vagueness of “Payee Contact.” As a researcher I could only ask “what do you think it means?” Without breaking character I was able to glean some missteps and misuse of words. In the above case I wanted that form to indicate that you could search your phone contacts as payees.
A user shouldn’t have to stray far from the origin of their task before they feel like they’ve made the core decisions they need to make in that task. This should inform the flow and develop a hierarchy of what order processes should be taken. If the designer fails to do this, the user can become lost and uncertain, as well as feel surprised that something important comes up so late in the process.
On several occasions I made this mistake.
Bank app users should:
- Be able to indicate early in a transfer flow whether the money will be transferred between their own accounts or elsewhere.
- When paying a friend the user should be able to indicate early on if they are requesting or paying money (something I failed to do if the user is requesting money).
- When paying a new bill the user should be able to choose early on whether it is a one-time payment or a payment they wish to schedule in the future and have a recurring system for the bill.
One of my hypotheses was that I could eliminate nesting options and drop downs by using simple and bold iconography. In particular I was inspired by the ANZ banking app’s transfer interface. However I found a lot of users confused by the visuals and I’ve gone through some iterating below and going forward I will be looking for continued feedback as I develop this feature.
Original Transfer Flow:
Transfer Revised Flow: