A restaurant near where I live has a menu with twelve items described in a single adjective each: “aromatic,” “seasonal,” “house-style.” No ingredients, no allergens, no indication of size or spiciness. The waiter answers questions, which is helpful, but the wait is long and the tables are close together. Ordering takes twice as long as it should because each table needs a verbal tutorial.
That’s a documentation problem. And it has nothing to do with software.
Physical products have manuals. Services have onboarding flows and policies. Internal processes have runbooks. Government forms have instructions, when they have them at all. The principles are identical across all of these: users need to know what the thing does, how to use it, and what to do when it doesn’t work the way they expected.
What software does is accelerate the consequences of documentation failure. A restaurant with a confusing menu inconveniences the forty people who eat there on a given night. A software product with confusing documentation can inconvenience forty thousand users in the same span of time, and the exit is easier: users don’t finish the meal and leave disappointed; they close the tab in the first thirty seconds and look for something else.
The visibility of software documentation failures is also higher. A user who can’t figure out how to set up a developer tool might post on Reddit, file a GitHub issue, or write a blog post. A customer who can’t figure out a restaurant menu doesn’t usually write a thread about it. Software creates a feedback loop that other products rarely experience.
But the underlying problem is the same. A medical device with a 340-page PDF manual that covers every possible feature but buries the most common use case on page 97 fails its users exactly the way a software product fails users with an unstructured help system. A government benefits form with no instructions, or with instructions that use the word “hereinafter” eleven times, is documentation that has prioritized legal precision over user comprehension.
The questions worth asking are the same regardless of the product: Does the user know what this is for? Do they know how to start? When something goes wrong, can they figure out why? If they can’t do any of these things on their own, that’s a documentation problem.
The Write the Docs community started in software but the conversation has always extended beyond it. The craft of explaining things to people who need to understand them doesn’t change depending on whether the product runs in a browser. Clarity is clarity. An explanation that works is an explanation that works.
Every product has users. Every user needs to succeed with the product. That’s the frame, and it doesn’t require a software license.