In the enterprise software I work on, the hard part is rarely the interface. It's making someone confident enough to use it correctly the first time.
I came to design through QA. For years my job was to find the gap between what a product promised and what actually happened when a real person touched it, which meant I spent a long time studying exactly where people go wrong and why. Most designers learn that after launch, from support tickets. I had it before I drew my first screen.
That shows up in a specific way in my work. When I design a feature that operates on data people depend on, I treat comprehension as part of the design, not as documentation somebody writes afterward.
Across the enterprise features I've shipped, I keep building the same thing without being asked: guidance that lives inside the tool. A merge feature that sounds like it destroys records got a panel explaining what it will never do, because that was the question standing between an administrator and the button. A user table got a column surfacing fields someone had edited by hand, because that invisible state was behind the most confusing support cases.
The goal is a product that teaches itself, so a client gets it right on the first attempt instead of learning the hard way through support. A tool someone uses correctly the first time is a tool they trust.
The rest of the practice is what you'd expect: research, information architecture, high-fidelity design in Figma, usability testing, and accessible work built to WCAG standards. I'm based in New Jersey and open to remote roles.
My design org adopted AI-assisted prototyping as standard practice, and it's how I work on production features now. The skill isn't generating a screen. It's directing an exploration, then evaluating and discarding most of what comes back.
I'm open to new opportunities. Whether you have a project in mind, want to chat about design, or just want to connect I'd love to hear from you.