Where should you keep instructions for your app?
Keep a team copy where someone can review and update it. Publish a separate copy with the steps a customer can actually follow. Start with one question people keep asking, such as where to turn on booking reminders.
Do you need a document, a wiki or a help site?
A document works for one guide a few people maintain. A wiki brings related team pages together. A help site gives customers a place to start when they get stuck.
| When this happens | What to set up |
|---|---|
| One teammate needs to check the setup instructions. | Keep one shared document in a team location. Give the teammate permission to comment on the steps. |
| People keep asking which of several instructions applies. | Use a wiki with a short index. Give each page a clear name and someone responsible for updating it. |
| A customer needs help without entering your team workspace. | Use a customer help page with a stable address. Put it where someone is likely to get stuck. |
How do you prepare one page to share?
Try a short help page for a made-up booking app. Keep the practice copies private and use invented content. You can do the entire exercise on paper.
- Write down the result the reader should seeFor example, open Settings, choose Booking reminders, then turn reminders on. After saving, the page should show “Reminders on.” Name someone to keep these instructions current.
- Make a clean reader copyWrite the steps again in a separate document or page. Leave a fake team-only sentence in the private draft. Check that the reader copy contains only the steps, expected result and any picture you intend readers to see.
- Ask someone to find and follow itHave them start from a help link or index without telling them which page to open. If you rehearse in a private test workspace, confirm the parent folder or page, the two test accounts and who can open the attached files before sharing anything.
- Review one changePretend the app moved the setting. Let a reviewer suggest the new steps, have the maintainer accept them, and update the reader copy. Check that a person starting from the old entry point still reaches the right instructions.
Compare tools
Scroll the table sideways to read every column.
| Tool | Editing workflowWhat you start with and how another person reviews an edit. | Publishing controlHow you share the draft and publish or withdraw the reader copy. | API referenceWhether this workflow generates a reference from an API description. | Content exportWhat format you can take with you and what needs separate work. | Answer sourcesWhere readers find the current page and what answer sources are documented. |
|---|---|---|---|---|---|
| Google Docs | Start with one document. Commenters can suggest changes, and editors can accept or reject them. | Keep the document restricted while reviewing. Publish to web creates a separate read-only address with its own stop control. | Write examples in the document. Use a dedicated API reference workflow to generate and update a reference from a specification. | Download editable Word or Markdown, or PDF for reading. Check which document tabs are included. | Send readers to the approved document or published address. The publishing workflow described here is a read-only page. |
| Notion | Start with a page or collect team pages in a wiki. Set page-level view, comment or edit permissions. | A Site updates when you edit the published page. Check child pages and remove the separate public share link when withdrawing access. | Write examples on a page. The wiki and Sites workflow here does not generate a reference from a specification. | Export pages as Markdown or HTML and full-page databases as CSV. Recreating a workspace takes separate setup. | Find pages with Notion search. Eligible AI connectors can cite their sources. Open the cited page to confirm the answer. |
What should you check before making instructions public?
Check the exact content, who can publish changes and what a signed-out visitor can open. Publishing is a separate step from giving a teammate access to the draft.
| When you check | What to look for |
|---|---|
| Before publishing | Open the reader copy and check every linked file and child page. Remove internal notes, real customer data and anything that identifies a person without their approval. |
| After publishing | Open the intended public address in a fresh browser window while signed out. The help page and intended assets should open. The private draft and private attachments should stay inaccessible. |
| When taking it down | Turn off publication and separately remove any public sharing link. Reopen each exact address signed out. Anyone who downloaded or copied the content may still have that copy. |
What should you keep so you can move the guide?
Keep editable text, the files it uses and a small list of the addresses people already follow. Try opening one exported page in the tool you would move to.
A PDF is useful for reading a snapshot. A text or editable document is more useful if someone needs to make the next correction. Check a heading link, one image and any extra page or tab you expect to keep.
Record who should be able to view and edit the guide in its next home. Keep old public addresses and links to individual headings so the team can check what needs to change after a move.
When do you need more than a shared page?
Add a specialist tool when the reader needs a job the current page cannot do well. Examples include reviewing a preview before shipping it with the app, or building a reference from a description of the app’s API.
An API lets another program ask your app to do something. A reference can show what each request accepts and returns. It still helps to write one example a new reader can follow and check against the working app.
If you add AI answers, open the cited page and check that it describes the current version. Try a question the help pages do not cover. A confident reply with an unrelated source is a reason to improve the guide or the search setup.