6 заметок с тегом

организация работы

Как мы перевели оферту с юридического на человеческий. Кейс Ozon Marketplace

Даже компании с самым дружелюбным tone of voice часто упускают из виду, что cкучную ошибку 404 или рассылку с «Вы» и «Доброго времени суток» пользователи могут и не заметить, а вот самый ужас наступает, когда приходится открыть договор.

Но в Ozon редакция — лапушки-задроты. Мы решили протянуть нашим продавцам руку помощи даже там, где обычно это невозможно.

Место действия: Ozon Marketplace
Проект: договор, который заключает каждый продавец перед работой на площадке.
Период работы: с марта по июль 2021 включительно. Дальше просто правили и дополняли в соответствии со всеми изменениями оферты.
Команда: главный юрист маркетплейса Майя Лаврова, главред Оля Литченкова, я как редактор. Дизайнер, продакт-менеджеры и разработчики маркетплейса.

Что было раньше

Надо сказать, что в Ozon сразу учитывали, как важно продавцам понимать каждый пункт оферты. Поэтому обо всех изменениях мы обязательно присылаем письмо с пояснениями — из него можно узнать, что изменилось, почему и как отразится на работе.

А вот сам договор был таким же, как у всех — стандартная страница с сухим юридическим текстом. Кажется, что даже на уровне визуала он всеми силами пытается помешать в нем разобраться. Структура документа тоже была иной: он состоял из огромной основной части и трех приложений — это делало его громоздким и сложным.

Так выглядел договор в марте 2021 года. Естественно, когда нашлись ресурсы на его переделку, я не могла отказаться от удовольствия поучаствовать в проекте

Как работали над офертой

Решили действовать сразу в трех направлениях:

  • юристы — упростить структуру и формулировки самого документа;
  • редакция — сделать подсказки с переводом каждого пункта на понятный язык;
  • технические специалисты — перенести документ на новый сайт с современным дизайном.

Шаг 1. Собрать референсы и подготовить дизайн

Первым делом мы стали смотреть, как показывают свои договоры другие компании. Нашлись два подходящих референса, на которые мы ориентировались: это лицензионное соглашение игры Cyberpunk и договор Бюро Горбунова.

Так выглядели сайты, которые мы отдали дизайнеру в качестве референсов

Изначально мы тоже хотели сделать параллельный текст: слева — юридический, справа — обычный. Но так не получилось из-за особенностей личного кабинета. Дело в том, что база знаний там открывается в окне, которое занимает всего лишь половину экрана: если его поделить еще на две части, читать будет слишком мелко и неудобно даже с десктопа. А еще будут оставаться некрасивые дыры, потому что оригинальный текст и подсказки разные по размеру.

В итоге дизайнеры расположили подсказки под юридическим текстом — так они точно будут хорошо смотреться на любом устройстве. Каждую подсказку можно закрыть, нажав крестик. Еще мы планировали сделать кнопку, чтобы закрыть сразу все подсказки, но это пока не реализовали.

Макет договора с подсказками. От релизной версии он отличается оглавлением и возможностью сворачивать разделы и скрывать подсказки
Мы честно проверили, как договор будет отображаться в сайдпанели — в итоге поняли, что разумнее поменять дизайн, чем переделывать логику кабинета. Здесь текст подсказки рыбный

Шаг 2. Подготовить подсказки к договору

Когда новый текст договора был готов, у меня началась самая активная фаза. Как я работала:

  1. Проводила созвоны с главным юристом Майей, где мы прошлись почти по всем пунктам. Я старалась проговаривать каждый тезис, даже если вопросов по смыслу не было — нередко оказывалось, что сама я могла бы упустить нюансы. Чтобы досконально разобрать оферту, понадобилось 4-5 созвонов.
  2. Писала текст подсказок в гуглдокументе, стараясь передать весь смысл пункта, а кое-где даже давать дополнительные пояснения — в этом наше отличие от референсов, в которых информация передана только крупными мазками. Мы же сделали полноценный перевод, чтобы продавцы могли его читать вместо юридического текста.
  3. Согласовывала текст сначала с юристом, потом с главным редактором и руководителем отдела.
  4. Отдала готовый текст техническим специалистам. Они создали недостающие элементы по макету и подготовили страницу для дальнейшей работы в GitLab. После этого я проверяла верстку, дополняла текст и вносила все нужные изменения перед публикацией.
Работу вели в одном гуглдокументе, общались там же в комментариях. Все изменения я отмечала цветом, а кусочки для согласования — заливкой

