The challenge

The MetLife mobile app had not received any design love in some time. While the services users expect are available on the app, it's not the streamlined experience it could be.

Between myself and a fellow experience designer at SapientNitro, we had 3 weeks to design and build a prototype covering 3 areas:

• Finding a dentist
• Insurance payments
• Car insurance claims

“While the services users expect are available on the app, it's not the streamlined experience it could be.”

The project was already 4 months underway and, unfortunately, the experience designer before us was unable to stick around due to personal matters. With the project already overextended, we had very little slack for ramp up and exploration. We also weren't left much to work with, so we started from scratch.

Finding a dentist

We focused on just one scenario at a time, taking a day or 2 before reviewing with the client. Coming out of reviews, we'd make updates immediately in an effort to get sign-off as quickly as possible and move on to the next set of flows and wires.

Working so rapidly, we were primarily focused on nailing down the individual scenarios, but still needed a home screen and global navigation for presentation purposes. It's not the holistic approach we'd typically follow, but this also wasn't a typical project. We needed to narrow our focus to the primary ask.

The first week, we focused on the scenario for finding a dentist. This scenario was unique from the others in that it dealt with a mix of public and login-required features. While searching for a dentist does not require login, scheduling an appointment or viewing your insurance information does. After some discussion, we decided that the user would be prompted to login on launch, but could still access certain features without logging in, including search.

Insurance payments

The next scenario we tackled was insurance payments. The challenge with anything transactional tends to be in succinctly informing the user where they are in the process and what happens next. For this scenario specifically, we had 3 paths that needed to be clear and distinct:

• Making a one-time payment
• Setting up auto pay
• Making a one-time payment, with auto pay in play

“The challenge with anything transactional tends to be in succinctly informing the user where they are...and what happens next.”

On its own, making a one-time payment was straightforward. So it was a good place to also illustrate how you might capture bank details used for payment.

Setting up auto pay was slightly more challenging. Early iterations had auto pay and one-time payment as one screen, where an auto pay on/off switch would toggle between the states. We opted instead to make them more clearly distinct screens using primary and secondary buttons, with a horizontal rule separating the two.

Lastly, a third flow shows how a one-time payment might be made while auto pay is turned on. A number of things could happen here and it needs to be transparent to the user what his/her options are. When switching to one-time payment from auto pay, the user is presented an intermediate screen with options and an explanation for each. Depending on the user's selection, the following screen contains messaging to remind the user of his/her selection before making the payment. In this situation, we ran the risk of over-communicating and cluttering the screen, so we tried to keep messaging short while telling the user what he/she needs to know.

“...we ran the risk of over-communicating...so we tried to keep messaging short while telling the user what he/she needs to know.”

Claim status

Our last scenario involved car insurance claims, more specifically, how a claim is completed over a period of time. The user will come to the app to do something, leave, and return at a later point when he/she is notified that new information is available.

The scenario begins with a message from your adjuster, who will provide you a cost estimate with insurance accounted for. We use overlays as a mechanism for time jumping forward or backward in the scenario.

Upon viewing the estimate, you're presented with two paths: paying out or using a preferred body shop. This is another instance where we aimed to craft brief, digestible copy, without losing meaning or clarity. Upon choosing pay out and a payout method, the flow ends.

“...we aimed to craft brief, digestible copy, without losing meaning or clarity.”

When choosing to use a preferred body shop, you're given the option to “find a body shop.” After discussion with the client, we agreed not to explore what this look like as there were other priorities to address. Instead, we time jump to the point where you've already dropped off your car at the body shop and use the app to check on its status. The flow ends when your car is repaired and picked up, the respective parties are paid, and the claim is completed.

Conclusion

Following delivery of the prototype, my role was finished. The project would bring on a visual designer to define styles, and the client would have their product and technology team begin updating the existing MetLife mobile app, using our prototype as a guide for the desired experience.