ICTICT309 Create ICT user documentation

When an ICT product reaches the people who use it, the product is only half of what they need. The other half is the documentation that lets them get value out of it. User documentation is written for the person who uses a product, not for the person who builds or maintains it, and the whole unit turns on keeping that distinction clear.

A useful way to hold it: user documentation explains how to use the thing; technical documentation explains how the thing works and how to keep it working. User documentation is created for end users on how to use a product; technical documentation is created for the experts who work on the software or the technical parts of it. The features that mark documentation as technical rather than user-facing include the product definition and specification, quality assurance and manufacturing detail, a description of features and functions, maintenance information and fault-finding. If a document is telling a reader how a component is built, tested or repaired, it has crossed into technical documentation.

Within user documentation there are several recognisable types, and they are worth being able to name because the planning stage starts by choosing one:

A user guide is generally short and concise. Its aim is to introduce a reader to a product and give step-by-step "how-to" guidance on using it. A short guide that walks a new user through the basics of a video-conferencing application is a good mental model for the form: focused, task-based, no assumed expertise.

A user manual is more comprehensive. It is a full reference to the operation and maintenance of a hardware or software product, and it is often written by the manufacturer. The terms guide and manual are used interchangeably in day-to-day ICT work, but the distinction is real; a guide gets you started, a manual is what you return to.

Installation and setup documentation gives detailed step-by-step instructions on installing, configuring and first operating a product. It is usually treated as a type of user manual.

Beyond those sit the everyday forms a reader meets constantly: quick start guides, frequently asked questions, online help, troubleshooting guides, reference cards and training manuals. A quick start guide, for example, is a short document that helps a reader get going with the least possible reading, which is why it suits an advanced or a returning user rather than a complete beginner.

Nothing in this unit matters more than knowing who the documentation is for, because every later decision, the format, the reading level, the amount of hand-holding, the media, flows from that. The tool for it is a needs analysis, sometimes called a user needs analysis: a deliberate step, before any writing, that identifies and analyses the needs of the intended readers. It answers what the documentation must contain and the most appropriate way to present it. A needs analysis might conclude, for instance, that the audience needs plain English, a larger font and visual demonstrations of each task, and that conclusion then shapes the template.

End users sort into groups, and the point of the grouping is that the same content is written differently for each:

A novice user is a beginner with no prior exposure to the product. Nothing frustrates a beginner more than instructions they cannot follow, so this reader needs simple, plain-English steps with visual support and no assumed knowledge.

An intermediate user has had some training and can already perform most routine tasks. Documentation for this reader can assume the basics and concentrate on working more efficiently or on the product's more advanced features. If you know your audience is made up of intermediate users, that is a signal to skip the ground-level material and get to the parts that are specific to the product.

An advanced user has sustained, in-depth exposure and is proficient. This reader rarely needs a detailed guide; a short reference card that covers specific tasks is usually enough.

Two further types are worth naming. A casual user uses the product only occasionally, so cannot be assumed to remember much between uses. A transfer user knows a previous version and mainly needs to know what has changed, which is why "what's new" documentation exists at all.

None of this works on a "one size fits all" assumption. The reader's language, culture and familiarity with the product all shape the writing, and this is also where accessibility enters: some of the audience will read with a screen reader, at a larger text size, or with limited colour vision, and the needs analysis is the place to catch that rather than the point of handover.

There is a compact test for quality worth committing to memory, because it doubles as a review checklist. Well-developed user documentation is accessible, accurate, clear, complete, concise and correct:

Accessible means the content is correctly structured and searchable, so a reader can find the part they need.

Accurate means the information is factual and correct; the steps actually match what the product does.

Clear means the content is unambiguous and easily understood by the target audience.

Complete means it contains everything the reader needs to apply the information efficiently and effectively, with no missing step.

Concise means it contains only relevant information; no padding.

Correct means it is free of spelling and grammatical errors.

