Operators weren't avoiding ZoneSage because it was hard to use. They were stalling because they didn't trust it enough to replace their existing system. That became the design problem.

Operators weren't avoiding ZoneSage because it was hard to use. They were stalling because they didn't trust it enough to replace their existing system. That became the design problem.

Role:

Founding Product Designer

Scope:

Scope:

Scope: End-to-end: Research → UX → UI → testing → iteration

0→1 financial operations platform for short-term rental owners, spanning transaction ingestion, categorization, reporting, and tax-ready outputs.

Scope: End-to-end: Research → UX → UI → testing → iteration

Focus:

Designing trust-critical workflows, data clarity, and reversible automation in a financial system.

Duration:

Aug 2023 - Dec 2024

Status:

Completed · Dec 2024

/Overview

Designing for Trust in High-Risk Financial Workflows

ZoneSage was a financial operations platform for short-term rental operators, built to track transactions, categorize expenses, and generate tax-ready reports. The structural opportunity was real: tax advantages in short-term rentals only materialize when transactions are recorded with precision. Most operators were leaving money on the table.

The design challenge wasn't simplifying the interface. It was earning enough trust that operators would replace a financial workflow they already relied on.

/Problem Framing

Adoption Was Limited by Trust, Not UI

Switching financial systems introduced asymmetric risk. Once data was imported and automations ran, errors were difficult to detect and costly to unwind. Operators didn't need a simpler interface. They needed to know every decision could be inspected and corrected before it touched real records.

The system had to earn trust before it could earn usage.

The system needed to:

Enable easy migration of historical financial data

Support accountant validation

Preserve visibility and control in manual workflows

/System Foundations

Defining the Financial Interpretation Layer

Before building product surfaces, we had to define how financial data would be interpreted.

Short-term rental operators reason across overlapping tax categories, property-level allocations, and jurisdiction-specific rules. Existing tools treated transactions as generic ledger entries. In practice, operators did not.

A significant portion of the work focused on mapping real transaction patterns to tax-relevant categories, defining attribution rules across properties, and modeling how accountants validated records.

Trust depended on formalizing this interpretation layer. Once the rules were explicit, reviewable, and testable, the rest of the system could be built on top of it.

/System Architecture

Earning Trust Through Sequence

In a trust-critical domain, automation could not lead. Confidence only emerged when users could see how data was interpreted, intervene when uncertain, and validate outcomes before relying on it.


Before designing any screens, we defined the minimum sequence required for trust:

Data Ingestion · Contextualization · Visible Logic · Actionable Insight

This sequencing clarified where friction was necessary and where it would permanently block adoption.

/Key Design Decisions

Where trust actually formed

Trust formed at the transaction level.

Users could see how raw financial inputs were interpreted, where the system was uncertain, and intervene before automation affected real records.

Confidence did not come from dashboards. It came from making system logic visible and correctable at the point of decision.

Resolved transactions

Requires review

/Key Design Decisions

Designing for Metric Prioritization, Not Static Dashboards

Different operators prioritize different signals based on portfolio size, ownership model, and operational goals. A fixed dashboard couldn't serve all of them.


ZoneSage introduced a composable metric system that let users surface what mattered most while preserving structural hierarchy. This shifted the product from reporting data to supporting decisions.

/Outcome

What Shipped and What We Learned

ZoneSage successfully reduced early adoption friction through transparent data framing, visible system logic, and progressive automation. Users could validate outputs and build confidence incrementally.

However, full replacement required more than interface trust.

Sustained adoption depended on structural factors outside the product. Larger operators still relied on accountants for official filings, limiting incentive to switch. Smaller operators often did not require specialized tooling at all.

Expanding into formal tax filing introduced regulatory and authorization constraints that narrowed the viable market.

Design accelerated trust. Market structure determined scale.

"ZoneSage has absolutely transformed the way I do my finances for 30+ properties. Incredible."
Jay Ulrich, Property Manager · San Diego

/Reflection

How This Project Strengthened My Product Judgment

ZoneSage clarified the boundary between problems design can solve and constraints that are structural.

It strengthened my ability to identify irreversible user moments, where confidence must exist before action. In trust-critical systems, reducing friction is not always correct. Sometimes friction is the product.

This was the first project where correctness had to precede convenience. Clarity had to come before automation.

The experience reinforced a principle that continues to guide my work: in complex domains, system design and interface design cannot be separated.

Some products fail because of UX. Others stall because of incentives, regulation, or market structure. Knowing the difference is part of product judgment.

Selected Work.

© Chrisk Studio

A focused selection of product work and the decisions behind it.