Retail Personas Project

I love personas. I believe every product should begin with a personas, and those personas should be openly shared, updated, displayed and referenced throughout the product’s timeline. Thus I was given the task of updating our retail banking personas - a task that had been brought up as a need time and time again.

For the uninitiated, a persona is “….a fictional, yet realistic, description of a typical or target user of the product” (Nielsen Norman Group). They can be informative and useful wrapped up in a minimal, practical package. When done properly, they represent real data on users, or potential users, thorough a fictional representation. A “character” if you will. Personas are also a chance to build empathy and build the story of your end users in a document that’s easy to read at a glance. Personas can also determine the direction of a product or inform important decisions about that product.

The key is that these personas must be built on real data.

An example of a persona from my personal project “Tome” showing an image of a woman with a quote as well as other relevant data including motivations, personality and frustrations.

What had been accomplished?

In previous research with our clients (financial institutions) a fellow designer had interviewed a number of our clients to dig into who they considered their customers (our end users) and filter those customers into categories.

Out of that research a few customer “types” were discovered

  • Wealthy

  • High Earner Not Rich Yet (H.E.N.R.Y.)

  • Mass Market

  • Underbanked

Wealthy customers managed multiple investment accounts and primarily lived off those accounts. H.E.N.R.Y. customers still worked and made over $70K yearly. Mass Market customers were the largest category as they usually had two (or more) accounts, primarily and checking and savings account, and sometimes had a mortgage account as well. Underbanked customers usually had just a single account and didn’t move money much at all. These customer types were what our clients found valuable when defining their own customers.

Please keep in mind these “types” have no bearing on decisions made by a financial institution and were used only to make product discussions between our clients and ourselves easier to facilitate.

We decided not to create a persona for the Wealthy category as we felt their needs were outliers from the rest of the persona types. Thus we settled on 3 retail customer personas - H.E.N.R.Y., Mass Market and Underbanked.

Where I Pick Up

The first order of business was to research potential users to find how closely they might match with these customer types. Because the previous research had been done only with our customers, and their own assumptions defined these customer types, I wanted to balance those assumptions with the customers themselves to better define these customer types. I also wanted to find out more about where the cut off lay between these categories as Mass Market seemed to blend into the other two categories.

 In order to help gather that data and insights about our audience, I collaborated with our research team to form an interview script to dive deeper into their banking habits and find out more about their experience finding a bank account or loan.

An image showing part of a screener survey that allowed us to accept or reject participants based on our criteria. Questions displayed here show a range of possible answers regarding a new deposit account and a loan account.

I looked for customers who opened a bank or loan account within the last 6 months so the experience would still be fresh in their mind, and divided test participants into three categories based on their income level, number and type of accounts, debt ratio and credit rating. User Interviews allowed us the flexibility to source test participants from all over and we were delighted to find that a number of testers met our criteria, giving us a large pool to draw from.

In the end, 6 test participants were chosen, two participants to represent each customer type. Our script contained 56 questions and ran an hour long. We asked about their experience finding and choosing a financial institution, onboarding experience with a loan provider, experience switching financial institutions (if applicable) and credit cards. The script was the same between each participants for consistency and data comparison.

The results were astounding.

The Experiences

I heard from multiple people who would happily pay more to have better convenience, from someone who struggled to make ends meet while working a full-time job, from someone who had to choose their financial institution based on the walking distance from their residence. Stories from the nurse who considered herself financially savvy but retained tens of thousands in debt, the tech worker who got a loan from her father, the line worker whose only option at times was to use a cash advance loan and who struggled to get our of the predatory cycle it resulted in.

One of the common threads among all test participants was they they chose their financial institution based on familial recommendations. People relied on the advice of their family, or their financially savvy peers, and used that as their starting point when choosing a financial institution. This was especially significant as many of our clients focused on the onboarding process but this data showed that focusing on satisfying and supporting current customers long-term could result in generational relationships.

Organizing the data

Now that I had this data, the next step was to assemble it all into a format that would be easily digestible for everyone from Executives to Product Owners to QA.

A chart showing buckets of data arranged into categories. The categories are color coded to make wireframing a layout easier.

I had core groups of data that I wanted to capture:

  • demographic data

  • financial information

  • financial knowledge

  • onboarding experiences

Putting all this information on a single sheet without overload was no small order. I ended up bucketing all of the data and wireframing the persona sheet to determine a usable layout for all the information. During this step I realized that we also needed a way to capture the emotional data we found in our testing sessions. Finances are very personal and a lot of emotion surrounds the topic. I wanted to highlight that as well so we had a constant reminder of how what we make affects people in a very real way.

A wireframe of a persona sheeting showing a layout of color coded blocks of information.

After designing several wireframes I settled on a layout that worked the best and began to organize the data into that wireframe. At one point I became stuck on how to display the type and amount of accounts a persona has and collaborated with a fellow designer to jump start some new ideas before landing on a word cloud. While I don’t find word clouds generally useful, I felt that this would be the perfect way to show the account types, as we could assign weight to the more common account types found for a particular customer segment.