Underneath usability sits plain language, which is the thread that runs through all six. Plain language is not dumbing down; it is writing so that the intended reader can find, understand and use the information on a first read. It now has an international standard behind it: ISO 24495-1:2023, Plain language, Part 1: Governing principles and guidelines, published in 2023, sets out four principles that map cleanly onto a documentation review: readers get what they need (the content is relevant), can find what they need, can understand what they find, and can use what they find. It gives "write in plain English" a defined meaning rather than leaving it as an instruction nobody can check. Reading-level targets belong here too; a common working target for general public documentation in Australia is around a Year 7 reading age, and most word processors and editing tools will now estimate readability for you.

Investigating and determining the industry standard documentation requirements is one of the unit's elements, and it is where a fair amount of the knowledge sits, so this section carries some weight.

Start with the definition. A standard is a voluntary document that sets out specifications, procedures and guidelines aimed at making products, services and systems safe, consistent and reliable. Standards are developed by industry and by standards bodies, and their central purpose here is to improve usability by giving guidance on what to include, how to write it and how to format it.

Standards sit at three levels. National standards are developed by a national body such as Standards Australia. Regional standards are developed for a region, such as the European Union. International standards are developed by international bodies for countries to adopt and use nationally.

The bodies worth knowing:

Standards Australia is the peak non-government standards body in Australia, recognised by the Australian Government, and it develops and maintains Australian Standards (AS) and joint Australian and New Zealand Standards (AS/NZS). Standards themselves are purchased through the Standards Store.

The International Organization for Standardization (ISO) develops international standards across almost every field. The International Electrotechnical Commission (IEC) does the same for electrical, electronic and related technologies, and the two often work together on ICT standards. The World Wide Web Consortium (W3C) develops the standards for the web itself, which matters the moment documentation goes online.

There is a point about standards being voluntary that is easy to get wrong. Standards are voluntary by default, so there is normally no legal obligation to comply. But State, Territory and Commonwealth legislation frequently refers to an Australian Standard, and where a law calls up a standard, that standard becomes compulsory for the purpose of the law. So "voluntary" is the starting position, not a guarantee.

Above the industry standards sit two more layers an organisation applies to its own documents. Organisational standards, often the organisation's style guide, keep every document the organisation produces consistent, and they take precedence over industry standards unless the industry standard is legislated. Project standards apply to a single project and take precedence over both, again unless an industry standard is legislated. The order of precedence, from the top: a legislated industry standard, then project standards, then organisational standards, then a voluntary industry standard.

The standard for user documentation

There is an international standard written specifically for the people who create user documentation, and it is the one to know for this unit. It is ISO/IEC/IEEE 26514:2022, "Systems and software engineering, Design and development of information for users", published on 14 January 2022. It provides requirements for the design and development of information for users across the software life cycle; it takes the viewpoint of the information developer; it describes how to establish what information users need; and it specifies the structure, content and format, with guidance on style.

Older reference materials, and a good deal of training content still in circulation, name an earlier edition, ISO/IEC 26514:2008, "Requirements for designers and developers of user documentation". That edition has been withdrawn and superseded, and three things changed in the move to the 2022 version, each worth noting. The title changed, from "requirements for designers and developers of user documentation" to "design and development of information for users", reflecting a deliberate shift in the field away from the word "documentation" and towards "information for users", because so much of what a reader now relies on is not a document at all but embedded help, a search result or a short video. The publisher changed; it is now a joint ISO, IEC and IEEE standard, hence the longer designation. And the coverage broadened to take in the full range of information types, user guides, multimedia and computer-based training among them, rather than the document-centred view of the older edition. When you cite the standard, give the edition year, because the two are structurally different documents.

The 2022 standard sits inside a family of related standards for information for users, and it helps to know the shape of it: ISO/IEC/IEEE 26511 covers managing the process, 26512 covers acquirers and suppliers, 26513 covers testing and reviewing, and 26515 covers producing information for users in an agile environment.

