> For the complete documentation index, see [llms.txt](https://alanandrew.gitbook.io/afourdocs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alanandrew.gitbook.io/afourdocs/document-structure/types-of-program-documentation.md).

# Types of Program Documentation

### **End-User documentation**

This is the how-to guide to which users turn when they're figuring things out. How do you configure the software? How do you convert a file? Can you add images? How do you fix a mistake? Even if the solution is a single click on the toolbar or the menu, there may be a lot of potential clicks through which to wade. Good user documentation makes it easier.

### **Project documentation**

Details of the project's development are valuable to your team as they work on it and possibly to users who want to customize an open-source program, for instance. The documentation can include contribution policies, best practices, changelogs, product requirements, design guidelines, and road maps.

### **Requirements documentation**

You'll usually draw this up at the start of the project. It defines the expectations for the software, including functional requirements, hardware requirements, compatibility and limitations.

### **Architecture documentation**

Defines the high-level architecture of the system: the components, their functions and the data and control flow.

### **Technical documentation**

Written for a technical audience, this covers the code, algorithms and interface.

You may be writing the documentation solo, but it's common to write it as a joint effort. Project documentation, for instance, may have contributions from project managers, engineers, and designers. If you have a team working on the material, the simplest way to coordinate contributions is with an online template to which everyone can add.