The way I used to design UI was to sit with paper sketches, or Figma, or a React prototype with no back end. Imagine every failure mode. Design beautiful flows for each. I slipped into this mistake while working on LanWhisper, a voice dictation app. I designed for the failure modes I could imagine, drew the flows, and shipped the app. Then real users hit failure modes that I hadn’t anticipated. For example, the AI transcription model can return hallucinated text even if the input audio is empty. I had imagined that if the model returned text at all then the app was working. This failure wasn’t in my carefully designed list of ideal failures. Whoops. The problem is that a representation of a system only contains what you put into it. The failure modes it shows you are exclusively the ones you already thought of. This is the same mistake as designing for users you’ve never talked to. Designers know that’s a trap. The same logic applies to the systems we design: imagined systems aren’t a substitute for real ones. When designing non-trivial systems, imagination is no longer your best source of truth. The system itself is. And increasingly, designers can build it themselves. Do. Build it, instrument it, surface every piece of state. You can see and feel how the system works instead of projecting the ideal behavior onto some drawings you linked together. Your list of ideal failure modes isn’t real.

Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. Sure, I was doing a lot of stuff. But I wasn’t pausing to ask whether I was doing the right stuff. Or whether my approach was working. Or if I was spending the right amount of time on it. My fingers were moving but I wasn’t really thinking. So I needed a reliable way to interrupt my “unproductive productivity” and actually think. The obvious solution was a timer. Unfortunately, if you use timers a lot, you learn to dismiss them reflexively. And it’s really easy to forget to set the next timer. A week later, I’d realize: “Hey, that timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer. It does 2 unique things: It asks what I’ll focus on. It gradually blurs my screen if I don’t set a new timer. When it asks “What will you focus on?” I answer in a word or two, start the next timer, and keep working. Having to name my intention keeps me fully aware of my trajectory. If I’m in danger of drifting, it’s obvious. And if I avoid thinking for long enough, my screen starts getting harder to see. If I’m making great progress on something that doesn’t require much thinking, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something more open-ended, I might tighten the leash all the way down to 3 minutes. Then I can’t get off track. Unlike a regular timer, I can’t fail to set the next one. If I don’t answer it promptly, the screen gradually becomes less readable until I do. If I wanted to avoid answering, I’d have to make a conscious decision to close the app. I’d have to decide to be less productive. I never do. This small intervention has worked beautifully. Not only am I catching unproductive divergences earlier, I’m noticing fewer of them over time. It seems to be training me to do more and better thinking. It’s not a replacement for a journal. I love journaling, but that takes more than a few seconds, and there’s a lot of benefit to reflecting more frequently. If you’re running macOS, Intention is available here. I use it every day, and I think it’s the superior way of working. Process Tools like Cursor and Claude Code have dramatically changed the way I approach the design process. In the past, I would have sketched some potential solutions, put together a clickable prototype, and user tested that. But how much does that user test actually test? A traditional prototype in Figma or the like is paper-thin. I’m testing much less than the full experience. Now I can sculpt functional software as I go. That means I can build something, really use it, notice opportunities to make it better, and implement the changes I’d like to see, all in the same working session. This fast and robust feedback loop means better software. That said, sketches are still faster. I’ll bounce back and forth between sketching and building as appropriate. It’s far more practical to draw usable imagery than to generate it. The dock icon is drawn by hand in Figma with the pen tool and layer effects. The candle in the dark serves as both a metaphor for the app’s purpose illuminating the way forward, and an allusion to meditative practice. Why does this menu bar application appear in the dock? The answer is in the riddle of keyboard focus. An app that steals my keyboard focus every 3 minutes would be impossible to use, so instead the appearance of the timer window in the top right of the screen gently reminds me, and the gradual blurring of the screen gets more insistent over time. But the app does not take keyboard focus itself. This balance is what makes the app work. So I need a fast and intuitive way to switch to the timer window when I’m ready. Cmd+Tab has to work, and having the app appear in the dock enables that. Inspiration The visual inspiration for the branding is the early 1600s Caravaggio painting Saint Jerome Writing. The aging scholar Jerome, remembering the nearness of death, absorbs himself completely in the most noble work he can find to do while ignoring everything else. This is our task.

