A Transparent banking application

Timeline: 7 Months
Roles: Lead of Human Factors Design, UX Design, Visual Design, UX Research
Team: 4 Designers, Engineering team Client
Tools: Sketch, Axure, Framer, Marvel, Photoshop, Illustrator, After Effects, InDesign


Our client, Exictos, tasked us to find ways that would help them to improve and adapt the way their customers interact with the products. Through research, we found that many of users' problems with banks come from banks being opaque, or not giving their users insight into what was happening with their money inside the bank. This opaqueness creates a lack of trust in the bank and more skepticism when dealing with their bank.


Our final product is called Echo, a mobile banking application that gives users clarity into their financial activity and actions. The application features three main sections: transactions, goals, and simulator. We took several design principles into consideration when coming up with our final solution: being a transparent app (letting users know what is happening), empowering users with the choices they make, and giving foresight, or predictions, into their future spending patterns. As the content strategy and human factors design lead, my job was to ensure that our application created value and was easy for our users to understand.

You can find comprehensive details about research and design process by looking at our process book.

Understanding our Market:

Exictos, a banking software leader in the Lusophone (Portuguese-speaking) countries, asked our team to create a contextually-aware consumer banking experience. Exictos valued a solution that could be easily adapted to the many different types of markets and users they serve. In order to guide our research, we created six core questions that we answered using a variety of research methodologies. 

What is already known about the banking market?
Literature Review & Market Study

We examined existing academic and business research information on spending habits, technology use, creation of financial services, and contextually-aware systems.

What are our competitors doing?
Competitive Analysis

We looked at 4 different markets:
Traditional banks: standard banks like BBVA, Santander, or Chase Bank.
Distant banking competitors: services that relate to money but do not operate as a bank.
Layers over banks: look like a bank to consumers but rely on partner banks.
Contextually-aware services: 
products/companies that work with contextual-awareness.

How do our users currently live? 
Photo Diary Study

Using specific prompts for our photo diary study, we were given another perspective into understanding how money is used and perceived by our potential users. This research method was primarily employed to build empathy with our users.  

What do users think about money?
Interviews & User Study

We had one-on-one conversations with users of consumer banking apps to help us understand their thoughts on banking: their desires, goals, frustrations, worries, and how they use money.

What do users already use and have? 
Survey & User Study

We created questionnaires that asked participants about different factors of their life, from technology usage, to banking habits, to online activities.

How do we define Context?
Concept Mapping

Through creating a concept web for context, we were able to see the relationship between concepts, objects, and people and what role money plays in daily life.

Research insights:

Lack of trust in banks and online merchants

Users strongly distrust banks and fetheir intentions, often taking steps to obfuscate their purchasing habits, especially online purchases.

Well-designed, mobile first

More than half of the Portuguese community use a mobile banking application, and much of the banking industry lacks a well-designed mobile application.

High degree of personal control

Users make conscious decisions for how they will pay for things, taking control of their money use. Users often have, or choose to go through multiple steps in order to achieve their goals.

Banks fail their customers

Banks are not providing services in a way that pleases their users. When customers have problems, they are unlikely to contact the bank about it. Instead, users get frustrated and begin looking for new banks. This is especially true when banks charge unknown “maintenance fees”. Without adequate communication, users wonder what these fees are for and suspect that the banks just want to take their money.

Difficulty of banking services

When users want to know where their money is, they track and budget their expenses. Excel and mental-tracking were the most popular forms of estimating budgets.

Forming our Vision:

In order to create a transparent consumer banking application, we compiled a four part vision that works to empower users to truly understand their finances.

v - categorized spending.jpg

Automatic Categorization
Automatically categorizing costs greatly simplifies the work customers have to do to understand their finances. When users make purchases, they shouldn’t have to wait for a bank statement or try to read lines of transactions nor should they have to create their own spreadsheets.

v - rent-buy.jpg

Simulate the Future
Users should be able to know what will happen to their finances if they take certain actions in the future. This gives users
 the context needed to understand complex financial questions and make the decisions that best suit their needs.

v - lunch.jpg

Anticipating Expenditures
By anticipating expenditures users can keep track of personal spending habits. Using spending data, the app can show patterns users might miss. For example, if a user eats out for lunch every day, their banking app could show them upcoming expected lunch transactions.

v - prioritizing goals.jpg

Goals Prioritization
By explicitly outlining goals, banks and their customers can work together to meet the user's end goals. Through this process, banks become more of a partner to users, rather than something that just holds money.

