Solving the Real Problem
How research challenged an approved direction and led to a better solution for Collections and Settlements
overview
Heritage Auctions is the world's largest collectibles auctioneer, supporting over 2 million registered online bidders across more than 50 categories. Behind every successful auction is a network of internal teams managing the financial operations that make it run accurately, on time, and at scale.
Two of those teams are Collections and Settlements, both part of the Accounting department. Collections ensures clients pay for their auction purchases; Settlements manages payments to consignors. Because these teams operate in sequence, a breakdown in one directly affects the other. Miscommunication, missed deadlines, or manual errors can result in incorrect payments, compliance risk, and damaged client relationships.
This case study follows an initiative I led for the Collections department — one that began as a straightforward request and evolved into something considerably more complex once research revealed what was actually going wrong.
MY Role
Lead UX Designer
Researcher
Strategist
Project Lead
TEAM
UX Designer
Project Manager
Application Engineer
SQL Engineer
UX Research
Stakeholder Alignment
Workflow Design
Automation
the brief
Leadership's request was straightforward: Collections needed a way to submit requests to Settlements through the internal application rather than via email, and Settlements needed a simple review process to manage incoming requests. The proposed solution was a request form, already scoped, approved, and ready to build.
Research & Discovery
Although the direction had already been approved, I approached discovery without assuming a form would ultimately be the right solution. The goal was to understand how requests were created, fulfilled, and impacted downstream work across both teams before converging on anything. I also wanted to surface the root causes behind missed deadlines, errors, and operational risk that the original brief hadn't accounted for.
To do that, we used a mix of qualitative and quantitative methods: user interviews across Collections, Settlements, and Account Management; field observations of Settlements completing live requests; data analysis of historical spreadsheets and request logs; artifact review of emails and trackers; cross-functional workflow walkthroughs; and engineering code reviews to validate system behavior against user perception.
1
User interviews
Conducted across Collections, Settlements, and Account Management to build a holistic view of the request lifecycle from every role involved
2
Field observations
Shadowed Settlements completing live requests to map end-to-end workflows, identify handoffs and wait states, and observe the real cognitive load involved
3
Data and artifact analysis
Reviewed historical request logs, spreadsheets, cycle times, and email threads to validate stakeholder claims and identify patterns in timing and volume
4
Cross-functional workflow walkthroughs
Facilitated sessions across both teams to align on the full request lifecycle and surface gaps in shared understanding
5
Engineering code review
Partnered with Engineering to validate which actions were automated versus manual, confirming that users' mental models accurately reflected real system constraints
Five findings reshaped the direction of the project:
1
Misaligned mental models
Collections viewed requests as lightweight tasks. Settlements experienced them as complex, high-risk, multi-step workflows with significant coordination overhead.
2
Requests are not uniform units of work
Each request type varied significantly in effort, dependencies, system touchpoints, and risk. A single form could not meaningfully address all of them.
3
Timing, not tracking, was the core issue
Late submissions, often triggered by upstream events outside Settlements' control, were the primary driver of errors and missed deadlines.
4
Operational risk was systemic
Manual workarounds, post-check corrections, and rework introduced financial and compliance risk that a submission form would not reduce.
5
A form alone would not solve the problem
The research reframed the problem from "missing structure" to missing shared understanding, prioritization, visibility, and standardized processes.
Strategy & Alignment
Reframing the Problem
Once it became clear that a single request form would not meaningfully improve outcomes, I worked with Product, Engineering, and Operations leadership to reset the scope. Rather than treating "Collections Requests" as one feature, I proposed breaking it down by request type and addressing each as an individual workflow with its own constraints, risks, and automation opportunities.
This meant challenging a direction that had already been approved by Collections leadership and a Senior VP. It also meant surfacing an uncomfortable reality: improving outcomes would require changes on both sides of the workflow. Not just better tracking for Settlements, but more accountability and structure in how Collections submitted requests.
Roadmapping the Solution
To support this shift, I synthesized research findings into a phased roadmap that prioritized request types based on frequency, manual effort, and operational risk. This allowed the team to deliver value incrementally rather than building a generalized solution that wouldn't scale.
The reframe also had real implications for timeline and resourcing. Solving fulfillment properly required data restructuring, backend logic, and dedicated support from both an application engineer and a SQL developer, significantly expanding the original scope. I worked closely with Product and Engineering to define a sequencing plan that balanced delivery urgency with long-term system integrity.
Aligning Stakeholders
Because our COO oversaw both IT and Project Management, moving forward required a strong, evidence-backed case that extended beyond design. I facilitated working sessions to walk stakeholders through end-to-end fulfillment workflows, highlighted where manual effort and delays occurred, and clarified which problems automation could and could not solve.
This shifted the conversation from "faster submissions" to "safer and more efficient fulfillment" and ultimately earned buy-in to invest the additional time and scope required to address the real problem.
Of the request types identified in the roadmap, Do Not Pay / Pay Consignor is the focus of this deep dive. It is high-volume, time-sensitive, and carries both financial and reputational risk, making it a strong example of how we approached research, problem reframing, and solution design across the broader initiative.
Context
When a client fails to pay for an auction purchase, the corresponding consignor's payment must be withheld — a "Do Not Pay" request. When the client pays, the consignor's payment must be reinstated — a "Pay Consignor" request. The purpose of this workflow is to ensure that on settlement day, consignors receive the correct settlement payment.
Existing Workflow
Mapping the full end-to-end workflow revealed how heavily manual the process was at every stage. From separating lots by consignor to reviewing agreements, calculating commission rates, entering line items across multiple systems, and maintaining a tracking spreadsheet — each step required significant effort from Settlements. The core issue was the volume of work required to process a single consignor's withheld payment. Multiply that across multiple consignors per invoice, and multiple invoices per auction, and the workload became unmanageable, especially with requests arriving days before settlement.
Redesign Goals
1
Reduce manual research and calculations
Surface consignor agreements, rates, and lot-level details within the workflow
2
Standardize request submission
Replace email with a structured process that ensures required information is included upfront
3
Improve cross-team visibility
Give both teams a shared system to track request status without spreadsheets or follow-up emails
4
Reduce last-minute operational risk
Introduce timing awareness and guardrails to prevent requests from arriving after checks are cut
5
Establish a scalable foundation
Create patterns that support additional request types across the broader initiative
Proposed Workflow
The redesigned workflow eliminates the majority of manual steps by automating the handoff between Collections and Settlements. Rather than receiving an email, Settlements receives a structured task list per consignor with amounts already calculated. Submitting the task handles the rest: updating the Settlements application and replacing the manual spreadsheet. For the first time, both teams have shared visibility into request status, and the system handles payment reversals without Collections acting as a middleman.
Impact
The Do Not Pay / Pay Consignor workflow has passed testing and is moving toward production. Quantitative metrics are pending post-launch, but the qualitative signal from the broader initiative is clear: stakeholders who initially backed a simple form are now aligned behind a phased, workflow-by-workflow approach, and the first workflow reflects a materially different level of rigor than what was originally scoped.
Learnings
This project reinforced that being a strong UX designer sometimes means being a strong advocate, not just for users, but for the right problem. The original brief wasn't wrong because of bad intentions; it was wrong because no one had mapped the full picture yet. Research gave us that picture, and the design work gave us credibility to act on it.
Convincing stakeholders to expand scope, timeline, and resourcing on a project that already had an approved direction required more than good research. It required framing findings in terms of risk and business impact, not just user experience.
This project also clarified how to evaluate when additional development investment is genuinely worth it. The expanded scope added engineering complexity and delayed delivery. But building the right thing, even slowly, was demonstrably less costly than shipping a form that would have solved the wrong problem.