I design complex software people can trust instead of work around.
Eight years in enterprise SaaS, across restaurant operations, corporate travel, and employee benefits. I work on the dense, high-stakes parts of a product, where good research, clear structure, and careful craft decide whether someone trusts the screen in front of them or quietly works around it.
Case studies
The product could notify people but couldn’t explain why. I designed a plain-language model for how and when the system acts, so a user can trust what a rule will do before it runs. Another designer later built on it for a problem it was never designed for.
Prep, inventory, and purchasing each counted the same items on their own, roughly fifty redundant counts in a single morning. I designed a shared counting layer so one physical count serves all three, with a freshness signal on every number so an operator can tell how far to trust a count someone else took hours ago.
Travel managers and travelers were handed the same PDF itinerary and left to find their own parts in it. I rebuilt the manager’s view around how they actually work, scanning many trips at once rather than reading one, so the detail they needed was a glance away instead of buried several clicks down.
Other projects
A healthcare staffing client ran its travel billing on tribal knowledge, with collection and allocation rules that shifted by work type and no safe way to change them. I designed an admin tool that let them set conditional rules and mappings in plain language, so the logic was theirs to manage without pulling in an engineer.
Members had access to exclusive discounts but were drifting away, unable to find offers near them and abandoning coupons in a confusing, multi-step redemption. I rebuilt discovery around location, surfacing nearby deals first, and stripped redemption down to something fast enough for a real checkout line.
Design is mostly deciding what the problem is, then making it visible to everyone else.
Start one level down
A request is usually a symptom, and the workaround people built around it points to the real problem. The first design decision is whether that problem is bigger than the ticket or belongs to one customer.
Name it before you draw it
A confusing screen is usually a confusing model wearing a layout. So before I draw anything, I say in plain words what the things in the system are and what they’re called.
Show the cost, don’t argue the case
People rarely oppose a better idea so much as a cost they can’t see. I’d rather build the map, prototype, or number that shows what the current way costs than win the debate.