JP Morgan Chase mobile app: adding a feature
Bootcamp Project
Adding a feature to an existing product
Duration
3 weeks
Role
UX research, UX/UI design
Tools
Google Meet, Figma, FigJam, JP Morgan Chase UI kit
1. Research & Research synthesis
Competitive analysis
User interviews
Personas
2. Prioritization & Roadmapping
HMW & POV
Lo-fi & Mid-fi wireframes
User testing
3. User testing & Iterations
Hi-fi wireframes
Usability testing
Iterations
1-min Overview ⏱️
JP Morgan Chase users run into frustrating experiences when searching for transactions on the mobile app.
Enhancing the system to allow cross-account transaction searches and better recognize transactions under different business names can boost user satisfaction and improve efficiency.
🔎 Research & Insight: Research included competitive analysis and user interviews, revealing a demand for enhanced search functionality.
👩🏻💻 Design & Iteration: The solution involved designing a cross-account transaction search feature, with iterative testing to refine the user interface.
Cross-account search feature integrated with existing UI
Search for transactions by category to find purchase from specific merchants
Keep scrolling for detailed case study ⬇️
1. Research & Research synthesis
Competitive analysis
I compared and contrasted the Chase mobile app against three other banks / fintech company: University of Wisconsin Credit Union, Discover, and PayPal.
.png)
Biggest insight: none of the platforms offer easy, intuitive, cross-account search functionality for transactions
User interviews
I discovered three important user pain points:
Some business names don't match with the vendor names on the statement, so it's hard to look up those transactions.
It is frustrating to have to manually search in each account for a transaction when they don't remember which account it’s specifically from.
Canceled subscription still being charged; if the user wasn’t paying attention to their transactions or if they weren’t notified, all that money could have gone through the crack.
Participant 1
I think searching for transactions is the stupidest thing.
I spent five minutes going through each account and got tired and, ‘nevermind.’
Participant 3
I would love to do a single search on both accounts if the transaction was a while ago.
Participant 2
Because two of the three discovered pain points were about the search transaction functionality, I decided to explore a solution for both of them.
Personas
Based on interview findings, I developed 2 user personas to represent different types of Chase app users to help me empathize with users' needs and kept me focused on them throughout the design process.
2. Prioritizing & Roadmapping
POVs and HMWs
Because this project addresses two pain points, two sets of POV (point of view) and HMW (how might we) are created.
POV: For mobile banking users with multiple accounts, it can be frustrating to look for specific transactions when they don’t remember from which account it originated.
HMW: How might we centralize transaction searching to improve multiple account holders’ search experience?
POV: When searching for transactions by vendor name, users can feel frustrated when the name on the bank statement does not match the known business name.
HMW: How might we allow users to easily find the transaction if the vendor’s known business name does not appear on the statement?
Lo-fi and Mid-fi wireframes
User testing
6 participants were asked to interact with the prototype and
-
Rate how easy it was to search for a Starbucks transaction across all accounts,
-
Comment on the "search for merchant type" functionality when search for exact merchant name failed.
Participants rated the task as 4.5/5 on average!
Very difficult
Effortless
And one participant left a useful insight:
When searching for the exact vendor name fails, the system should suggest more options to improve search. Now the system provides one suggestion, search for vendor type, limiting users to only one alternative.
Next step: Add more recommendations to improve search result if searching for vendor name fails (e.g., search for amount, date, etc), so that users are offered more possibilities to find the transaction.
3. Testing & Iteration
Hi-fi wireframes
I made five screens for two task flows: conducting a single search for a transaction across all accounts, and searching for the merchant type when the exact vendor name generated no results.
.png)
.png)
Usability testing (again!)
The usability test aimed to:
-
Check if users can find and use the cross-account search easily
-
Assess how well users understand the "search for merchant type" feature
-
Identify any navigation or usability issues
-
Gather user feedback and suggestions
Success metrics:
-
For the first task - finding the cross-account search engine - participants should rate it as at least 4 out of 5 on average for easiness.
-
For the second task - searching for merchant type - participants should rate it as at least 4 out of 5 on average for clarity.
Test results
7 people attempted the test: all 7 of them completed the first task, 1 person dropped out before reaching the second task.
First task: Success!
On average, participants rate it as 4.86 out of 5 for easiness.
Very difficult
Effortless
Second task: Success!
On average, participants rate it as 4.08 out of 5 for clarity.
Very ambiguous
Very clear
Even though both success metrics are met, for the second task, 2 participants did question whether users are able to come up with the exact word that matches the merchant type in the database.
For example, in my current prototype, I prefilled “flower” in the search box after searching for the exact vendor name failed. Participants of the usability test wondered whether users are able to come up with “flower” on their own – would using another word produce a failed result again?
With this in mind, I decide to change the terminology: instead of prompting users to search for “merchant type”, which suggests that there is only one correct input, the system would suggest users to search for “keyword”, which is more subjective and allows for a wider range of word choices.
Final design iteration
Even though success metrics of the usability test were met, two participants misunderstood the terminology "merchant type." This means that I needed to come up with a better, more straightforward word instead.
Final design
.png)
Key learnings
-
A deep dive into the world of standard UI practices - I got to flex my design muscles in a way that aligned with what Chase users already know and love. Sticking closely to Chase's design rules, I really practiced working within set guidelines, making sure the new feature I added fit in smoothly for the users. This experience underscored the importance of standard UI practices in maintaining consistency and usability in product design, enriching my skill set as a UX designer.
Next steps
-
Design a tool that helps users manage subscriptions - One common pain point that I learned during user interviews is that users find it taxing to mentally keep track of all the subscriptions they are enrolled in. They find it frustrating when they forget the date of an automatic renewal of a subscription and get charged against their will. If I had more time, I would design a tool that allows users to keep track of all their subscriptions that are paid via Chase, allowing more stress-free management of subscription expenses.
-
Conduct a moderated usability test - Both of my usability tests in this project were unmoderated. While the skill of creating succinct, smooth tests is valuable, I could also gain more qualitative feedback through moderated, face-to-face user tests, such as observing facial expressions and hesitations. For next steps, I would conduct a third usability test via Google Meet to uncover a wider scope of user feedback, further improving the usability of this feature.
Check out my other case studies
.png)
Website for Christ Community Church