Шаг 3. Опубликовать обновленную оферту

Пока технические специалисты занимались версткой, мы еще доводили подсказки до идеала. Поэтому получив верстку, я приступила к проверке:

  • обновила текст подсказок там, где он перестал быть актуальным;
  • проверила правильность верстки — например, где-то не оказалось списка, а где-то забыли зашить ссылки или они были битыми;
  • настроила навигацию на главной странице раздела — где можно открыть договор, любое приложение или регламент;
  • добавила предупреждение, что подсказки не имеют юридической силы;
  • поставила задачи на редиректы, чтобы по старому URL пользователи не видели ошибку 404 вместо договора и регламентов.

Все это делалось в GitLab. Это было мое первое столь тесное знакомство с сервисом — скажу честно, сначала было страшно. Но потом освоилась, узнала, что такое «коммиты» и «пайплайны» — настолько, что впоследствии GitLab стал постоянным рабочим инструментом наравне с гуглдоками. Надо добавить это в резюме :)

Как договор выглядит сейчас

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

Фрагмент договора на момент публикации этого кейса. Насколько я знаю, к концу 2022 года структура изменится, потому что страница объединит версии для продавцов из разных стран
Примеры подсказок к договору. Вместе с переводом писали дополнительную информацию. Например, в пункте про семплинг (п. 2.20) я решила объяснить, что вложения не повлияют на стоимость доставки — мы знали, что это одно из главных возражений
Анонс подсказок. Текст написала Оля Литченкова

Шаг 4. Сформировать правила подготовки архива

Иногда продавцам нужно вернуться к версии договора за определенную дату — например, если идет судебное разбирательство. Для этого каждую редакцию мы сохраняем и публикуем в виде PDF. Такой файл нужен для юристов и бухгалтеров, поэтому подсказки там лишние.

Держать договор в отдельном документе без подсказок неудобно, потому что можно запутаться в версиях + все новые правки придется вносить и туда, и на сайт. Значит, нужно снимать PDF прямо с сайта. Вот как я придумала действовать:

  • открывала инструменты разработчика в браузере и скрывала все подсказки. Нужно на вкладке Элементы найти div с нужным классом, а затем в стилях для него прописать display: none.
  • генерировала PDF с помощью расширения для Хрома Print Friendly & PDF. Просто скриншот страницы нам не подходил, потому что он не подготовлен для печати, сохраняет элементы интерфейса и не дает ссылку на сайт. А это расширение делает просто идеальные доки для нашей цели.
  • добавляла файл в хранилище и прописывала на странице архива суть каждого изменения и дату вступления в силу.

В конце сентября 2022 я полностью передала проект коллегам. Не все из них привыкли к инструментам разработчика, поэтому подготовила инструкцию с видеоуроком. Показать их не смогу — это внутренние документы.

Что получилось в итоге

Это тот контентный проект, результаты которого очень легко посчитать в цифрах. Смотрите:

  • снизилось количество запросов в поддержку по теме договора на 26% уже в первый месяц внедрения подсказок. Дальше при постоянном росте количества продавцов на площадке контактность продолжала снижаться: например, в январе 2022 пользователей было уже в 2 раза больше, чем в июне 2021, при этом запросов по теме договора на 4% меньше.
  • Customer Satisfaction Index (CSI) страницы с договором лучший из всей Базы знаний. Это показатель, с помощью которого измеряют удовлетворенность клиентов, в нашем случае — оценки статей. У оферты он держится на уровне 80%, а его влияние на общий результат портала — 32%.

Вместе с этим обновленная оферта помогает снять барьер у новых продавцов. На старте у них куча страхов, а такой подход даже к формальному казалось бы договору показывает: Ozon — это партнёр.

Вот такие отзывы на договор мы получаем от продавцов. Посмотреть кейс бренда и оригинал отзыва в Инстаграме


🔔 Подписывайтесь на телеграм-канал «Аня учится пилить проекты»

Собираю там примеры интерфейсов и делюсь размышлениями про работу UX-редактора → ссылка на канал

 1478   2022   кейс   организация работы   портфолио   редактура

Как мы искали редактора в команду

Так получилось, что с января 2022 единая редакция в Ozon Marketplace разделилась на отдельные направления, и я возглавила подгруппу по UX-редактуре и Базе знаний — так мы называем наш портал с инструкциями для продавцов. Задач было слишком много, а людей слишком мало, поэтому мы начали активно искать UX-редактора.

