SERGI BOSCH
3 min readJun 24, 2018

UX Case Study: REA Maps: Route Scheduling for Realtors

Final MVP Concept

REA Maps: Route Scheduling for Realtors began as a result of my attending an open house to observe a realtor as he conducted his job. We spoke about his process of organizing the open house, from the steps leading up to it, to the steps he would take following it. He showed me his organizational materials, and I observed how he greeted guests as they arrived.

Being that my design brief called for a glanceable interface, my first version of this product was an app that helped an agent manage his open house process — and render a series of data points in a summary screen (like a feed) that would appear on the apps home screen.

Early prototype to assists in the materials gathering stage for an open house
Feed for glanceable data points

However, after testing this app several users, I realized that my core proposal (my MVP), was not enough to carry a product. Though it would meet the need of some users, many others would not benefit. For instance, a lot of realtors don’t feel burdened by the process of gathering open house materials.

So I pivoted by focusing on another need realtors have, which is: struggling to map the route they will take when taking buyers to successive showings.

Pivot: Open House vs Showing

An open house has several dimensions to it. It begins with a realtor agent getting a listing from a seller, then arranging to show that home to potential buyers. That agent might show the home on Saturday from 12–3pm; or she might ask an associate show the home for her. This differs from a showing. A showing is when an agent works with a buyer (not a seller) to find them the perfect home. For a showing, the agent might schedule 6 showings between 11am and 5pm on a given day. And this is when things can get sticky — and when REA Maps comes into play.

As you can see from the screens below, the focus is on “when do you need to be where, and what time do you need to leave that location to make it to the next location on time”, aka, scheduling.

Iterating on Success

Once I nailed down my scheduling interaction design, user testing illuminated a shortcoming in my product: an agent might need to modify or cancel their route midway through the day. And that’s what led to Version 2.0, below. Notice the new edit menu.

Conclusively, this is an incomplete product as evidenced by the lo-fidelity quality of the screens displayed in this article. However, I have validated the need for this product and can’t wait to move forward with building it.

Edit screen discovered during user testing

See Interactive Figma Prototype Here