One practical skill goes with all of this: reading the status field on a standard's catalogue entry, because a standard's status tells you whether you can still rely on it. Withdrawn means the standard is no longer relevant and has been removed. Superseded means it has been replaced by a more recent document, which is exactly what happened to the 2008 edition. Obsolescent means the publication is no longer recommended for current practice or new equipment but is retained so people servicing existing equipment still have it. When a search on a standards catalogue returns several results for one topic, the status field is how you tell the live standard from its history.

Templates and style guides both control the layout and formatting of documentation, and it helps to keep the two roles distinct. A style guide is the reference that sets the standards for how documents are written and designed; it is the rule book. A template is a file that puts those rules into a reusable shell, showing where text and objects go on the page, usually with placeholder text. The style guide comes first and the template is built from it. In one sentence, the style guide says how documents should look and read, and the template is a ready-made document that already obeys the style guide.

A style guide for an electronic document typically covers voice and tone; use and positioning of the organisation's logos; font type, size and colour; typographical emphasis such as bold, underline and italics; line and paragraph spacing; indentation and alignment; list types; headings; tables; graphics, including images and graphs; page layout and margins; header and footer content and formatting; punctuation; and abbreviations and acronyms. Organisations keep different style guides for different outputs, because a printed document, a word processing document and a web page have different constraints.

A template built from that style guide carries the standard layout, styles and fonts, and it is populated with placeholder text so a writer can see how the real content will sit before it exists. Placeholder text is usually "lorem ipsum", dummy Latin used to show how text will look before the real words are written. A good template also includes the structural furniture the finished document will need: a table of contents, page numbers and version control information.

Two links are worth keeping for real examples: the TechWhirl style guide template, a downloadable Word template, and TechWhirl's companion piece on developing a departmental style guide.

For a current, Australian example of a style guide rather than a fictional one, the best is the Australian Government Style Manual. It replaced the old printed sixth edition and now lives entirely online, maintained continuously by the Digital Transformation Agency. It is worth looking at for two reasons. It is the reference most Australian public sector documentation is written against, so it is the organisational standard for a large slice of the industry. And it is itself a working example of everything this unit teaches: web-based, searchable, accessible, plain-language and versioned, with a public changelog so readers can see what changed and when. A good way to see what "good" looks like is to read how it handles headings, lists, tables and accessibility, and then compare that to a static PDF manual.

The way templates and style guides are held has also shifted for teams that produce a lot of documentation. Rather than a Word template and a PDF style guide sitting in a shared drive, many teams now treat documentation as content managed like source code, an approach usually called docs-as-code: the source is written in a lightweight markup such as Markdown, kept in version control, and published to a web help centre by a build tool. The related idea is single-sourcing, where one piece of content is written once and reused across a web page, a PDF and in-product help, so a change is made in one place and flows everywhere. This is where the field has gone, and it is the practical reason the current standard talks about "information for users" rather than "a document".

Producing user documentation follows a recognisable process, and the four elements of the unit are really this process with sign-off and finalisation drawn out. The phases are planning, drafting, reviewing, testing and sign-off.

flowchart TD
  A[Planning: purpose, resources, audience, structure and design, format and media] --> B[Drafting: write the preliminary version against the template]
  B --> C[Reviewing: check accuracy, spelling and grammar, and adherence to the style guide]
  C --> D[Testing: usability testing with real target users]
  D --> E{Feedback}
  E -->|changes needed| B
  E -->|no changes| F[Sign-off: approval by the required authority]
  F --> G[Distribute]

Planning is the phase that repays the most care, and it has five parts. Purpose: identify the product or service and what the documentation is for, a beginner's step-by-step guide or an advanced-features reference. Resources: research and familiarise yourself with the product so you can write about it accurately, and gather what you need. Audience: identify the readers, their background and their familiarity with the product; this is the needs analysis from earlier. Structure and design: decide the sections and their order, and the visual design, within any corporate style guide. Format and media: decide whether it will be printed or electronic, built in a word processor or a desktop publishing tool, and delivered as a word processing, PDF or web document.