Naming convention

Another element that stumped me for a while was the customer segment names themselves. The personal stories I discovered through testing got under my skin, and I had trouble connecting those stories with the names given to the groups by the small collection of financial institutions we interviewed. What exactly does “mass market” mean to the father of two in a single family household trying to get a loan to buy a car? What does H.E.N.R.Y mean to the young doctor trying to pay their medical school bills?

Thus, I have these segments subtitles that I hoped better represented these customer segments. Mass Market became “The Everybody”, Underbanked became “The Opportunity” and in the case of the H.E.N.R.Y segment, I simply spelled out the acronym to reduce confusion. I also pulled direct quotes from the interviews that I felt worked well to capture the spirit of each customer segment.

An image of a section of the Underbanked persona showing a quote that reads “I never could be comfortable. No matter how much I had, I knew I had an amount to pay back and I could never think clearly with that on my mind.”

The End Result

In the end, I wrote up descriptions to condense the general findings from the research, and ended up with the following three personas:

Mass Market - “The Everybody”: The Mass Market consumer segment tends to be financially savvy and are aware of fees and charges associated with everything from their savings accounts to a money transfer. They may have a focus on their credit score, making strategic choices to improve their credit. Emphasizing the value they receive with their Financial Institution will ensure a long-term relationship.

The Mass Market persona sheet showing demographics, financial data and onboarding experiences.

H.E.N.R.Y. - “The High Earner Not Rich Yet”: The H.E.N.R.Y. consumer segment values convenience and ease over finding ways to earn incentives or a better rate. When creating onboarding experiences for H.E.N.R.Y., making things simple, doing much of the work for them and spelling out the value you provide will go far in securing their loyalty.

The H.E.N.R.Y. persona sheet showing demographics, financial data and onboarding experiences.

Underbanked - “The Opportunity”: The Underbanked consumer segment is looking for options where few may exist. They have an awareness of their financial situation, and a desire to improve their finances and build credit, but may feel trapped. They seek low minimum requirements and flexibility, and bridging the gap can result in long-term loyalty that grows with their finances.

The Underbanked persona sheet showing demographics, financial data and onboarding experiences.

Once the personas were completed, I presented them to the larger design team and then to the larger organization as a whole to gather support and buy-in. Some really excellent questions and discussion came from those presentations, and I enjoyed sharing more of this effort with executives and decision-makers and it gave them a lot to chew on. One of the questions I received during the larger presentation was what area I felt we weren’t considering enough with our current products and I answered that we need to focus more on supporting our customers long-term because the data showed that the first place customers look to when finding a new financial institution is family and friends. Supporting and satisfying current customers can go a long way to ensure those generational relationships.

An example of an emotional journey taken from the Mass Market persona showing the ups and downs of an onboarding experience.

Final Thoughts

Personas are living documents and should never grow stale. They might need to be updated or retired as time passes and new and more information is discovered.

This was an excellent project to take the lead on, and I am grateful for all the guidance and support I received along the way. This project was mostly hands-off from my manager at the time, and I am grateful for his trust in me. I look forward to more opportunities like this one.

 
 

MY ROLE

As a passion project I worked on in my spare time, I was the sole creator on Tome. Working on research and data collecting, testing, creating wireframes, prototyping, iterating, and UI design allowed me to try my hand at multiple aspects of design, trying new techniques and learning along the way. 

 
 
Early requirements and user stories.

Early requirements and user stories.

Brainstorming content of Inventory screens.

Brainstorming content of Inventory screens.

 

REQUIREMENTS

Requirements for the product were brainstormed in MindNode, then catalogued in Trello and set up as user stories. Everything a user would want in a character management app when into that board. These requirements were gathered from interviews with players, browsing D&D forums, and competitive analysis of other D&D character sheet apps currently on the market.

at the heart of all this research was the player's desire for a lot of information in a way that was readily available.

 
 
Persona for Tome development.

Persona for Tome development.

Journey map detailing friction points and emotional states before Tome.

Journey map detailing friction points and emotional states before Tome.

 

PERSONAS AND EMPATHY MAPPING

A persona was created to represent a possible user, and from there, I created a journey map to identify current pain points when playing a game of D&D and an empathy map to thoroughly understand more about this person. Because of the nature of this app, the persona I created had another person of her own - the character that she would play in D&D, and, in a way, this character took on a persona of her own. Keeping Sarah Cochran (and her character) in mind while designing led to more informed decisions.

 
 
Early navigation exploration sketches and notes.

Early navigation exploration sketches and notes.

 

EARLY NAVIGATION EXPLORATIONS

