That feeling isn't noise.
It's emotionally-guided
reasoning.

The actual user isn't navigating my product with a requirements doc in hand. They're navigating it as a person, a real person, with habits, with pressure, with a feeling about whether something is working or not. That feeling isn't noise. It's emotionally-guided reasoning, and it's what determines whether they trust the product, return to it, and do the right thing at the moment it matters.

Getting there means holding the stakeholder's rational goals in one hand and a genuine curiosity about real human reaction in the other.

The person whose emotional response to your product is the only response that ultimately counts. That's who I'm designing for. Not the persona. Not the use case. The individual.

Most people use "human in the loop" as reassurance. The slide that says a person is still involved, so don't worry. The actual design problem is the moment between the algorithm finishing and the person deciding. Almost every interesting AI design question lives in that gap.

That moment has to do several things at once, and most of them fight each other. Show what the algorithm produced without telling the person what to think. Surface uncertainty without burying them in confidence scores. Respect the muscle memory of people who've done the work for years, while making the new path obviously better than the old one.

A common reflex is to treat all of this as a model problem. Tune the threshold, raise the auto-accept bar, retrain on the corrections. The design work is figuring out what a person needs to see, in what order, with what affordances, to make the right call quickly and stand behind it. The answer is different for every domain and every operator population, which is why there's no general pattern library for this yet and probably never will be.

I do this work in healthcare, automotive, and other environments. The cost of a bad review moment in those settings is measured in something more than churn, and the constraint sharpens the design.

Sitemap in week three, approved, filed, and then quietly out of sync with the product eighteen months later. The job is keeping a platform with real surface area coherent as it grows. New features arrive without homes. Language drifts as different teams ship their own vocabulary. Nav gets patched instead of rethought. After two years the product is a collection of things instead of a single thing, and the operators pay for that in cognitive load they can't name.

The visible part of IA is structure. What we call an object determines how operators think about it. What we call an action determines whether users trust it. Most platform IA failures are language failures wearing structural costumes, and the fix isn't a new nav. The fix is deciding, with conviction, what the platform's nouns and verbs are, and then defending those choices against the sixteen teams who want to ship a feature with their own vocabulary.

That defense is the part of the job that is unglamorous and political, and it's also what determines whether the product feels obvious or feels like a maze.

The design system is the agreements that keep the library alive. I've seen the version where the system dies. Components still sitting in Figma, nobody using them. Every team forked. New patterns shipping faster than the system can absorb. Engineers stop coming to design reviews because design reviews stopped affecting the code. None of that is a component problem.

Components, tokens, and patterns are about a third of the work. The rest is governance in, who decides what changes, what happens when teams disagree. Engineering partnership which means the design lead reads the code, files real issues, and shows up to technical reviews. A system that lives only in Figma has already lost.

The bar I hold myself to: an engineer I've never met can extend the system correctly without my involvement, and a designer who joins three years after I leave understands not just what the patterns are but why they're that way.