Силната стратегия за съдържанието запълва празнината между това, което екипът ви изгражда, и това, което аудиторията ви трябва да знае. За техническите организации това означава документацията, публикациите в блога и ръководствата да се третират като пълноценни продукти, а не като нещо второстепенно.
Продуктите имат собственици, пътни карти, критерии за качество и бюджети за поддръжка. Повечето техническо съдържание няма нищо от това и затова остарява още седмицата след пускането. Стъпките по-долу му дават същата структура, без да добавят тежък процес.
Одит на съществуващото съдържание
Преди да създавате ново съдържание, направете преглед на това, с което вече разполагате. Проведете одит на съдържанието, който оценява всеки материал по точност, актуалност и показатели за ефективност. Открийте пропуските, където потребителите често задават въпроси без отговор, и отбележете остарялото съдържание, което може да подведе читателите.
Достатъчна е една таблица. За всяка страница запишете:
- URL и заглавие
- Тип — справочник, ръководство, how-to, концепция, публикация в блога, бележка към изданието
- Собственик — конкретен човек или екип, а не „инженерният отдел“
- Последна проверка — датата, на която някой я е сверил с текущия продукт
- Действие — запазване, обновяване, обединяване или премахване
Премахването на съдържание е напълно легитимен резултат. Две наполовина точни страници по една и съща тема са по-лоши от една вярна страница, затова обединявайте дублиращите се материали и пренасочвайте старите URL адреси, вместо да ги оставяте да гният.
Най-добрият ви източник за пропуски не е аналитиката, а поддръжката. Прочетете последните заявки към поддръжката, темите във форума и въпросите във вътрешния чат и отбележете за всеки страницата, която е трябвало да му отговори. Страница, която още не съществува, ще се появи като група заявки без връзка.
Изграждане на календар на съдържанието
Последователността е ключът към изграждането на ангажирана аудитория. Създайте календар на съдържанието, който балансира различни видове материали — ръководства, експертни публикации, бележки към изданията и казуси. Определете собственик за всеки материал и поставете реалистични срокове, които отчитат циклите на технически преглед.
Свържете календара с пътната карта на продукта. Съдържанието за всяко значимо издание трябва да се планира заедно с функционалността: обновления на справочника, бележка за миграция, ако поведението се променя, и ръководство или публикация, ако функционалността го заслужава. Документацията, която излиза след функционалността, е документация, която повечето читатели никога не виждат.
Предвидете време и за поддръжка. Календар, в който фигурират само нови материали, тихо трупа технически дълг; запазете повтарящ се слот за работа по колоната „обновяване“ от одита.
Писане за разработчици
Съдържанието за разработчици изисква прецизност и практически примери. Всяко твърдение трябва да бъде подкрепено с примерен код, който читателите могат да копират и изпълнят. Избягвайте маркетинговия език в техническата документация; вместо това се съсредоточете върху това какво прави технологията, как се използва и какви компромиси трябва да се имат предвид.
Структурирайте съдържанието си с ясни заглавия и лесни за преглеждане секции. Разработчиците често прелистват документацията в търсене на конкретни отговори, затова поставяйте най-важната информация в началото и давайте постепенно повече подробности, колкото по-навътре навлиза читателят.
Съобразете формата с целта на читателя
Читателят, който усвоява концепция, читателят, който следва стъпки, и читателят, който търси параметър, се нуждаят от различни страници. Смесването им води до ръководства, пълни със справочни таблици, и справочни страници, които се отклоняват в лични мнения. Решете какво е дадена страница, преди да я напишете.
Направете примерите надеждни
- Показвайте пълния пример, включително импортите и конфигурацията, а не фрагмент, който работи само в главата на автора.
- Посочвайте версиите, с които е тестван примерът.
- Използвайте реалистични, но очевидно измислени стойности, като домейни
example.comи ключове заместители. - Където е възможно, изпълнявайте примерите в CI, така че несъвместима промяна да провали компилация, а не следобеда на някой читател.
# Предпочитайте команди, които читателите могат да поставят без промяна
npm install your-package
npx your-package init --template minimalПроверявайте точността и яснотата поотделно
Техническите рецензенти проверяват дали съдържанието е вярно; редакторът проверява дали е разбираемо. Ако помолите един човек да прави и двете, обикновено едното се пропуска.
Измерване на успеха
Следете както количествени показатели (прегледи на страници, време на страницата, процент на отпадане), така и качествена обратна връзка (коментари, заявки към поддръжката, дискусии в общността). Използвайте тези наблюдения, за да усъвършенствате стратегията си и да приоритизирате бъдещите инвестиции в съдържание.
Тълкувайте числата внимателно. Дългото време на страницата може да означава, че ръководството е увлекателно, но и че е объркващо. Високият процент на отпадане на справочна страница често означава, че читателят е намерил отговора и си е тръгнал доволен. Свържете всеки показател с въпрос, на който се опитвате да отговорите, например „намали ли новото ръководство за настройка заявките за инсталиране?“, и търсете сигнали, които отговарят директно на него.
Простият бутон „Полезна ли беше тази страница?“ с незадължително поле за коментар се добавя лесно и носи конкретна обратна връзка, по която може да се действа. Насочвайте тези коментари към собственика на страницата, а не към обща пощенска кутия.
Обобщение
Работещата стратегия за съдържанието на технически екип се побира на една страница: одит със собственици, календар, свързан с изданията, стандарт за писане на примери и малък набор от показатели, свързани с реални въпроси. Започнете с одита, защото всичко останало зависи от това да знаете с какво разполагате.