В редакции вообще и в Ozon в частности устоявшаяся система найма, наш главный редактор и вовсе с первых слов чувствует людей, но я оказалась впервые по ту сторону. Поэтому решила записать свои впечатления и по ходу дела пояснить, на что обращала внимание.

Навеяно комментариями под постами с вакансиями в нашу редакцию. На самом деле мы никого не едим, просто растем очень быстро, а людей в команду отбираем тщательно. Так вакансия UX-редактора была открыта еще в 2021, а вышел человек только 15 апреля 2022

Этап составления вакансии наш главред прошла без меня — поиск того самого редактора начали задолго до того, как я стала курировать UX-редактуру. Зато я сразу же окунулась в активную фазу отбора, который состоял из трёх этапов.

Этап 1. Отсеиваем неподходящих

Сначала смотрели резюме и портфолио. Хотя я все чаще слышу, что резюме — это что-то вроде пережитка прошлого, но для меня важными оказались оба документа.

В резюме я хотела увидеть:

  • структуру и акценты, ведь если редактор не может в нем грамотно рассказать о себе, то объяснить что-то в интерфейсе или инструкции не сможет и подавно.
  • релевантный опыт. В воронку попадали как совсем новички с единственным кейсом в виде диплома в «Нетологии», так и руководители отделов, которые прямо указывают, что давно не пишут сами — и те, и другие нам бы не подошли.
  • близкие компании — мне кажется, что адаптироваться будет проще, если в прошлом компании были похожи на Ozon по сфере, размеру и общим ценностям. Плюсом был опыт сложных продуктов и b2b.

А вот образование не имело значения — коммерческой редактуре как таковой в вузах не учат, поэтому все разными путями приходят в профессию. Например, в команду в итоге попала девушка, которая в прошлом была дизайнером.

С примерами работ было гораздо сложнее. Для меня важно, чтобы портфолио:

  • в принципе было у редактора. Я честно не понимаю тех, которые выходит на рынок труда без него. Даже если все под NDA, всегда можно специально сделать пару придуманных экранов онбординга или оформить как пример тестовое задание. Кандидаты без портфолио в моих глазах получали большой минус.
  • содержало тексты именно по интерфейсам. Почему-то многие присылали в качестве примеров рассылки и даже статьи в блог.
  • показывало разные форматы. Например, пуш, онбординг, тексты ошибок и подписи в рамках какого-то большого сценария — нужно посмотреть навыки со всех сторон.

Этап 2. Тестируем кандидатов

У нас UX-редакторы не только занимаются интерфейсами, но и пишут инструкции. Поэтому было два задания — это задачи, с которыми предстоит столкнуться в повседневной работе.

Тестовое задание 1: написать онбординг для новой фичи

Это задание придумала наш главред: смысл в том, чтобы рассказать покупателям о новой услуге в двух экранах. Оно хорошо тем, что просто написать текст недостаточно — нужно порассуждать, правда ли услуга так хороша и стоит ли подавать ее так, как это указано в задании.

Скриншот гуглдока с заданием. Ниже давали ссылку на фигму с призывом скопировать макеты к себе и сделать задание прямо в них

У кандидатов не было какого-то одного правильного способа сделать это задание. Например, можно было подготовить идеальный текст, обойдя ограничения и подсветив реальные преимущества фичи. Или сделать анализ рынка и доказать нам, что мы дураки и так делать не стоит :)

Так что мы больше смотрели на подход к работе и логику в целом. В результате хотелось увидеть:

  • минимальную аналитику — например, рассуждения о том, что доставка практически из любого города есть и сейчас, в недалеком будущем это и подавно станет нормой, а не преимуществом.
  • аргументацию — как правильно «продать» покупателям новую услугу, ведь в задании мы специально подсветили не лучшие плюшки.
  • работу в фигме — все-таки это уже почти стандарт для работы над интерфейсами.

Конечно, мы не отказывали работам в гуглдоках, но нужно хотя бы учитывать формат. Одна из кандидаток написала текст такого объема, что его и в целый пост не поместить, что уж говорить про два экрана — а если бы писала сразу в макете, то сама бы увидела попытку «впихнуть невпихуемое».

Тестовое задание 2: написать инструкцию в Базу знаний

Чтобы посмотреть, как кандидаты умеют объяснять и подавать информацию, мы дали им реальный макет и попросили написать по нему инструкцию.

