T-mobile | mobile application

 
 
 

Purpose

T-Mobile wants to give prospective customers a chance to experience their service and eventually make the switch.

Vision

Create a mobile app experience that is so compelling, useful and meaningful that T-Mobile prospect customers download and install on their device and eventually make the carrier switch to T-Mobile.

Experience Goal

What special access can we give to prospects that can create new & different wireless experiences?

my role

Out of 4 designers, 2 were Visual Designers and I was one of 2 UX Designers. i also held roles in content strategy and interaction design.

 
 

Hero flow

 

We created a hero flow that described how the prospective customer experienced and used the free trial run.


wireframes

 

ONBOARDING
At a high level, explain what the benefits are. Allow the user to find the details of the benefits in the next screens. Below that is a teaser to start the trial, and below that are ads and a shopping button and a QR code scan for an in-store experience - all were persistent throughout the trial.

USAGE
The second screen is how it would look like after the user uses some data. We’d welcome the user to the app and update them on how much they have been saving so far. We also included a card for benefits in case the user wants to review them again. The rotating ads, shopping button, and the code scanner were business requirements for users to shop.

SUMMARY
This is what the user sees after the trial is over. They can see the total amount of money they’ve saved, some offers based on their usage pattern, and an incentive to sign up now.

MAKING THE SWITCH
The user has a discussion with a rep about their experience within the app. The rep recommends a plan based on their week’s data usage. The user then accepts the plan through the app and the rep initiates the change of service.

 

usability results

OVERALL
Out of 9 users, they liked the idea of being able to test drive another carrier’s wireless network but they didn’t believe that it was technically feasible.

ONBOARDING (MISSED INFORMATION BY DESIGN)
Here we found that users didn't know they had to scroll…even though there was content peeking below the fold. Maybe we could have given directional UI indicators or a tour of the app with an overlay of step-by-step directions.

USAGE (MID-TRIAL TOUCH POINT)
Users didn't know they had to scroll here either, which is more understandable than the previous example. As for showing how much users saved, what we didn't think about was the fact that some users would have grandfathered plans…so it would be super hard to make this accurate. A better way to do this was to explain this was an estimate of savings based on current average plans and then show a transparent breakdown of that, possibly on the other side of the card.

SUMMARY (END-TRIAL TOUCH POINT)
Users had an issue of accuracy on the savings again. We thought that by showing the amount of data used and how much money was saved that it would equate to the T-mobile service being useful in the user’s eyes…but that opened up the question of whether the person had a grandfathered plan, how much data they currently had with their current carrier, etc. So instead of showing data used, we should show the coverage pattern, which is obviously more valuable for users.

MAKING THE SWITCH (TEXT CHAT WITH SALES REP)
Users liked the ability to text with sales reps. this is something I felt pretty strong about, because I don't like talking on the phone with customer service myself…allowing users to text and if the issue is more complicated, allowing them to call…and the phone operator would have context on the app’s conversation.

MAKING THE SWITCH (COMPLETE SIGN UP USING TEXT MESSAGE)
This screen wasn’t as detailed as it should have been. We should have included visual cues for users to learn more about the plan and an option to sign up or have a follow up later.


LEARNINGS FOR NEXT TIME

Testing sooner
I think the testing happened too far down the line in design, and didn't happen often enough. Having a tighter testing/iterative schedule with wireframes instead of comps would have given us better results, and sooner.