Designing within an
Enterprise Tax Platform
Introduction
Over eleven months, I collaborated with individual product teams across the platform on work that ranged from pilot enhancements to 0-to-1 product ideation, always in service of a better experience for internal customers.
Two deep dives below show this method in action:
Use tax calculation: two major feature rollouts
Audit tax compliance: design for regional rollout
Other surfaces I owned during my time included:
Budget and matter management: three feature rollouts
Energy procurement account management: phase 1 product ideation
Global procurement tax tool: pilot product ideation
Intercompany tax calculation: one major feature rollout
Intercompany tax data registration: one feature rollout
Tax data rule engine: two feature rollouts
Tax data unification: phase 1 product ideation
Tax document management: experience audit and enhancement recommendations
Tax obligation management: one feature rollout
Tax reporting tool: one feature rollout
Ramping Into Unfamiliar Domains
Independent Research
The product teams were new to collaborating with a designer and were often unsure what to share. I ran independent research, reviewing any documentation, metrics, or surveys I could find to understand the problem space and the domain.
Eliciting Requirements Through Mockups
I dug into the specific problems the team had to solve. Requirements were often underdefined, so the PM sometimes ran intermediate discussions with internal customers to gather detail, and at times I conducted those customer interviews directly.
Given the time pressure and short product cycles, I used mockups as my primary tool for eliciting requirements. Rather than wait for fully specified requirements, I would encode a set of assumptions into an early mockup, use it to make my design rationale concrete, and let stakeholders react to something tangible, which surfaced the real requirements faster than discussion alone.
I chose this over upfront user testing deliberately. With rapid iterative rollouts, designs that missed the mark surfaced and got corrected in later cycles anyway. And the value of this work was in surfacing the right underlying data, not in interface polish, so getting the data correct mattered more than testing the presentation up front. Front-loading testing would have cost time without changing the outcome much.
Reading the System
Once I had learned the domain through a single product, I analyzed the broader patterns of tax work: what a given team was trying to accomplish and which transaction data they analyzed. Tracing which data users needed, where it came from, and the context required to make sense of it was the bulk of the work across the platform.
A Gap Beyond My Scope
During my engagements I tried to map how tax teams worked across products, and it was clear the surfaces were fragmented. Teams whose work spanned several surfaces had to learn and move between disconnected tools, and because each surface was owned separately, no one was positioned to see that burden. A cross-surface experience map could open the door to designing at the system level, across the ecosystem rather than one surface at a time. Acting on it would have required cross-product ownership the org structure didn't have, but it's the kind of system-level problem I'd want to take on.
Laying out the surfaces this way is what made their fragmentation visible to me. Each was designed on its own terms, and no single view connected them.