Context: I currently work as a Learning Technology Specialist, but I have lots of opportunities to write and organize information in my job. I manage a Level 3 support guide library, co-manage the Sharepoint stakeholder guide site, and mentor others to become regular contributors to the knowledge. This site emphasizes what I do along those lines, but most of my work is higher priority than that–process improvement, supporting advanced issues from the support team, managing the university’s syllabus tool, release testing and communication, and supporting technology improvements.

Timeline: Because of my higher priority work, writing something new can take 2 days (if there’s a deadline) or 1 month (if it wasn’t assigned). Keeping a generally consistent writing process helps to ensure I’m meeting standards and not losing track of the details while I wait until I have time to write (or edit) again.

Audience: My primary audience for this process is a Level 3 support team that assists with publishing, updating content, fixing technical errors, and managing operations processes.

Feedback and updates: I take feedback in a Teams #Documentation channel and the process is that whoever asks the question has to make sure it gets answered. This helps us support each other, effectively forcing the team to become friends of the documentation (advocates for keeping it up to date), but also alleviating some of the maintenance weight off of me. I answer their questions (or ask for clarification), then offer to update it unless they want to take a stab at it. (Their priority is the queue and they don’t always have the capacity to help.)

I monitor chat as much as I can and save messages that point to doc updates. I’m not expected to read every chat scouring for them, but this is a courtesy I provide to keep things moving. The team will only notice issues when they have that question again and need to seek that information, so it does not always require an immediate update. I collect and apply these updates at the start of each month. (This is another reason the team is encouraged to keep the guides up to date too–they may get to it much faster!)

Personal documentation workflow: My support guide writing is a cyclic process with no real starting point. Because I’m constantly updating/going live, there’s usually only one draft version and no iterations that people do not see*. (We will adopt more mature doc processes for the stakeholder guide site, some based on what we learned from this guide library.)

*Unless I’m reorganizing the entire guide, including template updates. I do that secretly and then update it at once, providing demos and answering questions as they learn the new guide organization or format.

Outline. Whether it’s a new doc or a revision of an existing one, I create or review the outline. Processes and tools are constantly updated in our work here so I want to make sure this is up to date and reflects the best possible method of getting to the information.

Draft. Drafting usually involves more in depth research and note-taking, so this portion of my process takes the longest. I try to make usable first drafts when I can so if I don’t have time to touch the document again for another few weeks, I can extract any high priority instructions for the team and paste it in the live document (with a note that it’ll be reviewed for consistency soon).

Test and edit. During testing and editing I create screenshots. I put myself in the mind of the “guide user” and review, following the steps as if I need to complete them for a duty. This helps me see that the content flows well and where screenshots are useful.

SME and guide user review. At my job, I’m the SME for many things. I’ve been here a decade, and since most of my immediate-team left during that time, I hold a bunch of knowledge no one else has (though I try to share as much as I can). This puts me at an advantage as a writer, but I’m still a stickler for a “real” SME to review before publishing. I requested that my team respects a documentation process that will require their time for review and this is when that happens. After SME review, I coordinate with a guide user to ensure it’s clear and usable and makes sense.

Edit and finalize styling. With the feedback received from the SME and guide user, I edit and finalize the document according to the formatting/styling standards my team uses. Once again I run through the whole doc in the mind of the “guide user” and work until I’ve achieved (what I perceive as) complete clarity.

Publish and communicate. I try everything I can to make processing information easier for my guide readers! Whenever possible, publishing a new guide includes an announcement/communication and a walkthrough. Even for one-pagers, it’s better for the team to be introduced to the resource by you, the author. This connects you to your readers as they feel better supported by you but also puts a snapshot memory in their brains that this new guide exists (or that the old guide was updated).