Drafting produces the first working version against the template, and it is usually the most time-consuming phase.

Reviewing checks the draft for accuracy, for spelling and grammar, and for adherence to the organisational standards including the style guide. A second, experienced reviewer is worth having, because a fresh reader sees ambiguity the writer cannot. Reviewing checks the content; it does not tell you whether the document actually works, which is what testing is for.

Testing means usability testing, and the distinction between review and usability testing is one worth holding onto. A reviewer tells you whether the content is correct; a usability test tells you whether the documentation does its job. It is run with a small sample of people drawn from the real target audience, who try to use the product with only the documentation to guide them, and it surfaces problems a reviewer would never catch because a reviewer already knows the product. The feedback is analysed and the valid concerns are fixed before the documentation reaches a wider audience.

Sign-off submits the finished documentation to a higher authority or a committee for the final decision. If it is accepted, the documentation is complete and ready to distribute.

Standards do not just tell you how to write; they also tell you how to manage a document over its life, and this is document control. Document control is a set of tasks that let an organisation manage its documents in an orderly way, and it is the responsibility of everyone who creates or uses documents, not just a records team. Done properly, it ensures documents are created, reviewed, distributed and disposed of in an orderly and acceptable way; that the current version is always the one in use; and that an archiving system keeps previous versions.

The quality management standard most often cited here is ISO 9001, and there is a point of currency worth getting right. An older, six-part way of describing document control, approval, identification, change tracking and storage, comes from earlier editions of ISO 9001. The current edition, ISO 9001:2015, folded all of that into a single clause called "documented information" (clause 7.5), which covers creating and updating documents and controlling them, and it deliberately dropped the separate "documents" and "records" language in favour of one term. The individual controls still describe good practice; they are just no longer separate numbered requirements. Document approval still means someone is responsible for approving a document before release and that the approval travels with the document; identification still means a document can be uniquely identified; change tracking still means changes are recorded; and storage still means documents are held so they can be retrieved and are protected. A revised sixth edition of ISO 9001 is expected to publish around September 2026, after which certified organisations get a transition period, so the clause numbers may shift again before long.

Version control is the everyday half of document control and it is where the writer actually does the work. When a draft is changed, a version control process makes sure changes are not lost and versions are not confused. Two habits carry most of the value. Adopt a naming and numbering convention that makes each version easy to tell apart, and stick to it. And keep a change history separate from the document itself, a table recording what changed, when and by whom, while the document carries its own current version number and effective date. A typical version table records the title, a description, who created it and when, who maintains it, and then a row per version with the version number, the modifications made, who made them and the date.

Choosing the format and the distribution method is part of planning, and it turns on three questions: who the readers are, what the documentation is for, and what the content is. The same content goes to a field technician and to an office worker in different shapes.

Printed documentation is tangible and needs no device, but it dates the moment it is printed and costs money to reproduce. Electronic documentation is cheap to update and distribute but needs a device to read. When documentation is provided electronically it usually comes as either a word processing file or a PDF, and PDF is generally the better choice for two reasons: not every reader has the word processor installed, and a reader can accidentally alter an editable file, whereas a PDF opens in free readers, cannot be changed by default, and is platform-independent.

Video and audio are a third form, and they suit tasks that are easier shown than described, because people process visual and audio information quickly. Older material names AVI and MP4 as common video formats; in practice AVI is now legacy, still playable but chosen by nobody for new work, while MP4 (using the H.264 codec) is the safe default, with WebM and newer codecs like H.265 and AV1 used where efficiency matters. More to the point, video documentation is rarely distributed as a file at all now; it is hosted (an unlisted YouTube or Vimeo video, or a screen recording) and embedded next to the written steps. A newer category worth naming is in-product or interactive guidance, tooltips, guided tours and step-capture tools that record a workflow and generate an illustrated how-to automatically. These blur the old line between a document and the product, which is again why the current standard talks about information for users rather than documents.