I’m the person my friends and family come to for computer-related help. (Maybe you, gentle reader, can relate.) This experience has taught me which computing tasks are frustrating for normal people. Normal people often struggle with converting video. They will need to watch, upload, or otherwise do stuff with a video, but the format will be weird. (Weird, broadly defined, is anything that won’t play in QuickTime or upload to Facebook.) I would love to recommend Handbrake to them, but the user interface is by and for power users. Opening it makes normal people feel unpleasant feelings. This problem is rampant in free software. The FOSS world is full of powerful tools that only have a “power user” UI. As a result, people give up. Or worse: they ask people like you and I to do it for them. I want to make the case to you that you can (and should) solve this kind of problem in a single evening. Take the example of Magicbrake, a simple front end I built. It hides the power and flexibility of Handbrake. It does only the one thing most people need Handbrake for: taking a weird video file and making it normal. (Normal, for our purposes, means a small MP4 that works just about anywhere.) There is exactly one button. This is a fast and uncomplicated thing to do. Unfortunately, the people who have the ability to solve problems like this are often disinclined to do it. “Why would you make Handbrake less powerful on purpose?” “What if someone wants a different format?” “What about [feature/edge case]?” The answer to all these questions is the same: a person who needs or wants that stuff can use Handbrake. If they don’t need everything Handbrake can do and find it bewildering, they can use this. Everyone wins. It’s a bit like obscuring the less-used functions on a TV remote with tape. The functions still exist if you need them, but you’re not required to contend with them just to turn the TV on. People benefit from stuff like this, and I challenge you to make more of it. Opportunities are everywhere. The world is full of media servers normal people can’t set up. Free audio editing software that requires hours of learning to be useful for simple tasks. Network monitoring tools that seem designed to ward off the uninitiated. Great stuff normal people don’t use. All because there’s only one UI, and it’s designed to do everything. 80% of the people only need 20% of the features. Hide the rest from them and you’ll make them more productive and happy. That’s really all it takes.

Code forces humans to be precise. That’s good. Computers need precision. But it also forces humans to think like machines. For decades we tried to fix this by making programming more human-friendly. Higher-level languages. Visual interfaces. Each step helped, but we were still translating human thoughts into computer instructions. AI was supposed to change everything. Finally, plain English could be a programming language. No syntax. No rules. Just say what you want. The first wave of AI coding tools squandered this opportunity. They make flashy demos but produce garbage software. People call them “great for prototyping,” which means “don’t use this for anything real.” Many blame the AI models, saying we just need them to get smarter. This is wrong. Yes, better AI will make better guesses about what you mean. But when you’re building serious software, you don’t want guesses. Not even smart ones. You want to know exactly what you’re building. Current AI tools pretend writing software is like having a conversation. It’s not. It’s like writing laws. You’re using English, but you’re defining terms, establishing rules, and managing complex interactions between everything you’ve said. Try writing a tax code in chat messages. You can’t. Even simple tax codes are too complex to keep in your head. That’s why we use documents—they let us organize complexity, reference specific points, and track changes systematically. Chat reduces you to memory and hope. This is the core problem. You can’t build real software without being precise about what you want. Every successful programming tool in history reflects this truth. AI briefly fooled us into thinking we could just chat our way to complex software. We can’t. You don’t program by chatting. You program by writing documents. When your intent is in a document instead of scattered across a chat log, English becomes a real programming language: You can see your whole system at once You can clarify and improve your intent You can track changes properly Teams can work on the system together Requirements become their own quality checks Changes start from clear specifications The first company to get this will own the next phase of AI development tools. They’ll build tools for real software instead of toys. They’ll make everything available today look like primitive experiments.