Most teams stop when the problem still looks big. I keep going until it has a shape - because the expensive decisions are almost never made in the design, they are made in what the design assumes.
Every engagement I take on arrives as a tangle: legacy systems whose rules nobody wrote down, stakeholders who each hold one true fact about how it works, requirements stated as solutions. Shipping against that fog is how teams end up with confident software that solves the wrong thing - expensively, twice.
Before any visual work begins I map the system as it actually is: every actor, every state a record can be in, every place data changes hands. Not as a guess - as an inventory built from interviews, logs and the old screens themselves. Complexity stops being frightening the moment it is written down; what remains is merely large.
That inventory becomes the shared vocabulary for the whole project. When the client, the developers and I all mean the same thing by 'order' or 'session', half of the meetings that would have argued about definitions simply disappear.
Systems fail at their seams - the handoff between two tools, the moment offline meets online, the point where a human assumption replaces a rule. I spend disproportionate time exactly there, tracing one real object (one invoice, one booking, one patient) end to end through the machine. A single traced thread exposes more truth than any amount of reading documentation nobody maintains.
With the structure mapped and the seams traced, the core of the problem usually announces itself: not the feature request that opened the project, but the one invariant everything else bends around. Designing around that invariant is what makes the result feel inevitable - and it is only findable after the complexity has been taken seriously, not after it has been waved away.
Understanding complexity is not slow - it is what makes the building fast. When the essence is known, the interface writes itself, and everyone can defend why it looks the way it does.