Real problems don’t arrive in optimal conditions. They arrive at 11pm when you’re tired, or week three of a project when half the team has dropped off, or in the middle of a pain flare you’ve learned not to mention. Most software is designed for a user in their best-case scenario — rested, focused, uninterrupted. I’m interested in the other version.

The measure of a system isn’t how it performs when everything goes right. It’s what it does for the person who is already overwhelmed before they open it.

I came to this through a specific kind of attention — the kind you develop when you care too much about things finishing. A mod that has to ship without a salary. A meal plan that has to work for a household that just got a diagnosis. A postpartum resource that has to be usable when you haven’t slept properly in three weeks. In every case, the constraint isn’t technical. It’s human.

My answer tends to involve incentive structures and friction management more than visual polish. I think about what a system rewards — what behaviour it makes easy, what it makes hard, what it quietly teaches users to expect. A good system is a set of affordances that stay legible under pressure. That’s harder than it sounds, and I think it’s the thing worth practicing.

I try to leave scaffolding for whoever comes after me — contributors, users, future maintainers who will be dealing with a messier world than the one I designed for. The work isn’t done when it ships. It’s done when it stays useful.