Conceptual Banking App
Balancing voice and functionality in a conceptual banking app
My Role
UX Writing and Research
%20(Mockuuups%20Studio).png)
Duration
2 weeks
Tools
Figma
Miro
Metrics used
Time spent within
application
Process
Empathize
-
Reexamining the older design
-
Competitive research
Specify
-
Building the prota- persona
Ideate
-
Lofi Wireframes
Bring to Life
-
Prototype
Verify
-
User testing
-
Post user testing
The Challenge
Based on an older design for a UX writing challenge, the first iteration lacked refinement, research, and testing with the limited time I had. I wanted to investigate financial industry terminology and expectations to help shape the language and interface.
The Goals
-
The first goal was from a business perspective, experimenting with other ideas to have users engage with the product
-
The second was from a user perspective, putting the language through user testing, revealing pain points and opportunities for improvement with the text's relationship with the user and the UI.
Everyone, say hi to Julia. Julia is a prota persona that will be helping with the rest of our journey.
She is 29, has a median income of 55,000 USD per year and has a healthy financial literacy with everyday bills and savings.
The User
Frustrations: Not having enough options to maximize her personal finances.
Goals: Engaging with a platform that has robust options for her personal finances without being overwhelming.
The Original Design
.png)
This design was thrown together quickly, with a larger focus on the language than the UI or a solid understanding of traditional financial applications.
Competitive Research
Note: I couldn't take screenshots of these banking platforms due to their built in safeguards
I did competitive research for tone and UI experience for two banks and one credit union to see how they handled the auto pay experience
Pros: Doesn't require any manual number entry if the user doesn't want to
Cons: Payments are on a fixed date that can't be changed
Click States: 4 taps/clicks to set up and confirm autopay schedule and amount
Pros: Has an a amount limit that user can input if the bill is too high for their liking
Cons: Cluttered interface, confusing language
Click States: 5 taps/clicks to set up and confirm autopay schedule and amount
Pros: Easy interface to change dates, the language in the drop down menu is concise
Cons: There is no clear language to set up auto pay until you get into the "at this time:" drop down menu
Click States: 10 taps/clicks to set up and confirm autopay schedule and amount, with mandatory input fields for the date
New Wireframes
New Design
The redesign happened in the middle, replacing the second screen for three screen states that offered more flexibility around the amount.
if
User Journey
User Testing Parameters
Recruitment
For this app test, I recruited three participants
-
The average age was 33
-
Previous experience with banking/financial platforms for managing day to day expenses
-
average financial literacy, no stock market analysts
-
Metrics
The metric that I used to guide my testing was
-
Time in user flow (my initial estimate was less than 60 seconds)
-
Specifically keeping track of time with regards to the automation screen states
-
Post test questions
My top concerns were on the middle three screen states and the final screen.
-
Was there at any point you wanted some customer support option? Or prompts from the application to guide you?
-
Did you understand the services that were being offered on the final screen?
-
Were there services you would like added or taken away from the final screen?
-
Did you understand how much you were paying each month?
-
At any point did the language feel ambiguous or failed to instruct you?
I had the users follow the user journey I have outlined below
Testing Results
The good:
-
Users enjoyed the interface's simplicity and the language felt supportive and unambiguous at nearly all times
-
The average time was just over a minute
The not so good:
-
There was some confusion over the "do not pay if amount is over ___" input field and if they needed to interact with it
-
One user was wondering if they needed to keep going because the buttons on the last screen seemed like an additional step
-
The "you can change this at any time" language above the confirm button should have been "you can change these settings at any time"
The Bad
-
There was some frustration over the fact that in the drop down menu, it doesn't show you the amounts next to the language so there was some eye's hunting for that information in the next screen state
Conclusion
The best way to help Julia will be more focus on the text language aiding the smaller actions within automatic payment set up. I ended up focusing more on the UI for this project more than anticipated. This ended up being a benefit since I was able to have a deeper understanding of the real estate for the language.