From inventory dashboards to actionable reconciliation

The dashboard showed discrepancies. It did not help users resolve them.

The original experience centered on totals, matches, mismatches, and high-level widgets.

That created visibility, but visibility was only the beginning of the job.

A discrepancy did not necessarily indicate a problem. Some differences represented legitimate operational exceptions, so users needed enough context to distinguish issues requiring action from expected differences.

A red mismatch count could therefore create more investigation without creating more understanding.

Users were compensating outside the product.

Participants described downloading information from multiple systems, manipulating datasets, and manually comparing them.

Other recurring inventory system comparisons were performed approximately weekly and could consume several hours or as much as a working day. Larger datasets became increasingly difficult to reconcile manually.

The opportunity was not simply to surface discrepancies faster.

It was to help people determine which discrepancies actually required attention and what they should do next.

The real workflow happened after the mismatch

Research showed a sequence that the dashboard did not support well:

That changed how I thought about the product.

Instead of organizing the experience around dashboard widgets, I began organizing it around the decisions users needed to make.

The core question became:

What information does someone need to move from “these systems disagree” to “I understand why, and I know what should happen next”?

What the evidence changed

The strongest and most consistent research signal supported inventory system-to-tool reconciliation.

Across four stakeholder-provided participant lists, I spoke with 23 people. And all expressed a need for inventory system-to-tool comparison and could describe the surrounding work.

They could explain:

That gave me enough behavioral evidence to design the workflow with confidence.

The evidence for broader multi-tool comparison was different.

Stakeholders wanted the inventory reconciliation experience to support more flexible comparisons across operational tools, but the research had not yet surfaced users who could consistently describe the complete generic workflow from comparison → decision → action.

That difference became central to the project.

Decision

I chose not to let generic multi-tool comparison become the primary organizing model simply because it was technically possible and requested by stakeholders.

As an experience, it introduced unresolved questions:

Instead, I made the validated reconciliation workflow the actionable foundation while leaving room for broader comparisons.

The experience moved from high-level dashboard widgets toward:

Outcome

The team's framing shifted to:

“What does this discrepancy mean, what decision does the user need to make, and what should happen next?”

Three possible directions

1. Reproduce the existing dashboard

Benefit: Fastest path to feature parity and multi-tool comparison capability.

Risk: We would recreate the original problem: an interface that displayed discrepancies without helping users understand or act on them.

2. Support only inventory system-to-tool reconciliation

Benefit: Strongest research confidence, a known baseline, meaningful discrepancy logic, and identifiable next actions.

Risk: It would ignore a broader product capability that stakeholders considered important.

3. Build an actionable foundation and expand deliberately — recommended

Benefit: Go deep where the evidence was strong while allowing the product to accommodate broader comparison over time.

Tradeoff: the multi-tool comparison scenario would not initially receive the same contextual guidance.

Inventory system-to-tool reconciliation would have a known baseline, meaningful discrepancy logic, and clear next actions.

Multi-tool comparison could still exist as a capability, but it would not automatically receive the same prescriptive guidance until we understood the workflow well enough.

Inventory system-to-tool reconciliation

Once the workflow was clear, the experience moved away from summary-heavy reporting and toward resource-level task support.

The redesigned flow helped someone:

Each component existed because it supported part of the reconciliation decision.

For a complex workflow, I moved beyond clickable prototypes

Using Cursor and my background in development, I built and iterated the workflow directly to accelerate implementation where useful. This also helped participants work through realistic reconciliation scenarios rather than respond primarily to isolated screens.

Users needed to work with realistic data, switch between states, filter resources, inspect fields, interpret discrepancies, distinguish exceptions from problems, and determine the appropriate next action.

For this project, code became a research tool.

Higher prototype fidelity gave me higher-fidelity behavioral feedback and surfaced interaction assumptions and edge cases earlier.

The later designs reflected what the research was teaching us

The design progressed through eight prototype versions.

The experience became progressively less about summarizing inventory and more about helping people investigate it.

Among the changes across iterations were:

Later iterations containing clearer discrepancy information and actionable guidance were received positively in research and review sessions.

I turned the prototype into a working implementation for engineering

I developed the validated experience into a working implementation and pushed it to the frontend repository as a reference the engineering team could build from.

This gave the team both usable code they could build from and a shared reference for the intended design and behavior of the experience.

My intention was to reduce the distance between design intent and implementation.

For me, this was an extension of the same responsibility I had taken throughout the project: reduce ambiguity before it becomes implementation debt.