I’m listening to what you’re saying. I’m sorry if it feels like I’m not. It’s just that my mind is racing. My mind is racing most of the time. It races harder when I try to stop it from racing.

It’s not an “inner monologue”. Inner monologues, I presume, are coherent and single-threaded. This is more like random chatter. On one hand, it’s somewhat abstract because it’s not really words or sentences, but on the other, it’s laden with all sorts of emotions.

It’s not “voices in my head” either. Not hallucinations. Not things I can listen to and have a conversation with. More like background noise at a party that makes it harder to concentrate. And sure, I can tune in to one source of background noise to try and make out what it’s saying, but most of the time it’s all just meshed together. …

Originally published on somehowmanage.com, I’m publishing it here for posterity. There’s also a fun comment section on HackerNews around this article.

It’s a common narrative in tech to design products with the assumption that users are stupid and lazy. I think that is both disrespectful and wrong.

The idea is rooted in a lot of research around product usability, but it has been bastardized. Thing of it as a perversion of the Don’t Make Me Think thesis.

Don’t Make Me Think, the seminal web usability book by Steve Krug, tells us that products should be as simple as possible for users to use. Products shouldn’t be self-explanatory (ie understandable given a set of instructions), they should be self-evident (ie so obvious that they can be used without having to read instructions). A good door has a push/pull sign to make it self-explanatory, but it still requires you to read and think. …

Image for post
Image for post

I often write design documents even if no one will read them.

There are a lot of resources out there on how to write good design documents. There are also many different ways to define what constitutes a design doc — what it includes, how long it is, how formal it is, etc.

For my purposes, a design doc is any document that you write before you begin the actual implementation. It can be long or short, formal or informal, etc. The point is it’s something you do independently of the implementation—and before.

Most of the known benefits of writing design docs center around organizational alignment. Design docs can help you plan, help you get input from others on your team or in your company, serve as a record for the future. At larger companies, they’re also a great educational channel. While experienced engineers debate pros/cons of different approaches, many other can watch from the stands. …


Osman (Ozzie) Osman

Co-founder, Monarch Money. Ex-Quora, Google.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store