Improved
Expense Comp Search & Filtering

I’d use this data all of the time if I could parse through it more easily. What we have right now is unusable.
— bowery user

Discover

Similarly to how an appraiser must use comparable sales of similar nearby properties to justify the appraised sale value of their subject, they must also use the expenses of similar nearby properties in order to evaluate and estimate the cash flow of their subject in upcoming years. These sets of building expenses are known as Expense Comps, and like other comps, the information around building expenses can be fragmented, inaccurate, and hard to locate. At Bowery we have created a database of expense comparables for internal use in order to alleviate some of the pain of searching for expense info in the public domain.

The Problem


The on-app search and filtering process for expense comps hasn’t been modified since it was first created, over five years ago. The company has grown significantly since this point, and we have expanded into appraising many new asset types and geographies. The expense data we have on-app wasn’t organized in a scalable way, and the on-app expense page has lost its utility for many appraisers at the company who simply cannot use the data we have in their appraisals, or who have found sources of expense comps that are more suitable for the needs of their work.

The Opportunity

We recently implemented a feature known as “Subject as Expenses,” which is the same concept as Subject as Sales (read more about that here). In capturing subject expense data to submit to our on-app database, we have enriched our database with approximately 10,000 expense comps to date. This provides us with an excellent opportunity to re-evaluate the design of our expense comp search page, and the underlying architecture of how our expense data is stored.

The Hypothesis

We believe that appraisers will have to spend less time searching for and validating expense comparable information if we can provide them with a robust collection of on-app expense data and an efficient way to search through and sort it.

The Technicalities

  • The goal: Reduce time spent off-app searching for and verifying expense comparable details; bring more appraisers on-app for the income approach

  • Timeline: 2 weeks

  • Tools used: Paper & pencil, Google Forms, Miro, Figma

  • Process: you guessed it! The double diamond 💎


Understanding the Problem

I began by referencing existing research I had conducted on previous expense-related features, such as Subject as Expenses, to establish a baseline understanding of the difficulties users had with the existing expense comparable search & filtering. I followed up in a few cases with individual appraisers in order to have a more targeted conversation about their process. I also ran a follow-up survey of 7 questions with 14 participants

  • What are some of the most painful or tedious parts of finding expense comps to use in your reports?

  • If we stored additional pieces of information about comps on-app, what would be helpful to know about an on-app expense comp in order to feel more comfortable using it in a report?

  • What part of the expense comp search and selection process takes you the most time?

On average, how long does it take you to find and verify a full set of usable expense comps for a report?

How likely would you be to use on-app stored expense comps in your reports if they always contained the information you previously mentioned? (Address, building type, unit breakdown, etc.)

Expense comps are weird. They’re not as heavily scrutinized as other types of comps where the information is publicly verifiable, like sales. You don’t need as much information in a set of expenses, and so often times a comp in our database will have the minimum required amount of info. Sometimes I’ll find one that looks usable, but I won’t even know what city or state it came from!
— bowery user

How reliable do you find Bowery internal expense comp data?

I asked questions like:

Define

Who are we trying to help?

Once I felt like I had a solid understanding of the problem I was trying to solve, I jumped into Miro to assemble my research into one space. I pulled key quotes, insights, and pain points from the survey and discussions with users in order to firmly illustrate the user I was designing for. I was able to assemble the following user story from that data to help scope the rest of my process for this project, and anchor myself to a specific goal.

As an appraiser working on Mixed Use & Multifamily properties on-app, I want to more easily search and filter expense comps on-app, so that I can quickly identify important details about a comp and include it in my report.

With the help of another teammate, I put together a few separate task flows for how an appraiser might go about finding expense comps off-app to really demonstrate the inefficiencies of the current process.

Develop

Need for Speed

Because of the high level of visibility on my project, I was encouraged by key stakeholders to get this feature into the hands of our users quickly. This meant that a 3-week project had to be condensed into a sprint lasting less than 2 weeks. Typically I would run this project through a large collaborative ideation with several members of my team from design, product, and engineering. Because of the time-crunch I felt that I had enough compelling data about what appraisers felt was lacking in our on-app expense data.

In order to compromise between a shortened timeline and stakeholders’ requests to deliver more quickly, I chose to implement a solution that re-used a component that exists on a different comparable search page in the app. This way we would be able to shorten time to delivery, and my engineers wouldn’t be working on an entirely new feature from scratch during a smaller sprint cycle.

I’m the Map!


Within the Sales Comparable Search page on the application, we have a map-based search that allows appraisers to sort their comps by location, as well as additional advanced filters. This page has been extremely well-received by appraisers in the past few months, and has been shown to significantly increase the efficiency of appraisers who search for and select their sales comps on-app.

After speaking with members of my engineering team, I was given their blessing to pursue a solution similar to this for the expense comp search page, as we felt confident that in re-using the map component we would be able to cut down on development time without having our QA or dev team having to work extra hours in order to meet the tight deadline.


Testing, testing….

I assembled my research plan in Notion and drafted a testing scenario in which appraisers were asked to filter their expense data and identify usable expense comps based on a set of parameters given by me. I ran five remote usability tests with appraisers at the company that did all or a majority of their work on the application. The designs scored an average of 4.8 usability points out of 5, and all five users stated they felt that the filtering and search system for expense comparables was significantly improved.

The prototype tested with users

Deliver

The Prototype

How did we do?

After testing, I collaborated with my Senior UX Researcher to run a GOMS analysis on the new designs, using the task flows I had assembled earlier as the basis of comparison. We found that the Improved Expense Search and Filtering feature:

  • Made appraisers 68% more efficient

  • Would save an estimated total of 166 days, 22 hours, and 37 minutes across all appraisers at the company over 3 years

  • Would allow 92 additional reports in 1 year to be completed across all appraisers at the company

    • 276 additional reports in 3 years

  • Increased estimated yearly revenue per appraiser by $3,800

    • $349,600 yearly across all appraisers

    • $1,048,800 across all appraisers over 3 years

Next Steps

  • Because of the short project timeline and additional pressure from stakeholders, I didn’t have the luxury of exploring alternative solutions to the problem besides re-using existing search patterns.

  • If I had the opportunity to iterate on this project, instead of leaning on existing components, I would love to spend additional time in ideation to see of there are any new design patterns I could introduce into the application that would be more suited for surfacing expense data specifically.

  • I have a hunch that because expense comps aren’t as heavily scrutinized as other comp types, some sort of ‘suggested comps’ or ‘smart filtering’ feature would significantly reduce the time appraisers spend combing through the data looking for acceptable sets of expense data to use as comps.

Takeaways

  • Working directly with engineering through the entire design process is the key to delivering a robust feature on a not-so-robust timeline, and an excellent way to cut down on lead time for developers

  • Compromising on project timelines by leaning on existing application functionality is often a win-win for Product, Design, and Engineering, as long as you have the opportunity to iterate on the feature with more resources in the future.