What I do

I believe the best systems are the ones people don't have to think about.

If someone has to stop and figure out how something works, I've probably missed something.

That's why I don't start with tools. I start by understanding what's actually happening, what's getting in the way, and what people really need. Sometimes the best solution isn't adding something new. It's removing what was never needed in the first place.

Here's what that looks like in practice:

1. I ask what's actually causing the problem before I think about the solution.
2. I simplify a workflow before I automate it. If a step doesn't need to exist, I remove it.
3. I care about how information is organized just as much as how the interface looks.
4. I design for the least technical person in the room. If they need help to use it, it isn't ready.
5. I write documentation for the people using the system, not just the people who built it.

The result? People spend less time figuring things out and more time getting things done.