Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах

Провели работу наш ошибками над тем, что работает и не работает в нашей системе обучения и критериях качества по текстам в интерфейсах.

О чем вообще ты говоришь, женщина?
А вот о чём:
— У нас есть период онбординга нового члена команды, за который он выравнивается с командой на этом безопасном плато.
— Есть система обучения: разные форматы и подходы, которые помогают научиться писать тексты
(рассказывали на VC и давали примеры домашек)
— А есть критерии качества текстов и типографики — каждый может свою работу проверить, а до командного ревью она доходит уже без ошибок по этим чеклистам.

Спустя год, нам было над чем поразмыслить.

И вот что работает хорошо:

1. Рассказывать новичку о чеклистах — о том как надо, а как не надо писать текст, до первых задач смысла нет. Критерии не четкие как, например, в типографике, поэтому понятия «Краткость», «Человечность» тоже размыты.
Их не измеришь, а значит, теория до первого опыта неприменима. Рассказывать стоит уже в первых задачах, на примере уже написанного текста и с личным разбором. Показывать и объяснять, что плохо или хорошо и почему.

2. Сильно помогает предварительная UX-аналитика и интервью c ЦА. Портреты и характеристики пользователей помогают писать в правильном тоне и с единым уровнем детализации сложных понятий.

Грубо говоря — пишем как для офлайнового предпринимателя в продукте валютного контроля, или как для разбирающегося relations-менеджера в KYC-продукте.

3. Свежий взгляд на текст — как не парадоксально, это сильно помогает и об этом нельзя забывать. Утро вечера мудренее: написали тексты, ушли домой, а утром ещё раз просмотрели и сразу заметили грубые ошибки.

4. Ролевые игры 🙂
Практика, которую мы применяли в обучении UX-исследователей, работает и в обучении дизайнеров UX-текстам. Устраивает исследователь для дизайнера на его задачах. Многим новичкам помогает, так как они не понимают о пользователе ничего, включая реакции и потребности на конкретном шаге конкретного процесса.


А вот что у нас не работает или приносит несущественную пользу:

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

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

3. Мудборды по UX-текстам: сложно находить специально, человеку без опыта сложно понять, что хорошо, а что плохо.
— Мудборд нужно делать общекомандным и обязательно нужно разбирать и оставлять комменты о том что и почему в конкретном примере хорошо и плохо.

4. Главред — это зло, когда не умеешь им пользоваться. Сколько не говори о рейтинге и о том, что не надо на него смотреть и доводить свой текст до 8 и выше, люди в это выдрачивание всё равно скатываются.

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

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


Ну вот и всё. Удачи вам с microcopy

UX

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

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

Если продолжать тему про любимые занятия, то в первом семестре Антон в начале каждого занятия давал нам прокачку, после которой я теперь не боюсь сталкиваться с поиском быстрого и креативного решения любой проблемы. В этих прокачках нужно было очень быстро, за 10-15 минут, придумать, нарисовать и сделать бумажный прототип конкретной задачи. Например, придумать приложение по разделению счета в баре, по поиску собутыльника, приложение для знакомства в общественном транспорте, для настройки фортепиано и т.д. Круто, когда через 5 занятий до тебя наконец доходит алгоритм по которому нужно действовать, и ты начинаешь играться этими кейсами в своё удовольствие, но это уже отдельная история.
___________

Так вот, закончили мы исследовать наш продукт и настало время для конкретных действий. За блок UX нам было необходимо:

⁃определиться с парадигмой навигации (гамбургер меню, либо таббар);
⁃найти основную работу на которую пользователи нанимают наше приложение, воспользовавшись фреймворком JTBD;
⁃составить карту экранов;
⁃составить информационную архитектуру;
⁃нарисовать вайрфреймы экранов и собрать из них прототип;
⁃протестировать прототип;
⁃подготовить отчет по тестированию и внести правки.

После чего, в идеале, с протестированным прототипом и вайрфреймами мы должны перейти к блоку UI и начать поиск своего визуального языка…
___________

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

Проблема в том, что главный ограничитель наших требований — мы сами. Довольно сложно не уйти в частности и вовремя остановиться, расставив ограничения самим себе.

Например, в нашем приложении есть карточка заказа — как, без реальных бизнес метрик, определить какая информация важна, а какая нет? Нужен просто адрес или подробная карта? Как подать информацию об авторе объявления? Что из этого важнее и должно располагаться выше?

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

Так и остается — выдумывать ограничения самим, а отсюда соблазн сделать так как красиво, как лучше всего ляжет на макет.

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

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

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

Подводя итог — на блоке UX каждая команда сначала придумывает бизнес ограничения, а потом героически их преодолевает.

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

Инсайты + конкуренты

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

