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:

Role:

Founding Product Designer

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:

Focus:

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

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

Duration:

Duration:

Aug 2023 - Dec 2024

Aug 2023 - Dec 2024

Status:

Status:

Completed · Dec 2024

Completed · Dec 2024

Disclosure:

Disclosure:

UI shown: Final redesign completed pre-closure. Earlier version remains live at zonesage.com.

UI shown: Final redesign completed pre-closure. Earlier version remains live at zonesage.com.

/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.

Fintech is slow to earn trust. The design challenge was making ZoneSage feel safer than the manual workflows operators had relied on for years.

/System Requirements

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 review and validation

Keep operators in control

/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.

Not the actual decision chart*

/Design Approach

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.

Raw Financial Inputs

Transactions, properties, and bank feeds enter the system as unstructured data with varying context and reliability

System Interpretation Layer

Rules and logic determine how financial data is structured, categorized, and trusted.

Interface Outputs

Dashboards, tables, and reports reflect the system's interpretation.

/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

Flexible Metrics for Every Operator Type

Operators told us a fixed dashboard didn't match how they actually worked. Someone managing one property needed a quick summary. Someone managing thirty needed depth across multiple signals at once.

The redesign introduced flexible graph selection: operators choose exactly which metrics to surface and how many. A single property owner might show three charts. A multi-property manager might show twelve. The same system serves both without compromise.

Based on operator feedback we also introduced dark mode and a refreshed visual language, giving the product a more professional feel that matched the financial context operators were working in.

Flexible chart selection — operators build their own view

/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.

But product trust alone was not enough to support long-term scale. Larger operators still depended on accountants for final filings, while smaller operators often lacked urgency for dedicated tooling. Moving deeper into formal tax workflows also introduced regulatory and authorization constraints that narrowed the opportunity.

At the same time, we were building a second company that showed stronger traction and clearer market pull. Given limited time and resources, we chose to focus on the business with greater momentum and shut ZoneSage down.

Design accelerated trust. Market structure and business prioritization determined where we invested next.

"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.

Selected Work.

Selected Work.

© Chrisk Studio

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