Online Application 3.0

Project Background

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 the user.
  • 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):

Want a funky experience filling out forms? Fill out an form. #ouch #BadUX 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.

Project Involvement

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.

Design Process

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 issues.
  • 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.

During Engineering

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).

Usability Testing

In addition to the workflows I adopted above, I also set up several forms of UX testing and measurements.

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 to leverage their panel of testers.

A sample test session. A sample test session, via

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.

Qualitative Feedback

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 application.

Placement of the survey link, after the user completed their to-do list. 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 particularly useful.)

Watching FullStory User Sessions

FullStory is a tool that allows you to record user sessions on your website based on Javascript events and DOM changes. It pieces 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!)

Product Screenshots

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., a subsidiary of RealPage, Inc.

Responsive Design Remote Usability Testing Qualitative Surveys HTML CSS Javascript PHP React.js Product Management
Balsamiq Google Analytics FullStory JIRA PollDaddy