On distribution, storage media such as CDs and DVDs, common in the early internet, are gone; almost all user documentation is now delivered online, over the internet or an organisation's intranet, either as a download in the formats above or as a web page. The intranet point still holds: documentation meant only for an organisation's own staff, such as an internal training manual, belongs on the intranet where only authorised people can reach it, which protects sensitive business practice.

Web-based documentation has become the default for good reasons, and the intent behind converting a printable document into a web-based one is knowledge the unit covers directly. A web-based document is accessible from anywhere; it improves productivity; it cuts printing costs; it improves organisation and storage; it is constantly available; it makes online collaboration and sharing quick; and it gives easy access to both current and past versions. The benefit that outranks the rest in practice is that a web page lets an organisation distribute the most up-to-date version to everyone at once, which is the problem a printed manual can never solve.

The moment documentation goes online it comes under the web's own standards, and this is where the W3C matters. The W3C's recommendations for making web content usable by people with disability apply directly, because online documentation that ignores them can attract disability discrimination complaints. In Australia that is not a soft risk; the Disability Discrimination Act 1992 makes it unlawful to discriminate on the basis of disability in the provision of goods, services and information, and it has been applied to inaccessible websites. Accessibility here is both an ethical obligation and a legal one.

The W3C's accessibility standard is the Web Content Accessibility Guidelines (WCAG). The current version is WCAG 2.2, which became a W3C Recommendation on 5 October 2023, with a maintenance update in December 2024. WCAG 2.1 (2018) is still the version most Australian government policy formally references, and the older WCAG 2.0 is the one adopted as an ISO standard, so you will see all three cited depending on the document; the W3C overview explains how they relate. A next-generation WCAG 3.0 exists only as an early draft and is not something to rely on yet. The common benchmark to aim for is WCAG conformance at Level AA.

WCAG is organised around four principles, remembered as POUR: content must be perceivable, operable, understandable and robust. For a documentation writer that turns into a short, practical checklist. Provide a text alternative (the "alt" attribute) for every image, screenshot, icon and other non-text feature, so a screen reader can describe it. Do not rely on colour alone to carry meaning, and keep sufficient contrast between text and background. Caption and, where needed, transcribe video and audio, so an instructional video is not lost on a reader who cannot hear it. Use real headings, lists and tables so the structure is navigable, rather than text that only looks like a heading. Make sure everything works from a keyboard, not just a mouse. And write link text that makes sense on its own, because a screen-reader user often navigates by jumping between links. Accessibility is not a finishing polish; it is one of the things a usability test should check alongside clarity and design.

A document has a purpose, so you have to find out whether it fulfils it, and that means asking the people it was written for. Gathering and responding to feedback is two of the unit's four elements, so it is worth treating as a topic in its own right rather than a step tacked on at the end.

Collecting good feedback needs the right mechanism. The common feedback tools are surveys, interviews, email, phone and live chat, and each has a place. Surveys reach many people cheaply and produce data you can compare; interviews go deeper and let you follow up; email is low-effort for the respondent; phone and live chat are immediate and good for catching a problem while the reader is in it.

Surveys are where most of the craft sits, because a badly written survey produces feedback you cannot act on. Whether a survey is on paper, in a document, or built in an online tool such as Microsoft Forms or SurveyMonkey, the questions have to consider the target audience and stay focused on accessibility, usability, design and clarity. A good survey mixes two question types. Closed-ended questions, often multiple choice, give a fixed set of answers; they get higher response rates because the reader does not have to type, and the answers are easy to analyse statistically. Open-ended questions let the reader answer freely and are where you learn the things you did not think to ask about. A practical default is to weight the survey towards closed questions for the data, keep at least one open question for the surprises, and give every multiple-choice question at least four options, because a bare yes or no, or agree or disagree, tells you almost nothing.

