Quext Resident Portal: but what about the resident?

Link to product

This resident portal project was a part of a larger property managment system called Quext. Ultimately, Quext seeks to stand out in the space by offering robust features in an easy to use and uncluttered package.  For the resident portal, these goals remained the same while focusing on a wider and more general userbase. The purpose of the resident portal was to be used by the residents of the properties using Quext to accomplish all the tasks that go along with the renting process, such as paying rent and submitting service requests.

Client

Quext

Type

User Research • UX Design • UI Design

Year

2020

My Role

My primary role on this project was as the UI/UX designer. This meant::

  • Conducting user research (surveys and interviews)
  • Wireframing
  • UI Design
  • Design system build and maintenance support

Foundations

Process

User Research

A question from the resident survey showing what devices residents are using to access their portal
A question from the resident survey showing how often residents report accessing their portal account

The main goal of the research was to discover, validate, or invalidate potential features for the resident portal. In addition to this, I wanted to develop a research plan that gathered large amounts of quantitative data to see patterns and smaller amounts of qualitative data to dig into the why of those patterns. With these goals in mind, the plan was to recruit a large number of people with experience renting an apartment, and with experience using a resident portal app as a part of that renting experience.

We had a decent number (160 participants) take part in a survey, and had a smaller amount (10) take part in both the survey and an interview session. To find these participants, I reached out to friends, family and social media. In addition to this, we leveraged resident and renting message boards to find interested and willing participants. The advantage of this project is that you did not have to look too hard to find our user group, many people have had some sort of experience with a resident portal app and with renting.

Obviously, I could rant on and on about everything that was learned during this valuable research time. Big insights. Small insights. Operational ones. Industry wide ones. But for our sake I will boil this down into the most critical insights we uncovered that directly informed the design and build of the app.

Insight 1: Simplicity and Efficiency. 84% of our participants reported using their resident portal app 1-2 times a month. In addition to this, 75% of our respondents reported only using their app to pay their bill online and for service requests. Even when these participants were offered a resident portal app that has many features beyond these, this remained constant. Through interviews, we drilled into these insights. Essentially, users see their resident portals as simply a tool they do not “like” or “want” to use. They are using it to accomplish a task that often is not associated with a positive experience, such as having to submit a services request or paying rent. This may seem obvious, but it brought about a shift in the way our stakeholders and team approached the project. Our resident portal will be judged largely on the handling of two tasks, paying rent and the service request process. We as a team need to nail these first, everything else is gravy.
Insight 2: Feedback and Transparency. 58% of our participants claimed that one of the primary things missing from their renting experience is communication from the property. 53% said responsiveness from the property. 38% said transparency. These responses were in regard to a variety of matters, but the primary gripe was the service request process. We feel all these responses fall into an insight of the gap communication gap between the resident and property that the resident portal app absolutely should fill. Overall, we will seek to close the communication and feedback gap that exists between the resident and the property.

Defining the problem

Following our research and discovery, we aligned around what our focus was in order to solve the right problems. Our problem statement was the culmination of everything we had learned thus far on the project and informed how we moved forward.

Residents need to be able to accomplish critical tasks associated with renting quickly and easily through the app. Additionally, users currently find frustration with the lack of communication to and from the property as it pertains to a variety of issues

Ideate

The ideation process was primarily used to explore the communication and feedback process between the resident and property in specific contexts. We sought to understand the positive in-person communication and processes to try to model the communication in the portal after those real life exchanges.

We created a variety of journey maps that follow a variety of different starting places for the resident and outcomes. Above is a good example of how the services request process should go. Almost always the resident is starting the journey in a place of mild to considerable frustration, and the job of the app and property staff is to bring those frustrations down by addressing the problem, but by also giving the resident adequate transparency and communication into the request.

How might we exercise to begin to drill into solutions for our stated issues to address

Through various ideation techniques we nailed down specific issues in the communication process that we wanted to address in the app. Many beneficial insights and design foundations came about through this process.

Structure & Flows

Following our ideation process, we now begin to establish the main app structure and flows with an understanding and approach.

Here you can see an example of an early iteration for the service request flow with an approach taken from modeling the process after the positive aspects of an in-person experience, by making the process more conversational.

These are the statuses of our services requests from a high level and how a request would progress through them.

Through establishing our flows and structure in a low fidelity stage, we more easily align and iterate by enabling and inviting visual collaboration.

Wireframing

Now we move on to wireframing, where we bring another level of fidelity to our process. In this stage, we mapped out the resident portal and the flows that comprise it.

These are some of the view / submit service request screens. You can see the conversational approach start to take shape with breaking the sections of submitting a request down into “What is the Problem” and “Where is the Problem"
This is the submitting a payment flow. One aspect from the research that we wanted to drill on is being able pay quickly, and through this flow the user can utilize an “accelerated payment” flow which utilizes preferred methods to allow the user to pay in three taps.

UI Design

At this stage, I collaborated with 2 UI designers who then led the UI design of the resident portal app. Collaboration with these designers began in the ideation stage where they were brought up to speed on the research and began to get foundations into the users and insights. In this stage, I collaborated and supported in various ways including UI support and design system build support.

Examples of our service request screens
Examples of various designed screens

Next Steps

The last step for me on this project was ongoing collaboration with an external dev team to ensure the designs and flows were implemented as intended. This was a challenge as our client outsourced this work, so extra steps were taken in terms of documentation and prototyping to communicate the designs, alongside presentations, walk throughs and constant review and feedback.


Want to hear about this project in more detail?

See more of my work