{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "Виталий Филатов: заметки с тегом кейс", "_rss_description": "Меня зовут Виталий Филатов. Я коммерческий писатель, помогаю бизнесу рассказывать о себе и продукте. Пишу и редактирую статьи, инструкции, текст сайтов и интерфейсов. Люблю работать в команде с дизайнерами и разработчиками.", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.vitalyfilatov.ru\/tags\/keys\/", "feed_url": "https:\/\/www.vitalyfilatov.ru\/tags\/keys\/json\/", "icon": "https:\/\/www.vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987", "author": { "name": "Виталий Филатов", "url": "https:\/\/www.vitalyfilatov.ru\/", "avatar": "https:\/\/www.vitalyfilatov.ru\/user\/userpic@2x.jpg?1613163987" }, "items": [ { "id": "104", "url": "https:\/\/www.vitalyfilatov.ru\/all\/status-model\/", "title": "Упрощаем набор статусов статьи", "content_html": "

Ещё один частный случай с высокими абстракциями. На этот раз на примере статусов статьи в админке Помощи ВТБ Бизнеса из прошлой статьи<\/a>.<\/p>\n

TLDR. Сперва модель статусов отражала серверную логику, отчего жизненный цикл статьи выглядел сложно. Мы вынесли один из статусов в параметр, и стало попроще, но не всем понравилось.<\/p>\n

Контекст и задача<\/h2>\n

На тот момент из-за особенностей архитектуры продукта статьи Помощи считались частью кода и обновлялись с общим релизом. Просто так править статьи было нельзя. Все изменения собирались в админке, ждали ближайшего релиза и синхронизировались с версией Помощи на проде.<\/p>\n

Из-за привязки к общему релизу статусы в админке отражали не только текущее состояние, но и будущие изменения. Кроме того, у опубликованных статей можно было управлять видимостью, что создавало дополнительные статусы.<\/p>\n

\n\"\"\n
Статусная модель статьи в админке. Если не сохранять изменения, статья возвращается в предыдущее состояние. Статью нельзя стразу опубликовать скрытой, но почему — уже не помню<\/div>\n<\/div>\n

Мне доверили придумать краткие и ясные названия статусам, чтобы пользователь меньше путался. Но я сам запутался и решил, что для начала хорошо бы упростить саму модель.<\/p>\n

Немного теории<\/h2>\n

Статусная модель описывает жизненный цикл сущностей, с которыми работает пользователь: заказы, посылки, статьи. Модель объясняет, в каких состояниях объекты могут находиться и по каким правилам переходят из одного в другое.<\/p>\n

Редакторам статусная модель интересна тем, что в ней пересекаются миры разработчиков и пользователей.<\/p>\n

Для разработчика<\/b> статусная модель — это модель жизненного цикла объекта данных, она показывает логику работы программы. За прямоугольниками на схеме разработчик видит программный код, схемы баз данных и текст запросов к ним.<\/p>\n

Для пользователя<\/b> статусная модель — важная часть ментальной модели продукта. На её основе пользователь собирает у себя в голове понимание того, как работает интерфейс. Очевидно, чем логичнее для пользователя набор состояний сущности, тем проще: не нужно запоминать значения статусов и сложные схемы переходов.<\/p>\n

\n

Хорошую статусную модель пользователь понимает интуитивно<\/p>\n<\/blockquote>\n

Чаще всего глазами пользователя на статусную модель никто не смотрит, поэтому вместе с ней в интерфейс просачивается логика программного кода. А когда пользователи начинают путаться, редактору поручают лечить проблемы в сценариях формулировками статусов и тултипами.<\/p>\n

Решение<\/h2>\n

Я предложил сделать видимость статьи одним из параметров, как её название или ключевые слова. В этом случае мы бы переключали видимость флажком в настройках и катили изменённую статью на прод. Такой подход не сильно менял структуру баз данных, но здорово упрощал схему состояний и переходов:<\/p>\n

\n\"\"\n
Если видимость сделать параметром, отдельные статусы для включения и выключения не понадобятся<\/div>\n<\/div>\n

По этой же логике можно было бы вынести в параметры и удаление, но его решили оставить отдельным статусом для удобства. Кнопка «Удалить» перемещала статью в статус «Удаляем» и заменялась на «Отменить удаление».<\/p>\n

В интерфейсе я предложил вынести статьи к релизу в отдельную вкладку и показывать там не статусы, а описание изменений.<\/p>\n

\n\"\"\n
Фрагмент условного интерфейса админки со списком публикуемых статей<\/div>\n<\/div>\n

Аналитику такое решение показалось непривычным и избыточным, мнения разделились. К счастью, пока мы спорили, публикацию статей удалось отвязать от релизного цикла, и набор статусов упростился сам собой.<\/p>\n", "date_published": "2026-05-06T17:06:57+05:00", "date_modified": "2026-05-08T17:56:02+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "_date_published_rfc2822": "Wed, 06 May 2026 17:06:57 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "104", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/092-complex-model@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/092-simple-model@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/092-articles-lists@2x.png" ] } }, { "id": "103", "url": "https:\/\/www.vitalyfilatov.ru\/all\/vtb-help\/", "title": "Редакционные процессы Помощи ВТБ Бизнеса", "content_html": "

История о том, как рерайт статей превратился в реорганизацию процессов производства.<\/p>\n

Ситуация и задача<\/h2>\n

В 2020 году ВТБ открыл интернет-банк для малого и среднего бизнеса — ВТБ Бизнес. Он служил витриной для уже существовавших банковских продуктов, которые вели автономные команды — СУБО. Такая архитектура не предусматривала единой языковой службы, да и мода на большие редакции до банка ещё не добралась. В команде платформы уже был редактор, но он занимался в основном задачами маркетинга, а статьи для справочного раздела каждое команда-СУБО писала сама.<\/p>\n

Статьи публиковались в сервисе «Помощь»<\/a>, который вела специальная команда внутренних сервисов. Руководителя этой команды беспокоило неравномерное качество этих статей, и он решил нанять второго редактора, переписывать за бизнес-аналитиками и наводить красоту. Так в команде Помощи появился я.<\/p>\n

На момент моего появления работа была организована так:<\/p>\n

    \n
  1. Каждое СУБО отвечало за свои статьи и никого к себе не пускало. Аналитики и юристы не умели писать пользовательские инструкции, поэтому ограничивались односложными ответами на частые вопросы, а стиль и глубина изложения сильно отличались.<\/li>\n
  2. Исходники статей хранились в эксель-таблицах у каждого СУБО. Авторы сами делали иллюстрации из скриншотов на тестовом сервере и заливали в общее облако.<\/li>\n
  3. Когда нужно было что-то изменить или добавить, бизнес-аналитик СУБО правил свою таблицу, выделял изменения цветом и присылал новый файл по почте команде Помощи.<\/li>\n
  4. Там текст из файла вставляли в базу данных и выкатывали на прод с общим релизом.<\/li>\n<\/ol>\n

    Процесс получался хаотичным: версии статей не отслеживали, файлы таблиц дублировались, актуальные правки терялись, картинки разных СУБО перетирали друг друга из-за совпадающих имён. Оперативно выложить что-то было невозможно из-за релизной политики, поэтому иногда статьи успевали обновиться несколько раз до релиза и окончательно всех запутать.<\/p>\n

    Чтобы упорядочить процесс, команда Помощи написала специальную админку с визуальным редактором, где авторы смогли бы работать со статьями без посредников. Но качество от этого не росло, а править и согласовывать текст в админке было так же муторно, как и в эксель-таблицах. Так что я составил план, заручился поддержкой команды и переделал сам подход к производству.<\/p>\n

    Работа с материалами<\/h2>\n

    Первым делом я убедил команду, что писать статьи и следить за структурой разделов нужно нам самим, а СУБО оставить только сбор фактуры, обновление макетов и согласование. Уже опубликованные статьи мы решили постепенно переписать по мере изменений в продуктах.<\/p>\n

    СУБО не обрадовались потере контроля, но после нескольких согласованных статей они обычно убеждались, что редактор бережно передаёт смысл, начинали доверять и охотнее рассказывать о бизнес-логике и нюансах.<\/p>\n

    Мы перенесли все статьи в гугл-доки<\/b>, а ссылки на них и служебную информацию собрали в сводной гугл-таблице. Таблица решала две задачи: хранила статьи со статусами и служила функциональным прототипом для следующих версий админки Помощи.<\/p>\n

    \n\"\"\n
    Сводная таблица — сердце системы контента. Там мы хранили все статьи, включая снятые с публикации, отменённые и удалённые. Вся таблица в гигантском PNG<\/a>, 2 Мб<\/div>\n<\/div>\n

    В первой версии админки не было инструментов согласования, поэтому их заменяли гугл-доки. Мы гибко настраивали доступы, вели архив версий, принимали и согласовывали правки. Особый шик давала совместная работа: на сложных согласованиях я приглашал всех следить за моим курсором в документе и правил текст прямо во время звонка, без расшаривания экрана.<\/p>\n

    Гугл-доки помогали и в вёрстке. Я подогнал шаблон статьи максимально близко к дизайну прода и при редактировании сразу видел примерную форму абзацев и переносы строк.<\/p>\n

    \n\"\"\n
    Аналитики и юристы могли комментировать исходники в любое время, я оперативно разбирал правки и публиковал обновления с ближайшим релизом<\/div>\n<\/div>\n

    Далее мы убрали автогенерацию слагов<\/b> — уникальных частей в URL-адресах статей. Первоначально слаг создавался транслитерацией заголовка, но адреса получались длинными и нечитаемыми. Я предложил составлять слаги силами редактора, чтобы адреса получались понятнее, умещались в СМС и не разрывали сообщения чат-бота.<\/p>\n

    \n

    Срок действия дополнительных опций к пакетам услуг
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dejstviya-dopolnitelnyh-opcij-k-paketam-uslug<\/b>
    \n↓
    \ndb.vtb.ru\/faq\/answers\/srok-dop-optsii<\/b><\/p>\n<\/blockquote>\n

    Уникальностью слагов отслеживали по сводной таблице и проверке на дубли в админке.<\/p>\n

    Поскольку слаги менялись крайне редко, я включил их в имена файлов иллюстраций. Такие имена не повторялись, и по ним можно было фильтровать файлы в хранилище. Папки в облаке также назывались слагом статьи.<\/p>\n

    \n\"\"\n
    Имена файлов упрощали рутину. Например, пожав пачку картинок в тинифаере, я сразу знал, куда сохранять архив с результатом<\/div>\n<\/div>\n

    Перешли со скриншотов интерфейса на макеты в Фигме<\/b>. Пришлось искать подход к дизайнерам СУБО и убеждать их обновлять макеты к релизам, но оно того стоило. Иллюстрации стали чище и консистентнее, а их исходники были всегда доступны. Но главное — мы смогли показывать все нужные состояния интерфейса, а не только те, что получалось поймать на тестовом сервере.<\/p>\n

    Сначала я готовил иллюстрации сам, чтобы изучить нюансы и сформулировать правила. Позже собрал всё в гайд для дизайнеров, и они начали мне помогать.<\/p>\n

    Гайд по изображениям для статей Помощи<\/a> получился наглядным: все картинки в нём собраны по требованиям гайда, чтобы читатель сразу видел образец.<\/p>\n

    Создали наглядный прототип в Обсидиане<\/b>, где отслеживали структуру каталогов, связи между статьями, выпавшие иллюстрации и ссылки на файлы. Чтобы не делать это руками после каждого крупного обновления, я собрал требования, а аналитик Евгений написал скрипт на Питоне.<\/p>\n

    \n\"\"\n
    Граф опубликованных статей в Обсидиане. Красные точки — страницы категорий, оранжевые — статьи с перекрёстными ссылками, а зелёные — с файлами для скачивания<\/div>\n<\/div>\n

    Публикация статей<\/h2>\n

    Админка Помощи задумывалась не для редакторов, поэтому за основу команда взяла визуальный редактор на контейнерах — как в Ноушене. Но он не умел работать в режиме исходного кода — HTML или маркдауна.<\/p>\n

    Необходимость настраивать оформление вручную ломала мой отработанный процесс: на других проектах я целиком копировал гугл-док и прогонял текст через Драйзер<\/a> — самописный скрипт на регулярках. Скрипт вырезал инлайн-стили и служебные блоки, оставляя чистый HTML. Так я мог заряжать в админку по статье в минуту.<\/p>\n

    Менять редактор было поздно, но разработчики нашли остроумное решение: добавили переключатель, который скрывал все контейнеры и показывал поле для HTML-кода.<\/p>\n

    \n
    \n\"\"\n\"\"\n<\/div>\n
    Редактирование статьи в обычном и экспертном режимах. В ранних версиях админки статья называлась вопросом, так уж вышло<\/div>\n<\/div>\n

    Мы выбрали HTML, а не в маркдаун, чтобы как можно меньше переписывать админку. Я всё равно получал готовый код из гугл-дока и сразу типографил текст своими скриптами.<\/p>\n

    Ещё я поучаствовал в разработке админки: тестировал механики, писал текст интерфейса, подменял дизайнера, надоедал всем нормами типографики и спорил с бизнес-аналитиком из-за статусной модели<\/a> :3<\/p>\n

    Работа с СУБО<\/h2>\n

    Сначала в Помощи публиковались 10 команд, но позже их стало уже 35. Они постоянно что-то меняли, уследить за всем было невозможно. Поэтому мы договорились, что за актуальностью своих статей СУБО следят сами, а команда Помощи отвечает за подготовку и публикацию.<\/p>\n

    Процесс добавления новой статьи выглядел так:<\/p>\n

      \n
    1. В СУБО назначали ответственного за процесс и обновляли макеты.<\/li>\n
    2. Ответственный заполнял бриф на новую статью<\/a>, в котором указывал тему, полезное действие, примерный план, ссылки на макеты и документацию.<\/li>\n
    3. Я принимал заявку, изучал материалы и предметную область, задавал вопросы аналитикам и дизайнерам, просил показать продукт в работе.<\/li>\n
    4. Собрав всю фактуру, я писал черновик и готовил иллюстрации по макетам.<\/li>\n
    5. Ответственный вычитывал и комментировал черновик, я дописывал нужное, и всё повторялось, пока статья не была готова.<\/li>\n
    6. Согласованную статью я добавлял в админку, помечал готовой к публикации и закрывал задачу.<\/li>\n<\/ol>\n

      Чтобы изменить уже опубликованную статью, ответственный просто правил копию исходника и передавал мне. А чтобы не тонуть в бюрократии, мелкие правки мы вносили без задачи в Джире, просто по переписке в мессенджере.<\/p>\n

      Задачи шли потоком, мы постоянно что-то правили, обновляли, поддерживали порядок и готовили пачки новых статей к релизам. Отслеживать всё в Джире не получалось, поэтому я завёл редакционный дашборд в Трелло.<\/p>\n

      \n\"\"\n
      Объём задачи в карточке мог быть любым, от мелкой правки до десятка статей<\/div>\n<\/div>\n

      Карточка с задачами типичного релиза выглядела так:<\/p>\n

      \n\"\"\n
      Обновляем 77 статей: добавляем новые, объединяем старые, правим опечатки, заменяем иллюстрации со старым интерфейсом<\/div>\n<\/div>\n

      Итоги<\/h2>\n

      Настроив процессы, мы занялись обычной текучкой: писали новые статьи, обновляли старые, изучали обратную связь от пользователей и операторов горячей линии, следили за обращениями в поддержку и метриками сервиса.<\/p>\n

      Наша команда занималась и другими внутренними сервисами, поэтому мы смогли включить статьи Помощи в глобальный поиск, базу знаний поддержки, чат-бота и контекстную справку в интерфейсе. Нашему руководителю Александру удалось совершить дипломатическое чудо и отвязать публикацию статей от общего релизного цикла, и мы стали обновлять статьи по мере изменений в продуктах, без очередей и предрелизной спешки.<\/p>\n

      Но статей становилось всё больше, а задач на UX-редактуру не прибавлялось, так что я решил заняться Умным домом в МТС. А чтобы проект было легче передать, собрал материалы, записал скринкасты с основными процессами и составил вакансию редактора Помощи<\/a>.<\/p>\n

      К сожалению, вскоре в компании изменилась политика информационной безопасности, внешние облачные сервисы запретили и отбить гугл-доки не удалось. Исходники статей переехали в корпоративную вики, и процессы вновь пришлось менять.<\/p>\n

      Благодарности<\/h2>\n

      Спасибо команде Помощи за понимание, поддержку и вовлечённость. Вы с готовностью вникали во все мои идеи, хоть иногда я не особо выбирал выражения. С вами я получил бесценный опыт — как быть частью команды и находить продуктивное решение.<\/p>\n

      «Хороших выходных. И ведите себя плохо!» ©<\/p>\n", "date_published": "2026-03-23T11:51:11+05:00", "date_modified": "2026-05-06T17:22:18+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "_date_published_rfc2822": "Mon, 23 Mar 2026 11:51:11 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "103", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/jquery\/jquery.js", "system\/library\/fotorama\/fotorama.css", "system\/library\/fotorama\/fotorama.js" ], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/091-pivot-table@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-comments@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-tinypng@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-obsidian@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-editor-nodes@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-editor-html@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-trello-dashboard@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/091-trello-release@2x.png" ] } }, { "id": "98", "url": "https:\/\/www.vitalyfilatov.ru\/all\/ideal-id\/", "title": "Кейс с совпадающими номерами", "content_html": "

      История про совпадения в номерах стикеров и понимание коммуникационной задачи. И почему нельзя просто так взять и сделать правильно<\/i>.<\/p>\n

      Рабочие макеты под NDA, поэтому в этот раз только текстом.<\/p>\n

      Ситуация<\/h2>\n

      Пользователю нужно подготовить поставку в пункт выдачи: пройтись по своему складу, собрать товары по списку, наклеить на них стикеры с уникальными номерами, упаковать и отвезти.<\/p>\n

      Чтобы человеку было удобно, разработчики придумали интерактивный чек-лист с нужными товарами и номерами стикеров. Абстрактно список выглядит так:<\/p>\n

      \n

      1245642 9258<\/b>
      \n9008731 9685<\/b>
      \n5748202 4973<\/b>
      \n4505331 9685<\/b>
      \n2356911 6736<\/b><\/p>\n<\/blockquote>\n

      Там ещё есть чекбоксы, фотки и названия товаров, но про макеты я уже говорил, просто представьте, что они там есть. Четыре последних цифры выделены — пользователям удобно по ним ориентироваться.<\/p>\n

      Фишка в том, что эти «хвосты» в большинстве случаев уникальны, но иногда совпадают у разных номеров, как в примере выше. И это проблема: пользователь может спутать, наклеить не тот стикер, и товар не примут.<\/p>\n

      Чтобы обратить внимание пользователя на совпадающие хвосты, команда решает подсветить их цветной плашкой и написать про это в справке к разделу. Наша задача — составить текст, не влезая в уже готовый дизайн.<\/p>\n

      Формальное решение<\/h2>\n

      Сперва напишем, что просят, а потом будем рассуждать про дизайн, визуальную коммуникацию и основы когнитивной психологии.<\/p>\n

      \n

      Похожие стикеры подсвечиваются<\/b>
      \nКогда у разных стикеров совпадают последние 4 цифры, мы выделяем их цветом. Если встретили такой, обратите внимание на его полный номер<\/p>\n<\/blockquote>\n

      Теперь можно сформулировать коммуникационную задачу<\/i> и начать думать. Задача коммуникации простая:<\/p>\n

      \n

      Обратить внимание пользователя на разные номера с одинаковыми «хвостами» и помочь не спутать стикеры<\/p>\n<\/blockquote>\n

      Очевидно, что в контексте задачи выделять «хвосты» цветом — плохое решение: мы привлекаем внимание к какому-то искусственному признаку, а не к важному. Как чиновники, когда подсвечивают знак пешеходного перехода вместо самого пешехода (смотри бессмертную заметку Лебедева<\/a>).<\/p>\n

      Мало того. Мы привлекаем внимание к общей части различающихся сущностей, что помогает мало. Перефразируя один из гештальт-принципов, можно сказать, что похожие сущности воспринимаются, как связанные по смыслу<\/i>. А нам нужно сделать акцент на их различии. Для этого можно выделить различающиеся части проблемных номеров:<\/p>\n

      \n

      1245642 9258<\/b>
      \n9008731<\/b> 9685
      \n5748202 4973<\/b>
      \n4505331<\/b> 9685
      \n2356911 6736<\/b><\/p>\n<\/blockquote>\n

      Выглядит так себе, но задачу решает.<\/p>\n

      Можно оставить выделение цветом, но дополнительно его усилить каким-нибудь сигналом. Например, значком:<\/p>\n

      \n

      9008731 9685<\/b><\/mark> ⚠
      \n5748202 4973<\/b>
      \n4505331 9685<\/b><\/mark> ⚠<\/p>\n<\/blockquote>\n

      Спорно, конечно, но хорошее визуальное решение найдёт дизайнер, нам важнее показать общий принцип.<\/p>\n

      Системное решение<\/h2>\n

      Всё по ТРИЗ: масштабно и безответственно. Изменить алгоритм генерации номера, чтобы исключить возможность путаницы. Например, генерировать номер так, чтобы в одной поставке не было одинаковых «хвостов».<\/p>\n

      А ещё лучше — генерировать номер на основе системного ID пользователя и даты сбора поставки с исключением номеров, совпадающих в последних 4 цифрах. Если вдруг не хватит разрядности, можно увеличить длину номера или перейти на шестнадцатеричную систему счисления, где вариантов будет примерно в шесть раз больше.<\/p>\n

      \n

      0000—9999 — 10 000 вариантов, 10 в 4 степени
      \n0000—FFFF — 65 536 вариантов, 16 в 4 степени<\/p>\n<\/blockquote>\n

      Но решение с уникальной генерацией реализуемо только в принципе. Номерами, чек-листом и печатью стикеров заведуют разные команды. У каждой — свои приоритеты, ресурсы и горящие задачи. Никто просто не сможет протащить через владельца и скоординировать такое крупное изменение. В компаниях обычно просто нет продактов, которые таким занимаются. А у имеющихся зона ответственности и интересов ограничена задачами их команды.<\/p>\n

      Стоит добавить, что про «правильную» генерацию наверняка уже кто-то думал, но столкнулся с таким ворохом трудностей и зависимостей в реализации, который с лихвой перекрыл ожидаемую выгоду. Но мы не узнаем наверняка: на большинстве проектов не ведут поисковую<\/del> документацию.<\/p>\n

      UPD. Статье нужен какой-нибудь афористичный вывод, так что вот он: продукт нужно проектировать до того, как он начнёт приносить прибыль. Потом уже будет не до этого.<\/p>\n", "date_published": "2025-06-19T22:06:29+05:00", "date_modified": "2025-06-19T22:46:06+05:00", "_date_published_rfc2822": "Thu, 19 Jun 2025 22:06:29 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "98", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "96", "url": "https:\/\/www.vitalyfilatov.ru\/all\/input\/", "title": "Поле ввода с подсказками", "content_html": "

      Помогаем пользователю заполнить сложное поле и разбираемся, чем задача отличается от проблемы. Кейс свежий, детали под NDA, поэтому всё в условном дизайне и без конкретики.<\/p>\n

      Ситуация<\/h2>\n

      Пользователю нужно заполнить графу с номером документа, подтверждающего качество товара. Бэк-офис проверяет документы, у товара в каталоге появляется отметка подлинности, и покупатели охотнее его берут.<\/p>\n

      \n\"\"\n
      Качество товаров в России подтверждают сертификаты и декларации соответствия<\/div>\n<\/div>\n

      Нумерация у документов ожидаемо дикая, по четыре префикса на каждый вид:<\/p>\n

      \n

      ЕАЭС [N] RU [Д,С]<\/b>-XX.YYYY.A.00000<\/p>\n<\/blockquote>\n

      \n

      РОСС RU [Д,С]<\/b>-XX.YYYY.A.00000<\/p>\n<\/blockquote>\n

      \n

      ТС [N] RU [Д,С]<\/b>-XX.YYYY.A.00000<\/p>\n<\/blockquote>\n

      \n

      RU [Д,С]<\/b>-XX.YYYY.A.00000<\/p>\n<\/blockquote>\n

      У деклараций есть N и «Д» перед дефисом, у сертификатов пишем только «С». Остальные части номера тоже хитрые: сначала русские буквы и цифры, потом они же с латиницей, потом опять русская, потом только цифры.<\/p>\n

      Пользователи ожидаемо путаются, пишут в поддержку и плохо проводят время. Нужно помочь им разобраться и правильно всё ввести. Для этого фронты придумали узнавать префикс и накладывать на поле нужную маску:<\/p>\n

      \n\"\"\n<\/div>\n

      Задача<\/h2>\n

      Маску мы показываем, но пользователи всё ещё плохо понимают, где какие символы вводить. Когда пользователи ошибаются, форма ругается ошибками, но это не очень помогает.<\/p>\n

      \n\"\"\n<\/div>\n

      Нужно как-то подсветить, что часть номера может состоять как из латинских символов, так и из русских. Есть памятка во всплывающем окне, где изложен весь этот ребус. Она написана по мотивам документации, нужно переписать по-человечески:<\/p>\n

      \n

      Как заполнить номер<\/b><\/p>\n<\/blockquote>\n

      \n

      С или Д<\/b> — кириллические буквы. Символ принадлежности номера к сертификату\/декларации соответствия<\/p>\n<\/blockquote>\n

      \n

      ХХ<\/b> — кириллические буквы и цифры. Код страны изготовителя продукции<\/p>\n<\/blockquote>\n

      \n

      YYYY<\/b> — латинские и кириллические буквы и цифры. Код органа по сертификации, выдавшего сертификат соответствия<\/p>\n<\/blockquote>\n

      \n

      А<\/b> — только кириллические буквы. Тип объекта сертификации<\/p>\n<\/blockquote>\n

      \n

      00001<\/b> — только цифры. Порядковый номер сертификата соответствия<\/p>\n<\/blockquote>\n

      Такое получается, потому что постановщики задач в продукте часто мыслят категориями разработки и описывают в инструкции технические требования, а не порядок действий для человека. Это нормально.<\/p>\n

      Решение<\/h2>\n

      Формальное.<\/b> Изучим предмет и напишем памятку в понятном формате: какие бывают номера и какие буквы вводить. Про заглавные писать не будем, пусть фронты сделают перевод всех символов в верхний регистр. Остальное изложим от читателя. Заодно чуть поменяем маску, чтобы не обозначать русские буквы латинскими. Получится примерно так:<\/p>\n

      \n

      Как заполнить номер<\/b><\/p>\n<\/blockquote>\n

      \n

      1. Найдите номер документа<\/b><\/p>\n<\/blockquote>\n

      \n

      У сертификата номер в Росаккредитации указан внизу листа, а у декларации в самом верху.<\/p>\n<\/blockquote>\n

      \n

      Сертификат<\/b><\/p>\n<\/blockquote>\n

      \n

      — ЕАЭС RU С-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — РОСС RU С-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — ТС RU С-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — RU С-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      Декларация<\/b><\/p>\n<\/blockquote>\n

      \n

      — ЕАЭС N RU Д-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — РОСС RU Д-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — ТС N RU Д-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      — RU Д-ББ.YYYY.Г.00000<\/p>\n<\/blockquote>\n

      \n

      2. Начните вводить номер<\/b><\/p>\n<\/blockquote>\n

      \n

      Введите первые символы номера, и в поле появится подсказка с его форматом. Жирным выделена общая часть для всех номеров:<\/p>\n<\/blockquote>\n

      \n

      ЕАЭС RU С-ББ.YYYY.Г.00000<\/b><\/p>\n<\/blockquote>\n

      \n

      ББ<\/b> — русские буквы и цифры<\/p>\n<\/blockquote>\n

      \n

      YYYY<\/b> — цифры, русские или английские буквы<\/p>\n<\/blockquote>\n

      \n

      Г<\/b> — русская буква<\/p>\n<\/blockquote>\n

      \n

      00000<\/b> — только цифры<\/p>\n<\/blockquote>\n

      Понятно, что изначальную проблему памятка не решает и нужно идти дальше. Хорошо бы не только написать в мире читателя, но и разобраться, где именно у него возникает проблема, и работать с ней по месту.<\/p>\n

      Полное.<\/b> Очевидно, проблемы у пользователя возникают в момент ввода номера, а потому отрывать его от ввода и показывать памятку бессмысленно. Её нужно открыть, прочитать и запомнить, а потом ещё и применить. Поэтому стоит просто подсказывать нужное по мере ввода. Вот примерно так:<\/p>\n

      \n\"\"\n
      Маску можно распознать по первому символу: все четыре вида уникальны, а тип документа мы уже знаем<\/div>\n<\/div>\n

      Можно ограничивать ввод по позиции курсора, но это сложнее в реализации и не факт, что сильно удобнее. Поэтому ограничимся подсказками и за кадром проработаем ошибки.<\/p>\n

      На этом стоило бы и закончить, но у нас есть ещё два решения.<\/p>\n

      Избыточное.<\/b> Можно вместо маски показывать набор полей для каждой части номера. Выглядит серьёзно, но на деле только сделает дороже разработку и поддержку. Ещё это усложнит обработку при вставке из буфера обмена, а пользователи чаще всего копируют номер документа, а не набирают его руками. Вот так не нужно:<\/p>\n

      \n\"\"\n<\/div>\n

      Идеальное.<\/b> Сделать так, чтобы человеку вообще ничего не надо было вводить. Пусть номер считывает камера телефона и распознаёт нейросеть. Пока это возможно лишь технически, но когда-нибудь наша цивилизация покорит космос, и такие вещи станут ожидаемой нормой.<\/p>\n

      Выводы<\/h2>\n

      Формальную часть решения у нас точно примут — она не противоречит условиям задачи и ситуации в команде продукта. А вот полное, скорее всего, завернут или добавят частями в конец бэклога. Решение нужно ещё вчера, есть задачи важнее, а разработчики и так вывихнули мозги, пока вкрячивали подстановку маски в типовое поле ввода, которое это не предусматривало.<\/p>\n

      Тем не менее задачи стоит решать полностью, чтобы собирать портфолио<\/s> постепенно убеждать окружающих в пользе UX-специалистов. А заодно подкреплять идею, что пользовательские проблемы решаются не только редактурой текста, но и организацией смысла вообще.<\/p>\n", "date_published": "2024-10-24T11:23:04+05:00", "date_modified": "2024-10-24T13:17:21+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/086-original@2x.png", "_date_published_rfc2822": "Thu, 24 Oct 2024 11:23:04 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "96", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/086-original@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/086-mask@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/086-error@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/086-result@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/086-toomuch@2x.png" ] } }, { "id": "95", "url": "https:\/\/www.vitalyfilatov.ru\/all\/book-of-melentor\/", "title": "Продолжение истории про эльфа и его друзей", "content_html": "

      В далёком уже 2021 году мы с художником-иллюстратором Ulv Vind печатали самодельную книжку «Заметки беспечного путешественника». В блоге был рассказ про неё<\/a>.<\/p>\n

      \n

      UPD. Ноябрь 2024
      \nСайт книги       mel.vitalyfilatov.ru<\/a>
      \n      Бусти с книгой и дополнительными материалами<\/a><\/p>\n<\/blockquote>\n

      \n\"\"\n
      Так выглядел тираж версии 2021 года<\/div>\n<\/div>\n

      Тираж мы распродали и думали заняться чем-нибудь другим, но читатели просили продолжение. Так что мы собрались, дописали-дорисовали книжку до полноценной повести с добротным эпилогом. А теперь предлагаем вам её почитать.<\/p>\n

      О чём книга<\/h2>\n

      Молодой эльф Мелентор отправляется в долгожданное путешествие и записывает всё увиденное в дорожном дневнике. В таверне он встречает пройдоху-следопыта и молчаливого мечника, с которыми решает совершить дерзкое ограбление дракона. Конечно же, этот поход не приносит добычи, а одни неприятности. И теперь героям предстоит осознать все последствия и попытаться их исправить…<\/p>\n

      Чем книга интересна<\/h2>\n

      Она сказочная и с картинками<\/b><\/p>\n

      Главное достоинство нашей истории — она простая, добрая и написана от лица интеллигентного эльфа. В ней нет безысходной мрачности тёмного фэнтези, жестоких сцен и грубых выражений. Так что её можно читать детям и дарить любителям лёгкого фэнтези.<\/p>\n

      Основные темы повести: дружба, ответственность за поступки и красота волшебного мира. Наши герои не выясняют отношений и не тонут в рефлексии, они беспечно гуляют по лесам-болотам и без истерик справляются с трудностями.<\/p>\n

      А ещё в книге много красивых иллюстраций, которые интересно рассматривать.<\/p>\n

      \n\"\"\n<\/div>\n

      История собрана вокруг игры с жанром<\/b><\/p>\n

      Мы не стали оригинальничать и сосредоточились на том, чему научились по настольным ролевым играм — игре в персонажа. Наш рассказчик — талантливый дилетант: он субъективен и несведущ в литературном ремесле, а часть важных событий происходит за пределами его внимания.<\/p>\n

      Эта игра в постфэнтези роуд-муви привела нас к «постмодернизму здорового человека». История прикидывается модерном, делая вид, что до неё никакого фэнтези не было, вместе с тем в меру интеллигентно опирается на устоявшиеся жанровые тропы: концепцию научной магии, базовые расы, героическое прошлое родственников, вот это всё.<\/p>\n

      Герой-рассказчик не преследует цели развлечь читателя, а просто по порядку излагает увиденное в своих первых трёх походах. В то же время книга взрослеет вместе с автором. Если первый поход занимает три страницы обрывочных заметок, второй под 60 страниц дневника, то третий уже написан как полноценная повесть.<\/p>\n

      \n\"\"\n
      Дварф и его драконовая ящерица<\/div>\n<\/div>\n

      По книге можно изучать цикл производства<\/b><\/p>\n

      Я UX-редактор, а Ulv — профессиональный художник. Конечно же, наша книжка — типичный информационный продукт, прошедший все стадии от MVP-уродца до полноценного проекта.<\/p>\n

      Книг мы до этого не писали, а потому собрали все возможные грабли, утонули в проблемах и героически их преодолевали. В итоге мы преисполнились и применили проектный подход, наша книжка выросла в полноценный проект, а проблемы в итоге привели к некоторым удачным решениям.<\/p>\n

      В тексте видны следы дыр, нестыковок и последствий срочных решений, но вместе с тем, можно проследить поэтапное взросление идеи произведения и нашего подхода к работе. В дополнительных материалах на Бусти мы про всё это потихоньку рассказываем.<\/p>\n

      \n\"\"\n<\/div>\n

      Где читать<\/h2>\n

      На Бусти, по главам<\/b>. Сама книга с иллюстрациями доступна бесплатно, дополнительные материалы — по платной подписке.<\/p>\n

      Сам бусти — https:\/\/boosty.to\/melentor<\/a><\/a><\/p>\n

      Оглавление и ссылки на материалы по книге<\/a><\/p>\n

      PDF-версия<\/b> появится на Бусти, когда я её доверстаю, а литредактор её вычитает. Ориентировочные сроки — середина лета 2024. Следите за новостями.<\/p>\n

      Бумажная версия<\/b> — TBD. Мы планируем печатать книгу в твёрдом переплёте на хорошей бумаге, но когда это будет и сколько будет стоить, пока не ясно. Следите за новостями и подписывайтесь на обновления, чтобы ничего не пропустить.<\/p>\n", "date_published": "2024-06-14T16:16:44+05:00", "date_modified": "2024-11-18T22:37:18+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/055-book-cover.jpg", "_date_published_rfc2822": "Fri, 14 Jun 2024 16:16:44 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "95", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/055-book-cover.jpg", "https:\/\/www.vitalyfilatov.ru\/pictures\/055-book-pack.jpg", "https:\/\/www.vitalyfilatov.ru\/pictures\/085-doroga-v-himelhol@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/085-kusala-i-gnom@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/085-derev-gnom@2x.png" ] } }, { "id": "93", "url": "https:\/\/www.vitalyfilatov.ru\/all\/stalker\/", "title": "Сила маркера и скотча", "content_html": "

      Помогал проводить ролевую игру по Сталкеру<\/a>: следил за работой игровой локации, изображавшей заброшенную лабораторию. Я проверял на входе ключ-пропуск и снаряжение, напоминал правила и следил за временем забегов, а в перерывах подкидывал внутрь игровые ценности и дымовые шашки.<\/p>\n

      В ходе игры выяснилось, что локация работает непонятно и неудобно. Пришлось решать на месте подручными средствами.<\/p>\n

      Ситуация<\/h2>\n

      Лабораторию устроили в заброшенном овощехранилище. Закрыли окна и лишние двери, оставив два входа: один для игроков, другой для организаторов. Служебный вход пометили сигнальной лентой, а на игровой повесили старый кассовый аппарат в роли кодового замка на шлюзе.<\/p>\n

      \n\"\"\n
      В неигровой зоне я ждал игроков и хранил реквизит<\/div>\n<\/div>\n

      Оказалось, что локация непонятно и неудобно организована.<\/p>\n

      Непонятки.<\/b> По задумке я должен был встречать игроков внутри, проверять ключ-пропуск и запускать в лабораторию. Но иногда игроки просто шли мимо и решали проверить дверь со странной штукой. Они врывались внутрь, осматривали углы и иногда успевали пробежать мимо меня в неигровую зону или лабораторию. Приходилось их останавливать, а это сбивало кураж и портило погружение.<\/p>\n

      Неудобки.<\/b> Локация работала с утра до двух ночи, сидеть там постоянно не получалось. Пока меня не было, локация портила игру: игроки без ключа решали, что закрытые двери ведут в неигровые зоны, а игроки с ключом не знали, когда я вернусь, и теряли время.<\/p>\n

      Решение<\/h2>\n

      У меня был маркер, бумага и двухсторонний скотч, поэтому я написал таблички.<\/p>\n

      Первой я повесил табличку на входе. Двери в лабораторию и неигровую зону закрывались навесными замками, а входная нет, да и закрывать её было бессмысленно — всё равно непонятно, что это и как с этим играть. Нужна была четкая инструкция, отсекающая кейс неавторизованного входа.<\/p>\n

      \n\"\"\n
      Неприметная дверь в заросшем закутке вела в полный опасностей лабиринт<\/div>\n<\/div>\n
      \n\"\"\n
      Понятно, что это игровая зона и нужен игровой предмет, а мне нужно поработать над леттерингом<\/div>\n<\/div>\n

      После этого случайные посетители перестали забегать, а игроки с ключами показывали их с порога.<\/p>\n

      Внутри я повесил ещё по табличке на каждую дверь. На неигровую — пояснение со стрелкой, а на игровую — инструкцию с подсказкой.<\/p>\n

      \n
      \n\"\"\n\"\"\n<\/div>\n
      Рация есть у каждого, но за сутки она может разрядиться<\/div>\n<\/div>\n

      После этого я смог смело ходить по делам, а игроки меня не теряли.<\/p>\n

      Выводы<\/h2>\n
        \n
      1. Интерфейсы и процессы есть везде, где есть люди.<\/li>\n
      2. Пользовательский опыт нужно целенаправленно организовывать, иначе люди организуют его себе сами как сумеют.<\/li>\n
      3. Суть важнее формы. Вовремя и кое-как лучше, чем красиво, но поздно.<\/li>\n
      4. Люди читают, если текст выглядит важным. Просто важность субъективна и зависит от контекста и внимания.<\/li>\n<\/ol>\n", "date_published": "2023-09-12T18:22:49+05:00", "date_modified": "2023-09-12T22:22:33+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/083-plan@2x.png", "_date_published_rfc2822": "Tue, 12 Sep 2023 18:22:49 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "93", "_e2_data": { "is_favourite": false, "links_required": [ "system\/library\/jquery\/jquery.js", "system\/library\/fotorama\/fotorama.css", "system\/library\/fotorama\/fotorama.js" ], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/083-plan@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/083-lab-entrance@2x.jpg", "https:\/\/www.vitalyfilatov.ru\/pictures\/083-lab-entrance-door@2x.jpg", "https:\/\/www.vitalyfilatov.ru\/pictures\/083-lab-gateway@2x.jpg", "https:\/\/www.vitalyfilatov.ru\/pictures\/083-lab-door@2x.jpg" ] } }, { "id": "92", "url": "https:\/\/www.vitalyfilatov.ru\/all\/status\/", "title": "Статус с числительным", "content_html": "

        Заметка о согласовании глаголов с числительными: как сначала не получалось, а потом я уточнил ограничения и получилось.<\/p>\n

        Задача<\/h2>\n

        Есть умный терморегулятор для батареи отопления. Он работает как автоматический вентиль: накручивается на трубу и открывает-закрывает клапан, поддерживая нужную температуру в комнате.<\/p>\n

        \n\"\"\n
        Умный регулятор Aqara. Фото неизвестного автора из отзывов на Яндекс-Маркете<\/div>\n<\/div>\n

        Поскольку это умный<\/i> терморегулятор, в нём много чего есть: защита от детей, режим антифриза, контроль заряда батарейки, перекрытие клапана. Все изменения в работе отражаются в событиях приложения умного дома. Нужен текст этих событий.<\/p>\n

        Сложность возникла с формулировкой изменения температуры. Каждый раз, когда мы выставляем температуру, в историю пишется событие типа:<\/p>\n

        \n

        На термоголовке установлена температура XX,X градусов<\/p>\n<\/blockquote>\n

        Дизайн уже согласован, менять ничего нельзя. Нужно написать в одну строку, влезть в количество символов с обязательной дробью и ещё как-то отметить, где пользователь выставил температуру: физической крутилкой или в приложении.<\/p>\n

        Решение<\/h2>\n

        Уберём пока про термоголовку и заменим слово «градусов» на символ:<\/p>\n

        \n

        На термоголовке установлена температура XX,X градусов<\/p>\n<\/blockquote>\n

        \n

        ↓<\/p>\n<\/blockquote>\n

        \n

        Установлена температура XX,X°<\/p>\n<\/blockquote>\n

        Стало короче, но всё ещё не влезает. Слово «температура» вроде лишнее, но без него придётся согласовывать окончания глагола:<\/p>\n

        \n

        Установлен 1,0°<\/p>\n<\/blockquote>\n

        \n

        Установлено 30,0°<\/p>\n<\/blockquote>\n

        Следить за окончаниями разработчики категорически откажутся, нужно изящно-тупое решение. Заменить слово символом или поставить двоеточие не годится, получается ребус или неестественный уродец:<\/p>\n

        \n

        ❌ Установлена t° 1,0<\/p>\n<\/blockquote>\n

        \n

        ❌ Установлено: 1,0°<\/p>\n<\/blockquote>\n

        Можно было бы вывернуться с фразой «Вы установили…», но это звучит глупо и пользователей у умного дома может быть несколько.<\/p>\n

        Выясняю у аналитиков диапазон температуры, которую можно выставить на девайсе: 5—30 С°.<\/p>\n

        Получается, для всех вариантов подойдёт «Установлено». Остаётся 21°, который «установлен», но тут мы пойдём на сделку с совестью и прочтём с дробью:<\/p>\n

        \n

        Установлено двадцать один и ноль десятых градуса<\/p>\n<\/blockquote>\n

        Кому, вообще, нужен ровно 21 градус Цельсия? Зато теперь всё влезает, а место изменений уместилось под строкой статуса. Оказалось, в реализованном компоненте оставили коробок для служебной информации, которая в событиях отдельного устройства не выводится. Там же можно указывать других пользователей.<\/p>\n

        \n\"\"\n
        Результат в условном дизайне. Рабочий под NDA<\/div>\n<\/div>\n

        Выводы-советы<\/h2>\n
          \n
        1. Дружите с аналитиками и разработчиками<\/li>\n
        2. Выясняйте технические ограничения<\/li>\n
        3. Изучите дизайн-систему и UI-кит<\/li>\n
        4. Не всё можно и нужно решать текстом, советуйтесь с дизайнером<\/li>\n<\/ol>\n", "date_published": "2023-08-03T14:39:45+05:00", "date_modified": "2023-08-03T14:48:23+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/082-aqara.png", "_date_published_rfc2822": "Thu, 03 Aug 2023 14:39:45 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "92", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/082-aqara.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/082-logs@2x.png" ] } }, { "id": "84", "url": "https:\/\/www.vitalyfilatov.ru\/all\/complicated-example\/", "title": "Сложный способ нарисовать лабиринт", "content_html": "

          Дополнение к заметке о трудных и сложных задачах<\/a>. Посмотрим на примере картинки с лабиринтами, как трудоёмкую задачу можно преобразовать в изобретательскую. Пример не самый наглядный, но я постараюсь показать движение мысли на чём есть.<\/p>\n

          \n

          В тексте встречаются вводные Итак<\/i>, Следовательно<\/i> и Очевидно<\/i>. Вы предупреждены.<\/p>\n<\/blockquote>\n

          Контекст<\/h2>\n

          Итак, для статьи мне была нужна иллюстрация с двумя лабиринтами: обычным и линейным, из одного коридора без тупиков.<\/p>\n

          \n\"\"\n
          По замыслу лабиринты иллюстрируют мысль, что сложное от трудного отличается обязательным поиском пути к результату<\/div>\n<\/div>\n

          Лабиринты нужны в одном стиле и размере, но рисовать их весь вечер не хочется. Шансы подобрать готовые картинки нулевые, никому в голову не придёт рисовать лабиринт из одного коридора. Коллеги подсказали поискать генератор лабиринтов, но задать нужный рисунок в них нельзя, так что я решил рисовать сам.<\/p>\n

          Задача<\/h2>\n

          Нарисовать два лабиринта как можно быстрее и проще.<\/p>\n

          Чтобы не тратить время на постройку обычного лабиринта, можно обвести в Фигме картинку из интернета, но это всё ещё трудная<\/i> задача.<\/p>\n

          Сначала придётся нащёлкать каждую линию по сетке. Потом я обязательно увижу, что получилось некрасиво, и решу всё переделать. Для этого придётся двигать вершины линий, удалять-добавлять и всячески путаться в куче объектов. Для меня всё это долго и муторно.<\/p>\n

          Задачу стоит превратить в сложную<\/i>: вместо непосредственного рисования придумать способ быстро нарисовать<\/i> два лабиринта в одном стиле.<\/p>\n

          Поиски и решение<\/h2>\n

          Если рисование каждой линии нас не устраивает, нужно получить рисунок другим способом: автоматизировать, делегировать или придумать какой-то приём. Автоматизировать нечем, искать исполнителя ещё дольше, чем нарисовать самому. Остаётся что-то придумать.<\/p>\n

          Лабиринты обычно рисуют по прямоугольной сетке. Следовательно, лабиринт — это куча квадратных комнат без одной, двух или трёх стенок.<\/p>\n

          \n\"\"\n<\/div>\n

          Далее мысль совершает скачок: что, если не рисовать нужные стенки, а нарисовать вообще все и убрать лишние? Например, сделать ячейку лабиринта из четырёх отдельных линий и выделять ненужные рамкой.<\/p>\n

          \n\"\"\n
          Выделение рамкой требует меньшей точности, чем рисование<\/div>\n<\/div>\n

          Добавим к методу возможности инструмента. В Фигме стенки ячейки можно объединить в группу, загнать нужное количество ячеек в Auto Layout, получить сетку, а потом всё разгруппировать. Ещё можно закомпонентить лабиринт со всеми стенками и работать с его копиями.<\/p>\n

          В результате получается метод рисования лабиринта, который не требует точных движений и прощает ошибки. Таким образом, мы не только экономим время, но и снижаем когнитивную нагрузку.<\/p>\n", "date_published": "2022-06-24T23:52:24+05:00", "date_modified": "2022-06-25T10:53:10+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/073-mazes@2x.svg", "_date_published_rfc2822": "Fri, 24 Jun 2022 23:52:24 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "84", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/073-mazes@2x.svg", "https:\/\/www.vitalyfilatov.ru\/pictures\/074-maze-grid@2x.png", "https:\/\/www.vitalyfilatov.ru\/pictures\/074-methods-comparison@2x.png" ] } }, { "id": "81", "url": "https:\/\/www.vitalyfilatov.ru\/all\/kak-napisat\/", "title": "Как написать статью, если вы не писатель (методичка)", "content_html": "

          Базовые советы для тех, кто не занимается текстом профессионально. Советы помогут сделать 80 % работы редактора: выбрать полезную тему, выстроить логичную структуру и написать понятный текст.<\/p>\n

          Содержание<\/b><\/p>\n

            \n
          1. Тема и полезное действие<\/a><\/li>\n
          2. Принцип «пользу вперёд»<\/a><\/li>\n
          3. Структура статьи<\/a><\/li>\n
          4. Заголовки<\/a><\/li>\n
          5. Лид-абзац, введение и выводы<\/a><\/li>\n
          6. Разделы<\/a><\/li>\n
          7. Абзацы<\/a><\/li>\n
          8. Предложения<\/a><\/li>\n
          9. Базовая гигиена<\/a><\/li>\n
          10. Полезные ссылки<\/a><\/li>\n<\/ol>\n


            <\/p>\n

            Методичка собрана для авторов блога StringConcat.com<\/a> в 2021 году. Получился очередной пересказ «Пиши, сокращай», но я постарался выделить самое важное и подобрать забавные примеры.<\/p>\n

            \n

            ⚠ Содержит много букв!<\/p>\n<\/blockquote>\n

            <\/a><\/p>\n

            Тема и полезное действие<\/h2>\n

            Прежде чем писать, определитесь с темой и полезным действием: о чём конкретно будет статья и как прочитанное поможет читателю качественно изменить жизнь и поведение.<\/p>\n

            \n

            Например, тема этой методички — написание статей, а полезное действие — помочь читателю писать просто и понятно без специальной подготовки.<\/p>\n<\/blockquote>\n

            Польза важнее оригинальности.<\/b> Тема может быть старой, но всё ещё актуальной. Если у вас есть хорошие примеры и опора на жизненный опыт, статья будет приносить пользу.<\/p>\n

            Выбирайте максимально узкую тему.<\/b> Лучше написать пять коротких статей, чем два поверхностных лонгрида. Чем ỳже тема, тем конкретнее её польза.<\/p>\n

            \n

            Как освоить веб-разработку<\/p>\n<\/blockquote>\n

            \n

            ↓<\/p>\n<\/blockquote>\n

            \n

            Как стать разработчиком на Ангуляр<\/p>\n<\/blockquote>\n

            \n

            ↓<\/p>\n<\/blockquote>\n

            \n

            Как выучить Ангуляр и найти работу за три месяца (никак)<\/p>\n<\/blockquote>\n

            Тему и полезное действие можно записать своими словами и держать на виду. Периодически сверяйтесь с ними и удаляйте всё, что не раскрывает тему и не работает на полезное действие.<\/p>\n

            <\/a><\/p>\n

            Принцип «пользу вперёд»<\/h2>\n

            Старайтесь максимально сократить расстояние до пользы. Начинайте статью с главной мысли, абзац — с ключевых утверждений, а предложение — с сути.<\/p>\n

            Не стоит начинать с общих слов или отвлечённых рассуждений. Так появляются рыхлые статьи копирайтеров:<\/p>\n

            \n

            Плохо<\/b><\/p>\n<\/blockquote>\n

            \n

            Ни для кого не секрет, что в настоящее время индивидуальному предпринимателю не обязательно проходить сложные процедуры регистрации...<\/p>\n<\/blockquote>\n

            \n

            Хорошо<\/b><\/p>\n<\/blockquote>\n

            \n

            С 2021 фрилансеру достаточно быть самозанятым<\/p>\n<\/blockquote>\n

            <\/a><\/p>\n

            Структура статьи<\/h2>\n

            Структура организует материал и помогает последовательно раскрывать тему, а читателю — свободно ориентироваться в тексте. Без структуры повествование будет хаотично скакать по фактам, читатель устанет разбираться и уйдёт.<\/p>\n

            Базовых структур две: параллельная<\/i> и последовательная<\/i>.<\/p>\n

            Параллельная<\/b> состоит из нескольких равноценных блоков с повторяющейся логикой. Например, обзор холодильников, сравнение туров на Байкал или гайд по самодельным ракетам.<\/p>\n

            \n

            Как выбрать двигатель для ракеты<\/b><\/p>\n<\/blockquote>\n

            \n

            Введение и отказ от ответственности<\/p>\n<\/blockquote>\n

            \n

            Двигатель на твёрдом топливе<\/p>\n<\/blockquote>\n

            \n

            — Устройство<\/p>\n<\/blockquote>\n

            \n

            — Предел тяги<\/p>\n<\/blockquote>\n

            \n

            — Получение топлива<\/p>\n<\/blockquote>\n

            \n

            — Как он вас убьёт<\/p>\n<\/blockquote>\n

            \n

            Керосин и кислород<\/p>\n<\/blockquote>\n

            \n

            — <...><\/p>\n<\/blockquote>\n

            \n

            Гидразин и фтор<\/p>\n<\/blockquote>\n

            \n

            — <...><\/p>\n<\/blockquote>\n

            \n

            Выводы<\/p>\n<\/blockquote>\n

            Параллельные статьи обычно читают выборочно, начиная с заголовка и переходя к интересующим разделам. Поэтому в таких статьях важно, чтобы разделы имели похожую структуру. Читатель видит логику и понимает, что где искать.<\/p>\n

            Структуру внутри разделов не обязательно делать одинаковой. Если какой-то части не хватает, подраздел с ней можно пропустить или заменить другим.<\/p>\n

            \n

            Чем фотографировать пришельцев<\/b><\/p>\n<\/blockquote>\n

            \n

            Мыльница<\/p>\n<\/blockquote>\n

            \n

            — Качество<\/p>\n<\/blockquote>\n

            \n

            — Режимы съёмки<\/p>\n<\/blockquote>\n

            \n

            Зеркалка<\/p>\n<\/blockquote>\n

            \n

            — Качество<\/p>\n<\/blockquote>\n

            \n

            — Режимы съёмки<\/p>\n<\/blockquote>\n

            \n

            — Оптика<\/p>\n<\/blockquote>\n

            \n

            Смартфон<\/p>\n<\/blockquote>\n

            \n

            — Качество<\/p>\n<\/blockquote>\n

            Последовательная<\/b> структура организует материал по определённой линейной логике: от общего к частному, от уже известного читателю к новому, от важного к подробностям.<\/p>\n

            Например, учебники, рецепты и объяснения, как доехать до казанского Кремля, пишут в последовательной структуре.<\/p>\n

            \n

            Марсу нужны девопсы<\/b><\/p>\n<\/blockquote>\n

            \n

            [1] Зачем туда лететь<\/p>\n<\/blockquote>\n

            \n

            [2] Чем там заниматься<\/p>\n<\/blockquote>\n

            \n

            [3] Как подготовиться<\/p>\n<\/blockquote>\n

            \n

            [4] Кого не возьмут<\/p>\n<\/blockquote>\n

            \n

            [5] Пункты вербовки<\/p>\n<\/blockquote>\n

            Важно, чтобы каждый раздел ограничивался одной темой. Если информация будет повторяться или лежать в неожиданном месте, читатель запутается.<\/p>\n

            \n

            Позитивный пример<\/b><\/p>\n<\/blockquote>\n

            \n

            Допустим, статья о сетевых протоколах, раздел о стеке TCP\/IP. В разделе будет только о TCP\/IP, а другие протоколы описаны отдельно или упоминаются в связи с основной темой. Например, как TCP\/IP вытеснил IPX\/SPX.<\/p>\n<\/blockquote>\n

            Структура может быть смешанной.<\/b> Например, в комплексной статье с последовательной структурой вполне может жить фрагмент с параллельным изложением. Главное, чтобы это помогало читателю.<\/p>\n

            \n

            Меняем проводку в хрущёвке<\/b><\/p>\n<\/blockquote>\n

            \n

            [1] Как понять, что проводка не справляется<\/p>\n<\/blockquote>\n

            \n

            [2] Готовим квартиру<\/p>\n<\/blockquote>\n

            \n

            [3] Собираем инструменты<\/p>\n<\/blockquote>\n

            \n

            [4] Выбираем провода<\/p>\n<\/blockquote>\n

            \n

            — Алюминиевые<\/p>\n<\/blockquote>\n

            \n

            — Медные многожильные<\/p>\n<\/blockquote>\n

            \n

            — Медные одножильные<\/p>\n<\/blockquote>\n

            \n

            — Китайские загадочные<\/p>\n<\/blockquote>\n

            \n

            [5] Предупреждаем соседей<\/p>\n<\/blockquote>\n

            \n

            <...><\/p>\n<\/blockquote>\n

            Старайтесь не вкладывать разделы в друг друга без крайней необходимости. Такую структуру называют вложенной и читать её труднее. Идеально — один уровень вложенности:<\/p>\n

            \n

            Заголовок статьи → Разделы → Темы в начале абзацев<\/p>\n<\/blockquote>\n

            Если требуется больше, у вас что-то не так со структурой. Возможно, стоит сузить тему, сократить текст или разбить статью на несколько коротких.<\/p>\n

            <\/a><\/p>\n

            Заголовки<\/h2>\n

            Заголовки бывают трёх типов: статьи, раздела и абзаца. Заголовки статьи и раздела делают крупнее и ставят на отдельной строке, а заголовок абзаца выделяют жирным.<\/p>\n

            Заголовок статьи<\/b> — первое, что замечает читатель. По заголовку читатель оценивает потенциальную пользу и решает, стоит ли читать. Поэтому формулировка заголовка должна раскрывать тему и полезное действие.<\/p>\n

            Заголовки бывают назывные<\/i> и транзитивные<\/i>. Назывные описывают содержание материала, транзитивные передают основную мысль.<\/p>\n

            \n

            Как бросить саморазвиваться и начать жить — назывной<\/p>\n<\/blockquote>\n

            \n

            Самодельный фторовый двигатель вас убьёт — транзитивный<\/p>\n<\/blockquote>\n

            По назывному заголовку читатель решает, насколько заявленная тема ему интересна. По транзитивному — оценивает главную мысль и читает, чтобы узнать подробности.<\/p>\n

            Хорошо указывать в заголовке целевую аудиторию, автора, тематику и вид материала: список правил, история из жизни, новость, обзор.<\/p>\n

            \n

            Практикум. С чего начать рефакторинг, если проект уже не дышит<\/p>\n<\/blockquote>\n

            \n

            10 правил безопасности данных от Кевина Митника<\/p>\n<\/blockquote>\n

            \n

            Патент или НПД: какой налоговый режим выбрать фрилансеру<\/p>\n<\/blockquote>\n

            Заголовок — самостоятельная сущность и не должен быть связан с первым предложением.<\/p>\n

            В конце заголовков не ставится точка.<\/p>\n

            Заголовки разделов и подразделов<\/b> делят статью на смысловые части. Желательно формулировать их кратко и однозначно, чтобы читателю не приходилось гадать, о чём пойдёт речь.<\/p>\n

            \n

            Плохо<\/b><\/p>\n<\/blockquote>\n

            \n

            Как спаять два провода<\/b><\/p>\n<\/blockquote>\n

            \n

            Стриппер — это не то, о чём вы подумали<\/p>\n<\/blockquote>\n

            \n

            Ах, этот запах канифоли по утрам<\/p>\n<\/blockquote>\n

            \n

            Осторожней с брызгами!<\/p>\n<\/blockquote>\n

            \n

            Хорошо<\/b><\/p>\n<\/blockquote>\n

            \n

            Как спаять два провода<\/b><\/p>\n<\/blockquote>\n

            \n

            Зачищаем место пайки<\/p>\n<\/blockquote>\n

            \n

            Обезжириваем и прогреваем<\/p>\n<\/blockquote>\n

            \n

            Убираем лишний припой<\/p>\n<\/blockquote>\n

            Заголовки абзацев<\/b> нужны, когда в разделе несколько логических блоков. Выделите в первом предложении ключевые слова или основную мысль, чтобы читатель быстрее сориентировался.<\/p>\n

            В отличие от предыдущих видов, такие заголовки могут входить в предложения и после них ставят точки.<\/p>\n

            \n

            Твердотопливный двигатель<\/b> можно собрать даже в гараже<\/p>\n<\/blockquote>\n

            \n

            Стартовый стол.<\/b> Разместите ракету на ровной поверхности…<\/p>\n<\/blockquote>\n

            <\/a><\/p>\n

            Лид-абзац, введение и выводы<\/h2>\n

            Лид-абзац<\/b> — подводка, краткое описание темы статьи. Им можно дополнять заголовок статьи, выводить в предварительном просмотре для соцсетей и мессенджеров.<\/p>\n

            Лид нужен простой и бойкий. Картинка привлекает внимание, заголовок описывает содержимое, а лид «продаёт» статью, раскрывая пользу.<\/p>\n

            \n

            Ещё один нож в спину алгоритмических задачек<\/b><\/p>\n<\/blockquote>\n

            \n

            Разберём, из-за каких особенностей нашего мозга алгоритмические задачи поджигают задницу и как это прекратить.<\/p>\n<\/blockquote>\n

            Во введении<\/b> мы подготавливаем читателя: объясняем, о чём пойдёт речь, какой уровень подготовки нужен, почему авторам можно верить, вот это всё.<\/p>\n

            Введение не должно дословно повторять лид, начинаться с риторического вопроса, безосновательного обобщения или содержать несущественные детали.<\/p>\n

            \n

            Плохое введение<\/b><\/p>\n<\/blockquote>\n

            \n

            Хотите открыть интернет-магазин? Не работать на дядю и быть сами себе хозяевами? Увлекательная картина, не правда ли? А ведь это не так просто…<\/p>\n<\/blockquote>\n

            \n

            Все в детстве любили сливочное мороженое и пинать мячик…<\/p>\n<\/blockquote>\n

            \n

            Как-то весной в московском офисе «Рогопыта» раздался звонок…<\/p>\n<\/blockquote>\n

            Если тема новая, погружаем читателя в тему и объясняем новые термины. Это поможет найти общий язык и познакомить с проблемами. Если читатель в курсе, переходим сразу к интриге и конфликту.<\/p>\n

            Конфликт — это противоречие между общеизвестным и авторской позицией, с которой у читателя возникнет резонанс. Например, все рвутся в большие компании за деньгами и статусом, но там из людей делают сутулых осликов. Кто-то согласится и прочтёт, чтобы подтвердить свои убеждения, а кто-то — чтобы написать, что вы всё врёте.<\/p>\n

            \n

            Нормальное введение<\/b><\/p>\n<\/blockquote>\n

            \n

            Мозг — сложная штука. Мы привыкли считать, что размышления полностью подчиняются сознательным усилиям, но не всё так просто. Согласно недавним исследованиям…<\/p>\n<\/blockquote>\n

            Конфликт не самоцель и нужен для раскрытия проблемы. Если польза статьи очевидна, то можно и без конфликта.<\/p>\n

            Хитрость.<\/b> Если у вас сложная тема и вывод, с которым кому-то будет сложно согласиться, начните во введении от обратного. Это покажет, что вы не осуждаете читателя, и снимет возможное напряжение.<\/p>\n

            \n

            Как убедить менеджеров, что рефакторинг необходим уже сейчас<\/b><\/p>\n<\/blockquote>\n

            \n

            Управление проектом — сложная и неблагодарная работа. Менеджер зажат между заказчиком и командой, его не любят и считают основной причиной плохого продукта…<\/p>\n<\/blockquote>\n

            Выводы.<\/b> Статью хорошо заканчивать выводами — тем, что читатель точно запомнит из всего прочитанного. Хорошие выводы объясняют, что теперь с этим всем делать на практике.<\/p>\n

            Статью нежелательно заканчивать таблицей или рисунком. Это иногда выглядит так, словно страница не загрузилась целиком. Если добавить в конце нечего, перескажите основные мысли в столбик. Так и напишите:<\/p>\n

            \n

            Запомнить<\/b><\/p>\n<\/blockquote>\n

            \n

            Статью нельзя заканчивать иллюстрацией или таблицей.<\/p>\n<\/blockquote>\n

            \n

            В конце должен идти обобщающий вывод.<\/p>\n<\/blockquote>\n

            \n

            Если выводов нет, можно перечислить основные мысли.<\/p>\n<\/blockquote>\n

            Лид, введение и выводы<\/b> лучше писать в самом конце, когда остальная статья готова. Вы будете знать материал и понимать, с чего начать и чем закончить.<\/p>\n

            <\/a><\/p>\n

            Разделы<\/h2>\n

            Раздел или модуль — самодостаточная группа абзацев на одну тему. Раздел можно прочитать в отрыве от статьи и всё будет понятно.<\/p>\n

            У раздела должен быть заголовок. Хорошо, если заголовки разделов согласованы между собой и складываются в связный рассказ. Это упрощает навигацию и увеличивает интерес читателя.<\/p>\n

            В последовательной структуре разделы идут в порядке раскрытия темы.<\/p>\n

            \n

            Марсу нужны девопсы<\/b><\/p>\n<\/blockquote>\n

            \n

            [1] Зачем туда лететь<\/p>\n<\/blockquote>\n

            \n

            [2] Чем там заниматься<\/p>\n<\/blockquote>\n

            \n

            [3] Как подготовиться<\/p>\n<\/blockquote>\n

            \n

            [4] Кого не возьмут<\/p>\n<\/blockquote>\n

            \n

            [5] Адреса пунктов вербовки<\/p>\n<\/blockquote>\n

            Каждый раздел длиннее пяти абзацев начинается с объяснения своей пользы и заканчивается краткими выводами.<\/p>\n

            <\/a><\/p>\n

            Абзацы<\/h2>\n

            Абзац содержит одну последовательно раскрытую мысль и повторяет структуру статьи и раздела: введение, суть и заключение. В первом предложении выражаем главную мысль, в следующих раскрываем и приводим примеры, в последнем формулируем вывод. Абзац — законченное высказывание.<\/p>\n

            Если тема раскрывается в двух предложениях, дописывать абзац до трёх не нужно. Если мысль укладывается в одно — оставьте одно.<\/p>\n

            \n

            Абзац в начале этого раздела состоит из 3 предложений: основной мысли, пояснения и вывода.<\/p>\n<\/blockquote>\n

            \n

            Абзацу про тему для полноты мысли хватает двух предложений.<\/p>\n<\/blockquote>\n

            Суть лучше выносить в начало, чтобы читатель мог сразу понять, о чём речь. Многие читают по диагонали, сканируя первые предложения в абзацах. Если начинать с сути, читатель с большей вероятностью найдёт что-то полезное и прочтёт остальное.<\/p>\n

            Максимальная длина абзаца — девять предложений, оптимально 3—5. Если на вёрстке абзац занимает больше 8 строк, попробуйте разделить его на два.<\/p>\n

            Чередуйте длинные и короткие абзацы, чтобы текст не выглядел монотонно.<\/p>\n

            <\/a><\/p>\n

            Предложения<\/h2>\n

            Предложение — высказывание с законченным смыслом. Старайтесь, чтобы в предложении была одна новая для читателя сущность или комбинация уже известных. Если получается больше, разделяйте предложение на несколько и раскрывайте их по очереди.<\/p>\n

            Чтобы предложение было сильным, ему нужны действующее лицо и действие. Ищите, кто или что может совершать действие.<\/p>\n

            \n

            Тролль гнёт ель<\/p>\n<\/blockquote>\n

            \n

            Разработчики выкатывают релиз<\/p>\n<\/blockquote>\n

            \n

            Крупные корпорации уходят от ответственности<\/p>\n<\/blockquote>\n

            Активное действие добавляет жизни:<\/p>\n

            \n

            Заявление принимается заполненным от руки → Заполните бланк от руки<\/p>\n<\/blockquote>\n

            \n

            Регистрация требует подтверждения → Подтвердите регистрацию<\/p>\n<\/blockquote>\n

            \n

            Дети будут находиться под присмотром сотрудника центра → Инструктор присмотрит за детьми<\/p>\n<\/blockquote>\n

            Страдательный залог пригодится, когда нужно обратить внимание на состояние объекта и нам не важно, кто именно совершил действие.<\/p>\n

            \n

            Дом сдан вовремя — важно, что он готов, а не то, что его кто-то строил<\/p>\n<\/blockquote>\n

            \n

            К аудиту всё готово — важно, что мы пройдём проверку<\/p>\n<\/blockquote>\n

            Не используйте парцелляцию<\/a> — дробление полноценного предложения для усиления интонации. Не надо. Не дробите.<\/p>\n

            Не начинайте предложение с цифр. Измените формулировку или напишите числа словами.<\/p>\n

            \n

            30 % подписчиков — боты → Треть подписчиков — боты<\/p>\n<\/blockquote>\n

            \n

            5 29-дюймовых мониторов → Пять 29-дюймовых мониторов<\/p>\n<\/blockquote>\n

            Упрощайте-сокращайте.<\/p>\n

            \n

            Значительно выросла сумма задолженности → Долг вырос<\/p>\n<\/blockquote>\n

            \n

            Осуществление работ по разработке → Разрабатывать<\/p>\n<\/blockquote>\n

            \n

            В целях, во избежание, посредством → Чтобы<\/p>\n<\/blockquote>\n

            \n

            По причине, в связи → Из-за<\/p>\n<\/blockquote>\n

            \n

            В течение 2-х летнего срока → За два года<\/p>\n<\/blockquote>\n

            Лучший знак препинания в предложении — точка.<\/p>\n

            После смайлика точку ставить не нужно;-)<\/p>\n

            <\/a><\/p>\n

            Базовая гигиена<\/h2>\n

            Жирный и наклонный шрифт.<\/b> Не выделяйте жирным слова в середине предложения. Для этого лучше использовать наклонный шрифт<\/i> или выделение маркером<\/mark>. Жирным можно выделять главные мысли в начале предложения.<\/p>\n

            Кавычки.<\/b> Правильные кавычки для русского языка — «ёлочки». Набираем Alt+0171 и Alt+0187 на цифровой клавиатуре в Виндоус.<\/p>\n

            Внутри первых кавычек используем „“.<\/p>\n

            \n

            «Общественное объединение „Тролль гнёт ель“»<\/p>\n<\/blockquote>\n

            Тире<\/b> в русской типографике два: длинное (Em-dash) и короткое (En-dash).<\/p>\n

            Длинное тире разделяет слова в предложении и даты с месяцами, короткое — числовые диапазоны. Дефис разделяет составные слова: Петров-Водкин, стоп-кран.<\/p>\n

            Правильное длинное тире — Alt+0151. Короткое — Alt+0150. Дефис и минус не тире.<\/p>\n

            \n

            Длинное тире<\/b><\/p>\n<\/blockquote>\n

            \n

            Пренебрежение вёрсткой — моветон<\/p>\n<\/blockquote>\n

            \n

            Дефис и короткое тире<\/b><\/p>\n<\/blockquote>\n

            \n

            Какие-то клиенты, 2—3 человека<\/p>\n<\/blockquote>\n

            Диапазоны дат<\/b> пишем с коротким тире, если нет названий месяцев.<\/p>\n

            \n

            12—20 августа<\/p>\n<\/blockquote>\n

            \n

            12 января — 20 апреля<\/p>\n<\/blockquote>\n

            Числа<\/b> от десяти тысяч в сплошном тексте разделяем по разрядам, по три знака с конца:<\/p>\n

            \n

            1000<\/p>\n<\/blockquote>\n

            \n

            10 000<\/p>\n<\/blockquote>\n

            \n

            52 125 333<\/p>\n<\/blockquote>\n

            Большие числа можно округлять, если масштаб важнее точности:<\/p>\n

            \n

            1134 человека на место → тысяча человек<\/p>\n<\/blockquote>\n

            \n

            10 542 заявки в час → 10 тысяч заявок<\/p>\n<\/blockquote>\n

            \n

            52 125 333 плохих приложений → 52 миллиона<\/p>\n<\/blockquote>\n

            Диапазоны разбиваем коротким тире:<\/p>\n

            \n

            1000—1500 Мгц<\/p>\n<\/blockquote>\n

            \n

            2000—2020 годы<\/p>\n<\/blockquote>\n

            Дробную часть отделяем запятой.<\/p>\n

            \n

            36,6 ℃<\/p>\n<\/blockquote>\n

            <\/a><\/p>\n

            Полезные ссылки<\/h2>\n

            Инструменты<\/h3>\n

            Главред<\/a> — ищет в тексте лишние слова. Убирать всё не надо, но обратить внимание стоит. Достаточно семи баллов.<\/p>\n

            Орфограммка<\/a> — проверяет орфографию и пунктуацию. Обязательно проверьте текст перед публикацией.<\/p>\n

            Драйзер<\/a> — помогает перенести текст из гугл-доков в Вордпресс и Эгею.<\/p>\n

            Типограф Лебедева<\/a> — готовит текст для публикации: расставляет неразрывные пробелы, правильные тире и кавычки.<\/p>\n

            Карта слов и выражений русского языка<\/a><\/p>\n

            Ещё о редактуре<\/h3>\n

            Как побороть писательский ступор<\/a> — разобраться в задаче, собрать материал и поспать.<\/p>\n

            Как ставить ссылки<\/a> — скриншот редполитики, но вполне читаемый.<\/p>\n

            Не вставляйте картинки из гугл-доков<\/a> — если исходный документ удалить, картинки по ссылкам из него пропадут навсегда.<\/p>\n

            Как использовать эмодзи в тексте<\/a> — знайте меру и следите за смыслом.<\/p>\n", "date_published": "2022-04-03T21:10:00+05:00", "date_modified": "2025-07-08T23:12:35+05:00", "_date_published_rfc2822": "Sun, 03 Apr 2022 21:10:00 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "81", "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "80", "url": "https:\/\/www.vitalyfilatov.ru\/all\/reply\/", "title": "Ответ клиенту такси", "content_html": "

            Разбираем ответ службы поддержки, отжимаем лишнее и добавляем немного пользы. В конце смотрим текст в макете.<\/p>\n

            Текст попался в чате для подписчиков UX-рассылки Иры Моториной<\/a>. Говорят, это фрагмент тестового задания Яндекса, поэтому задача без контекста.<\/p>\n

            Исходный текст, орфография сохранена:<\/p>\n

            \n

            Обращение<\/b><\/p>\n<\/blockquote>\n

            \n

            День добрый! Заказ оплачивал наличными. Подскажите как можно получить чек по поездке?<\/p>\n<\/blockquote>\n

            \n

            Ответ<\/b><\/p>\n<\/blockquote>\n

            \n

            Здравствуйте!<\/p>\n<\/blockquote>\n

            \n

            Как я вижу, вы оплатили заказ наличными, а наш сервис отправляет чеки только при оплате картой. Это значит: чек вы получить не сможете. Зато при оплате наличными вы можете получить отчет о поездке, который содержит всю необходимую информацию.<\/p>\n<\/blockquote>\n

            \n

            Чтобы получить отчет, привяжите адрес почты в боковом меню приложения. Для этого нажмите на аватарку, выберите «Добавить почту» и подтвердите адрес в ответном письме. Потом вернитесь ко мне — я вышлю отчет.<\/p>\n<\/blockquote>\n

            Разберём ситуацию, проблемы ответа и попробуем сделать лучше.<\/p>\n

            Ситуация<\/h2>\n

            Предположим, после поездки клиенту не пришёл чек, поэтому он пишет в чат приложения и указывает способ оплаты. Скорее всего, клиент ездил по служебным делам и чек нужен бухгалтерии. Дальше всё опирается на это предположение, будьте снисходительны.<\/p>\n

            Проблемы<\/h2>\n

            Объём.<\/b> Макета у нас нет, мы не знаем размеров текста и пользовательских настроек. Скорее всего, ответ в чате займёт больше одного экрана и пользователю придётся скроллить. Скролл — самый простой жест, но будет здорово, если и он не потребуется.<\/p>\n

            Структура.<\/b> Текст содержит подробности, не имеющие прямого отношения к вопросу, а суть располагается в середине абзаца. Из-за этого текст придётся читать целиком. Если сделать текст лаконичнее, пользователь быстрее получит ответ и потратит меньше времени на тревогу.<\/p>\n

            \n

            Экономия времени, внимания и усилий — проявление заботы<\/p>\n<\/blockquote>\n

            Задача<\/h2>\n

            Сделать ответ короче, вынеси пользу в начало, сохранить вежливый тон и проявить заботу. Ответ уже вежлив и закрывает обращение, но мы попробуем копнуть глубже и сделать его полезнее.<\/p>\n

            Решение<\/h2>\n

            Разберём первый абзац по единицам смысла, чтобы найти избыточность. Для этого разбиваем текст по предложениям и удаляем всё не по делу.<\/p>\n

            Разбиваем:<\/p>\n

            \n

            Как я вижу, вы оплатили заказ наличными, а наш сервис отправляет чеки только при оплате картой.<\/p>\n<\/blockquote>\n

            \n

            Это значит: чек вы получить не сможете.<\/p>\n<\/blockquote>\n

            \n

            Зато при оплате наличными вы можете получить отчет о поездке, который содержит всю необходимую информацию.<\/p>\n<\/blockquote>\n

            Первое предложение звучит естественно, но причина и следствие получились такими громоздкими, что потребовали пояснения. Можно не говорить, что оператор видит способ оплаты, клиент сам об этом сообщил.<\/p>\n

            Отжимаем:<\/p>\n

            \n

            вы платили наличными, а чеки доступны при оплате картой<\/p>\n<\/blockquote>\n

            \n

            чек вы не получите — повтор, но мы его пока оставим<\/p>\n<\/blockquote>\n

            \n

            вместо чека можно получить отчёт о поездке с необходимой информацией<\/p>\n<\/blockquote>\n

            Вынесем суть в начало и перепишем:<\/p>\n

            \n

            Мы не выдаём чеки при оплате наличными, но можем отправить отчёт о поездке с необходимой информацией<\/p>\n<\/blockquote>\n

            Модальность «можем отправить» оставим, отчёт отправляется по запросу.<\/p>\n

            Для пользы объясним ценность отчёта. Очевидно, что клиенту нужен не сам чек, а отчитаться перед бухгалтерией и вернуть деньги. Чек он не получил, возврат денег под вопросом.<\/p>\n

            \n

            Бухгалтерии важно правильно оправдать расходы, иначе у налоговой могут возникнуть вопросы. Оплата такси подтверждается кассовым чеком или квитанцией в форме бланка строгой отчётности. В квитанции обязателен набор реквизитов<\/a>.<\/p>\n<\/blockquote>\n

            Для простоты предположим, что отчёт равноценен квитанции и бухгалтерия его примет вместо чека. Добавим, кому отчёт предназначается, чтобы пользователь не сомневался:<\/p>\n

            \n

            <…> с обязательными реквизитами для бухгалтерии<\/p>\n<\/blockquote>\n

            Обязательные — избыточность, реквизиты и так значат необходимые сведения. Но все привыкли, поэтому оставим для узнаваемости. Если пользователь слышал про квитанции от бухгалтеров, наше определение сработает лучше корректного, но незнакомого термина.<\/p>\n

            Немного сократим второй абзац:<\/p>\n

            \n

            Чтобы получить отчёт, привяжите адрес почты: нажмите на аватарку, выберите «Добавить почту» и подтвердите адрес в ответном письме. Потом напишите сюда, я вышлю отчёт на указанный адрес.<\/p>\n<\/blockquote>\n

            В идеале пользователь должен получать отчёт без обращения в поддержку, а приложение — знать, указана ли почта. Но мы примем, что менять логику приложения нельзя.<\/p>\n

            Для наглядности соберём всё в условном макете.<\/p>\n

            \n\"\"\n<\/div>\n", "date_published": "2022-03-08T01:36:16+05:00", "date_modified": "2022-03-08T13:19:37+05:00", "image": "https:\/\/www.vitalyfilatov.ru\/pictures\/070-replies-compare.png", "_date_published_rfc2822": "Tue, 08 Mar 2022 01:36:16 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "80", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/www.vitalyfilatov.ru\/pictures\/070-replies-compare.png" ] } }, { "id": "79", "url": "https:\/\/www.vitalyfilatov.ru\/all\/call-center-sms\/", "title": "СМС с рекламой сервиса", "content_html": "

            Немного редакторского процесса на примере СМС колл-центра. Вникаем в задачу, упрощаем сценарий и пишем текст под особенности формата.<\/p>\n

            TLDR. 860 слов о том, как написать 200 символов.<\/p>\n

            \n
            \n\"\"\n\"\"\n\"\"\n<\/div>\n
            Скриншот результата в мокапе iPhone SE. Для фотографии мой телефон слишком потёрт :3<\/div>\n<\/div>\n

            Ситуация<\/h2>\n

            Колл-центр сильно загружен: банк переводит клиентов на новую систему из трёх разных, многим нужна консультация по интерфейсу. Бывает, клиенты по полчаса ждут ответа оператора.<\/p>\n

            Чтобы клиенты чаще искали ответы сами, колл-центр решил отправлять им СМС с рекламой чат-бота и Помощи ВТБ Бизнес. Вот оригинал:<\/p>\n

            \n

            Переходите по ссылке https:\/\/db.vtb.ru\/faq<\/a> в раздел «Помощь». Здесь вы найдете много полезной информации по правилам работы Интернет банка ВТБ Бизнес. Еще у нас есть чат-бот, который подскажет ответы на самые актуальные вопросы.<\/p>\n<\/blockquote>\n

            \n

            Чат-бот живет в правом нижнем углу экрана https:\/\/db.vtb.ru<\/a> под названием «Чат». Особенно хорошо чат-бот разбирается в вопросах входа в систему. Напишите ему Ваш вопрос, он расскажет план действий.<\/p>\n<\/blockquote>\n

            Оператор будет отправлять это сообщение после консультаций, если у клиентов нет жестких технических проблем. Но по нескольким вопросам клиенты будут получать по два СМС: сначала ссылку на конкретную статью, а потом рекламу.<\/p>\n

            Очевидно, что текст можно сделать короче, а сценарий точнее.<\/p>\n

            Задача<\/h2>\n

            Колл-центр редактуру не заказывал, так что поставим задачу сами.<\/p>\n

              \n
            1. Упорядочим сценарий отправки. Нужно учитывать тему и настроение клиента. И два СМС подряд — это перебор.<\/li>\n
            2. Напишем лаконичнее, с пользой в мире клиента и конкретикой. Сейчас непонятно, чем Помощь и чат-бот удобнее общения с оператором.<\/li>\n<\/ol>\n

              Начнём со сценария, чтобы выстроить предсказуемый контекст. Чем больше мы узнаем о ситуации клиента, тем точнее напишем. Обратное тоже верно: без знания ситуации вместо работы со смыслом получится перестановка слов.<\/p>\n

              Сценарий<\/h2>\n

              Проблемы первоначального сценария:<\/p>\n