A caution that is easy to miss: rating scales are weaker than they look. When you ask people to rate something from one to five, a lot of respondents take the lazy path and either pick the same number for everything or sit on the middle option, so the results cluster around the middle or the top and the analysis is skewed. It is a real limitation of satisfaction scales, not a reason to avoid them entirely, but a reason to design questions that make a lazy answer harder. Feedback emojis, a small row of faces standing in for a rating, are a fast alternative that some organisations use to cut confusion, though they carry the same middle-hugging risk as any scale.

Once the feedback is in, responding to it is the part that actually counts. Summarise what you heard, address every concern raised, make the changes, update the table of contents, page numbers and version control, and submit the revised documentation for sign-off. Gathering feedback and doing nothing with it is not competence; the loop has to close.

The older teaching material for this unit predates the arrival of generative AI as an everyday tool, and documentation is one of the areas it has changed most, so it belongs here rather than in a footnote.

AI genuinely helps at several points in producing documentation. It drafts a first version fast, so the writer edits rather than starts from a blank page. It rewrites for a reading level or a tone, which is directly useful for the plain-English and audience work this unit stresses; you can ask for the same steps written for a novice and for an intermediate user. It summarises long technical or design documents down to what a user needs, which is the "access and examine existing technical, design and supporting documentation" work of the second element. It drafts alt text for screenshots and captions for video, lowering the cost of the accessibility work above. And it translates, which matters when the audience analysis finds readers in more than one language.

What has to stay with the human is the part worth being firm about. A generative model produces fluent, confident text whether or not it is correct, so it will happily describe a menu item that does not exist or a step in the wrong order. In documentation that is a direct failure of the "accurate" and "correct" quality criteria, and the reader has no way to tell a real step from an invented one. So AI raises the value of the parts of this unit that verify, it does not lower it. Every AI-drafted step still has to be checked against the actual product, and usability testing with real users, the thing that catches the invented step, matters more now, not less. The safe working pattern is to let AI draft and reshape, and to keep a human doing the source-checking, the product walkthrough and the sign-off. Professional practice adds one more expectation: be open about where AI was used, and do not present AI-generated content as finished work without a human standing behind its accuracy.

The unit's teaching content, the types of documentation, user types and needs analysis, the quality characteristics, the standards material, the style guide and template detail, the creation process, document and version control, media and distribution, and the feedback tools, is drawn from the CDU material held in the unit folder: the ICTICT309 Assessor Guide v4.2 (2025), which sets out in one place what a student who has worked through the unit should know and be able to do, together with the six ICTICT309 session notes (2021). The unit's currency and title were confirmed at training.gov.au (ICTICT309, read 3 September 2026).

The current-practice material was sourced as follows, all read 3 September 2026. The documentation standard: the ISO catalogue entry for ISO/IEC/IEEE 26514:2022 (iso.org), confirming publication on 14 January 2022 and the withdrawal of ISO/IEC 26514:2008. Quality management and document control: the ISO catalogue entries for ISO 9001:2015 (iso.org) and for the ISO 9001 revision expected in 2026 (iso.org), with the September 2026 publication timing and transition arrangements drawn from certification-body commentary (ANSI, SGS and TUV). Web accessibility: the W3C Web Content Accessibility Guidelines 2.2 Recommendation of 5 October 2023 and the W3C WAI overview (w3.org), together with the Disability Discrimination Act 1992 on the Federal Register of Legislation (legislation.gov.au). Plain language: the ISO catalogue entry for ISO 24495-1:2023 (iso.org). Style guides: the Australian Government Style Manual (stylemanual.gov.au) and the TechWhirl style guide template and departmental style guide articles (techwhirl.com). Standards bodies: Standards Australia and its Standards Store (standards.org.au, store.standards.org.au), ISO (iso.org) and the W3C (w3.org). The docs-as-code, single-sourcing, hosted-video, interactive-guidance and AI-assisted-documentation observations reflect current industry practice rather than a single source.