Complex systems, made usable
I design the software people depend on every day. Complex B2B products where the workflow is intricate, the business rules are unforgiving, and nobody using it got to choose it.
See the workTwo systems, End to end products
The first interface over a payment system that couldn't be changed
Four consoles over a fixed backend, with approve and transfer in different seats—so no role can move money alone.
Attendance that never quietly becomes absent
Ten modules where a shift is policy rather than a time range, an unresolved day has its own state, and every bulk change previews as a per-record diff.
Where I am useful
- 01
Enterprise workflows and information architecture
Multi-step processes with approvals, states, and exceptions. Untangling what the screens should be before drawing any of them.
- 02
Permission and role-based systems
Who can see what, who can approve what, and what happens at the edges. The part most products get wrong late and expensively.
- 03
Operational dashboards
Screens people watch all day. Deciding what actually belongs on them and what is noise.
Understand it, then draw it
- 01
Read the system before drawing it
On the payments project most of the week went on understanding, not screens. Commissions, returns, approvals and transfers looked like four processes and were one number, recalculated. Once that was clear the screens mostly fell out of it.
- 02
Find the boundary and say it out loud
The workforce project generates payroll inputs and does not calculate payroll. Naming that boundary early decided what every screen was for, and kept an existing engine out of scope instead of half-rebuilt.
- 03
Design the state between success and failure
The happy path and the error path are the easy two. A half-applied bulk job, an approval nobody owns, a day the system cannot resolve — those are where operational tools actually hurt, and they get designed on purpose.
- 04
Do not let the interface outrun the data
A grouping that exists only on screen has to be maintained by hand forever. If the data model does not have the object, the interface does not invent one — it does the grouping as a view and says so.
Only what this site can point at
- Workflow and information architecture
- Interaction design
- Design systems
- Figma
- Permission and role models
- State machines
- Data models and schemas
- Bulk and exception handling
Why this work
Enterprise design is data models, permission hierarchies, state machines and edge cases. A computer science background pays here rather than being a detour: reading a schema and arguing with the backend engineer is most of the job, and it is what makes the difference between a design that survives implementation and one that gets quietly simplified.
I build front end as well. That is not the pitch — it matters to you only as designs that hand off cleanly and survive contact with your engineers, and as the fact that this site is the same hands.
Procurement and vendor management · marketplace payments · manufacturing workforce and payroll operations