Writing
Notes on making complicated software clearer, from twenty years inside enterprise products and the tools that now build with them. Each one answers a question people ask before they know who to ask, in its first paragraph.
Craft and code
What makes an interface feel finished, what a design engineer’s day is made of, and how a designer works in the developer’s own tools.
-
What makes an interface feel finished?
What makes an interface feel finished: type on a scale, color as a measured pair, motion as a duration and a curve with a rule about interruption, a decision for every state, spacing from tokens, and checks that hold all of it. Craft you can name and measure.
-
What does a product design engineer actually do?
What a product design engineer actually does: the component as the deliverable, tokens that flow one way, pull requests as design reviews, prototypes on a branch, motion you can review, and checks that hold the system. The tools, and how a designer grows into them.
-
How does a designer work in the developer’s tools?
Not by becoming an engineer. A branch for every change, a commit that says why, a pull request as the unit of work, checks that run before the merge, a deploy you watch land and a log you read when the page says nothing. What each tool is for, what it teaches about how developers think, and which of it a designer runs on day one.
Enterprise and operational software
What a person needs when an operational workflow breaks, how a broad request becomes a release, and what held one system across forty apps.
-
Designing for the moment the workflow breaks
When an order stalls or a transaction fails, people need more than an error message. They need to understand what happened, what it affects, and what they can safely do next.
-
How I move a complex workflow from ambiguity to release
A broad product request becomes useful through shared problem framing, focused investigation, realistic prototypes, and decisions made with engineering, not through a design handoff at the end.
-
What I learned standardizing UX across 40+ SAP Fiori apps
Lead UX for 40+ SAP Fiori apps built by different teams: one style guide and component library, feedback loops, checks in the release process, and teams that own it.
AI as the material
What a framework for human–AI interaction gets right, what an AI feature owes the person who has to act on it, and what a prototype of one has to prove.
-
What Microsoft’s HAX framework gets right about enterprise AI
AI recommendations need more than accuracy. Microsoft’s HAX framework offers a useful way to design evidence, uncertainty, correction and human control into consequential workflows.
-
Enterprise AI should help people decide, not just answer
A useful AI feature helps someone judge a recommendation and act on it appropriately. That means designing the evidence, the uncertainty, the controls, and the path when the suggestion is wrong.
-
What should a working prototype actually prove?
A prototype should resolve the uncertainty that makes the next investment risky, usually whether the idea is worth building: real code, real inputs, the people who would use it, and a build, kill, or park call.