My Role
UX Design, UI design
Other contributors:
Mitch Park, Product Management
Rob Taylor, Development
Trevor Michaelis, Development
Julie Manzi, User-testing collaboration
Background
Vivint Multifamily was a small team within Vivint that provided smart home products to rental and multifamily communities.
We were tasked with providing residents secure, reliable access to the variety of common spaces (e.g. the pool or gym) as well as to essential doors and buildings to access their personal living space.
Scope
Improve on the current implementation of "Common Access" within the app such that residents can easily find and use door lock controls within the existing Vivint Smart Home app.
Goals & Constraints
-
"Fit" the Vivint app experience
-
Easily discoverable in the app
-
Scalable (works for communities of all sizes)
-
Work for web but fit in the app
UX Challenge
How might we provide apartment community residents a better way to find and unlock common doors from the Vivint app?
Identifying problems with the old experience
I did a brief “audit” of the current experience to identify the areas where we could make improvements to the experience.
Problems:
-
Controls: Buttons and labels were too close together.
-
Hierarchy: Visually, it was hard to differentiate between elements on the page. Additionally, the two column list makes scanning rooms difficult.
-
Color usage: The use of green was not appropriate for this application. The green has special meaning in the Vivint app (used to communicate disarmed state of the security system.)
-
Naming / Discoverability: "Common Access" hadn't been verified as a good name for this feature
-
General Usability: The lock icon is confusing - does it mean lock or unlock?
User stories
The primary user of the common access experience were residents of the apartment community. I worked with my product manager and property managers to determine the needs of users.
"As a resident, I need to be able unlock doors to my building and my stairwell so I can get to my home."
"As a resident, I need to be able unlock doors to use my community’s amenities such as the pool, gym, and clubhouse."
Defining user needs
In this exercise, I collaborated with my product manager to identify the base user needs (requirements) for the experience. I presented these to the engineering team and other stakeholders for feedback.
Wireframing & Prototyping
With the user needs as my guide, I explored different concepts in high-fidelity wireframes and with prototypes - as the lock control was an important aspect of the design.
Exploration on "favoriting" or saving doors that are used most often.
Exploration on information architecture and unlocking controls.
Changing the feature name to "Community Doors"
I wanted to see if "Common Access" was the right name for this user-facing feature
-
Researched what our clients called their public spaces to see what would apply best
-
Got feedback from property managers and residents
We landed on "Community Doors" because it captured an important aspect of residential living that the property managers wanted to convey to their residents: "Community." We chose "Doors" because it was clear in its meaning. "Doors" is concise albeit literal but better than the generic term "access."
Prototyping & User testing
I created prototypes in Protopie to explore the different aspects of the experience.
I developed a test plan. A colleague and I tested a prototype with a resident, property manager, and from a maintenance professional as well.
Learnings from user testing
-
Two new user stories emerged:
-
We needed to include something in the UI that indicated when a door could not be unlocked - due to maintenance or the amenity/space being closed (e.g. the pool is open till 11pm.)
-
This would now allow residents to remotely let guests or service professionals into the community, even if the residents wasn't present at the property. Generally, this was seen as a good thing because it provided additional convenience to the resident.
-
-
The lock control is easy to use but the timer is confusing and probably unnecessary. The timer in the UI was received well but the audible "click" at the door of the lock was more important than anything.
-
"Saving" doors was usable and intuitive.
-
Default to the "All doors" page initially. If the resident has doors saved, then default to "Saved." (Continue testing this)
Final Experience
The user can access community doors on the Security page. They can then access all the doors (organized by product managers).
To unlock a door, the user follows the same swipe action. The countdown clock was abandoned.
Users can add and remove doors from their saved list by tapping the heart. This was used because it is a well understood pattern from e-commerce and other experiences. The zero state (no saved doors) is shown here also.
Outcomes
👍 My product manager decided to move forward with a small pilot with about 400 residents in early 2020. This would be a great chance to see how things operate in the wild and get additional feedback from residents.
👎 Unfortunately, due to the beginning of the COVID-19 pandemic in March 2020 and other factors, the Multifamily team was dissolved and the project discontinued. This meant that we weren't able to roll out the pilot.
Learnings
Done is better than perfect. While I would have loved more time to improve on the UI before our pilot, I felt good enough to move forward so that we could keep learning. Fortunately, we were building on the web, so I knew we would have more opportunities to adjust, faster.
Get prototypes into real hands in the real environment as soon as possible because it will uncover a lot more than just usability issues.