Commercial Real Estate Valuations - Designing for the properties that matter

Thesis: The firm didn't have a valuation problem. It had an attention problem. Analysts reviewed every property every year because nothing told them which ones were mispriced. A better calculator wouldn't fix that. Triage would.

For the reader: If you're hiring a product designer who measures success by whether people use the tool, not whether it ships, this one's for you. There was already a tool. Nobody touched it. This case study is about why.

---

01Project Overview & Context

The hook

At a national property-tax advisory firm, a large portion of revenue came from one thing: getting clients' commercial real estate assessments reduced so they weren't overpaying property taxes. Find the apartment building, warehouse, or office tower the county has over-valued, build the case, win the client a lower assessment. That's the business.

The entire operation ran on Excel. Every jurisdiction had its own spreadsheets and its own process for walking a client through valuation and assessment. Behind it sat a large data-entry team overseas, re-keying the same property data into the same sheets every year (number of units, square footage, income figures) for thousands of properties.

The fragility hurt most. One missed data point could throw off the calculation that determined whether a client was overpaying. One person told me this over and over:

"We'd have to enter the number of units for an apartment building over and over, and if we missed something, we'd look really incompetent to our clients."

That fear of looking incompetent in front of a client because a cell was wrong is what the project was about.

My role

Lead Product Designer, working alongside the product owner. I owned research, the process-design work with our stakeholders, interaction and visual design, and the design system that let the software flex across jurisdictions.

Timeline & tools

Timeframe: January 2025 to January 2026 (roughly one year, end to end).

Approach: Stakeholder-embedded research with five key users, iterative and testable process design, and a flexible component/system approach so one product could serve many jurisdictions.

---

02The Problem Statement

The challenge

Three problems, tangled together:

1. No common process. Each jurisdiction guided clients through valuation differently. There was no single product to design, just dozens of Excel dialects.
2. Brutal, error-prone data entry. A large overseas team re-entered the same property data annually. The work was repetitive, the stakes were high, and a single miss could invalidate a client's case.
3. A tool nobody used. A valuations tool had already been built before I arrived. It sat unused because it didn't do what the analysts needed. That was the most important fact in the project. Shipping software here wasn't the same as solving the problem.

Underneath all three was the question the analysts were drowning in: of all these client properties, which ones are even worth reviewing this year? The old answer was basically "all of them." Analysts made educated guesses about where to look, but as one user told me, they had to look at everything. That's an unwinnable amount of work.

Objectives

1. Triage, not just calculate. Tell an analyst which properties to review and why, so attention goes where the money is.
2. Kill the annual re-entry. Make records reusable year over year instead of rebuilt from scratch.
3. One flexible process. A single common workflow that could still bend to each jurisdiction's assessment rules and valuation methods.
4. Build something people adopt. The opposite of the tool already gathering dust.

---

03Process & Methodology

Research & insights

The product owner and I picked five key players and made them our go-to partners for the whole project. We worked with them on three things:

1. Learning the existing processes. How each jurisdiction actually worked, not how a process doc said it did.
2. Understanding the business. Assessments and valuations, so design decisions were grounded in how the firm made money for clients.
3. Co-designing a testable process. Something concrete we could put in front of them and iterate on quickly. We worked toward a common process with them instead of imposing one.

The best idea came from one of these stakeholders: a tool that could identify opportunities for a possible reduction in property value, surfacing the properties most likely to be over-assessed. It wasn't on the original brief. It came from listening, and it became the center of the product.

We also found that dozens of incompatible-looking jurisdiction processes came down to a smaller set of real differences: how each jurisdiction assessed value, and which valuation method applied and how comparables were used within it. Once we named those differences precisely, one flexible product could absorb them.

Design decisions (the why)

1. Design for triage. Turn "look at everything" into "look at these, here's why." The system evaluates properties and gives a clear visual signal that a property should be reviewed, with the reason attached. Considered instead: a faster version of the old workflow. A better calculator that analysts still had to point at every property themselves. Why: Calculation speed was never the bottleneck. Deciding where to spend attention was. Educated guessing across thousands of properties doesn't scale. Once the software did the triage and showed its reasoning, an unwinnable review pile became a ranked, defensible worklist.

2. Make records reusable year over year. Property records persist and carry forward instead of being re-entered every cycle. Considered instead: keeping the annual re-keying workflow and just speeding up data entry. Why: The repetitive re-entry was both the largest cost (a large overseas team) and the largest risk (one missed field invalidating a case). Reuse fixes both. It removes the work and the failure mode, instead of just making a fragile process faster.

3. Design one flexible product, not one tool per jurisdiction. A common process and component system, built to flex on the two axes that varied: assessment approach and valuation method. It supports the sales-comparison (comps), income (cap-rate / NOI), and cost approaches. Considered instead: separate tooling per jurisdiction, mirroring the Excel-dialect status quo. Why: Per-jurisdiction tools would have re-created the fragmentation we were trying to end. Isolating the real variables meant one product could serve everyone and still respect each jurisdiction's rules. Common process, no false uniformity.

4. Earn adoption by solving the abandoned tool's failure. Every decision was tested against the five stakeholders before it hardened. Considered instead: trusting the spec and building to it, the way the first, unused tool had been. Why: A tool already existed and failed for one reason: it didn't do what users needed. Validating with real users the whole way through was the direct fix. We wanted to build the thing people would open.

---

04The Final Solution

A single valuations product that replaced the tangle of jurisdiction spreadsheets:

• A triage engine. It evaluates client properties and flags which ones need review, with a clear visual signal and the reason why. Analysts spend their time on the properties most likely to win a reduction.
• Reusable records. Property data carries forward year to year. No more annual re-entry, and no more missed-field risk that came with it.
• A flexible valuation system. One common process that bends to each jurisdiction's assessment rules and supports the comps, income, and cost valuation methods.
• A product built with its users. We validated it with the five key stakeholders throughout so it wouldn't end up like the tool it replaced.

---

05Outcome & Impact

What changed (measured post-launch)

• 60-70% reduction in time spent evaluating client properties. The system triages properties and shows which to review and why, so analysts no longer have to look at everything.
• A much smaller data-entry footprint. Reusing records year over year reduced the need for the large overseas data-entry team that had been re-keying property data every cycle.
• One common, flexible process replaced the per-jurisdiction Excel dialects. It flexes on assessment approach and valuation method instead of splitting into separate tools.

The number that matters most

In the end, we built something 95% of users wanted us to build. Nobody used the tool that came before it at all. For an internal product, adoption is the success metric.

Learnings - what I'd do differently

The best feature in the product, the triage / reduction-opportunity engine, wasn't in the original brief. It came up because we embedded with five real users and listened. That's what I carry forward. On enterprise tools, the best idea is usually already in a user's head, phrased as a frustration ("we have to look at everything"). My job is to hear it as a design opportunity and not just a complaint.

Then there's the tool that already existed. Someone built a reasonable-looking valuations tool, and it failed completely for one reason: it didn't do what people needed, and no one had checked that it would. If I ran this again, I'd formalize that validation even earlier. Testable process artifacts in front of users before a line of production code is written, every time.