PortfolioAbout
Jonathan Heavner
Designing enterprise products that make complex work feel simple.
Senior Product Designer
I design the software businesses run on without ever noticing it. Underwriting desks, sales counters, treasury systems. Most interfaces feel simple because somebody spent months making sure you’d never see what’s underneath. I’d rather see it first, then decide what the interface should look like.
15 YearsEnterprise Product DesignKansas City
Outside the Interface
I’m happiest taking something apart to see why it works, then putting it back together better than I found it. A motorcycle rewards that instinct without any translation layer in the way. Nothing sits between you and the machine. Just throttle, weight, and consequence. Retro games reward it differently. The good ones were built inside constraints far tighter than anything I get to work with now, and it shows in how deliberately every pixel earns its place.
Most weekends I’m behind a camera or losing an argument to two Yorkies who have never cared about my opinion on information architecture. None of it is research. But the habit underneath it is the same. I notice how something is actually built instead of how it’s supposed to work. That habit doesn’t stop when I leave the studio.
Perspective
This work has taught me that the real complexity is almost never on the screen. It lives in approval chains, edge cases, and the workarounds people invent because the software stopped understanding their job years ago. I stopped starting with the interface a long time ago. Now I start with the system: who touches the work, what they’re accountable for, what breaks when something goes wrong. The interface is simply where that understanding becomes visible.
The best version of that understanding is software that adapts to the work instead of asking people to adapt to it. Most of what I’m actually designing isn’t visual. It’s removing decisions people shouldn’t have to make twice a day. That’s also why I trust working prototypes more than slide decks. People can tell you what they want, but they can only show you what actually works once they’re using it.
Experience
Underwriting, retail, healthcare, and government. On paper they’re different industries. In practice they’re the same design problem repeated in different places. Every system has someone trying to make work happen despite software that no longer matches reality. That’s the person I’ve spent the last fifteen years designing for.
15 Years
- Financial Services
- Insurance
- Government
- Healthcare
- Retail & Point of Sale
- Enterprise SaaS
How I Work
- Understand the work first.
- The work always happens before the interface does. If I don't understand it first, I'm just decorating someone else's confusion.
- Move between the whole and the detail.
- Strategy that never touches a screen is just an opinion. I stay close enough to the execution to find out if the idea was actually right.
- Prototype to find out, not to demo.
- A slide deck can win a meeting. Only a working prototype tells you if the idea actually holds up. I'd rather find out early.
- Design with engineering, not for a handoff.
- The best ideas I've had were never mine alone. They came out of a conversation with the person actually building the thing.
Working Together
I ask more questions early than most people expect. I’d rather arrive with an ugly working prototype than a polished plan I haven’t tested. Being wrong on Tuesday is cheaper than being wrong in front of a client on Friday, so I try to find out early and stay honest about what I learn.
The best partnerships I’ve had with engineers started with curiosity, not specifications. They began with a conversation about what was actually difficult. I’d rather be the designer who asks a naïve question in a technical review than the one who hands off a file and hopes it holds up.
Beyond Client Work
Fifteen years of client work taught me the interface end of a product extremely well. It also left me curious about everything on the other side of the handoff: pricing, positioning, operational decisions, and the countless tradeoffs that shape a roadmap long before anyone draws a wireframe. StudioPOD became a way to close that gap. Building something from the first ambiguous idea through the system holding it together has let me experience the entire lifecycle of a product instead of joining halfway through someone else’s. It’s the same curiosity that shows up everywhere else on this page, simply applied at a different scale.
None of this is separate from the work. The motorcycle. The Yorkies. The prototypes built at midnight. It’s the same question asked in different places: how does this actually work, and what would it take to make it better? I haven’t run out of places to ask it yet.