Product Ownership
Defined requirements, priorities, workflows, and product direction with technical and domain stakeholders.
Case Study
Product Design and Business Analysis
Tax Data Processor
Turning incomplete financial data into tax-ready data through a highly configurable pre- and post-processing utility.
Overview
Complex tax calculations depend on the right data.
Enterprise tax calculation depends on accurate, tax-sensitive data. But the financial systems feeding our tax engine were often designed for accounting and transaction processing—not tax.
As a result, critical tax attributes were frequently missing, incomplete, or represented in ways that were not sufficient to calculate tax correctly.
I served as both UX Designer and Product Owner on a specialized cross-functional team tasked with solving that problem.
The System
Bridging the gap between financial data and tax calculation.
Source
ERP / Financial System
Incomplete transaction data
→
New Capability
Pre / Post Processor
Derive, enrich, transform, and validate data
→
Calculation
Tax Engine
Receives tax-sensitive data
→
Output
Tax Result
More reliable downstream processing
The Challenge
Source systems were not built with tax in mind.
The tax engine could only produce accurate results when it received the right inputs. Unfortunately, those inputs varied widely from one customer and financial system to another.
A transaction arriving from an ERP might contain basic information such as a product, customer, amount, or location, while lacking other attributes needed to determine the correct tax treatment.
Customers needed a way to derive those missing values from the information they already had—without rewriting their ERP systems or building large amounts of custom integration code.
How do you give expert users enormous flexibility without making a powerful system impossibly difficult to understand and configure?
My Role
I worked across product strategy, UX design, and delivery.
UX Design
Designed a sophisticated configuration experience for complex tax-data transformation rules.
Systems Thinking
Mapped relationships between source financial data, preprocessing logic, tax calculation, and downstream processing.
User Research
Introduced usability testing with real users and incorporated observed behavior into design decisions.
The Solution
A configurable rules engine around the tax calculation process.
We designed a configurable processing utility that operated around the tax calculation engine.
Before calculation, the system could evaluate incoming transaction data and apply configurable rules to derive or transform the additional tax-sensitive attributes the engine required.
After calculation, it could also process and transform resulting data when customers needed additional downstream handling.
Rather than building a rigid set of predetermined rules, we created a flexible configuration model that allowed customers to define their own logic.
If these conditions are true...
derive or modify these values in this way.
Designing for Complexity
Power without unnecessary cognitive overload.
Clear sequencing
Make the order of rules and processing steps visible and understandable.
Consistent patterns
Use repeatable interaction patterns for conditions, transformations, and outcomes.
Progressive disclosure
Expose advanced options when needed rather than overwhelming users up front.
Domain language
Use terminology that reflects tax and business concepts rather than system architecture.
Visible relationships
Help users understand how data moves through the configured processing logic.
Useful guardrails
Help users build valid configurations without removing the flexibility expert users require.
Usability Testing
We tested the design with real users.
At the time, usability testing with customers and users was not a routine part of the company’s product development process.
I created prototypes and tested the emerging design with people who worked with tax configuration and transaction data.
Instead of relying solely on internal assumptions, we observed users attempting realistic configuration tasks.
The sessions revealed where terminology was unclear, where workflows did not match users’ mental models, and where the flexibility of the system introduced unnecessary cognitive load.
Those findings directly influenced the design. We refined interaction patterns, clarified terminology, simplified portions of the workflow, and improved the way complex rule relationships were presented.
Outcome
Complex software does not have to become simple by removing capability.
The completed processor became a highly successful part of the tax calculation platform and addressed an important limitation in enterprise tax integrations.
It allowed organizations to adapt imperfect source-system data for tax calculation without requiring extensive changes to the systems producing that data.
The project reinforced a principle that became central to my approach to enterprise UX: complexity can be made usable by giving it the right structure.