Документація та база знань

Що охоплює ця категорія

Місця, де можна записати все так, щоб інші могли це знайти: довідкові центри для клієнтів, внутрішні посібники, документація для розробників і пошук, що робить корисним усе це.

Важлива відмінність це аудиторія. Документація для клієнтів потребує публічної адреси, процесу рецензування й мови, написаної для того, хто вже застряг. Документація для персоналу може бути безладнішою, але потребує прав доступу.

Особисті знання та знання малих команд належать до нотаток і вікі. Черга звернень, куди надходять питання без відповіді, це підтримка клієнтів.

Структура вирішує, чи щось знайдуть

Кожен проєкт документації починається впорядкованим і закінчується купою. Інструменти або сповільнюють це, або прискорюють.

Подивіться, як працює ієрархія: категорії, підсторінки, перехресні посилання і чи може сторінка стояти у двох місцях без дублювання. Потім подивіться, що буде на трьохстах сторінках, де розвалюється навігація, розрахована на тридцять.

Пошук це чесний тест. Спробуйте запит словами, якими скористався б клієнт, а не вашим внутрішнім словником. Продукти, що збігаються лише із заголовками, цей тест не пройдуть, і читачі потраплять у вашу чергу підтримки.

Теги та підказки пов’язаних статей допомагають, коли їх підтримують. Вручну їх ніхто довго не веде, тож обирайте продукти, що будують зв’язки з вмісту.

Написання, рецензування та підтримка правдивості сторінок

Документація гниє тихо. Сторінка, що була правильна в березні, у вересні стає зверненням до підтримки, і нічого в ній не виглядає неправильним.

Корисні продукти несуть власника, дати перегляду та мітку останньої перевірки, яку бачить читач. Стани чернеток і процес рецензування важливі, коли пише більше двох людей, а історія версій важлива вперше, коли хтось питає, що сторінка казала до зміни.

Варто перевірити й повторне використання. Ліміт, ціна чи список підтримуваних версій мають існувати один раз і підключатися всюди, де з’являються, а не вставлятися на одинадцять сторінок, які до наступного кварталу суперечитимуть одна одній.

Публікація та питання пошуку

Публічний довідковий центр це вебсайт, і поводитися він має як вебсайт.

• Чисті URL, що переживають реорганізацію, з редиректами, коли не можуть.
• Редаговані заголовки й описи для кожної статті, а не згенеровані з першого рядка.
• Швидкі сторінки без важкого застосунку, що завантажується перед появою тексту.
• Карти сайту, які оновлюються під час публікації, а не за розкладом, якого ніхто не пам’ятає.
• Власний домен, щоб матеріал будував авторитет вашого сайту, а не постачальника.

За останній пункт варто боротися всередині компанії. Документація часто найрезультативніший контент, який має софтверна компанія, і розміщення на піддомені постачальника віддає цей трафік.

Вимірювання і єдина метрика, що має значення

Перегляди сторінок не кажуть майже нічого. Дві цифри кажуть багато.

Перша це пошуки без корисного результату, і це письмовий список того, що створити далі. Друга це чи звертаються до підтримки читачі, які відкрили статтю, що потребує зв’язку довідкового центру з системою звернень.

Переписуйте за цим списком, а не за думкою. П’ять статей, що найчастіше не спрацьовують, вартують більшої уваги, ніж п’ятдесят, які ніхто не відвідує.

Як тарифікуються ці продукти

Місця для авторів, іноді безкоштовне читання для всіх, іноді за зареєстрованого внутрішнього читача. Публічні довідкові центри зазвичай беруть плату за автора й за обсяг статей, внутрішні вікі за користувача.

Стежте за трьома межами. Власні домени, версіонування та єдиний вхід лежать зазвичай на рівень вище за початковий тариф. Глибина аналітики це четверта. Постачальники, що поєднують довідковий центр із продуктом підтримки, нерідко ціняться його як додаток, а не включають, і це одна зі звичок, зібраних у матеріалі що приховують сторінки з цінами.

Перш ніж зобов’язуватися, експортуйте все й прочитайте результат. Markdown чи чиста розмітка означає, що ви можете піти. Власний формат означає, що архів у заручниках.

Довідковий центр із нуля

Перша версія має бути збентежливо малою.

Візьміть двадцять питань, що найчастіше надходять у вашу чергу підтримки, і відповідайте на них як слід. Це покриває більшість звернень і займає тиждень, тоді як спершу планувати повну структуру займає квартал і за цей час нічого не відповідає.

Пишіть кожну статтю для того, хто вже застряг, тобто спочатку відповідь, потім пояснення. Скриншоти старіють погано, тож використовуйте їх там, де вони справді допомагають, і чекайте на заміну.

Потім дайте структурі виникнути самій. Після тридцяти статей категорії стають очевидними, а нав’язування їх на п’ятій статті все одно означає реорганізацію.

Публікуйте пошукові запити без результату як чергу для написання. Це єдиний контент-план у цій категорії, який ніколи не закінчується і ніколи не вгадує невірно.