The online application allows renters to submit all of the information landlords need
to screen and qualify someone for an apartment. When I initially joined On-Site back
in 2012, the application product we had was called "Online Application 2.0", or "OA2"
for short. There were a few issues I quickly noticed:
The application itself was only 1-3 pages long, however, the first page alone
typically had 30-50 questions, depending on the client. It was a daunting experience.
The third question on the application was "What is your Social Security Number?" A
number of other personal questions were asked before any trust was established with
It was slow and clunky. This was more of an engineering fix than a design fix, but
it was noticeable enough to be a detriment to the user experience.
Likewise, we had received some public feedback about the existing product (mean tweet style):
Needless to say, this user wasn't happy with the experience.
Redesigning an entire product from the ground up is no small feat—and to top it
off, On-Site had not done something like that before in its short history. (Even though the
existing product was "2.0", it was just the original product with added features that
marketing deemed worthy of a 2.0 label.) Internally, I advocated for the project, and the
stars finally aligned in December 2015 when the project was approved to begin. The first
clients went live with its MVP version in fall 2016, with a small drip of clients being
added in 2017 as new features were added.
When I left On-Site, the 2018 goal was to get as many clients switched over as possible
as the product matured.
I acted as lead designer for the online application for the entire product's lifetime.
Initially, I was also the main advocate for convincing leadership to take on the project
and replace the existing application.
My design responsibilities included:
- Wireframing the experience from start to finish.
- Creating polished HTML mock ups that our engineers could reference and use the markup from.
Running multiple iterations of usability tests on both the mock ups and live product to
iterate on the design.
For about 6 months towards the end of my tenure at On-Site, I also acted as its product
manager. I presided over a series of engineering sprints that added critical features
needed for a wider deployment of the product to our clients.
This product's development took place over several years while I was at On-Site. I
approached the design differently depending on when my work was taking place:
Before engineering began working on creating the new online app, my design process
was fairly simple:
Reviewed the existing application and learning about the needs of our clients.
Ran a baseline usability test on the existing application to look for usability
Created wireframes, either sketching on paper or using Balsamiq (a wireframing
program). Both mobile and desktop experiences were created.
Iterated through multiple versions of paper/Balsamiq wireframes after performing
basic usability tests, such as click testing and hallway testing.
Built an HTML-based mock up of the new experience. The intent was to create
something "real" that could be used to advocate for the development resources
needed for the project and act as something engineers could work from. Using
HTML also allowed for me to thoughtfully craft the mobile friendly version, as
the application was able to be responsively designed.
While the product was in development, I took on the following design process:
Worked closely with the product manager to plan out what features were coming up.
Prioritized those features to get mocked up.
Mock ups included either sketching a flow out on paper or augmenting the HTML-based
mock up I had already created.
Ran usability tests once a feature was mock up ready, if testing was feasible.
Detailed out JIRA tickets with explanations on the feature (or bug fix), motivations
for why we wanted to do it (with links to usability videos or analytics for review),
and UI markup for the engineers to use.
Hooked up various analytics tools, such as Google Analytics (to track the basics and
conversion rates) and FullStory (a usability tool that allows you to review user sessions).
Implemented a qualitative survey to ask users for feedback about their experience—
which was used to identify user experience issues (or bugs, in some cases).
In addition to the workflows I adopted above, I also set up several forms of UX testing and
Remote Usability Testing
As the product reached MVP status, I began performing several rounds of usability testing on
the live product with remote testers. I planned rounds of testing after each set or two of
major features went live. Each round consisted of 10 test sessions: 5 on desktop and 5 on
mobile (splitting either 2 on iOS and 3 on Android or vice versa). Tasks were uploaded to
UserTesting.com to leverage their panel of testers.
A sample test session, via UserTesting.com
After the end of each round, I reviewed all of the test footage and filed tickets for each
of the usability issues I encountered. I worked closely with the product manager to prioritize
fixes, and a few times I was able to lobby for an entire engineering sprint dedicated to
usability fixes and enhancements. Testing on a regular basis also allowed me to confirm
that prior issues no longer popped up.
As the product gained users, I set up a simple survey presented at the end of the funnel.
I created the survey using our corporate PollDaddy account and linked it directly in the
Placement of the survey link, after the user completed their to-do list.
I monitored results daily (especially the "Did you have any problems filling out your
application?" question) to gauge any hot issues that may have come up. (We were
releasing new code every 2-3 weeks. The day after a release was when this question was
Watching FullStory User Sessions
FullStory is a tool that allows you to record
the data together to give you a "video" that you can play back. In addition, you can
search for sessions based on where in your product they went, what they clicked, or the
meta data that you can provide.
I hooked up FullStory to the online application as more users began to use it daily.
I was able to spend time observing real users and how they interacted with our product.
I was able to catch multiple usability issues with a random sampling of videos. Coupled
with the qualitative survey above, it was also a great resource to get more details
when a user reported a problem in the survey. (And on a few occasions, when a client
reported a problem!)
Below are some screenshots of the product, as it stood in February 2018:
The first page of the application. Here, users will choose which unit they would like to move into.
Each apartment had an individual page listing details, amenities, and pricing.
After choosing a unit, the application itself would begin with a review of the rental criteria.
I tried to keep the "About You" page minimal—no more asking for a Social Security Number
here! Everything in the first part of the application was intended to be provided from the
user's memory. We didn't want them stopping to go find a piece of information before getting
committed to the process.
Once we knew who the applicant was, we would ask them to list any other residents they wanted to apply with.
Here's where we started to get serious. The step following this will ask for the application
fee, so I wanted to make sure we asked for the personal information before the user had money
on the line. (I wanted to avoid the feeling of a "bait and switch," as a number of users were
sensitive when it came to providing a Social Security Number.)
Our clients enjoyed collecting fees, much to my chagrin. Our payment page had to support
multiple fee types (application fees, administrative fees, convenience fees...), along with
credit card and ACH payment options. We even squeezed in promo codes! Communication
about what was being charged and how we would charge it was very important.
After getting a financial commitment from the user, we would get into the meat of the rental
application. The to-do list could include: photo ID number, previous home/landlord information,
income sources, vehicle information, pet information, and any arbitrary document that the client
wanted applicants to review and sign.
Here's what the income section looked like. We supported a wide variety of income sources.
Once the to-do list was complete, there was a final "sign and submit" step.
As our application was responsively designed, these are the same pages as above, just in a mobile-sized format.
In some cases, the UI would adapt a bit more than just shifting around: on the "Pre-Qualification"
page above, the No/Yes buttons are normally radio buttons on desktop.
In other cases, we adopted a card format, such as the Personal Details page on the left (which
could potentially list multiple applicants).
The sidebar that appears on the desktop version was collapsed into an off screen menu.
The flow of the application remained identical on mobile, ending with the "sign and submit" step.