RentHub
RentHub is an online real estate data and intelligence platform. Their products provide real-time, rental market pricing information to investors and property managers. Essentially, their tool allows customers to track current rents and rent trends for properties that are comparable. This information is used to inform investment decisions, as well as accurately set rental prices to meet market demand.
Kelli, the Project Manager at RentHub, approached our team in the early stages of development of a new product. Based on customer feedback, they saw an opportunity and were developing a new tool that would provide detailed submarket research data for multi-family property investors and acquisition managers. Kelli had developed an initial wireframe for the concept, but wanted our team to validate the new product functionality with users, develop detailed wireframes, and a working prototype. We had three weeks to develop and present these final deliverables.
Coming into this project, our team had no prior experience with multifamily property investing. So the first step of our process was learning everything we could about the space through domain research, a competitive analysis, and user interviews. We wanted to understand not only our primary users needs and motivations, but also the entire multi-family investment deal cycle. For instance, what data is most important when evaluating a multifamily property? What does the current research and evaluation process look like for investors? Since we were completely unfamiliar with the space, we had to get up to speed quickly with a lot of foreign terms.
Our domain research yielded insights in four areas:
Democratization of data is leading to a better understanding and evaluation of submarkets.
Hot markets tend to share similar characteristics, such as strong population growth and average educational attainment. This helped us understand what metrics would be important to include in the tool.
Trust is built over time, however, infusing transparency and reliability into the product will help speed up the process.
Not only are context and timeliness important, but also users need to know why something happened in order to respond.
We were able to identify that RentHub has a few direct and indirect competitors. Through our research into each potential competitor we were able to determine that some sites offered more analysis versus strictly data. They also differed on the amount of quantitative versus qualitative metrics presented.
RentHub’s direct competitors tended to offer more analysis and more quantitative versus qualitative data. RentHub’s indirect competitors focused more on qualitative metrics, such as demographics and surrounding attractions, and offered little analysis.
Costar: has a market analytics tool with submarket data and analysis. High monthly cost and low flexibility.
Axiometrics: provides comparable property info and basic submarket data, but is only updated weekly or monthly.
Trulia: while marketed more towards single family buyers and renters, they have submarket info. But Info is limited and is not easily exportable.
Zillow: is similar to Trulia in that it is primarily marketed to single family buyers and renters. Has submarket data and slightly more analysis than Trulia.
Recruiting potential users for interviews was a challenge for this project because of the very specialized nature of the product. However, we were able to recruit and interview several multifamily real estate professionals to gain a better understanding of their current research process and what they are looking for when making an investment decision.
We found that while they differed slightly in their process, they all used 5-7 different sites to help evaluate a submarket during their research phase. Investors and acquisitions managers at large firms tended to use Axiometrics, Costar, and Reis, which have high subscription costs, but more analysis. Small firm or independent investors on the other hand, used information available on free sites like Trulia, Redfin, and City-Data.com.
After synthesizing the information collected from our interviews, we identified a few common areas of frustration and needs for our users:
1. In order to trust data, users need to know where it’s coming from and how it’s analyzed.
“Just tell me a story about what you do and where it comes from. And why you got it from those places.”
2. Data needs to be multi-dimensional. Users want more than just averages and want to see trends over time.
“I need to see how this area evolved over time. A one day snapshot doesn’t really tell me much.”
3. Market conditions can change dramatically block to block. User need to be able to see smaller views of the submarket.
“Submarkets are pretty broad. You’ve got to drill down into the economics of the area. Am I on the right side of the tracks?”
4. Users need to have the flexibility to customize data to fit their search.
“It would be nice to customize, like a filtered search, so I don’t have to go into excel in order to filter through the data. It should happen beforehand.”
From our interviews and research, we knew that data visualization was going to be an integral part in the final product. It would be important to present the data in a way that is easily absorbed by users so they can quickly understand market conditions.
Our team set out to learn best practices for presenting complex data sets in easily understandable and aesthetically pleasing ways. We drew inspiration from everything from weather pattern dashboards to political maps.
This is an example of a Bloomberg terminal, which helps financial investors to monitor and analyze financial data. We learned highly experienced professionals prefer more data over clean interfaces.
We looked at heat maps for weather and political data. Heat maps are very effective in communicating how data changes by location and can also illustrate changes over time.
In addition to these general insights, we were also able to identify four distinct types of users. We felt that based on these users' current processes and needs, a submarket research product could be of use to each.
Works for a mid to large investment company building and maintaining a portfolio of multifamily properties. They typically receive potential deals from brokers and evaluate using subscription based services like Axio Metrics, Costar, or Reis.
Works on his or her own and is searching for local, smaller budget multi-family investments. Also receives emails from brokers advertising potential properties, but typically in a newsletter or email sent to multiple investors.
Typically working for a mid to large company. Uses subscription-based submarket research tools and conducts heavy research to determine if a property is a good potential acquisition for their employer.
Can work for a small to large company. Is more involved in the beginning of the deal cycle, actively searching for potential properties or developments that fit their company’s model. They then approach external investors to seek capital, while their company will manage the day-to-day operations of the property.
We discovered that the deal cycle for a multi-family property investment was similar across the users we interviewed, but they were involved at different stages depending upon their role. By mapping out the deal cycle we were able to identify pain points and opportunities throughout the cycle.
This deal cycle flow allowed our team to determine that all potential users are interested in similar metrics, but are evaluating at different stages of the deal cycle. Brokers and Acquisitions for an Investor roles would typically be involved first, searching out opportunities, researching, and then putting together a summary of the property to entice potential investors.
Once investors received this property summary packet, they still conducted their own property and submarket research to validate the information provided. We discovered that investors and acquisitions managers tended to only trust information that they had verified on their own and analyzed independently.
From our research and interviews, we found users were researching and evaluating properties and their submarkets using multiple sites and resources, which led us to distill our main problem down to:
Throughout the cycle of a multi-family real estate deal, various stakeholders need an aggregated, trustworthy source of submarket data and analysis in order to market a property, verify provided information, and make accurate investment decisions.
Before designing, we developed four principles to ensure our designs reflected our research and the needs of our users:
Users are skeptical of information they have not gathered and analyzed on their own. Trust must be built over time through transparency. Tell the user what, why, and how the data is collected and analyzed. Cite sources and make raw data easily accessible every step of the way.
Many users specialize in a specific type of property. Give users the freedom to customize and classify their data so that they aren’t sifting through irrelevant information. Users should be able to analyze the data specific to their property types in a timely manner.
Users want the raw data, but can get that anywhere. What they need, and what they pay for, are insights derived from the data that help them make better decisions. Insights should be absorbable at a glance and relevant to the individual user.
Users are simultaneously seeking information and insights from varying levels of detail. They should be able to seamlessly view data on the city and neighborhood level, all the way down to an individual property and the apartments within it.
With a problem and design principles in place it was time to start concepting. We started out by sketching 6-8-5s and developing as many possible solutions as we could. From these initial sketches and fragments of ideas, three concepts emerged, which we built out in Sketch for concept testing.
This is the concept I built out. The idea was the screen would be comprised of various customizable widgets that would make up the dashboard. Users could create, delete, and move these widgets to fit their individual research needs.
This concept focused on organizing the vast amount of information being presented to users. It contained distinct categories nestled into tabs that users could easily flip between. Categories included high level financials, demographics, and comparable properties. Another goal of this concept was to evaluate the importance of including comparable properties when conducting submarket research.
This concept tested the appeal of a large, ever-present map as a primary feature of the product. Numerous sites such as Trulia and Redfin feature an ever-present map, but we had not seen this applied to a multifamily submarket research tool.
We developed a concept test plan and took our three concepts to test with potential users. From these tests, we received both critical and positive feedback:
“I want to be able to see where I am on the map at all times. I don’t want to have to constantly scroll between the data and the map view.”
“We look at submarket research to estimate supply and demand. That’s how we think about it. So if I can see supply and demand for a submarket here, that’s huge.”
“I want to see sales comps here too. How much did similar properties sell for? That’s really important. I look at both. But not at the same time.”
From feedback during concept testing, we identified three main takeaways:
Users wanted the map always visible regardless of whether they were researching demographics or comps. Interactivity and overlays tested extremely well across users.
Two main categories resonated best with users. One, a market research section with supply, demand, and demographic metrics. Two, a comps section with rent and sale comps.
Users want the ability to narrow their search so they don’t have to sift through information that isn’t relevant. They want this customization through filters where they can set specific parameters for their search.
While we felt we had started to establish a direction to a converged prototype, there were still a lot of unanswered questions. Most importantly, what would the site architecture look like? What features were most important to include and how would users navigate between various sections?
To answer these questions, our team listed and categorized all the different features and sections the product would need based on research and then built out the site architecture on a whiteboard.
Using our research, design principles, and site architecture as a guide, we built out our initial prototype using Sketch and InVision.
The primary design element of the initial prototype was a split screen view. On the left would be an always-present interactive map and on the right would be detailed data and information on market research and comps. This would allow users to see the map at all times and not have to constantly flip back and forth.
Additionally, the map included a heat map and the ability to layer data on the map based on our research into data visualization best practices. We also divided the right side into two main sections: Market Research and Comparable Properties. We heard from users that both of these sections were important during the research stage. In the initial prototype they were included in a drop down menu in the top navigation bar.
After testing our initial prototype on potential users, we were able to identify what was working and where we could improve. Some of our key iterations included:
We brought down Market Research and Comparable Properties from the top navigation into the sidebar. Users had trouble identifying where third level categories such as demographics were located when they were hidden under a dropdown in the top navigation bar.
Users did not immediately recognize that they could filter their comp set because the comp set filters looked too much like a header. They also wanted more customizability when adding comps to their comp set, for instance filter by the number of bedrooms.
In the comp detail popup, users not only wanted to see information on that particular property, but also how the property compared to the comps in their comp set. We included a comp set average bar on each metric so users could benchmark against their comp set.
Users wanted to see the how, what, and why of RentHub. Although we included the ability to export data, users said they would also like to see an overview of how it all worked. We added a “How RentHub works” section to the top nav in order to built trust with users.
We were able to identify and iterate on these areas from our initial designs. But in general, users overwhelmingly gave positive feedback about the overall layout and functionality of the prototype. They loved the split screen and the ability to see the map at all times. They also really liked the interactivity of the map, especially the heat map and ability to layer data.
After implementing our final iterations, we presented the final prototype to our client. A product that would significantly reduce the time needed to research a submarket for a multifamily property investment.
Our client was thrilled with the final prototype design. They plan to use our prototype to pitch to future investors. Our designs will also be utilized by a UI team in the summer of 2017 to flesh out the visual design of the product.
In the final presentation and handoff to the client, we developed a product roadmap and collaborated on implementation phase planning. Given the time and resource constraints of our client, everything wouldn’t be able to be implemented right away.
Our team listed out and rated the features of our proposed solution on a scale of 1-5, based on the impact on user experience. RentHub’s developer then rated on a scale of 1-5 the difficulty of implementing the various features we identified. Using these two metrics, we plotted on a Impact/Difficulty matrix to help Kelli and the RentHub team plan which features to implement first.
Presenting the final designs to our client and discussing our recommendations for the product roadmap.
We also delivered annotated wireframes, detailing every possible state of the product along with supportive research and instructions to assist in future product development.
Our team delivered three sets of annotated wireframes for use in future work by UI, Interaction Designers, and Developers.
This project taught me the importance of taking the time to understand the intricacies of the industry you are designing for through extensive domain research. This was especially challenging with RentHub because there was so much to learn in such a short amount of time.
We were completely unfamiliar with the space coming into the project, yet were able to talk like industry professionals by the time we presented our final designs. This added credibility to our design decisions and reassured our client that we understood the space and their users.