С юду действительно много пересечений, в частности они уже давно перешли на модель обратного аукциона, о которой я писал в самом начале (https://t.me/bukhtiyar/88). Поэтому многие процессы связанные с автоматизацией у них уже обкатаны и налажены.

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

Давайте сравним юду и профиру.

Итак, я решил зарегистрироваться в профиру и юду в качестве дизайнера-фрилансера, давайте посмотрим, что из этого получилось (и не получилось).

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

И что бы вы думали?
У меня не получилось зарегистрироваться! Так как для регистрации в роли дизайнера необходим диплом о высшем образовании, карл! Я на свою работу устроился без диплома, потому что дизайнеру не нужен диплом! А знаете почему в профиру он нужен? Потому что по иерархии дизайн относится к IT сфере, куда в том числе входят и программисты, которым действительно важно иметь высшее образование, а правила для всей категории вакансий в сфере IT одинаковые, вот и получается, что дизайнеру нужен диплом.

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

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

Очевидно, что истина где-то посередине.

Джон Коулман из Intercom посчитал, что на стартовых экранах популярных приложений в среднем 36% текста.

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

1. Стремись к меньшему. Из двух вариантов, одинаковых по смыслу, предпочитай короткий.

2. Начни с «зачем». Всегда помни, зачем добавляешь слова.

3. Не заставляй думать. Используй слова, чтобы быть понятным, а не остроумным.


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

Метод гипотез в решении технических задач

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

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

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

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

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

Вопрос читателя: “Какие образовательные программы и сертификации считаете полезными для продакта?

Не говорю про самообразование и постоянное "затачивание пилы", а именно с целью документального подтверждения навыков (например, при собеседовании) – что было и полезно вам и ценно для работодателей”.

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

Лично мой честный вам ответ – никакие. Ни в одном месте, куда я устраивалась на работу, меня не просили предъявить “корочки”. Я сама ни разу не смотрела на список законченных курсов кандидата, когда принимала решение о найме.

У меня нет ни одной сертификации или диплома (кроме как о получении высшего образования). Когда я устраивалась на работу в Яндекс, одно из собеседований было про статистику – а я в статистике была ни в зуб ногой. Когда я пришла работать в Suitepad, мне надо было проводить пользовательские исследования, что я раньше никогда не делала. В Intercom нужно было уметь работать с SQL, чего я, опять же, не знала.

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

1. По своей природе, профессия продакта похожа на любую руководящую должность. Не могу представить ситуацию, где интервьюер говорит: “Ну да, вы классный менеджер, умеете строить команды с нуля, вести людей за собой и приносить деньги компании, но вот сертификатика про Agile у вас нет. Жаль-жаль, придется вам отказать”. Des Traynor, один из основателей Intercom, успешно переключается между разнообразными C-level должностями: какое-то время был CMO, до этого – CPO, а после - COO. Многие tech компании также практикуют “взаимозаменяемость” топ менеджеров. Все потому, что их ключевые навыки, как и у продактов, в большей степени относятся к soft skills или к независимым от функции hard skills (например, стратегия или приоритезация).
2. Продакт-менеджер – это швейцарский нож; набор “инструментов”, который вам потребуется, будет сильно зависеть от нанимающей компании. Где-то будет нужен уклон в маркетинг, где-то в анализ данных, и так далее. Все знать невозможно, и адекватные работодатели это понимают.
3. Хороший продакт должен уметь быстро во всем разбираться – и иногда курс или сертификация действительно могут в этом помочь. Однако даже в этом случае “корочка” – лишь ненужный артефакт. Ни один диплом не докажет, что вы не просто усвоили знания, но и, что гораздо важнее, научились их применять на практике. Ни одной компании не нужен продакт с сертификатом по Data Science – но нужен продакт, который умеет принимать решения на основе данных. Фокусируйтесь на результате, а не на средствах его достижения. В этом случае часто оказывается, что нам не нужен курс за 20 тысяч рублей; можно прочитать книгу, пару статей, а все остальное осваивать уже в “бою” :)

Сразу также отвечу на популярный вопрос от проджект-менеджеров: нужна ли сертификация PMBOK или Agile, чтобы найти работу. Прежде всего должна сказать, что уже давно не сталкивалась с подобными вакансиями в продуктовой разработке; мне кажется, за границей это все больше и больше становится рудиментом (конечно, не говорю здесь об агентствах). Когда я работала в России, ни у кого из моих знакомых проджектов таких сертификатов не было.

И еще одна важная оговорка: мы не затронули тему MBA, так как это отдельная и очень объемная история. Приходите слушать нашу трансляцию с Юлей Нечаевой, где она будет говорить про свой опыт с MBA в одном из топовых американских университетов и как это повлияло на ее карьеру https://t.me/proproduct/956 (https://t.me/proproduct/956)