Это задание чисто на хард скилы. На что я обращала внимание:

  • текст — думаю, тут нет смысла долго рассказывать. Обращала внимание на структуру, разбивку по блокам, корявые фразы и прочее.
  • полнота информации. Не возьму соискателя, который проигнорировал часть настроек, которые отражены в макете — а таких было немало.
  • наглядность. Наш кабинет может показаться непростым, поэтому одной простыни текста недостаточно. Я смотрела, добавляет ли кандидат картинки, что именно иллюстрирует и как оформляет скриншоты.
  • вопросы и рассуждения. Хотелось найти человека, который действительно старается вникнуть в задачу. Тогда у него неизбежно возникнет куча вопросов о том, как у нас все работает — здорово, когда прямо в тестовом было написано что-то вроде «В задании недостаточно информации, я бы еще уточнил у заказчика вот это...». Или если кандидат говорил, из каких допущений исходил при выполнении задания.
  • выход за рамки задания. Мы просили написать статью для существующего портала. В моих глазах 100 очков вперед получали те, кто просматривали опубликованные статьи — делали перелинковки, учитывали tone of voice или стиль иллюстраций.
  • оформление. Если человек сделал все красиво — выделил заголовки, вставил картинки, использовал правильные тире и кавычки, не забыл вычитать текст перед сдачей тестового, — значит, в работе он тоже окажется аккуратным. Скорее всего, с небрежным кандидатом я не сработаюсь.

Этап 3. Собеседуем лучших

В итоге у меня было четыре собеседования. Я никогда раньше их не проводила, поэтому на трех со мной была главный редактор, на нескольких — еще HR. Так как мы удаленщики, созванивались в Microsoft Teams. Обязательно включали видео, потому что так проще наладить контакт — видишь мимику и реакции человека.

К каждому собеседованию я готовилась и зачастую набрасывала список вопросов, которые хочу уточнить. Чтобы понять, подходит ли человек, спрашивала:

  • какие форматы и типы задач нравятся, а какие нет;
  • как обычно взаимодействует с заказчиками и смежными командами;
  • как строит работу над задачей;
  • куда хочет развиваться.

Обычно мы начинали разговор с того, что просили кандидата кратко рассказать о себе — что угодно. Дальше задавали какие-то вопросы по ходу и завязывался непринужденный диалог. Порой я не хотела перебивать кандидата, поэтому все время держала перед собой листок, где записывала новые детали, которые хочу уточнить. Советую всем такой лайфхак — начала так делать, еще когда сама устраивалась на работу.

Мне было важно понять, совпадает ли опыт и ожидания кандидата с тем, что мы ему предлагаем. Особенно обращала внимание на:

  • рассказ о прошлом опыте. Следила за тем, насколько внятно человек описывает свои функции и результаты на других местах работы.
  • самооценку кандидата. Мне было важно, чтобы человек знал, чего он хочет — куда расти, какие задачи брать и сколько денег получать. Одному кандидату мы отказали как раз потому, что не увидели в нем стержня и сформированного мнения даже на такие вопросы — кажется, что и рабочие решения кандидат отстоять не сможет.
  • вопросы к нам. Считаю, что их не может не быть, какой бы подробной не была вакансия. Для меня четкие вопросы — это знак, что человеку важно понять его роль и порядок работы, что он не идет абы куда. Ну а еще это показывает, что в работе редактор будет так же дотошно приставать с уточнениями и фактурой.

Обычно после собеседования мы оставались и делились своими впечатлениями, но с нашим будущим редактором получилось иначе. Уже на середине встречи я чувствовала, что хочу работать с этим человеком — и сразу же обсудила в личке с главредом, что «да, это оно».

Что после найма: помогаем освоиться

Команда у нас новая, какой-то документации еще не было. Чтобы новому редактору было проще вливаться, я начала описывать процессы — как мы работаем над задачами, какие нужны доступы и куда обращаться.

В день оформления я приехала в офис, чтобы лично познакомиться и рассказать, как все устроено. Теперь мы регулярно созваниваемся и обсуждаем как задачи, так и впечатления. Ну а насколько сработаемся, покажет испытательный срок в три месяца.


🔔 Подписывайтесь на телеграм-канал «Аня учится пилить проекты»

Собираю там примеры интерфейсов и делюсь размышлениями про работу UX-редактора → ссылка на канал

 538   2022   организация работы   рефлексия   управление проектом

Зачем редактору владеть графическими программами, если есть дизайнер

Я работаю редактором в компании. Для нас очень важен визуал, поэтому мы уделяем большое внимание оформлению, какой бы мелкой и незначительной не казалась задача. Для этого есть отдельная команда дизайнеров. Если мне нужна иллюстрация для статьи, картинка в соцсети или PDF-файл с чек-листом, я всегда могу поставить задачу.

