Blueprint Mobile Banking App
I created a new native iOS app for our customers to manage their loans and payments via the app. Customers had a need for a dedicated place to manage their account without all the marketing of the website, and the business had goals to reduce charge-offs and calls to customer service. So we set out to please everyone.
I created a new native iOS app for our customers to manage their loans and payments via the app. Customers had a need for a dedicated place to manage their account without all the marketing of the website, and the business had goals to reduce charge-offs and calls to customer service. So we set out to please everyone.
I created a new native iOS app for our customers to manage their loans and payments via the app. Customers had a need for a dedicated place to manage their account without all the marketing of the website, and the business had goals to reduce charge-offs and calls to customer service. So we set out to please everyone.
I created a new native iOS app for our customers to manage their loans and payments via the app. Customers had a need for a dedicated place to manage their account without all the marketing of the website, and the business had goals to reduce charge-offs and calls to customer service. So we set out to please everyone.
The Final Results
Final Results
The Final Results
Results
Results
Results
Start at the End
Start at the End
Start at the End
Start at the End
One quick note before we begin: The actual app that exists in the real world is not called Blueprint. It could be any bank you've interacted with, as the project's goal was to sell to any of our banking partners as a stand-alone application they could use. It was specifically designed for one banking partner, with specific needs, and then expanded to cover wide-ranging needs, scenarios, and edge cases.
I would consider the project a success, and also a learning experience (more on that in my conclusion). But overall, I was able to address the business goals and still create a good experience for our customers. I was also able to come up with a roadmap of future iterations and features that would be crucial to recuperating our initial investment by making this a product we could sell to our existing and future banking partners.
One quick note before we begin: The actual app that exists in the real world is not called Blueprint. It could be any bank you've interacted with, as the project's goal was to sell to any of our banking partners as a stand-alone application they could use. It was specifically designed for one banking partner, with specific needs, and then expanded to cover wide-ranging needs, scenarios, and edge cases.
I would consider the project a success, and also a learning experience (more on that in my conclusion). But overall, I was able to address the business goals and still create a good experience for our customers. I was also able to come up with a roadmap of future iterations and features that would be crucial to recuperating our initial investment by making this a product we could sell to our existing and future banking partners.
One quick note before we begin: The actual app that exists in the real world is not called Blueprint. It could be any bank you've interacted with, as the project's goal was to sell to any of our banking partners as a stand-alone application they could use. It was specifically designed for one banking partner, with specific needs, and then expanded to cover wide-ranging needs, scenarios, and edge cases.
I would consider the project a success, and also a learning experience (more on that in my conclusion). But overall, I was able to address the business goals and still create a good experience for our customers. I was also able to come up with a roadmap of future iterations and features that would be crucial to recuperating our initial investment by making this a product we could sell to our existing and future banking partners.
Notable Outcomes for the Business
Notable Outcomes for the Business
Over 1,500 Customers onboarded in the first week
18% decline in late or missed payments quarter-over-quarter
12% fewer calls to Customer Care flagged as website issues
Over 1,500 Customers onboarded in the first week
18% decline in late or missed payments quarter-over-quarter
12% fewer calls to Customer Care flagged as website issues
Over 1,500 Customers onboarded in the first week
18% decline in late or missed payments quarter-over-quarter
12% fewer calls to Customer Care flagged as website issues
Identified Priorities for MVP
Identified Priorities for MVP
Sign In (no sign up because customers already exist)
Connecting Bank Accounts
Cash Advance and Withdraws
Schedule/View Payments and AutoPay
Account settings, Personal Info, etc.
Sign In (no sign up because customers already exist)
Connecting Bank Accounts
Cash Advance and Withdraws
Schedule/View Payments and AutoPay
Account settings, Personal Info, etc.
Sign In (no sign up because customers already exist)
Connecting Bank Accounts
Cash Advance and Withdraws
Schedule/View Payments and AutoPay
Account settings, Personal Info, etc.
Introduction
Introduction
Introduction
Project Background
Background
Project Background
A bit of background. This company is a credit and lending institution with three products. Each product has its own brand, own domain, and is not under a common umbrella like you’d find somewhere like Discover. This app was intended to be designed and launched for one of those loan products first, but would also be the foundation for the other products. So, whatever we designed would need to work (with minor changes) for all three different products: two loan products, and one credit card. There are nuances between each of the products that I would have to customize for, but many of the features would be consistent across all products. And we wanted to focus on those for our MVP.
A bit of background. This company is a credit and lending institution with three products. Each product has its own brand, own domain, and is not under a common umbrella like you’d find somewhere like Discover. This app was intended to be designed and launched for one of those loan products first, but would also be the foundation for the other products. So, whatever we designed would need to work (with minor changes) for all three different products: two loan products, and one credit card. There are nuances between each of the products that I would have to customize for, but many of the features would be consistent across all products. And we wanted to focus on those for our MVP.
A bit of background. This company is a credit and lending institution with three products. Each product has its own brand, own domain, and is not under a common umbrella like you’d find somewhere like Discover. This app was intended to be designed and launched for one of those loan products first, but would also be the foundation for the other products. So, whatever we designed would need to work (with minor changes) for all three different products: two loan products, and one credit card. There are nuances between each of the products that I would have to customize for, but many of the features would be consistent across all products. And we wanted to focus on those for our MVP.
Working With Limited Data
Working With Limited Data
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
A Short Research Summary
Summary
Research Summary
Research Summary
Research
Research
Research
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
One of the issues we anticipated was that we didn’t have analytics data on our customer accounts. We had it on our public-facing marketing pages, but once you log in, we can’t see what you’re doing. So we had just to just do everything ourselves and make some hypotheses about what our customers are doing.
I sat down with the PM and we set priorities and expectations for the project into phases. What will MVP be that will meet the basic needs of customers? What are expectations that can be added post-launch? What amount of time will the dev team need to build and test the product? It was a lot of give and take trying to find the right balance of features we could — and should — launch with.
Initial Design Work
Design
Initial Design Work
Progress
Progress
Progress
Yes, I did low-fidelity design work, user flows, and task mapping. I feel like it’s a given that we do this when trying to solve the problem. Especially at the level of Lead Designer. I thought about skipping it but it still feels important to show for some reason. Probably because of everyone’s general anxiety around portfolios?
I started with simply exploring our own site on mobile and trying to achieve high level tasks, including multiple tasks in the same session (withdraw, transfer, add a new bank, set up a new direct deposit, and pay a bill).
I then mapped out how we may be able to perform those tasks in fewer clicks
I then did some quick sketches of what these steps might look like and how some of the functionality might play out in a real environment
I made notes along the way of feedback or ideas needing additional explanation. We then went on to use the sketches to start mocking up the designs.
Yes, I did low-fidelity design work, user flows, and task mapping. I feel like it’s a given that we do this when trying to solve the problem. Especially at the level of Lead Designer. I thought about skipping it but it still feels important to show for some reason. Probably because of everyone’s general anxiety around portfolios?
I started with simply exploring our own site on mobile and trying to achieve high level tasks, including multiple tasks in the same session (withdraw, transfer, add a new bank, set up a new direct deposit, and pay a bill).
I then mapped out how we may be able to perform those tasks in fewer clicks
I then did some quick sketches of what these steps might look like and how some of the functionality might play out in a real environment
I made notes along the way of feedback or ideas needing additional explanation. We then went on to use the sketches to start mocking up the designs.
Yes, I did low-fidelity design work, user flows, and task mapping. I feel like it’s a given that we do this when trying to solve the problem. Especially at the level of Lead Designer. I thought about skipping it but it still feels important to show for some reason. Probably because of everyone’s general anxiety around portfolios?
I started with simply exploring our own site on mobile and trying to achieve high level tasks, including multiple tasks in the same session (withdraw, transfer, add a new bank, set up a new direct deposit, and pay a bill).
I then mapped out how we may be able to perform those tasks in fewer clicks
I then did some quick sketches of what these steps might look like and how some of the functionality might play out in a real environment
I made notes along the way of feedback or ideas needing additional explanation. We then went on to use the sketches to start mocking up the designs.
Final Product
Final Product
Final Product
Launching the MVP
Launching
Launching MVP
Launching MVP
I did some wireframing, but not a lot. Mostly because I already had a well-established Design System and a robust Component Library that I could pull from. For most of the mockups I was able to jump right into high-fidelity layouts for all of the screens. Which is wonderful when you’re working on such tight deadlines.
Here’s a handful of screenshots:
I did some wireframing, but not a lot. Mostly because I already had a well-established Design System and a robust Component Library that I could pull from. For most of the mockups I was able to jump right into high-fidelity layouts for all of the screens. Which is wonderful when you’re working on such tight deadlines.
Here’s a handful of screenshots:
I did some wireframing, but not a lot. Mostly because I already had a well-established Design System and a robust Component Library that I could pull from. For most of the mockups I was able to jump right into high-fidelity layouts for all of the screens. Which is wonderful when you’re working on such tight deadlines.
Here’s a handful of screenshots:
Obviously what’s up there was the final version, but we went through a handful of iterations as all things do. I had a habit of testing frequently during ideation by having non-product employees run through prototypes with me and providing feedback. Many compared what we were building with other apps they were already using and used to. As we were approaching the final stretch we did a small moderated test with 5 users over Zoom on User Testing. The files were handed off after a meeting to coordinate with the Product and Engineering Teams. Notes were made, documentation was written, key stakeholders were kept up on the progress during Sprint Demos.
Obviously what’s up there was the final version, but we went through a handful of iterations as all things do. I had a habit of testing frequently during ideation by having non-product employees run through prototypes with me and providing feedback. Many compared what we were building with other apps they were already using and used to. As we were approaching the final stretch we did a small moderated test with 5 users over Zoom on User Testing. The files were handed off after a meeting to coordinate with the Product and Engineering Teams. Notes were made, documentation was written, key stakeholders were kept up on the progress during Sprint Demos.
Obviously what’s up there was the final version, but we went through a handful of iterations as all things do. I had a habit of testing frequently during ideation by having non-product employees run through prototypes with me and providing feedback. Many compared what we were building with other apps they were already using and used to. As we were approaching the final stretch we did a small moderated test with 5 users over Zoom on User Testing. The files were handed off after a meeting to coordinate with the Product and Engineering Teams. Notes were made, documentation was written, key stakeholders were kept up on the progress during Sprint Demos.
Lessons Learned
Lessons
Lessons Learned
Conclusion
Conclusion
Conclusion
So, what did I learn from this? First, trying to design one app for three very different products was more challenging that I had expected. While some features would be consistent — login flows, making a payment, Menus, etc. — others are very different. A Line of Credit and a Credit Card serve two very different purposes, and their apps have very different functions. We learned that “serves as the foundation of” doesn’t mean you can use most of the codebase. We ultimately will have to create different apps to serve the needs of those brands.
So, what did I learn from this? First, trying to design one app for three very different products was more challenging that I had expected. While some features would be consistent — login flows, making a payment, Menus, etc. — others are very different. A Line of Credit and a Credit Card serve two very different purposes, and their apps have very different functions. We learned that “serves as the foundation of” doesn’t mean you can use most of the codebase. We ultimately will have to create different apps to serve the needs of those brands.
So, what did I learn from this? First, trying to design one app for three very different products was more challenging that I had expected. While some features would be consistent — login flows, making a payment, Menus, etc. — others are very different. A Line of Credit and a Credit Card serve two very different purposes, and their apps have very different functions. We learned that “serves as the foundation of” doesn’t mean you can use most of the codebase. We ultimately will have to create different apps to serve the needs of those brands.
Future Roadmap
Even before we started this MVP, we had identified features that would be beneficial to customers, but ultimately wouldn’t make it into MVP. We also identified a few features that would be new for our customers, such as using mobile pay to purchase items directly from your available balance. A lot of these features require more than just design support though. Features like mobile pay are going to require investment and updates to our enterprise architecture to allow for them. So, for now, I’m focusing on building out features we can currently support, while having discussions around future additions to keep the momentum going.
Even before we started this MVP, we had identified features that would be beneficial to customers, but ultimately wouldn’t make it into MVP. We also identified a few features that would be new for our customers, such as using mobile pay to purchase items directly from your available balance. A lot of these features require more than just design support though. Features like mobile pay are going to require investment and updates to our enterprise architecture to allow for them. So, for now, I’m focusing on building out features we can currently support, while having discussions around future additions to keep the momentum going.
Even before we started this MVP, we had identified features that would be beneficial to customers, but ultimately wouldn’t make it into MVP. We also identified a few features that would be new for our customers, such as using mobile pay to purchase items directly from your available balance. A lot of these features require more than just design support though. Features like mobile pay are going to require investment and updates to our enterprise architecture to allow for them. So, for now, I’m focusing on building out features we can currently support, while having discussions around future additions to keep the momentum going.
