The backend was defined. The product model and the console requirements were not, and I had to work them out from scratch.
No researcher and no prior IoT knowledge, so I became the first user. I set up a device from scratch as a beginner and logged every error and dead end on the way to a first working build. That struggle became my research, and it showed me the core problem: the product mirrored the system's structure, not the way a person thinks about the task.
I worked backward from the API to the likely user tasks, validated them in workshops, and turned them into a requirements framework engineering could build against. The core design move was a product model: Devices, Components, and Deployments, who, what, and when, instead of mirroring the database.
The terminology was locked, and a PM told me directly it was not up for discussion. But it was confusing customers, and I would not ship a navigation I believed people misread. So I moved the debate from opinion to evidence: I ran a card sort with nine solution architects, and 9 of 9 misread the locked terminology the same way. That evidence went to leadership, and the decision was reversed. The people who had pushed back became partners in the work.
As the design lead partnering with fifty engineers, I launched on time, then ran a dogfooding study one day after launch that turned 100+ findings into 30+ roadmap items.
To avoid becoming the bottleneck, I built a self-service UX evaluation framework, scored on effectiveness, efficiency, and satisfaction, with office hours for the hard cases.
The framework was the means. The real outcome was a more user-centric culture: engineers began flagging UX issues themselves in architecture reviews, and the framework became a standing part of the IoT team's toolkit, not a one-time exercise.