§ — Services · Documentation
Documentation that stays alive
The thing every team needs and no one wants to write. We love writing it, and we don’t stop there. We help design where documentation lives, who owns it, and how it stays current, so it doesn’t go stale in a wiki the month after we wrap things up.
Docs die when nobody believes they’re valuable
We’ve seen every failure mode: the stale wiki, the doc nobody owns, the heroic one-time effort to fix everything. The through-line is always the same; nobody believed the documentation was valuable, so nobody made time for it. The inverse is also true, and it’s quite useful: when documentation is genuinely helpful, people read it, and they eventually want to write their own documentation when they start their next project.
Our work typically starts with a question: what is the most helpful information to disseminate here, and how do we organize it clearly so that people can actually navigate it?
Where it lives, who owns it, how it stays current
A pile of well-written docs isn’t a documentation practice. We look at the whole system: the filing structure and hierarchy (an information-architecture assessment, at heart), the ownership model, and the cadence for keeping things current.
Our belief on ownership is simple: the person who does the work owns the documentation for it. Updating the doc becomes one of the items on the checklist when the work changes, not a bonus or nice-to-have someone does later.
We use these systems in our studio daily
Every working day, the two of us write a shared log: everything that was done, the decisions we made, what remains, and open questions for the other person. For a team of two, that granularity is exactly right. For your team, it might not be. You might keep that practice inside a smaller working group and roll something lighter up to the org.
Good documentation design means matching the practice to the team and what people’s capacities actually are, then designing something specifically for them. That’s what we aim to do with every engagement.
Audit first, then improvements
We pull from our user-research backgrounds and start by interviewing stakeholders: what matters to them, what work they’re responsible for, what they need to find and never can. The first two weeks are an audit of what’s already in place and identifying what immediate improvements are available. From there, it’s either sequenced improvements over time or one coordinated overhaul with a bit more preparation. We choose whichever fits the team and the size of the job.
What we deliver includes the documentation itself, an information architecture map for it, an ownership model, and an updating cadence that actually works. We also teach your team how to maintain it.
Asked and answered
Questions we hear
- How will you learn our domain fast enough?
- What tools do you work with?
- Do you maintain the docs after handoff, or teach us to?
- What's a typical scope?
Start a conversation
Tell us what you’re trying to do. We’ll tell you honestly whether we’re the right team for it.