In this project

Adding notifications to T-Mobile MONEY

Phone users today expect their apps to have notifications that keep them informed about important events or activity. As T-Mobile MONEY crept out of its infancy, notifications were the first thing to add to the fledgling banking app. For it’s first iteration, we were to have just 2 notifications: Debit card spend and Low Balance Alert. I was in charge of initial concepts, testing, and designs.

April 2019 - April 2020

Project team

  • 1 Designer (Me)
  • 1 Product Manager

My responsibilities

  • Primary designer
  • Building and maintaining user flows
  • Storytelling user flows for greater team and partners
  • Designing and maintaining screens and their states
  • Journey mapping new features into simple experiences
  • Integrating with development teams and business analysts
  • User testing to confirm design assumptions
  • Managing user stories in kanban cards

Project problem statement

T-Mobile MONEY customers need to be informed of important account activity and if needed, inquire to learn more if things don't look right.

We focused on the “lock screen” notifications for this portion of the project. Using this problem statement as the jumping point, we wanted to nail a couple of points:

  • Quickly inform the user of important information.
  • Keep the notifications brief, but allow for digging deeper.

What are others doing?

Other apps notifications in dark mode.
Other apps notifications in dark mode.
Other apps notifications in dark mode.

Some takeaways we found from these examples and others:

  • Some lock screen notifications used emojis or even images.
  • Notifications are actionable or informational.
    • For actionable, its important to provide a prompt for the user to take action on.
    • For informational, notifications should provide clear, relevant information in a timely manner.
  • "Force press" on iOS saves the customer time and gives the customer a quick way to get more information on a notification without having to unlock and authenticate into the app.

Using 5 second tests: What information is most important?

I did a few 5-second tests in the office to see which information architecture worked best. We had lots of information we thought was important for the customer, but weren’t sure what was most important. Plus, we didn’t know what order the customer should see the information:

  • What type of transaction occurred?
  • What is my balance now?
  • Where was the money spent or go?
  • When did the transaction occur
  • How did the transaction occur?
Notification reading $90.44 spent, balance now $566.34 at Lowe's Fruitville Pike.
Notification reading Debit card ending 4535 swiped at Starbucks 4PA21, $20.84 spent. Balance is now $894.60.
Notification reading REGAL MOVIE TH 3459, $34.79 spent. Balance is now $674.65.
Each test prioritized something different. The tester would have only 5 seconds to view the screen before the screen turned black.

For this test, I loaded the Axure prototype onto my phone and handed the phone to a co-worker. I asked them to check out this new feature I was working on, but I didn’t tell them much else.

I instructed the tester to press a random word that was shown on the screen. One of the screens above would show, but faded to black after 5 seconds.

At the end of each test, I asked them to tell me what they remembered from the previous screen. I changed the order the tester did them in as well.

Findings

  • The notification with the transaction type first tested best. Customers could quickly understand that money was spent and how much.
  • Having the transaction name in the second line helped the tester glance where the money was spent.
  • We probably don’t need to say "Debit card swiped".

How might we show more information on a notification?

Today’s phone operating systems (OS) give their users multiple ways to interact with their push notifications. Using a long press or “force press”, useful actions become available. Or a long press could open an expanded notification.

We wanted to make sure to use these existing frameworks to keep our notifications clean and usable. I built a realistic iOS lock screen for us to play around in, including the iOS included function buttons.

Spend notification "force press" or "long press"
Low balance "force press" or "long press". Not much customization here, just focus on action.

Getting from the lock screen to the app.

When a user clicks a push notification, a user expects to be brought into the app to see more information pertaining to the notification.

For us, that meant the user had to unlock the phone via biometrics or passcode, then access their account via biometrics or credentials, then get brought to the relevant information. Plus, we had to account for a development restriction that required a 2-5 second load time after logging in as the app gathered their information.

Once they’re in, we had two options:

  1. Bring them to the relevant screen that already exists in the app by automatically opening the pages. Easier development wise. Or,
  2. Show them the information right away on the home screen by creating a new screen that shows the relevant information. More work for development since its a new experience.
