What to do BEFORE you hit "Publish"

[#1]

What to do BEFORE you click “Create”

Confluence is great at encouraging folks to create content. This is, after all, basically its entire purpose! On the whole this is a good feature, since folks can easily pop open Confluence, click “Create” and start creating (this is even easier with addition of tools like “Create with Rovo” that allow us to use generative AI to create things with us). This easily accessible button does have a downside though… it’s INCREDIBLY easy to push it, and then get stumped about what to create!

 So here, we’ll take a look at some things you can/should do BEFORE you click “create”.

Have a process

Creating content is a process and the end of that process is typically “make the content” (well, technically it’s “archive” or “delete” the content :D). This means there’s a lot of work we should be doing before we get there. Everoyone (or every organization) will have it’s own own version of this, but at a high level it should include things like:

1. Determine need
2. Identify experts
3. Create an outline
4. Review
5. Draft
6. Review
7. Publish

Determine Need

This is the first step in a content-creation journey (and one I am VERY guilty of skipping most of the time!). Here you need to sit down and think about what you should be creating, and what that content will be used for. This can take several forms, from having someone ask (tell?) you to make a specific article, to you proactively reaching out to groups to solicit ideas.

This step should also including asking what the content is needed for, why it’s needed and other general questions. The point here isn’t to make something new, but rather to understand the purpose of that new thing and how it fits into everything else that is going on.

 For example, a sales team may ask for a new section to host “battle cards”. Understanding that these will need to be accessible by all sales reps in a specific region and used to help sell against competitors is important context.

Identify experts

Once you confirm the need for something and know its background, you should find experts. Many times this might be yourself, or even the person who submitted to the request… sometimes, however, you’ll have to ask around to find someone who knows about the topic. The expert(s) don’t necessarily have to create the content, but they do need to be available to help answer questions and provide general guidance (although they certainly could be the creator!).

In our “battle card” example we’d want to go talk to the sales team to understand the types of information that are needed, and where we can get that information.

Create an outline

Next up is creating a general outline of the content. For written information this could be the headings or major bullet points, for database this could be the columns needed, etc. This outline will serve as a high-level blueprint for the actual content and makes creating it a LOT easier.

For example we may have a list of critical information for our battle card, things like “how we compare”, “price points” etc.

Review

Go back to your experts with the outline and see what they think. Get their input on what’s missing, or could be expanded. This has several advantages, including

getting buy in. Your experts will have had a say in the content, making it more likely they’ll engage with it and provide support in the future. You’ll also build a relationship with these individuals, which can be incredibly helpful in the future when you need their help with other projects or content.

Draft

Once everyone OK’s the review you can begin draft. This is the step most people start.  It’s not a bad thing to begin here, however, the prior steps will help set you up for success and avoid a lot of the frustration I run into when I write (not knowing what to write or why!). When you draft follow your outline, but also be open to potential changes to it. The more you interact with, and understand, the content, the more you’ll start to see how it can be shaped. It’s not uncommon to adjust the outline here (or a bit later).

One other tip when drafting — don’t edit. Just write. Get the content down, and don’t worry about the structure, typos and the like, there will be time for that later!

Review, Again

Once you get your draft to state that feels OK it’s time to review it. I find this is really a multiple-step process as you will do your own review first before asking your experts to weigh in. The self-review is your chance to edit or change things you added when drafting. I find this is really helpful since it helps me notice and identify flaws that I either consciously ignored or just missed when I was drafting.

Once you complete your own self-review(s), it’s time to pass it on to the experts. When possible have them do a few passes at the review. First don’t tell them anything, just ask them to look at it and give you their thoughts. This helps keep them more objective and won’t skew what they see. Once they’ve done that, then give them specific things to look for or identify (e.g. did it match what we thought in the outline? Does a specific section make sense?). This two-step approach helps give you a broader view of the content.

Publishing

Once everyone reviews and agrees it looks good, it’s time to publish the content. This can be as simple as just pushing “Publish”, but there can (and generally should!) be more to it than that. Consider when the content should go live. You may choose to deploy publishing until a specific event happens or date occurs. You’ll also want to consider if you need to publicize the new content. This is especially true for things like new policies, important documentation or other plans.

Wrap Up

This type of structure helps ensure your content both meets you teams needs and fits into your overall documentation. It does add some additional time and steps, however, this investment more than pays off by providing actionable, findable information. I’m curious how your team deploys documentation? What tricks do you use? Share below!