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 were reviewing every property every year because nothing told them which ones were actually mispriced. The design job wasn't a better calculator; it was triage.

For the reader: If you're hiring a product designer who measures success by whether the tool actually gets used - not whether it ships - this one's for you. There was already a tool. Nobody touched it. Understanding why is the whole story.

---

01Project Overview & Context

The hook

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

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

The fragility was the real pain point. One missed data point could throw off the calculation that determined whether a client was overpaying. As one person put it to me, 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 really 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 - 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, so there was no single product to design - there were 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 actually needed. That was the most important fact in the whole project: shipping software here was clearly not the same as solving the problem.

Underneath all three was the real question the analysts were drowning in: of all these client properties, which ones are even worth reviewing this year? The old answer was essentially "all of them." Analysts made educated guesses about where to look, but as one user told me, they really had to look at everything - 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 actually adopt - the opposite of the tool already gathering dust.

---

03Process & Methodology

Research & insights

With the product owner, we identified five key players and made them our go-to partners for the life of the project. We used them for three things:

1. Learning the existing processes - how each jurisdiction actually worked, not how a process doc claimed it did.
2. Understanding the business - the domain of assessments and valuations, so design decisions were grounded in how the firm actually made money for clients.
3. Co-designing a testable process - building something concrete we could put in front of them and iterate on quickly, driving toward a common process rather than imposing one.

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

The other clarifying discovery: what looked like dozens of incompatible jurisdiction processes was, underneath, a smaller set of real differences - how each jurisdiction assessed value, and which valuation method applied and how comparables were used within it. Once the differences were named 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 analysts still had to point at every property themselves. Why: The bottleneck was never calculation speed; it was deciding where to spend attention. Educated guessing across thousands of properties doesn't scale. Making the software do the triage - and show its reasoning - is what turned an unwinnable review pile into 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 attacks both at once - 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 actually varied: assessment approach and valuation method - supporting 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 while still respecting each jurisdiction's rules - a common process that didn't force 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. Continuous validation with real users was the direct countermeasure. The goal wasn't to ship; it was to build the thing people would actually open.

---

04The Final Solution

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

• A triage engine - evaluates client properties and flags which ones warrant review, with a clear visual indication and the reason why, so analysts spend their time on the properties most likely to win a reduction.
• Reusable records - property data carries forward year to year, ending the annual re-entry cycle and the 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, not for them - validated continuously with the five key stakeholders so it wouldn't share the fate of the tool it replaced.

---

05Outcome & Impact

What changed (measured post-launch)

• 60-70% reduction in time spent evaluating client properties. By triaging properties and clearly signaling which to review and why, the system removed the "look at everything" burden that had defined the old workflow.
• A dramatically 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 - designed to flex on assessment approach and valuation method rather than fragment.

The number that matters most

In the end, we built something 95% of users wanted us to build - the sharpest possible contrast with the tool that came before it, which nobody used at all. For an internal product, adoption is the success metric, and this is the measure of it.

Learnings - what I'd do differently

The best feature in the product - the triage / reduction-opportunity engine - wasn't in the original brief. It surfaced because we embedded with five real users and listened. That's the lesson I carry forward: on enterprise tools, the highest-value idea is usually already in a user's head, phrased as a frustration ("we have to look at everything"), and the job is to hear it as a design opportunity rather than a complaint.

The cautionary half is 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 validated that it would. Given the chance to run it again, I'd formalize that validation even earlier - put testable process artifacts in front of users before a line of production code is written, every time.