Documentation is rarely discussed. It is considered secondary, too “procedural,” not heroic enough. Yet it is what remains when the computer is put away. I have made it my guiding principle: to document is to love a project enough to be able to walk away from it.
The first time I truly understood the power of a user manual was on a muggy Tuesday afternoon, in a room where the fans made more noise than air. We had just finished a very simple website. The home page said everything you needed to know, the calendar worked, and the “donate” page took three clicks. I could have stopped there, smiled, and taken a picture. Instead, I opened a blank document and wrote: “Update the ‘news’ page — step 1.” Then I continued, image after image, screenshot after screenshot. In the end, we had a ten-page guide that began with ‘Hello’ and ended with “You can do it.” .
That evening, I felt useful in a different way: not because I had “done” something, but because I could leave without taking the project with me.
Documenting isn’t about piling up files. It’s about writing for someone else, with their unstable connection, their tired computer, their limited time. It means choosing words that don’t intimidate. It means thinking about the person who will come after, or the one who will have to pick up on a Monday morning when everything starts flashing at once. Documenting means making the other person exist in their context, not ours.
You might think it’s an obsession with control; it’s the opposite. I document in order to voluntarily lose control: so that the team can adopt, adapt, divert, even delete—in short, so that it can live without me. In my early days as a digital nomad, I often came across tools that seemed brilliant, but whose light went out as soon as the author closed their computer. The documentation was either absent or written for clones: “click here, obviously.” Nothing is obvious when you don’t share the language, habits, or mental architecture of the person who designed the tool.
Today, I prepare my deliverables as one would prepare a travel kit. The essentials, nothing more. A step-by-step guide that doesn’t assume, but shows. Templates that open without a subscription. Short paths, file names that can be understood at a glance. And, when possible, a short video for those who prefer to watch rather than read. I’ve learned to love modest things: a “Publish” button that you’re not afraid to press, a “donate” page where you know what to fill in without asking me, a ten-line charter that you pin up near your desk.
I sometimes catch myself thinking that documenting is a bit like making room. Moving your ego aside so that the object can belong to others. It also means accepting that the “right” way is not my way, that the site will change, that the visuals will take on different colors, that the campaign will take on a local flavor. This plasticity reassures me: it means that the project has left my backpack.
People often ask me, “Aren’t you afraid that everything will be ruined?” Yes, of course. But I much prefer a tool that breaks in the hands of those who try to use it to an intact tool stored in a cloud that is never opened. And then there’s the documentation to cushion the blow: when you know you can go back, you dare to move forward.
Sometimes I write sentences that aren’t technical at all. “You have the right to make mistakes; save often.” Or “If you’re lost, stop and drink a glass of water.” These are caring sentences, not lines of code. They whisper, “What you’re doing is worthwhile. You can do it.” Documentation isn’t just a map, it’s a hand on your shoulder.
In Cambodia, with CFSWF, I felt how important this handover was. We worked on visual aids and guides that explain why as well as how: why this terminology, why this caution, how to protect without stifling speech. In Chiang Mai, with Empower, or at Thai Freedom House, we talk about simple websites that are easy to maintain, with uncluttered sections. My challenge is the same: to minimize friction between the desire to act and the tools to act.
A well-documented tool is not only usable; it is adoptable.
In a fast-paced world, documentation seems slow. It takes an hour that could have been spent embellishing a visual or aligning pixels. But I consider that time to be deferred impact. It’s what will allow the team to publish while I’m sleeping, to adjust information without scheduling a call, to run their campaign without asking for the invisible permission that too many “services” end up requiring.
I’m not idealizing the practice: sometimes, documenting is tedious. Sometimes, I rewrite the same step for the third time because one screen never looks quite like another.