A visual representation of the steps required to go from the lock screen to the app.
The first option (top right) reuses what we currently have but it requires extra time for the user to get to the information they’re looking for. The second option keeps the user right on the home screen where they can jump from to learn more if they want to.

Compare the options yourself

Hover over a screen to watch a flow

Option 1, reuse the screens we have and move them along to the relevant screen.
Option 2, create a new "mini modal" that shows on the home screen upon load.

Findings

Not surprising, we went with the simpler option, but that required more development time. It matched our initial plan of getting the customer the information they needed while being able to dig deeper if they wanted to. The other option was jarring and confused the user where they were in the app.

With this prototype, we were able to get a good feel for how the customer will interact with our push notifications and had a working prototype we could test with.

Designing the spend notification modal

One of the nice things about working on a bigger team is that you can find time to explore different options that would normally fall way outside the "MVP" category.

So I was able to spend some time exploring different options for how we may show the transaction after they open the app without having to jump to the transaction.

I came up with a "mini modal" concept that used little screen real estate while allowing for more information if the user wants it.

  • I wanted something small that didn't take up the whole screen to help you keep context.
  • I thought an animation for the changing balance would draw attention to the change in balance, especially if it went negative.
  • I played around with different animations and working the debit card into the experience to drive that it was a debit card transaction.

Here are 4 out of 11 different options I designed. Hover over or click a screen to watch a flow:

Findings

The card animations were a fun little way to bring the transaction back to the card, but it didn't feel like it fit. Especially the bigger card, I thought it was too distracting.

The exploration did open some ideas to how we may organize the mini modal card. We moved forward with a simpler option, but it was good to have these explorations done to come back to in the future if we wanted to spruce up the experience a bit.


How do users interact with push notifications?

We wanted to test the following assumptions:

  1. Users will tap the notification to learn more.
  2. Users will long press if they want to quickly learn more.
  3. Once they are in, they will swipe up on the “mini modal” to learn more.

We conducted 2 in-office tests with some coworkers who weren’t familiar with the project. My colleague ran the first test and I ran the second test. We asked the tester to imagine they just finished checking out at a Starbucks and look at their phone. We handed them my phone and the notification showed on the mock lock screen.

We tested two scenarios:

  1. The first time we told them they spent $20.84 at the coffeeshop (which matched the notification).
  2. The second time we told them they spent $10.42 (which was less than the amount in the notification).

Assumptions answered and outcomes

1. Users will tap the notification to learn more
Yes, they will only if something is very wrong or catches their eye.

2. Users will long press if they want to quickly learn more.
Testers said: “Whats a long press?”, “I didn’t know my phone could do that”. Seems like this feature was unknown to many iOS users. And especially to android users.

3. Once they are in, they will swipe up on the “mini modal” to learn more.
Users actually didn’t swipe up on the mini modal, even though there were some indicators to do so. What we did find is both testers tried tapping on the balance to go to their balance screen.

Unexpected outcome:
When the notification matched the amount they expected, both testers looked at the notification and did not interact with the notification. Even going as far as pressing the “lock” button on my phone to turn the screen off. We expected them to tap the notification regardless but we learned that users probably won’t tap the notification unless there’s a specific action to take or something seems wrong.

Final solution

After initial tests and exploration, we met with T-Mobile to include them in the process. We worked with them on copy and adjusted the IA after their feedback. We were able to use our research and testing to help explain our thinking and reasoning.

We built out the flows to match the latest experience to confirm the business logic and the different use cases.

Using my Axure Toolkit extension, we were able to walk through our flows with the team without losing context.

"Final" user flows

Spend flow

Low balance flow

Tying back to our original goals

  1. Quickly inform the user of important information.
    • Using the findings of the short 5-second tests, we found out what information was most important and,
    • Figured out how much information a person can remember in a short period of time and adjust the copy as needed.
  2. Keep the notifications brief, but allow for digging deeper.
    • Explored getting into the app to understand the time it takes.
    • In our in-office tests told us that a mini modal on the homepage is all they need, with a way to click into more info if needed.
    • Most people actually didn't know about force press, but we explored and accounted for it if we want to support it in the future.