How Do You Design for a Domain You've Never Seen Before?

Understanding it for real, before designing anything.

This was my first exposure to reconciliation as a domain, and the volume and complexity of data involved went well past a typical feature scope. Before I could design anything credible, I had to actually understand it: how reconciliation worked, what other ERP systems in the space could and couldn't do, and where our product's data model diverged from expectations shaped by those other tools.

Designing for continuity, not just for ship day.

I mapped specific flows through the reconciliation process and annotated them with research notes instead of working from assumptions. The domain surfaced enough edge cases that user interviews alone weren't going to cut it, so I tested and confirmed my understanding directly with subject matter experts. That's what caught the edge cases that never would have come up otherwise.

This feature spanned multiple sprints, quarters, and teams, so I built documentation as I went, specifically so ownership could move between people and phases without losing consistency along the way. That's a different discipline than designing for a single release: designing for continuity, not just for ship day.

Making disagreeing systems agree.

The final design let users work accurately within the reconciliation flow and adjust records so data stayed consistent across systems, the core requirement, given that most of the friction came from systems disagreeing with each other in the first place.