During the past week, I performed user testing with 6 users significantly varying in age and background. Based on the feedback, I’ve updated the wireframes that I created previously, and also updated the navigation concept map I initially created 2 weeks ago.
My user testing included 6 people, in age ranging from 13 to 48. I was lucky to get a teenager — who is a very confident user of a smartphone, but he has never deal with a bank application. It showed me how a person with no previous experience in the industry and with no expectations like “in my usual mobile bank application this function is here and acts that way” deals with the system.
Why 6 users? The research has shown that 5 to 10 users is enough to discover most usability problems; I’m going to be sticking to ~6-8 people at a time to apply the limited amount of time we have in our hands most efficiently, extracting the most value out of it.
As a result of User Testing, I’ve discovered three main problems:
When people were tasked to deposit a check into a CPC Checking Account, first thing they do is they try to tap on that Checking Account from the main screen of the application (which is the “Accounts” tab) – all 6 people did that. One other person has also tried to open Activities to do that.
“I think that normally I can go in there because that’s how… my Wells Fargo works.”
I felt like I was testing the tool and the approach and not necessarily the flow or the scenario of the app usage. People might have considered the task as a hint, and hearing the word “CPC Checking Account” and seeing it on the screen, they immediately tried to tap on it without looking much at anything, even though the task was in depositing a check, and the name of the checking account didn’t really matter.
Either way, I saw that it’s some valuable observation and I decided to have a way to “Move Money” through an Account page. The only difference going to be that the opened account is going to be pre-chosen in the proper fields (“From” for transfers, “To” for check deposit, etc).
It’s worth noting that people were learning really, really fast. On the second assignment, they all knew they needed to tap “Move Money” tab and go from there. For the next User Testing I’ll change the order of tasks and will add other options that are outside of the “Move Money” tab to see if the learning has lasting effect. While I plan on testing it on new users, it might be interesting to see if the same users have remembered what they’re supposed to do.
Many applications are non obvious these days. Snapchat is an extreme example. Applications like Instagram and Facebook has a bottom tab bar (similar to my application) that, from the first try, is not really obvious – you can’t tell what’s behind the options. However, first time you try it, it becomes obvious and not a problem for further use. I feel like it’s the same with the banking app that you use often. I try to stick to iOS conventions to make sure application looks familiar to iOS users, and if there’s something non-obvious, it should not be something that is non-obvious every time. Users should be able to learn it very, very easily.
Getting back to the problem, it can also be simply a visual design problem. The buttons on the bottom aren’t sticking out enough. They are of a regular size for iOS tab bar and are similarly used in hundreds of popular applications, however there can be a way to emphasize it with color and icons, maybe using Chase color styling. Regardless, as mentioned above, having access to “Move Money” from the Account page is still very useful because that’s also how many people think – instead of starting a thought process from the actions, they start thinking from the account they want to perform the action on.
After completing a task, users saw an overlay with “Your transaction is successfully complete” which was, in my prototype, an “exit” back to the homepage (Accounts page). However, it was not obvious for users that they need to tap it. They tried to tap outside of the overlay in free space or on one of the tabs at the bottom or on the “Transfer Money” button again, but not on the overlay as I planned.
“I don’t understand how to get off of this screen… I know I need to go there but how? Yeah, see, that’s obviously… these buttons should always work basically, you should always be able to get through”
Even though some people mentioned that they very like big blue overlay telling them that transaction is successfully complete and found it’s easy to read this overlay as “exit” sign, for most of my participants it wasn’t so obvious. In this iteration I’ll tried to make it is more clear by having a button that simply says “OK”.
On the Calendar screen where you are supposed to click on a date, today’s date is highlighted with blue (and is chosen by default), people still click on it (sometimes multiple times) even though there is no action to be taken and you can just move forward.
“I would expect something like “Today” button here or something like that.”
“That is another thing. I hate when it’s always this “Done” option. Once you clicked a date or clicked under it should just go.”
I realized that “TODAY” is actually such a popular “Date” for any kind of transaction you want to do that it makes sense to just have it default on the transaction information screen, so that people don’t even have to click on it to get to the Calendar screen in the first place. And if they do want to change it then (want to set another date), clicking on dates outside of Today is what they will do and it will be actionable.
Regarding the note that you have to click Done after choosing a date, I think it is still important to have it the way it is, because users may want to “tap around” on the page and having it jump back to the Transfer info page with every tap would be very annoying. I will keep an eye on it in next user testings.
Even though I said there are 3 problems, there are a couple of problems with the testing tool and approach that I used, and not with the application design itself:
When users were going through depositing a check, they did not know what to do. In the prototype, they just needed to click on the Image area that it would just automatically get filled out without really taking a picture (Invision prototyping does not allow taking pictures anyway). But users were wondering: “I don’t have a check, what should I take a picture of?”.
“We just don’t have a physical check that’s why I’m not doing it.”
This seemed like a testing approach problem and an immersion problem. Next user testing, I’ll make sure to have a check prepared with me so that users feel confident they can go through the flow.
I only prototyped the “perfect plan” screen flow. But all screens should ideally be accessible so that users can surf around, get lost, try everything they want to try.
“I know where I need to go I just can’t get there.”
With all preparation and technical issues for all 3 tasks the testing were lasting from 3:04 to 7:29 with an average time of 4:55.
The System Usability Scale (SUS) score has calculated to the following numbers:
- Average: 72.10
- Median: 81.25
One user was exceptionally unhappy with the fact that you couldn’t just surf around like in the real application and the prototype was restricted to the “perfect plan” (and that overall it was a prototype, and not a real functioning application) – my guess is that it was the user who gave an overall very low score, which lowered the Average score significantly. I will work on finding ways to communicate what you can and cannot do with the Invision prototype so that there are no wrong expectations.
Next time I will try include people older than 65 into the user testing to find out how easy the application is for people who aren’t afraid of banking in general, but might not be comfortable specifically with technologies and smartphones.
Lastly, below is the updated concept map that reflects the current application structure, and also includes further expansion and features that are not fully designed yet.
Click to enlarge. Save the photo on your computer to see in full detail.