Vivint Hub Notifications

Design a user experience around notifications on our wall-mounted hub. Specifically attacking the problem of various home layouts where the device could be installed and leveraging the onboard proximity sensor to enhance the experience.

The notification comes in at a larger size with minimal information. As the user approaches (and is detected by the proximity sensor) the notification shrinks down to its normal size, showing more details and actions if applicable.

I identified three primary scenarios that I would design around for this notification system:

• Near: the user is close (within 4 feet to be detected by the proximity sensor) when the notification goes off

• Far: the user is far away when the notification goes off, and does not approach the device

• Getting closer: the user is far away initially, but approaches the device (presumably to get more details about the notification).

By defining these scenarios I was able to determine that we needed two separate design views: a near and a far. Then we needed rules that would describe when each of those views would be used and when to transition from one to the other.

For the “far” view, I increased the size of the icon and headline text, removed the detail text and any actions, and increased the overall width of the banner to accommodate. This view would also sit on a higher z-index, covering any other ui that may conflict with this larger width. There was no concern about covering other ui elements in this view because the user isn’t in close enough range to interact with the screen as long as this view is being shown.

Now with the view designed, I started working on the optimal rules for the three scenarios.

• Near: show the “big” notification for 3 seconds, shrink, and persist for an additional 7 seconds.

• Far: show the “big” notification for 15 seconds, shrink, and show for an additional 15 seconds.

• Getting closer: show the “big” notification for up to 15 seconds, shrink when the user is detected by the proximity sensor, and show for an additional 15 seconds.

As I established these rules, I uncovered another potential scenario. What happens if the user approaches, but the notification has shrunk by the time they arrive. So I created a new rule for that scenario:

• If the user approaches the device after the notification has shrunk but before it has disappeared, show for an additional 15 seconds.

The main challenge we faced was in determining an MVP for the feature. We wanted to build the simplest viable version first, but being a financial product we had to make sure it offered all the essential features our customers (and their customers) would need. Some of the features we debated and, after some customer interviews, ultimately added into it are:

• Make one-time payment

• Edit billing method

• Edit payment plan (remaining balance, term, date of billing)

Ultimately we determined that without these features it could be a frustrating experience and not viable by our standards.

This feature isn't necessarily a revenue driver as it doesn't net Weave more money than a standard payment does. So the purpose of it really is to just provide further functionality and a positive experience for our users. Features like this are valuable because it makes the product stickier and increases the LTV (Lifetime Value) of our customers.