DESIGN & Prototyping PROCESS:

As the Human Factors Design Lead, it was my responsibility to help guide design sessions, give feedback and advice to other team members, make design decisions, and create prototypes. With our visions, we started designing and building prototypes using the Sprint process outlined by Jake Knapp, John Zeratsky, and Brandon Kowitz. Each of these sprints involved a week of doing different types of research and design methodology each day. These methods included performing Complementary Research, Sketching, Storyboarding, Prototyping, and User Testing

Complementary Research

During the first part of our sprints we define the goals we are trying to accomplish. We then come up with questions that pertain to these goals. Next, we create a high-level service blueprint for how the product would work. Finally, we interview experts, like bankers or accountants, who have expert level knowledge and insights into the area and receive feedback on the plausibility of our designs.


We explored interactions of other similar products and services for inspiration. We use four different types of sketching exercises that results in four unique design directions (one from each member of the team).  We explored interactions that best fit the problem users were trying to solve and giving them as much information as possible. 


After creating our sketches, we critiqued them, identifying which elements that work well and ones that don't. After the critique, we created storyboards to prepare for our mid-fidelity prototype. During the storyboards, we focused on creating flows that required the least amount of effort from our users.


From our storyboards, we build a mid-fidelity prototype for each design sprint. We used Axure as our main design tool and put it into Marvel for our user testing. We implement the prototypes in detail so we can answer the questions we came up with on day one of the sprint. 

These are our prototypes in the order we created them in, click on an image to see the prototype.

User Testing

We finished our weekly sprints by user testing 4-5 users per vision. This allowed us to gain insights on how to better improve our banking app. Joel, our research lead, performed the study while the rest of us sit in a separate room and watch the study via Google Hangouts, and take notes. We then summarize our findings and how we could improve upon our designs. Overall, users found a large amount of value in our prototypes, which validated our concepts and design directions.

Forming a cohesive product:

After validating our designs, we set to work on creating a cohesive product. We laid out the information architecture of how the application and built a medium-fidelity prototype that included the combined elements of our previous work. Through continuous iterations, critiques, and user testing sessions we removed and modified several aspects of our designs that felt out of place and improved clarity and functionality of the application. As a result of this long iterative cycle, we were able to create a solution well-fitted to solving the problems users had. 


Our product, Echo, is a transparent mobile banking application which features three main parts: transactions, goals, and simulator. These different applications work together to solve the many issues users have with their finances providing them with easy to understand information. 

If you would like to view comprehensive details about Echo, please look at our process book here.


We designed the transaction to give users a clear understanding of their spending habits and patterns. To be able to truly understand their transaction history, we created a way to let users focus in on a single transaction’s insights while also being able to focus on the ability to see their total spendings categorized. By categorizing transactions, we are able to give users an informative, cohesive picture of their spending history. We take the information we gained from categorizing and display it in ways that helps users truly understand where their money is spent.


We created the goals section to help our users to be able to easily reach their financial goals in life. We do this by creating virtual accounts that the money moves into on a daily basis. How much is saved over time for the goal is shown in days, which gives users a better understanding of the impact of the goal on their finances. 


Many financial situations are complex and do not exist in a vacuum. Simulator is designed to empower users with the knowledge they need to understand which financial options are available to them, and which ones best fit their needs. Simulator allows users to follow and understand the ever-changing financial environment they live in and how it might affect them.

search, profile, and onboarding:

When designing our product, we included additional features that were also important for the final application to include to meet all the goals a banking application should be able to provide. I took the initiative to help create a fuzzy search system, helping users find what they're looking effectively and efficiently.  

Conclusion & Prototypes:

Below are our prototypes built in Marvel and Framer. The Marvel prototype focuses on the visual design of the application while the Framer prototype focuses on the interaction design of the application. 

Our final product is the culmination of eight months of research, visions, designs, prototypes, and iterations in the Portuguese market. Through extensive testing, we have hard evidence that our solution solves a very real problem in the Portuguese community and brings value to users. By bringing more value to users, this in turn helps Exictos’ clients retain their users as well as grow their base.

By focusing on transparency, we resolve many of the issues users have with their banks, returning trust to the bank-client relationship. We empower users to truly understand their financial actions in the past, present, and future. These designs will drastically improve the way users interact with their bank.

If you would like to view comprehensive details about our process, please look at our process book here.