FIELD NOTE · June 25, 2026 · 4 min
What leading an IT team taught me about UX
Two years of watching people hit walls in real time is the best usability lab I’ve had.
Before I called myself a designer I spent two years leading a campus IT support team at IU. On paper that’s a job about fixing computers. In practice it was a job about watching people fail at interfaces all day — and it shaped how I design more than any single class.
People don’t read
The single most durable thing I learned: nobody reads the instructions. On my capstone team’s usability tests, 6 of 8 participants walked straight past our on-screen directions. That wasn’t a surprise to me — it was every support ticket I’d ever taken, in miniature. So I stopped designing for the person who reads and started designing for the person in a hurry: explicit success and error messages, confirmation after every destructive action, empty states that tell you what to do next.
The report is the design spec
A support queue is a live, unfiltered usability study. Every ticket is someone telling you exactly where your system’s mental model and theirs diverged. You learn to hear “this is broken” and translate it into “the affordance was missing” or “the label lied.” That translation — from complaint to design problem — is most of the job in both roles.
A support ticket and a usability finding are the same artifact. One just arrives after you shipped, and the other arrives before.
Calm is a feature
Leading the team also meant being the calm one when someone’s work was on the line. That’s an interface quality too — good software lowers the temperature instead of raising it. I try to design things that fail gently, explain themselves, and never make you feel stupid. That instinct came from the help desk, not the design studio.