Но я все равно считаю, что редактор должен сам уметь работать в редакторах. На это есть три причины.

Быстро сделать простые задачи

Тут все просто и очевидно: часто гораздо быстрее сделать картинку самому, чем ставить задачу и объяснять, что именно тебе нужно. Да и дизайнер вряд ли побежит сразу делать твою задачу. Поэтому все скриншоты для статей я делаю сама. Для этого я сделала себе шаблоны в Фигме с правильной «шапкой» браузера и рамкой смартфона. Благодаря им на подготовку скриншота в блог уходит около двух минут. А дизайнерам ставлю задачу, если мне нужны какие-то особые иллюстрации, например, схемы или таблички.

Простые иллюстрации, которые быстро и просто сделать в Фигме. Если нужно, здесь же я добавляю стрелочки или делаю затемнение

Для многих статей я люблю делать дополнительные «плюшки»: таблички с расчетами и формулами, чек-листы и все такое. Это помогает читателям разобраться в теме и сразу же применить информацию в своей работе. Чаще всего такие штуки можно сделать самостоятельно все в той же моей любимой Фигме.

Например, я готовила с блогером Натальей Бродач статью про продвижение в ТикТоке. Когда почти все было готово и до публикации оставалось два-три дня, мы придумали сделать чек-лист. Я сверстала его за пару часов, а от дизайнера получила бы не раньше, чем через неделю.

Готовый чек-лист, который я сверстала в Фигме. Можно посмотреть в PDF-файле

Легко набросать прототип и объяснить задачу дизайнеру

Как правило, основной рабочий инструмент редактора — это гуглдоки. Там я обычно пишу все свои материалы: тексты статей, постов и прочее. Пометки для дизайнеров приходится делать в комментариях или прямо в тексте. Расставлять заголовки «первый экран, второй экран...» или объяснять на пальцах «тут нужно сделать галерею со стрелочками, как на этом сайте... картинки подобрать вот такие вот отсюда...» жутко неудобно. Даже я спустя время не разберусь в своих пометках, хотя сама их писала.

Вот так выглядит обычное ТЗ на лендинг в гуглдоках

Куда удобнее и проще схематично показать, что именно ты хочешь. Для этого я делаю в Фигме грубый набросок, что-то вроде прототипа страницы. Разными оттенками серого разграничиваю блоки, а весь текст в файле — сразу боевой. Это удобно и мне, и ребятам в команде.

Конечно, такой подход не значит, что дизайнер обязан сделать макет в точности, как на прототипе. Но так я уверена, что дизайнер поймет меня правильно.

Слева фрагмент прототипа лендинга для онлайн-интенсива, а справа — готовый макет

Удобно работать над текстом

Многие редакторы, копирайтеры, авторы работают с текстом в ворде или гуглдоках. Тогда можно сколько угодно думать о контексте или представлять себе будущий макет, но ты все равно пишешь в вакууме. У тебя есть просто широкая колонка какого-то текста. А когда дизайнер переносит его в итоговый продукт, оказывается, что вот тут текст не влезает, здесь подсказка лишняя, а вот тут ну очень нужно добавить заголовок.

Я стараюсь всегда писать текст по-живому: прямо на формах, в макете, на странице или в коде. А если это не получается, то создаю себе такие условия искусственно. Например, нам нужно изменить подсказки в интерфейсе. Я либо открываю инструменты разработчика, либо снимаю скриншот и иду в Фигму — так я сразу вижу, как ложится текст и что нужно поменять.

Сверху пример ТЗ на картинки для Инстаграма, а снизу — итоговый результат

***
Напоследок скажу, что на мой взгляд не имеет значения, в какой программе работать. Я для себя выбрала Фигму, потому что она простая, бесплатная и онлайн. Но главное понять, что дело не в инструменте, а в подходе к работе. Такие дела.

 1055   2020   организация работы   принципы

Проект: страница Лаборатории поисковой аналитики

У нас в «Ашманов и партнеры» есть много крутых собственных технологий. На рынке таких больше нет, и это наше преимущество. Например, есть Лаборатория поисковой аналитики. Она помогает давать рекомендации, основанные на научном подходе к продвижению. Это круто, но никому непонятно, как она работает. Откуда берутся данные? В чем польза для клиента? Нужно об этом рассказать.

На сайте была страница, посвященная Лаборатории. Но она шаблонная и скучная.

Исходная версия страницы