From early on, I knew that navigation would be a very important decision to make. With so much information available in the app, finding a way to filter the large amount of data to only what the user needed at the time that they need it was going to be a big task. A lot of time was spent exploring navigation methods and ways of displaying information until I was happy. Early prototyping of these navigation methods allowed me to put the "app" into people's hands quickly so I could observe how they moved through the app to find information. This rapid prototyping allowed me to test, observe, and iterate quickly.

 
 
 
Prototype showing sign in screen.

Prototype showing sign in screen.

 
 

PROTOTYPING AND TESTING

Using Invision's prototyping tools, I was able to get a prototype of the app up and running early on in the process. As the designs developed further, I kept the prototype up-to-date, handing it to anyone who would look at it. Taking advantage of the many D&D groups in town, I found people who would be willing to take a few moments to look through the app, and listened carefully to their feedback and desires for features. 

 
 
Example screens of Tome.

Example screens of Tome.

 
 
 
 
 

MY ROLE

My responsibilities included the majority of the UX/UI work, after inheriting it from an outsourcing agency. A beta for the Android version was already in process when I began work on the iOS version of the app. This allowed me the opportunity to address inconsistencies and pain points in the app's design allowed me to create solutions for the iOS version that later were applied to the Android version as well.

 
 
Designs of the Android product at the beginning of my time on the project.

Designs of the Android product at the beginning of my time on the project.

 

REQUIREMENTS

With an Android version already in beta, and core functionality defined, I focused on creating elegant solutions with feature parity in an iOS framework.

 
 
Early sketches for report navigation.

Early sketches for report navigation.

 

RAPID ITERATION

With a tight deadline, ideas had to come fast and be adaptable. With a list of features organized by priority, I began working on paper and in Adobe XD to build wireframes quickly for rapid prototyping. Working closely with the developers allowed me to hone my designs to a core, achievable product.

 
 
Wireframes detailing account creation.

Wireframes detailing account creation.

 

TESTING

Due to a lack of resources, early testing was limited to in-house. I was reliant on minimal analytics from our Android product, and feedback from our support channels. After petitioning passionately, user testing was approved for future releases, following the beta launch of the iOS app. Unfornately, due to this lack of testing, the iOS launch was delayed.

 
 
High fidelity designs for iOS and Android screens.

High fidelity designs for iOS and Android screens.

 

ANDROID PARITY

Despite the delay in the iOS launch, internal feedback was positive - so much so that a plan was created to shift the Android product's design to be more in-line with iOS. As the iOS designer for this project, I was given this task, and was now responsible for both platforms.

 
 
Final product design for iOS.

Final product design for iOS.

 

FINAL PRODUCT

As we approach release candidate 1, we now have a fully implemented app improving the usability of the original Android product with clean and thoughtful designs across both platforms.

 
 
The login screen.

The login screen.

 

My role

For this project, my tasks included initial research into the app requirements, wireframing, user research and interviews, and writing and managing the text inventory. The user research and interviews led to insightful changes to our own assumptions, while the text inventory allowed me to stretch my writing skills and achieve a voice for the app that belied trust and affability. 

 
 
 

Competitive Analysis

The beginning steps included a full competitive analysis of similar apps on the market. Since this was a relatively new product, full reign was given to help determine a feature list, which was presented to the client, who prioritized those features, as well as adding others that were specific to this client.

 
 
TextInventoryExamples.png
 

User Research

We began user research very early on, and created personas that were refined as we began bringing in testers. We found that the most important feature to the users was the Prescription refill, and for many users, that was the feature they were most interested in. Through rigorous prototyping, testing, and iteration, we were able to design features that the client wanted, and that users were excited to use.

 
 
LookbackTesting.png
 

User testing

We used the RITE method for user testing. This involved a quick turnaround of prototype, test, iteration. We tested weekly, with low-fidelity prototypes early on, then high-fidelity prototypes as the visual design was finalized. We experienced first-hand the impact weekly user testing had on the product. A particular requirement - created to increase the security around the app - tested early on as confusing and complex to the user. Since this was a requirement that was crucial to the security of the app, as well as the patient, we knew we could not lose that feature. We had to find a way to make it clear to the user. We designed solutions and were able to test those solutions quickly, allowing us to scrap what did not work and refine what did. At the end of the project, we had created a feature around a requirement that made sense to the user, and was presented appropriately and in a context that made sense.

 
 
Text Inventory Spreadsheet
 

Text Inventory

The decision was made early on to build the text inventory along with the design of the app, and with my background in writing, I was nominated to own that aspect of the product. As wireframes were completed, the text inventory was built up and reviewed by the team for clarity, then tested by users in our weekly testing sessions. Once the app was feature complete for the Release Candidate, I was able to pass along a complete text inventory to the developers for integration into the product. 

 
 
HEBScreens.png
 

Final Product

At launch, we presented a beautiful and fully featured app that (more than) satisfied the client's wishes, and that the users were very excited to use. This was the direct result of thorough research, testing, and iteration.