|
1 | | -Every company has its organization rules that reflects the established hierarchy. You should mirror this hierarchy to create a usefull documentation. |
| 1 | +A well-structured hierarchy helps users navigate documentation efficiently. Just like a well-organized folder system, a clear hierarchy reduces confusion and speeds up information retrieval. |
2 | 2 |
|
3 | | -## Internal vs External |
| 3 | +## Why Hierarchy Matters |
| 4 | + |
| 5 | +1. **Faster Navigation** – Readers find what they need without digging through unrelated content. |
| 6 | +2. **Better Scalability** – As documentation grows, a logical structure keeps it manageable. |
| 7 | +3. **Reduced Duplication** – Clear separation prevents overlapping or repeated information. |
| 8 | + |
| 9 | +## How to Apply Hierarchy |
4 | 10 |
|
5 | | -First you have to divide the documentation between internal and external but the internal documentation is directed to the workers and the external to the clients |
| 11 | +### 1. **Repositories & Folders** |
| 12 | +Group related documents in dedicated repositories or folders. Example: |
6 | 13 |
|
7 | | -External documentation are an important part to the company marketing, sales and support. It should be treated with a high degree of precision and politeness otherwise it can hurt company's image. |
| 14 | +``` |
| 15 | +📁 Documentation/ |
| 16 | +├── 📁 Product-A/ |
| 17 | +│ ├── 📄 Architecture.md |
| 18 | +│ ├── 📄 Deployment-Guide.md |
| 19 | +│ └── 📄 Troubleshooting.md |
| 20 | +├── 📁 Product-B/ |
| 21 | +│ ├── 📄 User-Manual.md |
| 22 | +│ └── 📄 API-Reference.md |
| 23 | +└── 📁 Team/ |
| 24 | + ├── 📄 Onboarding.md |
| 25 | + └── 📄 Processes.md |
| 26 | +``` |
8 | 27 |
|
9 | | -### External documentation |
| 28 | +### 2. **Files & Sections** |
| 29 | +Break large documents into smaller, logical sections with clear headings. Example: |
10 | 30 |
|
11 | | -Companies should always delegate their communication to a especialized team using multiple steps to write, review and approve before publishing. |
| 31 | +```markdown |
| 32 | +# Project X Documentation |
12 | 33 |
|
13 | | -To reduce possible bottlenecks teams can be allowed to publish some types of communication like technical blocks or user manual but should follow strict rules to create a consistent communication. |
| 34 | +## Overview |
| 35 | +Brief description of the project. |
14 | 36 |
|
15 | | -### Internal documentation |
| 37 | +## Setup |
| 38 | +- Installation steps |
| 39 | +- Dependencies |
16 | 40 |
|
17 | | -Can be less strict in terms of precision or completeness. You can use pictures, videos, emojis and other informal elements but you should always be polite and respectful to keep things professional. |
| 41 | +## Usage |
| 42 | +- Common commands |
| 43 | +- Examples |
| 44 | + |
| 45 | +## Troubleshooting |
| 46 | +- Known issues |
| 47 | +- Workarounds |
| 48 | +``` |
| 49 | + |
| 50 | +## Internal vs External |
18 | 51 |
|
19 | | -Ex: Imagine a configuration manual |
| 52 | +Divide the documentation between internal (directed to the workers) and the external (directed to the clients): |
20 | 53 |
|
21 | | -''' |
22 | | -Li |
| 54 | +The **External documentation** are an important part to the company marketing, sales and support. It should be treated with a high degree of precision and politeness otherwise it can hurt company's image. Companies should always delegate their communication to a especialized team using multiple steps to write, review and approve before publishing. |
23 | 55 |
|
| 56 | +To reduce possible bottlenecks teams can be allowed to publish some types of communication like technical blocks or user manuals but should follow strict rules to create a consistent communication. |
24 | 57 |
|
| 58 | +The **Internal documentation** can be less strict in terms of precision or completeness. You can use pictures, videos, emojis and other informal elements but you should always be polite and respectful to keep things professional. |
25 | 59 |
|
0 commit comments