Мы решили сделать редизайн, рассказать о всех направлениях работы, сделать страницу визуально привлекательнее и дать «пощупать» результаты.

Что такое Лаборатория

Лаборатория поисковой аналитики — это несколько технологических разработок, которые позволяют «расшифровывать» поисковые алгоритмы.

Алгоритмы ранжирования постоянно усложняются и оперируют сотнями факторов. К тому же, сейчас поисковой выдачей управляет самообучающаяся машина. Поэтому даже поисковики не знают наверняка, как на самом деле устроено ранжирование.

Эксперты Лаборатории действуют от обратного: они анализируют сайты, которые уже попали в топ. Смотрят, какими характеристиками они обладают и чем отличаются друг от друга. Сравнивают страницы в топе между собой и со страницами, которые в топ не попали. На основе полученных данных выясняют, какие параметры могут влиять на ранжирование.

Гарантий Лаборатория не дает: наличие статистически значимой связи между значением параметра и попаданием в топ или позицией еще не означает, что Яндекс или Google прямо учитывает данный параметр при ранжировании. Но полученные данные позволяют понять, в каком направлении двигаться.

Страница — для маркетологов и SEO-оптимизаторов

Этой страницей мы хотели решить три задачи:

  • рассказать о пользе Лаборатории маркетологам. Не углубляясь в детали, ответить на вопрос: «А что я-то получу от этого?»
  • дать полезные материалы оптимизаторам. Как правило, они уже знают о Лаборатории из публикаций и докладов на конференциях. Поэтому они приходят с конкретной задачей: например, скачать исследование.
  • сделать материал, который поможет нашим продавцам рассказывать о Лаборатории на встречах с клиентами.

Моя задача — подготовить контент и вести проект

Я в «Ашманов и партнеры» занималась сайтом: писала тексты, создавала страницы, ставила задачи на дизайн и разработку. В этот раз все было так:

  1. Я продумала структуру страницы. Для этого собрала всю информацию: изучила отчеты и опубликованные интервью, побеседовала со специалистами Лаборатории, плзнакомилась с интерфейсом. Потом собрала из этого черновик и согласовала: в первую очередь с руководителем Лаборатории, а с нашей стороны — с исполнительным директором.
  2. Поставила задачу на прототип. Мы хотели, чтобы страница выделялась на общем фоне и имела интерактивные элементы, но при этом оставалась в рамках фирменного стиля. Я не специалист по интерфейсам, поэтому обратилась к профессионалам. В процессе обсуждения скорректировала первоначальную структуру.
  3. Поставила задачи на дизайн и верстку. Следила, чтобы все было правильно: дизайн соответствовал логике текста, верстка была точно по отрисованному макету, во всех браузерах страница отображалась верно и не было ошибок. Когда макеты готовы, показала их руководителю Лаборатории.
  4. Подготовила ТЗ на разработку. Чтобы удобно было размещать контент, а некоторые блоки использовать на страницах других технологий, нужно продумать компоненты и решить, что добавлять в шаблон, а что делать статикой. Потом окончательно проверить, что все работает, как запланировано.
  5. Написала окончательный текст и подобрала иллюстрации. Заполнила весь контент на тестовом домене и окончательно согласовала. Проверила страницу на боевом сайте.

Собираю информацию

Довольно долго мы не знали, с какой стороны подойти к задаче. «Под капотом» Лаборатории сложные технологии, основанные на методах математической статистики. Как это все работает, хорошо знает только руководитель Лаборатории Михаил Волович. Первым делом я обратилась к нему. Михаил посоветовал мне изучить аналитические отчеты, которые Лаборатория готовит с ноября 2017 года.

Аналитический отчет — это глобальное исследование факторов ранжирования. В нем даны теоретические рекомендации для оптимизаторов: какие коммерческие факторы сейчас важны, правда ли ссылки до сих пор работают и т. д. И подробно описана методика такого исследования.

Введение к отчету за 2018 год

На рынке о Лаборатории знают благодаря этим отчетам. Они публикуются в свободном доступе, тиражируются и выдержки из них перепечатываются в отраслевых СМИ. Но еще Лаборатория — это внутренний сервис, который помогает продвигать сайты наших клиентов. Это приоритетное направление, поэтому о нем нужно рассказать побольше.

Уже несколько лет Лаборатория делает бесплатные аудиты сайтов для участников конференции Optimization. Они автоматические: специалисты загружают в систему запросы и страницы сайта, а получают документ с рекомендациями. Результаты обсуждают на мастер-классе. Оказалось, что такой же документ генерируют оптимизаторы, когда работают с сайтами клиентов. Я попросила несколько примеров, чтобы их изучить.

