Типичные ошибки при написании текста о своём проекте: фичеризм и формализм
Коммерческий писатель, главред рассылки «Мегаплана», ответственный редактор дизайн-бюро Артема Горбунова и соавтор сервиса для очистки текста «Главред» Максим Ильяхов в колонке для ЦП объяснил, какие ошибки совершают основатели стартапов при составлении описания своих проектов и как их можно избежать.
Фичеризм
Обычному читателю неинтересны ваши фичи, модули и функции. Ему интересно, как от вашего проекта улучшится его жизнь. Фичи и модули интересны только другим программистам.
Нет:
- SSL-шифрование;
- Автоматическая синхронизация через облачное хранилище;
- Используется стандарт Bluetooth Low Energy.
Да:
- Данные зашифрованы: их не украдут, если вы работаете из кафе или аэропорта;
- Если вы измените документ на рабочем компьютере, он автоматически обновится на домашнем ноутбуке и в телефоне;
- Умные метки работают год без подзарядки. Поставил и забыл.
Писать о пользе не так просто, как кажется. Когда делаешь продукт, ты сосредоточен на его свойствах. Ты гордишься своей отказоустойчивой архитектурой или классной синхронизацией. Здесь нужно наступить себе на горло и подумать, в чем на самом деле польза. Когда я писал текст о собственном проекте, у меня это тоже получилось не сразу.
Версия 1:
«Главред» — это сервис для приведения текста к информационному стилю и удаления стоп-слов, канцеляризмов и признаков плохого синтаксиса.
Версия N:
«Главред» — это сервис для улучшения текста.
Я потратил четыре месяца на разработку всех этих возможностей, но это лично мои заморочки. Пользователю неважно, что у моего сервиса под капотом. Польза в том, чтобы его текст стал лучше.
Недавно на ЦП был выпуск «Трибуны» о проигрывателе на базе YouTube. Вот что они написали о себе:
Как было:
Музыкальное приложение для iPhone, позволяющее пользователям слушать любимую музыку и находить новые MP3-треки по названию, хэштегам и даже настроению.
Как нужно:
Подбирает музыку под настроение и помогает находить новых артистов в любимом жанре.
Я намеренно убрал здесь историю про «слушать любимую музыку», потому что нелюбимую музыку никто слушать не будет. А вот музыка под настроение и новые артисты в любимом жанре — это понятные мне сценарии.
Как избежать фичеризма: сформулируйте проблему, которую решает ваш продукт. Отвечайте не на вопрос «Чем вы хороши», а на вопрос «Как улучшится жизнь пользователя».
Попробуйте механически удалить из текста все технические термины: «тег», «категория», «файл», «синхронизация», «технология», «сервис», «платформа», «каталог», «база данных». Особенно осторожно со словами из обихода, которые вы используете как технический термин.
Нет:
- Находите пользователей по интересам;
- Сообщения сортируются по темам, давности и участникам;
- Храните файлы любого типа.
Да:
- Встречайте интересных собеседников;
- Легко найти переписку о прошлогоднем корпоративе или о том, что вы обсуждали с маркетологом прошлым летом;
- Храните документы, фотографии, музыку, фильмы и игры.
Формализм
Читателю некогда разбираться в тонкостях вашего продукта. Он хочет узнать главное и быстро. Плохо, когда в этом месте вы начинаете тонуть в подробностях.
Допустим, ваш сервис поддерживает соединение без шифрования, с шифрованием X и с шифрованием Y. Вы уже знаете, что пользователю, скорее всего, плевать, какое именно шифрование — лишь бы не украли данные в кафе. Но формально все равно вы умеете и шифровать, и не шифровать.
Нет:
Соединение без шифрования, с шифрованием X и шифрованием Y.
Да:
Защищенное соединение: данные не украдут в кафе или аэропорту.
Я намеренно убираю из этого текста информацию о нешифрованном соединении, потому что непонятно, какая от этого польза. Формально я неправ: я не рассказал об одной из возможностей продукта. Но пользователю наплевать, о скольких функциях я расскажу. Важна только польза. Если бы в нешифрованном соединении была какая-то польза, я бы должен был об этом написать.
Допустим, у сервиса есть два типа соединения: современное быстрое и старое медленное. Медленное нужно в тех случаях, когда сисадмин на работе заблокировал быстрый протокол. Тогда польза понятная.
Нет:
Соединение по протоколу «Альфа» и «Бета».
Да:
Работает по быстрому протоколу «Альфа». Если в вашем офисе он заблокирован, работает по протоколу «Бета».
Текст получается формальным, когда вы начинаете писать о вещах, которые читателю знать не обязательно. Формально вы правы, но читателю неинтересно.
Нет:
- Пишите комментарии, создавайте темы для всей компании и индивидуально для каждого сотрудника;
- Вы получите посадочный талон в СМС, в виде письма с PDF или как карточку Passbook;
- Любой объект можно добавить в закладки, отложить в «Избранное» или сохранить в публичном или личном «Листе желаний».
Да:
- Переписывайтесь с коллегами лично, внутри отдела или со всей компанией сразу;
- Посадочный талон придет по электронной почте и появится в телефоне;
- Гости откладывают интересные товары на потом и делятся находками с друзьями.
Да, вы срежете углы и напишете не обо всех нюансах сервиса. Но текст получится яснее, проще, и про людей, а не про фичи.
Как избежать формализма: отлавливайте в тексте однородные члены (как в примере про комментарии или лист желаний). Если видите, что разница между этими однородными членами небольшая, то смело сокращайте. Нюансы важны только тогда, когда вы можете объяснить их пользу. Разумеется, формализма не избежать в официальных документах: спецификации, договоре, пользовательском соглашении.
Ограничения
Все, о чем я писал, относится только к тексту для широкого круга читателей: для СМИ, на главную страницу, в раздел «О проекте» или «О компании». И не относится к тексту для профессиональной аудитории. Если вы программист и пишете статью для других программистов, то вы обязаны писать о фичах. Если вы юрист и пишете руководство для юристов, то будьте максимально формальными.
Помимо этих ошибок есть и другие: фальшивый продающий стиль, канцелярщина, корпоративщина, самовосхваление, манипуляции и англицизмы. Об этом в другой раз.