Turning Dead Ends into Pathways: Revamping an Unfinished Alerts Feed
THE PROBLEM
We thought the problem was engineering cutting features, but surprise! The original designs were unfinished, riddled with dead ends, and lacking proper system logic. Instead of adding value for our users, we'd be adding headaches!
THE SOLUTION
I conducted an extensive design audit, leaving no pixel unturned, to bring cross-platform consistency for alert layout, copy, and logic. I devised a clever method to keep the alerts feed fresh and relevant instead of redundant and cluttered. Plus, I completed the game-changing feature, a device history feed, that provides users with the crucial context they need to solve problems faster and easier.
Project
0verview
ROLE
UX Designer
TIMELINE
Approx 4 weeks
Reviewed previous interviews to ground the decisions to make on who the users are
Reviewed existing documentation to understand the current logic, and identify missing or inconsistent data
Conducted UX audit of the current experience to pinpoint specific opportunities for improvement
Mapped all user journies across multiple apps and emails relevant to receiving an alert
Understand the problem
Defined logic for the lifecycle of alerts that would solve for repetitious or out-of-date alerts clogging up the feed.
Revamped alert item layout and copy to make it easier to skim
Made the copy across apps and emails consistent and appropriate for each user to ensure there wouldn’t be a lapse in communication between staff and residents.
Added actions to the alerts to give the user more context on when and why an alert may have happened.
Recommended additional alerts to better reflect the possible device problems that were previously not considered
Define logic and re-design
Mapped out a sensible phased-release plan to account for current engineering limitations
Next steps
TEAM
Independent initiative
Context you need to know
What is this design?
This is the homepage of a new web app to help staff manage resident and visitor access and smart devices within an apartment complex. This is the main source of information regarding the health of their Level system.
Expectation (Figma design)
Who originally designed it?
An agency designed this page, but they finished their contract before the official handoff to engineering so any designers who worked on this were no longer with Level by the time it was being built.
How was it developed?
There was a decision by stakeholders to cut features to meet their deadline which greatly reduced the functionality of the page. This put a magnifying glass on the usability of this page as a whole once it was in production, which sparked my initiative to look into the alerts feed.
Reality (Production)
Only 2 of 8 main features were included in V1. And even then, they were simplified versions of the original. We’ve all been here. Just because it’s designed doesn’t mean it will get built, whether by deadlines or changes in priorities. The pragmatic next step is to have a clear understanding of your current, actual product and make thoughtful, incremental improvements from there.
So that’s exactly what I set out to do.
This is where I begin
Alerts are one of the most powerful features our platform offers, capable of preventing potentially catastrophic damage by notifying staff of issues such as leaks in units or security concerns like propped-open common area doors and motion detected in vacant units. These alerts are a cornerstone of our homepage, providing critical real-time information.
After collaborating with stakeholders to define goals for the next iteration of the homepage, I focused on enhancing the alert system. By thoroughly examining and refining the underlying UX, my goal is to make sure this crucial feature is robust and intuitive in the app's next version.
Remembering who this is for and why
I revisited some old interviews I helped conduct with apartment staff to ground my decisions in the human behind the task. These interviews were not about alerts specifically, but rather a broad understanding about their day to day tasks. Being able to zoom out from the specific problem can often times be more helpful than asking the users what they want to fix about something specific.
Some staff are almost never at a computer (think maintenance roles that are completing physical tasks all over the community), some staff are more hybrid (think leasing agents who give a lot of tours throughout the day), and some staff are fairly desk centric (think staff at the front desk who are available to answer questions from residents, prospects, and visitors). Managers seemed to split their time between solving problems from their desks and around the community.
Staff are almost always multitasking, busy, and trying to check things off their to-do lists. They do not have downtime. They are highly aware of the ins and outs of the community at any given time. As one staff member put it in an interview, the whole job is about “covering your ass”.
Many staff members we talked to were highly motivated to help residents solve problems that may arise with the Level platform, they just weren’t given any resources to be efficient and effective.
What’s going to be valuable to our users?
When possible, present a solution instead of a problem.
Do not add more to their already full plate or create extra friction points to their day.
Our platform should give a sense of reliability that everything is being handled rather than everything is breaking.
The Reckoning
Once I outlined my human-centered goals for the staff’s experience, I studied the current state, original design, and surrounding documentation to see how it all measured up. I quickly realized the problems were far more complex than initially anticipated. Even if the original design had been fully implemented in V1, numerous significant issues would still need to be addressed. Yikes! So I got to work doing a comprehensive audit of the 23 unique alerts we currently have and how they show up across our various platforms. These are my findings and suggested improvements.
Alert copy
Original
Many alerts are hard to scan. Building and entrance information gets jumbled within the alert message.
Most do not provide enough information. If this was an uncommon alert and it was the first time you saw it, would you know what you should do?
Does not clearly define if the space is a common area or an amenity door.
Does not clearly define if a unit is vacant or occupied, which is important since occupied units require permission to enter.
The timestamp is hard to track
Aligning all platforms
Update
Problem
Alerts are not confined to the feed; they also include email notifications sent to staff and residents based on their preferences or the criticality of the alert. Additionally, residents have a completely separate experience in their resident app. The original design overlooked these various uses of alerts, resulting in inconsistent information across different platforms which could potentially cause confusion and could lead to problems being addressed slower.
Device history
Enhanced scannability by putting location and device information in the eyebrow, additionally, this makes the body copy easier to write because it doesn’t need to include this information which greatly varies from community to community.
The timestamp is pulled out to the side so it can serve as a scannable timeline in a stack of alerts.
When possible, present contextual information such as what may have triggered the alert (a common door being open for longer than 5 minutes).
Provide a solution to the problem.
Solution
I meticulously reviewed and standardized the information for all 23 alerts across each platform, ensuring the copy was clear, concise, and consistent.
What happens when I click an alert?
In the original version, when a staff member clicked on an alert from the home feed or an email, they would be taken to the device card on the page of the space (unit, amenity, etc) the device is installed in. Upon closer examination, I discovered two issues with this approach:
The device card states were incomplete and did not cover all the possible alerts that could occur with a device. This meant that a user could click on an alert, but the alert might not be reflected in the device card.
Even if the device card state was accurate, there was limited action a staff member could take with this information beyond simply verifying the alert. However, I noticed a possible alternative route we could take the user…
Painting a more comprehensive picture to save time
Seeing the events that happened right before and after an alert provides invaluable context. For example, if you receive an alert that a common area door was propped open 5 minutes ago, one click reveals not only when it happened but also who the last person was to open that door. You might even see that the door is already closed! This feature can significantly reduce the need for staff to leave their desks and minimize the communication required to resolve issues.
Alert “Event” Lifecycle
Start of event: Common area or amenity door detected open for 5 minutes straight.
Event updated every 5 minutes: If the door has not been closed, the timestamp is updated every 5 minutes and is moved to the top of the feed.
Event resolved: As soon as the door is closed, the timestamp is updated and the alert moves to the top of the feed. The event is complete and will not be updated again.
The feature that was never finished
The device history feature was originally intended to complement device cards, but during my audit, I discovered it was never completed. It was filled with placeholder text, sparse documentation, and no clear background on its purpose. However, I saw the immense potential this feature could have for alerts. So, I rolled up my sleeves and got to work:
Identified all types of events that would appear in the device history for each type of device and ensured the copy was clear and consistent with the rest of the alert messages.
Created a task flow for each alert to map out how the information would be presented in the typical sequence of events.
Defined pre-filled search terms for each alert (if applicable) to narrow down the history to the most relevant information.
How are alerts triggered?
Our alert system guidelines range from immediate triggers (like a leak alert) to 30+ minutes (such as a window open in a vacant unit). While this system logic is a solid starting point, it presents a significant challenge in practice. We face two choices for how these alerts appear in the feed:
Trigger the alert once and hope the user sees it in the home feed.
Continuously trigger the alert until the issue is resolved, potentially clogging up the alerts feed.
The second option wouldn't be so bad with a snooze function, I guess, but what if we made the entire alert system a bit smarter? After all, we are a smart device company! Let's innovate and enhance our alert system to be more intelligent and efficient.
Making a single alert an “event”
To prevent multiple alerts from cluttering the feed, I designed a system to update a single alert as the event progresses, using the original trigger as the guide. This way, instead of generating multiple alerts, one alert will encapsulate the entire event history. Regardless of when you view the alert, it will highlight the most relevant information at that moment.
Great! I’ve solved all the problems! Now my new designs can swoop in and save the day!
… except that’s not always how things work.
During discussions with the stakeholders about my designs, I discovered that it would take quite a few sprints before the new alert event logic could even be reviewed by the backend team, and the device history wasn't even on the radar—likely a year out. But hey, that's just the reality of it! As a designer, my job is to ensure everything is ready when it's needed. In the meantime, I can take pride in knowing that I've been incredibly thorough and created a foundation that is now rock solid, and most importantly, the feature is now realigned with the user’s needs.
Phase 1
Phase 2
Phase 3
Because of the engineering limitations, I created a 3 phase plan to go from what we can immediately do on the front end to elevate the current version, to the intended version which will have the most value for our user.
Improve alert and email copy to be clear, skimmable, and consistent with one another.
Introduce alert “event” logic into the feed and include links to help articles within the alert itself. Add more states to the device cards to make problems apparent.
Build the device history feature so staff can be given the full context of a problem that may be happening. All the information they should need would be within a click.
What I learned
When working with an agency, it's crucial that their designs are thoroughly vetted by the internal team before handing them off to engineering. Ensuring a comprehensive review helps maintain quality and alignment with our project goals. This tends to be the first thing to go when deadlines are tight, but a little upstream problem-solving prevents a lot of headaches down the road.
A B2B2C experience requires an extra layer of systems thinking to make sure the experience is consistent across the various platforms for multiple users. You cannot design in a silo and expect optimal results. Problems sometimes need to be solved holistically.
Whenever I'm informed that a feature is being stripped down at the last minute due to engineering deadlines, I insist on taking a couple of hours to: 1) ensure that their proposal remains usable, and if not, suggest minor tweaks; and 2) create a Figma version that accurately reflects the current build with detailed annotations about how it’s different from the original design. This way, the front-end and QA teams can easily distinguish between what needs to be built now and what is planned for the future. Since starting this I have prevented other lapses in usability before they happen, and the communication across teams has greatly improved.