My product pod worked exclusively on the property management side of Apartments.com called Rental Manager. In Rental Manager, independent owners, or "IOs", are able to advertise their property on Apartments.com, and manage their property once it's rented.
Associate UX Designer, Apartments.com website
I worked closely with product managers, developers, UX and content writers, and UX researchers.
Having to design using components from an outdated and relatively limited design system.
A general lack of development resources.
Due to the fact that Apartments.com sees a massive amount of traffic and user engagement, our product pods opted to prioritize the release of new designs, and observe user responses to them to inform future iterations.
Before we jump in, it's important to establish a shared understanding of the things I'll be speaking on.
They're not career landlords, and only manage one to three properties.
This is what a fully activated Residents page looks like:
An RMS page is a roll up page, displaying the lease associated with the resident, and all of the property management product offerings tied to that lease.
This project began as an initiative to get rid of pain points for a specific set of users:
However, due to a lack of development resources, we were able to spend more time addressing a larger set of issues that were present with "Residents", and capitalize on opportunities to increase business value.
which meant implementing a way for them to edit their residents information after the initial set up.
After discussing the change we wanted to make with our development team, they gave us a lot of pushback, citing technical restraints and logistical dependencies for reasons why it couldn't be done.
This feedback enabled us to move forward with solving the issue our users were facing, while keeping our designs in line with the constraints voiced by development.
The following solutions came as a result:
By adding an "invited" state to the resident adoption process, we created more flexibility in the resident adoption process for both our users and our developers.
Instead of being automatically linked to an RMS page, the renter must accept an invite to join a residency. Additionally, if a landlord makes changes to a resident's email, it will automatically trigger the removal of the invitation sent to the wrong account, and send the correct account an invitation.
The first set of mockups above used a banner to display the "invited" state.
Then, after getting some feedback from my PM, I started experimenting with making "invited" state residence panels. (above and below)
For the finished designs, we settled on the ones below:
Additionally, in order to ensure our changes don't cause issues with peripheral functionality, we created defined points in the resident adoption lifecycle after which the landlord wouldn't be able to edit their residents' information without having to delete the RMS page and start the process over.
Once we had that issue sorted, we pursued a second change to the Residents section of the site that would slightly alter its logic, and cause less confusion for our users. This was to change the section's name from "Residents" to "Residents & Leases".
We had gathered feedback from users saying they were unable to find where their leases were within Rental Manager, and therefore couldn't perform key actions related to their leases like renewing them, canceling them, downloading related document, etc.
This difficulty made perfect sense considering there wasn't a navigation item that had anything to do with leases. Therefore, we made the label change to the left navigation, and to the header of the section. Additionally, in order to reflect the change in logic, I modified the font weights within the header of the RMS page to visually prioritize the lease term.
When considering opportunities to add business value within the Residents section of Rental Manager, we immediately looked at the "Set Up Residents" flow. This is the flow that an IO goes through in order to create an RMS page. We set our sights on the last screen of the flow, and then the newly set up RMS page that the user sees immediately following the last screen:
We realized that we were missing out on an opportunity to encourage the user to activate our other product offerings. As you can see in the current state, there was only a banner being displayed at the top of the RMS page that served primarily as a confirmation message, and secondly as a prompt to utilize our other products:
This banner was not only easily glossed over, but it disappeared after the user left the RMS page after completing their Residents set up. We knew we needed to be more direct with the user, and implement a change that served less as a reminder, and more as a speed bump.
So, the approach we settled on was adding a modal to the end of the Set Up Residents flow.
Yes, this modal needed to function as a confirmation message that informed the user that they had successfully added their residents, but more importantly, it needed to get the user to really stop and consider using our lease drafting tool and payments system.
We of course give the user the option to pass right through the modal and access their RMS page. What's important about the nature of the design, though, is that it brings the user to a stop, makes them consider the options in front of them, and then if they don't want to activate a second product, they have to deliberately take the action to click the "Maybe Later" CTA.
Additionally, I consulted our UX and content writers to ensure that the copy we used in the modal was brief, yet impactful. The heading "What's next?" establishes a playful tone, while also implying that the user "isn't done yet".
However effective the modal within the "Set Up Residents" flow may be, it was limited in its potential to have a positive impact due to it only being shown at a very early point in the user's journey with Rental Manger.
As a response to this dilemma, we began thinking of ways to prompt users to activate our products in a way that persisted after the initial set up, but that wouldn't bother them.
If we take a look at the RMS page in its current state after a user has only set up their residents and done nothing else, they are presented with empty-state product panels filled with copy encouraging them to activate the products.
To glean further insight into the way that our users interacted with the page in this state, we consulted recordings on FullStory. What we found was that the vast majority of users would quickly scroll by the empty-state panels, arrive at the bottom of the page, and then leave.
This made us realize that despite their best effort, the panels filled with content were not being engaged with, and served no tangible purpose.
As a response to these insights, we settled on the idea of implementing "set up cards".
These small and horizontally arranged cards would replace the empty-state panels, contain much less copy, and would remain on the RMS page after the initial resident set up. (rough wireframes above)
By adding the modal at the end of the "Set Up Residents" flow, and having the set up cards replace the empty-state panels on the RMS page, we aimed to maximize the potential for added business value while creating more palatable entry-points into our product line.
One final design change that we implemented within the "Residents" section of Rental Manager came as a response to user feedback that IOs wanted the ability to remind their new residents to set up payments through our platform, after they had already initially invited them to do so.
We felt this was an excellent opportunity to make a low-cost change that helped our users, while simultaneously adding business value.
The "Remind" CTA is displayed within the "Residents" panel on the RMS page, and comes with a status indicator that changes color and text depending on whether the resident has been invited, reminded, or has successfully set up payments.
As mentioned at the start of this case study, development resources were scarce while these designs were being made. In addition to their scarcity, the tech team that worked with our product pod didn't have a dedicated front-end developer. This made the process of design implementation a bit more difficult than normal, and required immaculate file hygiene in order to avoid confusion on their end as much as possible.
When the designs made it to our test environment, I conducted Visual Quality Assurance, or VQA, to ensure that everything was looking and functioning the way that it was meant to.
If something was wrong, I created a new page in the deliverables section of my design file, and used that space to point out the differences between my designs and what was up on the testing environment.
Unfortunately, the developers weren't able to correct all of the issues that were present in the testing environment before the end of the sprint, so I broke up the issues into small audits that were labeled by priority, so that the most pressing issues could be taken care of by the time the changes hit the production site.
Over the course of this project, I learned a few central lessons that an associate UX designer must learn if they're going to grow in their role, and be an impactful member of a product or design team.
They are:
