Most teams say they want better documentation.
What they usually mean is: “We want people to stop asking the same questions and making the same mistakes.”
What they usually build is a long Notion page or Google Doc that nobody reads twice.
I stopped fighting that reality.
For teams that hate documentation, I now build screenshot-first SOPs. The system is simple, visual, and fast to create. More importantly, people actually use it.
Why traditional SOPs fail in small teams
Long documents feel like homework
When the process lives in a wall of text, the path of least resistance is to ask a teammate or figure it out again from scratch.
Writing full prose is slow
By the time someone finishes writing a careful multi-page SOP, the process has often already changed. The document is outdated before it gets used.
Maintenance dies first
The first thing busy people stop doing is updating dense documentation. Once the written SOP drifts from reality, trust collapses and everyone goes back to tribal knowledge.
The screenshot-first rule
If the step can be shown, show it.
Only write the words that cannot be captured in an image.
A good SOP in this system usually looks like:
A short title
A one-sentence purpose
A series of numbered screenshots with 1–2 lines of text under each
A final “done looks like this” screenshot
That is the entire document.
The exact system I install
1. One home for all SOPs
A single Notion database or folder. No scattered pages.
Properties I actually use:
Name
Category (Onboarding, Sales, Delivery, Admin, etc.)
Owner
Last Reviewed date
Related tools
2. Strict page template
Every SOP starts from the same template so people know what to expect:
Purpose
One sentence. What this process is for and when to use it.
Steps
Numbered list. Each step is one screenshot + one short instruction.
Done looks like this
Final screenshot of the correct end state.
Common mistakes
Optional. Only include the two or three errors that actually happen.
3. Screenshot standards
Crop tightly. No giant desktop screenshots full of unrelated clutter.
Use simple arrows or boxes sparingly. If you need more than two callouts, the step is probably too big.
Capture the real tool interface, not a cleaned-up demo version.
Update the screenshot when the interface changes. Do not leave old UI in the doc.
4. Ownership and review cadence
Every SOP has one owner.
Every ninety days the owner spends five minutes checking whether the screenshots still match reality. If they do not, they update them or archive the SOP.
No owner = no SOP.
How I create a new SOP in under 20 minutes
Perform the task myself and capture screenshots as I go.
Drop the screenshots into the template in order.
Write one clear line under each image.
Add the “done looks like this” final image.
Assign an owner and publish.
I do not write a rough draft in prose first. The screenshots are the draft.
Real results from teams that hated documentation
New hire questions about basic processes dropped sharply within the first month
People started linking the SOP in Slack instead of re-explaining the steps
Updates became faster because changing a screenshot is easier than rewriting a paragraph
Resistance fell because the documents felt lightweight instead of bureaucratic
One operations manager told me: “This is the first time our process docs felt like a tool instead of a school assignment.”
When this system is the wrong fit
Screenshot-first SOPs work best for software processes, admin workflows, and internal tools.
They are weaker for:
Complex decision-making that requires judgment
Legal or compliance processes that need precise written language
Situations where the “why” matters more than the “how”
In those cases I still write short prose. But those cases are rarer than most teams think.
How to introduce it without a big rollout
Pick the three processes that generate the most repeat questions.
Build screenshot-first SOPs only for those three.
Share them in the places people already ask questions (Slack, email, onboarding checklist).
When someone asks a question the SOP answers, reply with the link and nothing else.
Expand only after the first three are being used.
Do not announce a new documentation program. Just make the most painful processes easier to look up than to ask about.
The Pegboard test
A good SOP should work like a labeled hook on the garage wall:
You can see what to do at a glance
You do not need a manual to use it
When something changes, it is obvious the label needs updating
Long written documentation often fails that test.
Screenshot-first SOPs pass it more often.
Meat. Heat. Bun.
Show the steps. Keep the words light. Make the correct end state obvious.
That is enough for most teams that claim they hate documentation.
No feedback yet — submit the first.