Потом я пообщалась с оптимизаторами и расспросила их, как они используют Лабораторию. Они показали интерфейс, дали примеры отчетов и сделали скриншоты.

Интерфейс внутреннего сервиса, актуальный на февраль 2019 года

Так я узнала, что внутренний сервис экономит оптимизаторам много времени:

  • автоматически сравнивает сайт клиента с конкурентами и сайтами в топе, а потом генерирует таблицы с результатами анализа;
  • формирует понятный отчет для клиента со скриншотами. Оптимизатору остается только дополнить его данными и поправить, если нужно;
  • помогает поставить ТЗ копирайтеру: рассчитывает нужный объем, вхождения и даже дает список слов, которые не являются ключами, но их полезно использовать.

На самом деле, всю эту работу можно сделать и без Лаборатории. Но этим придется заниматься вручную, а это долго и ненадежно — человек всегда может что-то пропустить.

Готовлю структуру страницы

Когда я получила общее представление о возможностях Лаборатории, выстроилась логика страницы:

  • описание работы сервиса (как работает Лаборатория) и главный вывод, зачем это все нужно
  • описание направлений работы — исследования, аналитика для оптимизатора, отчеты для клиента, задания для копирайтеров. В каждом блоке объяснение, иллюстрация и практическое применение со ссылкой на другой раздел сайта.
  • факты о Лаборатории — как давно существует, сколько параметров отслеживает. Ссылка на интервью с основателем.
  • рейтинг самых главных параметров для поисковых систем, основанный на данных из последнего отчета. На каждый параметр можно кликнуть и узнать подробности. Польза и элемент интерактивности :)
  • все отчеты Лаборатории, которые можно скачать за подписку на рассылку.

Такая структура легла в основу прототипа.

В процессе работы над дизайном мы внесли изменения:

  • полезное действие технологии вынесли на самое заметное место — под заголовком.
  • по просьбе Михаила в блок «Что мы делаем» добавили информацию о сервисах: на данных Лаборатории основаны «Тургенев» и AnalyzeThis.ru.
  • добавили FAQ. Текст этого блока взят из отчета «Факторы ранжирования — 2019. Финансы».

Что дальше

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

Пока мы придумывали страницу, у внутреннего сервиса обновился интерфейс — пришлось переснимать скриншоты и вносить изменения.

7 августа мы выложили готовую страницу на боевом сайте. Сейчас мы накапливаем данные и отслеживаем аналитику. Возможно, в будущем коллеги внесут в нее изменения.

Готовая страница, актуальная на август 2019 года
 795   2019   кейс   организация работы   портфолио

Как я пишу и редактирую кейсы

Пришлось мне недавно общаться с коллегами из Mindbox. И вот они спрашивают: «А как ты с клиентом общаешься, когда кейсы компании пишешь?». А я такая: «Никак. Мы не привлекаем клиента к подготовке кейса». Сейчас раскрою наш редакторский процесс на примере одного текста.

Начинается все с того, что менеджер проекта описывает все своими словами и приносит мне черновик. Я уже докручиваю материал.

Слайд из презентации с кейсом по контекстной рекламе для магазина «Сантехника № 1»

Нахожу тему

Просто рассказать, что мы запустили рекламу недостаточно — это никому не интересно. Нужна общая идея, чтобы читатель сразу понимал, стоит ли читать.

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

В лиде так и пишем: «Рассказываем, как с помощью „умных“ кампаний мы за три месяца снизили стоимость клика в 3,3 раза в условиях перегретого аукциона».

Строю историю

Любой кейс — это история. Чтобы ее было интересно читать, нужен построенный сюжет. У хорошей истории несколько этапов: событие, план А, план Б, финальная битва — вот это все.

Я пока не научилась использовать в кейсах законы драмы, поэтому придерживаюсь простой структуры:

  • проблема — с чем клиент к нам пришел или что мы пытаемся улучшить.
  • ход проекта — что делали и как добились целей.
  • факапы — что не сразу получилось и почему.
  • решение — как нашли работающий метод.
  • результаты — с цифрами и графиками.

Обычно менеджеры не акцентируют внимание на проблемах. Но мне кажется, что это важный момент кейса. Цель — чтобы читатель подумал «О, да, у меня была/есть такая же фигня».

