Beginner Resources

This level is for people who are new to technical writing or are still trying to understand what the role actually involves. The goal here is not to read everything available on the subject. It is to build enough of a foundation that you can sit down and write something useful for a reader.

You will cover four areas in this order: writing clearly, understanding document types, applying a style guide, and working with the people who have the information you need. Each section has resources and a practice exercise. Do not skip the practice.

1. What is technical writing?

Before learning how to write technical documentation, it helps to understand what technical writing actually is, what technical writers do day to day, and how the role has evolved.

Technical writing is the practice of creating documentation that helps people use, understand, or make decisions about technical products and systems. That includes software guides, API references, tutorials, help centres, release notes, and more. The people reading this documentation are usually developers, engineers, end users, or internal teams, each with different levels of technical knowledge and different goals.

The Knowledge Academy’s article on “What Is Technical Writing? Types, Examples and Benefits” provides more detail into what technical writing covers.

In 2026, however, the role has expanded. Technical writers are no longer only the people who write manuals and guides after a product is finished. Many now work directly with product teams, take part in planning, review content earlier in the development process, and work alongside AI tools that make writing faster and more efficient.

The ADOC Studio guide, “Technical Writing: A Comprehensive Guide (2026)”, provides a look at how technical writing is evolving in modern workflows and what the role looks like today in practice.

2. Writing clearly

The first thing to sort out is the difference between writing that sounds good and writing that communicates clearly. Technical writing is not about impressive vocabulary or formal tone. It is about helping a specific reader do or understand something specific. Everything else is secondary.

Before you move further, get comfortable with these ideas:

Resources

  1. Google Technical Writing One and Google Technical Writing Two are free online courses from Google that cover the fundamentals: clear sentences, useful structure, audience awareness, and editing. Take them in order. Course Two builds directly on what Course One teaches.

  2. Getting Started in Technical Writing (e-book) is a practical introduction to the field written for people starting from scratch. It explains what technical writers actually do and how to approach your first documentation project.

  3. Getting Started in Technical Writing: A Beginner’s Guide covers audience considerations and structured writing in a format you can work through at your own pace.

  4. TechnicalWritingMP has beginner-level courses on documentation fundamentals, basic API concepts, and markup languages.

Practice

Find a feature from an app you use regularly. It does not need to be complicated. Document it in three ways:

You can use any familiar app feature, for example posting on Instagram, creating a Google Doc, organizing a Notion page, or composing an email in Gmail.

3. Document types and structure

Most beginner documentation problems come down to the same mistake: mixing content types in a single document. A tutorial that becomes a reference page halfway through. A how-to guide that stops to explain background theory. These are different types of content serving different reader needs, and combining them makes all of them worse.

The Diataxis framework, developed by Daniele Procida, gives you a practical model for separating them. It identifies four types of documentation:

Tutorials are for learning. The reader is new and needs to be led through a hands-on experience. Your job is to ensure they succeed, not to be comprehensive.

How-to guides are for doing. The reader already knows what they want to accomplish. Your job is to give them the clearest path to that goal.

Reference is for looking things up. The reader needs accurate, consistent information in a predictable structure. Your job is not to explain or teach, but to be complete and precise.

Explanation is for understanding. The reader wants context, background, or the reasoning behind a decision. Your job is to give them a mental model, not instructions.

Resource

The Diataxis framework is the primary reference. It is short, well-written, and used by documentation teams at Cloudflare, Django, Gatsby, and others. Read it once to understand the model, then come back to it as you write.

Practice

Pick a documentation page from a tool you use. Work out which Diataxis type it is supposed to be. If it mixes types (most do), identify where the mixing happens and rewrite one section so it fits cleanly into a single type.

If you are not sure where to start, choose any familiar product or platform. This could be tools like GitHub, Notion, or any app you use regularly.

4. Style guides

A style guide is a set of agreed-upon rules for how your documentation is written: what words to use, how to format UI elements, whether to use active or passive voice, and how to write headings. Its main job is consistency. Consistent documentation is easier to read, easier to maintain, and easier to trust.

You do not need to write a full style guide at this stage. You need to understand what style guides do, be able to follow one when your organisation has it, and know where to start when it does not.

Resource

The Google Developer Documentation Style Guide is the most widely used free style guide in technical writing. Use it as your working default. When you join a team or project that has its own guide, follow that instead.

