Level is a company that focuses on security and digital automation for homes. During my time at Level, I focused on creating a streamlined approach to property management—creating a simpler, more human approach to everyday tasks like unit turn and access management. In ten short months, with help from Level’s amazing design team and input from Level’s VP of Product, we built and launched Level M. As a Senior designer on the project, I was responsible for many of the main features and flows, as well as the Level M branding and design system. I was the sole motion designer on the project, creating micro-animations to robust prototypes.
Level M is a tool for property managers, leasing staff, and maintenance staff. It smartly automates tasks like resident move-ins and move-outs, grants access to visitors and guests, and manages all the smart devices Level provides. It aims to ease the workload of property staff, but leaves room for human interactions by letting technology do most of the heavy lifting. I closely collaborated with several property managers throughout the project to ensure as the end users, they were not being left out of the conversation.
There are more than 300,000 property management companies in the U.S. alone, all with diverse needs. In addition to streamlining everyday tasks, we wanted to better understand our users current workflows and pain points to provide better experiences in common use cases.
User interviews were conducted with property managements from five different properties. Managers were asked to identify their top pain points with existing management tools. The pain points were then grouped into high-level categories, including unit turn, property access & safety, and maintenance and repairs.
A competitive analysis was also done on existing management tools to pinpoint essential versus non essential features. Property managers were asked to rank these features in terms of usefulness, ten being most useful.
Unit turns are incredibly demanding. It's a constant rush to ensure everything's ready for the next tenant, from repairs to cleaning, often feeling like a never-ending battle against time and unforeseen challenges
Every day feels like a tightrope walk between ensuring resident safety and managing the endless stream of maintenance tasks.
How might we improve and regulate property access and safety while allowing our new platform to automate processes?
After analyzing user research, it was evident that we had to focus on a handful of vital workflows for Level M: unit turn, adding and removing residents, resolving maintenance issues, and extending access to additional parties, including new staff members and visitors. Safety was an issue that came up repeatedly during user interviews, and remained at the forefront throughout the design process.
Before design ideation, we brainstormed user types and space types, or rather, the back end of the tool. We were able to identify several roles in a community, like staff members, residents, visitors, and guests. In order to maintain a secure community, it’s important to decide who can grant access to whom. Property managers are at the top of the food chain, and can grant access to most anyone, as well as decide whether residents can grant access to guests.
We also identified space types, like units, amenities, and common areas. We originally thought we could divide spaces into leasable and non leasable, but some higher-end communities require additional compensation from residents prior to granting access. Thus, our access model was born.
Most residents are bulk-uploaded via a PMS system into a property. However, we still had to allow for managers to manually add residents. We spent time gathering and understanding requirements for adding residents, focusing on manager and leasing agent roles.
The first sketch of the ‘add resident’ modal presented a few issues, namely the lack of specification for user type and permissions. To maintain safety and consistent access, I added a unit dropdown with inline search functionality as well as an amenity selection.
Another consideration was how we displayed residents within the tool. Originally I decided to represent them as entities of units. However, managers wanted to keep track of residents who have yet to move in, as well as past residents. So I extracted resident data into its own list with tabbed statuses.
Unit turn is the most frequently occurring event in a community, so we spent a lot of time assessing functionality and use cases.
A large part of managing vacant units is device oriented. Because a huge differential for Level is their smart devices, we needed to allow remote device control for property staff. By setting temperatures, unlocking doors, and disabling alarm systems, future residents can self-tour properties and staff can worry less about community safety.
Managers also have to revoke a resident’s access if they are fully leaving the property. Residents who are moving out within 15 days are showcased on the dashboard, as well as separated in the resident list. I originally thought access should be revoked from the resident detail page, with the flow being: search for a resident via name or unit, select resident from a list, revoke access. However, I could eliminate one of those clicks by surfacing commonly used actions on the focus state of a resident list item.
We first established a baseline for how property managers received notifications. They were all part of the same ‘alerts’ bucket, which was a point of frustration. They were going to their alerts tab to build their daily task list, then delegating tasks to other staff members or visiting maintenance personnel.
The main problems to solve were:
1. How do I see what I need to get done today? What needs the most attention versus what can I put off and plan for?
2. How frequently and by what method do I want to be notified?
To solve the first problem, we sat down as a team and crafted a spreadsheet of all possible alerts, then divided those alerts into critical, non critical, and tips/feature alerts. From here we ideated on the interactions of each notification type. We decided that all critical and non critical alerts can only be snoozed, not dismissed, as they must be addressed. We also introduced bundled alerts of the same type, alleviating long lists of alerts. The bundles can be exported and sent to maintenance staff for quick execution.
As for the second problem, I added a notification settings page in account. For the MVP, we retained the same notification settings for all staff roles.
Throughout the intensive brainstorming sessions and countless hours of work with different designers, inconsistencies crept in. I made consistency a central part of the Level design philosophy by establishing a new design system and presenting opportunities for component evolution, which aided visual consistency.
At the same time, I worked with the Level App team to ensure the tool worked with the app. The app facilitates all the device interactions for residents, visitors, and guests. We made small tweaks to the UI, including iconography and device status updates.
More than 38 million Americans live in apartment communities, so there was a lot of media fascination with our new platform. We received a lot of press after the initial launch. More importantly, we exceeded 100,000 downloads in the first 6 months after launch, indicating a strong interest and usage rate.
The transition to Level M was the best thing that could’ve happened. This was exactly the kind of upgrade we needed for our A-Class properties... allowing us to upgrade our units and increase rents.
This isn’t the end for Level M. Many existing features could receive much needed improvements, such as our PDK integrations and guest management. This was a great first step in smart automation and simplification for property managers.