Bank App Part III: User Testing, Feedback and Recommendations
Last week, I had presented an initial Bank App Concept. This concept was a redesign based on my personal preference. Four guests were then invited to on see our work and provide feedback to each student. With this feedback, I revised my initial design, digitized the drafts and took my design into the real world for user testing.
Assumptions and New Features
With the second redesign, I baked in a few of my assumptions and features that I wanted to learn from user testing. I set out to discover the following.
- Do users value Touch ID and will always opt-in to make logging in a faster process?
- Does laying our the main banking activities laid out like a buffet make navigating and conducting a task simpler, and faster?
- Is a visual of a user’s debt to ‘money they have’ and how they compare valuable information for the user? How would they respond to that ratio?
- Do icons make finding buttons and links more straightforward to find?
Users I Spoke To
Given the timeline of this project, I knew that I would not get as much of a variety of participants. So I set out to self-description a deeper understanding of what motivated the users’ banking choices. One way I did this was to ask the testing participant to describe themselves by what spirit animal they are, or what magic power do they wish they had and why.
Listening to their response and reason I got a sense of what they value as people. I considered that self-description when I revisited their feedback. What was interesting was how their self description helped explain why certain features caught their attention in a good or bad way, what bothered and excited them about the design, and found the following to be my participant’s banking style and goals. From those, I identified some more universal goals to incorporate into my key takeaways.
What was interesting what some of the contradictions I would hear from the users. There is a fine line to straddle between sufficient communications and ‘intuitive’ design flows. One example was when I chose to make the ‘Remember User ID’ Automatically be enabled when a user would allow “Touch ID.” From a technical perspective, it made complete sense, how else can you log in without a user ID. But this is not what I heard from Leo, who looks for full control of his banking choices. At the same time, I also heard from Leo that having an extra message after completing a deposit was redundant, and felt inefficient.
This contradiction is not because Leo can’t make up his mind, but a clear indicator that what is deemed as good communication, and intuitive user flow is defined differently depending on how the user perceived money and banking.
The need to further communication in around certain features such as password and ID management and less around transaction completion made me hyper-aware that there is a balancing act to be made. I am going forward to the problems identified, and proposed solutions will need to be guided by these takeaways, which were informed by the feedback, user’s banking style and goals.
The people I spoke to had real personal goals including, improving their credit score, getting a mortgage, improving their spending habits. Any goals made around money takes time, patience, and focused intent to achieve. It is unsurprising that people will react so quickly, intensely, and be firm in their resolve when technology behaved unexpectedly. Anything unexpected can be quickly interpreted as an obstacle for them to achieve these goals they set for themselves. Moving forward with my next iteration, I intend to use the data I have on user behavior to guide more of my redesign, as oppose to what ‘feels’ right to me. My job as a designer is not to intuit what people need, but to hear and crafts something based on what people demonstrate to me their needs and desires are.