Other widely used style guides in the industry include the Microsoft Writing Style Guide, which is commonly used for product documentation in enterprise and software environments, and the Apple Style Guide, which is used for consumer-facing documentation across Apple platforms. Some teams also maintain internal style guides that adapt these standards to their own products and workflows.

Practice

Write a one-page mini style guide for a fictional product. Include at minimum:

This is a legitimate portfolio piece and a useful reference to return to as you develop your own documentation habits.

5. Working with subject matter experts

Technical writers rarely have full knowledge of what they are documenting. Most of what goes into a document comes from engineers, product managers, designers, or other specialists. The skill here is not knowing everything. It is knowing how to get the right information from the people who do.

This is something most beginners underestimate. A poorly prepared conversation with an SME produces vague, incomplete information that is hard to turn into documentation. A well-prepared one gives you enough to write a first draft and ask the right follow-up questions.

A few things to keep in mind:

6. Using AI in entry-level technical writing

AI is now part of modern technical writing workflows, but it only becomes useful once you understand the basics of gathering and structuring information yourself. If you cannot interpret information from real systems or people, AI will not fix that gap. It will only help you produce incorrect content faster.

At this stage, AI should be treated as a support tool that helps you think more clearly, structure your ideas, and refine your writing. It works alongside your process, not instead of it.

A common concern for beginners is whether AI will make technical writers obsolete. The short answer is no. AI is a tool in the technical writer’s toolbox, not a replacement for the role. What AI cannot do is verify facts against real systems, understand the nuance of your product’s audience, or decide what information is truly relevant to your readers. Those decisions require human judgment.

As Ihuoma Anosike argues in her article, “Is AI Really Going to Replace Technical Writers?”, AI excels at generating drafts, restructuring content, and speeding up repetitive tasks. But it still needs a technical writer to guide it, validate its output, and ensure the documentation serves real users. The writers who thrive are the ones who learn to use AI as a force multiplier for their own skills, not as a substitute for them.

What you should learn at this level

1. Basic prompt engineering

The quality of what AI gives you depends on the quality of what you ask. Learn to write clear, specific prompts that include:

Start with zero-shot prompting for simple tasks, and use few-shot prompting when you need a specific format or tone by providing one or two examples in the prompt.

Zero-shot prompting means you ask the AI to perform a task without giving it any examples of what the output should look like. You describe the task and let the model figure out the format based on its training.

Few-shot prompting means you provide one or more examples of the desired input-output pattern before asking the AI to complete a new, similar task. The “few” typically means 1 to 5 examples.

2. AI output review and validation

You must be able to detect problems in AI-generated content before it reaches readers. Check for:

Always validate AI output against real documentation, code, or SME conversations. Never publish AI-generated content without reviewing it.

3. Safe and approved tool use

Use only AI tools approved by your organisation. Follow your team’s disclosure and privacy policies. Do not paste proprietary code, internal credentials, or confidential product plans into public AI tools. When in doubt, ask your manager or security team before using a new AI tool.

What you can use AI for at this level

What you should not rely on AI for at this level

A useful way to think about it is this: AI can help you write faster, but it cannot always decide what is true, or what is relevant to your work. The responsibility for accuracy always falls on you.

Resources

Practice

Take one of your earlier exercises from this guide, such as the how-to guide, quick-reference section, or explanation you wrote for a familiar app feature. Use AI to:

Document your prompt, the AI output, and your review notes. This is a portfolio piece that shows you can use AI responsibly and critically, not just generate content.

7. Further reading

These are supplementary articles for when you want more context on the field. Read them when you have time:

Ask the community

Once you have a sense of the field, introduce yourself in the WriteTech Hub community. You can also:

Capstone deliverable

Before moving to the Intermediate level, produce a small documentation set for a tool or process you know well. This could be tools such as Google Docs, Notion, GitHub, or Gmail. It should include:

Each piece should be a clean example of its Diataxis type. The set should read as a coherent documentation project, not four unrelated pages.

If you use AI during this process, your final documentation should show your understanding of the system, not just AI-generated fluency.

What matters is how clearly and consistently you structure the documentation across different content types.

This is your evidence that you understand the fundamentals and can produce documentation across different content types. When you can complete it without hesitating, you are ready for Intermediate Resources.

Next
Intermediate Resources