Говорим о проблеме: «На этом рынке сильная конкуренция со стороны крупных и мелких игроков. Из-за этого по популярным товарам аукцион „перегретый“ — стоимость клика часто превышает 100 рублей. Каждое обращение получается дорогим даже при хорошей конверсии».

Менеджер дал информацию по двум инструментам: динамические объявления в Яндекс.Директе и Google Smart Shopping. Но использовать именно Smart-кампании начали не сразу. Встраиваем это в общую логику. Теперь у нас есть три инструмента, один из которых не подошел. Читать уже интереснее, а пользы от статьи больше.

Допиливаю буквы

Когда менеджер пишет текст, он использует термины. Но кейсы читают маркетологи, которые могут не знать, что такое фид или зачем он нужен. Поясняем сложные моменты и попутно переписываем текст, чтобы сделать его более понятным.

Добавляю факты

«Мы запустили рекламу и снизили стоимость клика» — хороший тезис, но читателям нужны детали. Давно работаете с клиентом? Сколько длилась эта кампания? Сколько денег принесли клиенту?

О выручке мы говорить не можем — NDA, а остальные цифры указали. Результаты представили в табличке, чтобы их не надо было искать по тексту.

Добавляю личность

Кажется, что кейс — это история про бизнес. Но любой бизнес делают люди. Я прошу менеджера рассказать о проекте: какие выводы для себя сделали и как применить результаты кейса у себя. Добавляю цитату. Теперь исчезла абстрактность: над этой кампанией работал реальный и конкретный Саша.

У нас не принято беседовать с клиентом и просить комментарии. Вместо этого мы запрашиваем отзыв о работе компании: на официальном бланке, с печатью. Выкладываем скан в кейс.

Оформляю публикацию

В конце добавляем иллюстрации: пояснения-пояснениями, а проще один раз увидеть.

В итоге получился такой кейс.

 541   2019   организация работы   редактура

О доверии в команде

Когда я прихожу с работы и рассказываю мужу о своих переживаниях, он всегда удивляется, насколько мне важно доверие коллег. Я все время слышу: «Что ты переживаешь, это же не ты решила/накосячила?», «Ты свою работу сделала — какая разница что будет дальше?», «Зарплату платят, остальное не важно» и пр. Я удивлялась его легкому отношению к работе. Ему правда все равно, что о нем думают. А потом поняла — у нас просто разный опыт.

Любая задача, которую мы делаем, относится к проектам или к процессам. Проект имеет временные рамки, этапность и ведет к конкретному продукту/результату на выходе. Процесс — бесконечен.

процесс ≠ проект

В больших бюрократизированных организациях (вроде ГКУ ЦЗН, где работал муж) обычная работа сотрудников состоит из череды процессов. У них есть KPI, но они тоже завязаны на процессах — например, направить в 2019 году Х безработных на обучение. И ты изо дня в день общаешься с безработными, заполняешь одинаковые бумажки, пишешь одинаковые запросы — и так постоянно. Иногда рутина разбавляется очередным распоряжением сверху, но люди не понимают его смысла — они не видят картину целиком и поэтому не особо замотивированы в выполнении. И даже в конце месяца, квартала и года нет видимого результата, сплошная рутина.

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

В проектной работе иначе. Вы выполняете общую задачу и идете к одной цели. Вы — команда, поэтому конечный результат зависит от каждого из вас. Чтобы сделать хороший продукт, вы должны быть уверены в каждом — иначе ничего не получится. Сомнения в коллегах, недомолвки и недоверие ведут к конфликтам в команде, затягиванию сроков и падению эффективности.

Когда мы запускаем сайт, я как редактор работаю в команде с разработчиком и дизайнером. Иногда к задаче подключается оптимизатор и юзабилити-специалист. Каждый из нас отвечает за определенную часть проекта. Если мы не будем доверять друг другу, проект развалится: мы как лебедь, рак и щука будем тянуть его в разные стороны.

Помимо текстов я беру на себя функции проджект-менеджера и принимаю многие решения: делать фичу или не делать, релизить или не релизить. Иногда мне приходится что-то менять под давлением руководства. На первый взгляд, не моя вина, что у начальства семь пятниц на неделе. Но именно мне приходится идти к команде со старой новой задачей. И я понимаю, чем чаще я буду допускать такие ситуации, тем меньше мне будут доверять.

Доверие в команде — самое главное для успеха проекта

P.S. Компания целиком — та же команда. Поэтому не делайте, как мое начальство: принимайте решения обдуманно и берите на себя ответственность. Иначе подчиненные перестанут вам верить.

 56   2019   организация работы   принципы   рефлексия   управление проектом