The First Article Panic (and Why It’s Completely Normal)...

[#1]

When I speak with new team members, one thing comes up again and again: Confluence is seen as a great resource—but the idea of adding content can feel overwhelming, especially when writing that very first article.

That reaction is normal. But it’s also something we need to move past—together.

How I Introduce Confluence

Rather than starting with authoring, I start with searching.
Find a relevant topic, let smart search do its job, and see how quickly useful information appears. That’s when Confluence starts to make sense.

Only then do we talk about writing.

And yes—this is usually when the panic kicks in.

Progress Matters More Than Polish

Here’s the mindset I reinforce early:

An article that exists and can be improved is far better than one that never gets written.

Every strong page started as a rough one. As confidence grows, people naturally revisit and improve their earlier work. That’s exactly how Confluence is meant to evolve.

Write for the Next Person

When you create or update an article, think about the next person who’ll land there needing help—possibly under pressure.

Keep it simple.
Use clear language.
Write it the way you would have needed it explained yourself.

That alone adds value.

Maintaining Content Is a Team Responsibility

As a team, we all own the quality of our Confluence spaces.

If you can improve an article—by fixing grammar, clarifying a step, adding a screenshot, or updating outdated info—you should. Don’t hesitate. The responsibility doesn’t sit with the original author; it sits with all of us.

There’s No Risk

One final reassurance: every version of a page can be restored. You cannot break Confluence. That safety net exists so people feel confident contributing.

Stay Engaged

Make sure you’re watching relevant spaces and pages. Staying across updates, making small improvements, and keeping information current is part of being effective in your role.

When everyone understands and applies these basics, Confluence becomes a reliable, living knowledge base—not just a place to read, but a place we actively maintain.


Some basic mantras relating to Knowledgebases that help users stay engaged:

• If you found it unclear, improve it.
• If the answer didn’t exist, create it.
• Small edits from many people beat perfect pages from a few.

[Kris Klima _K15t_]

A nice first-person write-up. I like that you point out to anxiety of writing for the first time... trust me, that's completely normal AND repeatable. Every time you write for a new 'medium' for the first time ;) I've been writing for a living for over a 1/4 of a century and I still get the butterflies :D 

I'd add a to "Write for the Next Person" - use 'you' to address the reader. Don't use teams, users, unless you speak in general terms and users are your reader's users.

And keept the text structured - the so-called information elements practice uses formatting to convey the meaning. If you see a numbered list, you know it's a step by step guide.

I wrote a blog post about this, as a part of a wider Documentation Guide.

[Barbara Szczesniak]

I would also add that the author might want to use the page statuses to indicate how "done" they consider the page.

Or, since the Confluence page is likely for internal team members, it's maybe even more useful to put an inline comment near the top of the page or a paragraph (maybe a change history table) on the page itself saying something like:

<date> <author name> I just put the information I know at this time onto this page. If you have additional information or topics to include or a better way to organize the page, please edit it. Contact me if you have questions or want to brainstorm the changes. Then add a comment similar to this on the page, as well as a version comment when you publish. When the content is more complete, we will remove these comments from the page.

I would highlight this in a color that people will notice. 

I am the author of almost all pages in my space, but I do put such items on the page for my (dev, QA, Product) readers.

• In the better something than nothing case: "I'm not done writing this page/section yet. I've put the headings and will fill in the sections soon. Please tag me in an inline comment if you have additional information."
• Sometimes I add something like "I need to update this section when <Jira ticket link> is deployed," so people know that I have not yet changed the content for the new feature. This also reminds me that I need to do this.

[Steve Ashton]

@Barbara Szczesniak I like the idea of the status pill to clarify that a page may not yet be 'finished' just under way. I'll explore a good framework for that, or create an automation to automatically assign a DRAFT status to new articles perhaps?
In my company I have written most of the articles that exist and I used to put 'DRAFT - ' in front of the page title to show that it has been written but not yet tested.

The standard instruction for other users was that if you use a page beginning with DRAFT, you should be particular about following it exactly. If it works well, just delete the DRAFT from the title. If it needs extra content, just add it and report back to the author. It worked OK as it got users to see that it was everyone's responsibility to create and maintain.

I chose not to mention those any more to the new team members as it became a lot to remember and I wanted to just encourage action rather than add conditions. The team is experienced enough to see a new name as the author and make any updates required for accuracy or even just dropping an encouraging word as a comment.

@Kris Klima _K15t_ I generally correct the syntax if required after they start writing to ensure the article 'speaks' to the reader when used.

Numbered lists are by far the best, I agree, I like to encourage that screen shots are added inline and after their first creation, I will go back and demonstrate how to use the expand macro to keep as much of the process on the screen in the first instance. Tips like SHIFT+ENTER during a numbered list edit is also a good way to retain the numbering. I prefer to offer alternatives to things that will improve their writing after they have begun creating to as to not flood them with conditions. 

Thank you both for your suggestions :)