Rose debug info
---------------

Виталий Филатов

о тексте, смысле и красоте

Заглушка для сервисных работ

Простой пример работы с текстом: вникаем в ситуацию, формулируем задачу, собираем контекст и пишем.

Ситуация

В Дехабе сделали страховой калькулятор для Росгосстраха. Заказчик запланировал обновление серверной части и просит подготовить заглушку.

Текст на заглушке такой:

ВНИМАНИЕ!

6 марта 2021 года с 20.00 до 23.59 по московскому времени на сайте будут проводиться технические работы.

К сожалению, оформить полис в это время будет невозможно.

Приносим извинения за временные неудобства.

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

Задача

Написать человечнее, с заботой и конкретикой.

Контекст

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

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

В нашем случае удалось выяснить следующее:

  • Заказчик вводит в эксплуатацию отказоустойчивую схему базы данных
  • Работы займут четыре часа, в это время вместо калькулятора пользователь видит заглушку
  • Заглушка привязана к дате и времени работ
  • На время работ отключится внутренний сервис расчёта полисов, поэтому страховку нельзя будет оформить по телефону или в офисе
  • Работы перенесли на вечер воскресенья, калькулятор заработает в час ночи понедельника

Текст

Дальше дело техники. Собираем всё в кучу и составляем сообщение по схеме:

Что произошло → Почему → Что делать

Выбрасываем «Внимание!», заглушка привлекает внимание сама по себе. Вынесем суть в заголовок:

⚠ Оформление полиса временно не работает

В причине начинаем с указания времени:

Сегодня с 20:00 по Москве...

Получается связное сообщение: не работает именно сегодня, с 20:00. Дату указывать не нужно, в другой день пользователь заглушку не увидит.

Чтобы работы не проводили сами себя, добавляем действующее лицо — мы (Росгосстрах). Формулируем вескую причину, как косвенно полезную для пользователя. Это может снизить досаду от неработающего калькулятора:

...мы повышаем надёжность сервиса...

Дополняем причину следствием, чтобы связать с заголовком:

...поэтому расчет и оформление полиса недоступны.

Вряд ли кто-то будет звонить в офис ночью, поэтому про телефон и офис не говорим. Не работает и всё, нужно ждать. Скажем, когда приходить:

В 2:00 понедельника всё вновь заработает.

Для надёжности сдвинем срок на час, если заказчик не против. Извиняться в конце не будем, мы ничего не сломали, работы плановые и косвенно улучшают жизнь пользователя.

Всё вместе:

⚠ Оформление полиса временно не работает

Сегодня с 20:00 по Москве мы повышаем надёжность сервиса, поэтому расчет и оформление полиса недоступны. В 2:00 понедельника всё вновь заработает.

Страховой калькулятор и заглушка в работе:

Досадная мелочь: в макетах я перенёс «И» на следующую строку, привязав её неразрывным пробелом к следующему слову. На вёрстке на это не обратили внимания и предлог остался висеть :(

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

Советы

  1. Сформулируйте задачу: зачем и кому писать, какую задачу существующий текст не решает. Возможно, он путанный или туманный, а может, достаточно добавить указание на московское время.
  2. Соберите контекст: всё, что относится к ситуации и пользователю. Знание контекста помогает отобрать важное и преодолеть писательский ступор.
  3. Отвечайте на вероятные вопросы пользователя. Если это сообщение об ошибке, скажите, что произошло, почему и что делать. Если о плановых работах, то какая от них польза, когда всё заработает и как решать задачу, пока сервис не доступен.
  4. Если вы менеджер, вас засыпет вопросами. Чтобы писатель меньше вас дёргал, соберите материалы по теме в постановке задачи.

Согласуем иконки тарифов

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

Иконка диагностики откровенно плохая, но её мы трогать не будем :-)

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

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

Чтобы согласовать иконки с текстом и между собой, разберёмся в их смысле.

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

Движение мысли такое:

Чтобы открыть корпус большинства бытовых приборов достаточно отвёртки.

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

Для сложного ремонта понадобится целый набор: паяльник, плоскогубцы, кусачки, мультиметр и молоток.

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

Конечно, отвёртка нужна крестовая, но у плоской более узнаваемый силуэт, это важно

Картинки были в векторном формате SVG, поэтому я закинул их в Фигму, развернул ключ и прилепил его поверх отвёртки. Так отвёртка сохранила наклон, а мы подчеркнули идею добавления нового инструмента.

Получилось так:

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

Выводы.

  1. Давайте редактору макеты или доступ в Тильду. Редактор работает со всеми смыслами в продукте, а не только с текстом. Что-то сделает сам, что-то передаст дизайнеру.
  2. Векторные иконки — благо: масштабируются, мало весят, можно редактировать в Фигме. Одни плюсы.
  3. Согласованные иконки добавляют красоты и помогают передать комплексный смысл без слов.

Как ставить задачи UX-писателю (диплом 6/6)

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

Это шестая, заключительная статья из цикла о моём UX-дипломе. Ссылки на предыдущие части — в конце страницы.

О писателе и его задачах

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

Писатель работает со смыслами: решает, как писать, и помогает определиться, что писать.

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

UX-писатель может помочь:

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

Всё многообразие случаев можно свести к формуле:

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

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

Памятка по постановке задач

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

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

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

2. Заложите время на анализ. Набрать текст — четверть дела. Чтобы слова работали, писателю нужно разобраться в ситуации и понять, что именно следует сказать. Это может занять больше 5 минут.

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

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

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

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

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

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

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

5. Поставьте формальную задачу. Соберите всё в письме, Джире или Трелло. Объясните приоритет и укажите сроки. Добавьте ссылки на макеты, документы и примеры. Если этого не сделать, писатель сначала возьмёт срочные задачи, а потом пойдёт собирать материалы, уточнять контекст и ожидаемый результат.

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

Если вы соберёте всё нужное в одном месте и поставите сроки, писатель сможет спланировать и восстановить контекст в комфортное время, никого не отвлекая.

Пример

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

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

Ставим задачу в письме или таск-трекере:

Тема: Онбординг для главного экрана

Привет! Главной странице личного кабинета жильца нужен онбординг. Напиши, плиз, и предложи визуальное решение, если будут идеи.

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

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

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

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

Всё по задаче

Сторифреймы: miro.com/app/board/o8K_kxzrs1P=/?fbclid=IzAS2JyWuVp2JYDN_4qczjAeBE_WqjGEhupECAhtjbs6t6ML27tloNCEG5xJS

Исследование юзабилити. Там крутые комменты от участников, могут пригодиться: docs.google.com/document/d/1pP2af5Ec2fTyGj9b7jW8DE0E_aVIQlCb_-rHegxX8cc/edit

Макеты главной: www.figma.com/file/l3dNqhytcjCGIKjqSfJJYn/01-Main-Screen

Редполитика: confluence.drakkar.io/pages/viewpage.action?pageId=39321

Кейсы из запросов операторов ТП, про звонки и чат: confluence.drakkar.io/pages/viewpage.action?pageId=21347123

Визуальной частью занимается дизайнер Лёня @lkobiakov. Напиши ему, как приступишь, он в курсе. Его задача прилинкована к твоей.

Будут вопросы по проекту — звони/пиши:

+7 987 654-32-10 / @vfilat

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

Опоссум Ulv Vind

Ссылки

Памятка и пример — часть моей дипломной работы по курсу Нетологии «UX-писатель». Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю — вы находитесь здесь

Учебный проект: UX-исследование (часть 5/6)

Пятая часть цикла о моём UX-дипломе. Рассказываю, как показывал кусок интерфейса живым людям и какие выводы сделал из их отзывов. Будет много умных слов цветных диаграмм :3

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

Напомню, о чём диплом. Есть выдуманный холдинг «Яркий», который сам строит дома, продаёт квартиры и управляет коммунальным хозяйством. Для удобства жильцов и автоматизации процессов «Яркий» делает мобильное приложение с личным кабинетом. Диплом о разработке этого приложения: анализе потребностей пользователей, создании прототипа и проверке гипотез.

Предмет исследования

В макетах первой итерации меня смущал дизайн панели с чатом службы поддержки. Она расположена вверху экрана:

Главный экран с первой версией чата

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

Проблема состояла в том, что панель получилась запутанной и я не был уверен, что пользователи правильно поймут её назначение.

Для автора выглядит логично, а что поймёт пользователь — вопрос исследования

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

Подробное описание исследования и выводов в домашней работе № 5.

Исследовательские вопросы

  1. Считывает ли пользователь последовательность из иконки, подписи и индикатора как возможность перейти к чату с поддержкой?
  2. Понимает ли пользователь, что зелёный индикатор рядом со словом «оператор» означает, что оператор поддержки в сети?
  3. Понимает ли пользователь число в правом углу как количество ещё непрочитанных сообщений от оператора?
  4. Ожидает ли пользователь увидеть другие возможности связи на экране чата с оператором?

Методика исследования

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

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

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

Вопросы размещались на отдельных слайдах:

  1. Подводка и квалификационные вопросы о возрасте и опыте.
  2. Целевой вопрос и необязательный комментарий.
  3. Благодарность.
Первый экран с подводкой и квалификационными вопросами
Второй экран с целевым вопросом
Финальный экран с благодарностью за прохождение

Выборка

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

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

Для большей убедительности приведу фрагмент из домашней работы, где всё расписано подробнее:

Расчёт доверительного интервала

Доверительная вероятность — 95 %

Генеральная выборка — больше 100 000 человек

Размер выборки — 30—50

Ожидаемый процент ответов — 70 %

Вероятность взята выше 50 %, поскольку респондент самостоятельно решает перейти по ссылке на форму опроса.

Доверительный интервал — 16,4—12,7

Калькулятор и методика расчёта

Результаты

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

Таблица с ответами и обработанными результатами

Получилась следующая картина:

Возраст. В выборке преобладают представители ЦА «Яркого» и небольшое количество респондентов моложе 25 и старше 50 лет.

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

Связь опыта и возраста. Пользователи 25—30 лет чаще пользуются мобильными приложениями социальных сетей, сервисов такси и доставки. Пользователи в возрасте 30—50 лет чаще обладают выраженным и начальным опытом.

Общая понятность перевалила за 50 %.

Большинство опрошенных достаточно ясно поняли, что делает блок с чатом.

Совсем не поняли только 4,7 %.

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

Мне стало любопытно, как понимание распределяется по опыту и возрасту.

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

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

Выводы

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

Вот что вышло в финале:

Главный экран приложения

Благодарности

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

Благодаря вам исследование дало результаты, мне зачли домашку, а прототип приложения стал ощутимо лучше :3

Ссылки

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

Макеты в Фигме, если хотите посмотреть на бардак в слоях

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование — вы находитесь здесь
  6. Как ставить задачи UX-писателю

Абзац с отступом и иконкой в гугл-доках

Иногда в текст нужно добавить примечание с отступом и иконкой. Это проще всего сделать списком с маркером-эмодзи:

Выделяем текст примечания и делаем его маркированным списком.

Кликаем правой клавишей по маркеру списка и выбираем «Другие маркеры».

В окне «Вставка специальных символов» ищем эмодзи по категориям или в строке поиска по ключевым словам в названии. Например, bulb (лампочка). Кликаем по нужному значку, он становится маркером списка.

Если потребуется второй абзац уже без иконки, отбейте тест вправо кнопкой «Увеличить отступ». По умолчанию он равен отступу списка.

Расстояния до основного текста настраиваются в «Формат → Межстрочный интервал → Настройка интервалов». Посмотрите, какие интервалы у обычного абзаца и добавьте примечанию 2—3 пункта сверху и снизу.


Для справки ещё два способа, но не таких удобных.

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

Точные отступы абзацев и строк настраиваются в «Формат → Выравнивание и отступы», но если вы потом замените значок, всё может немного съехать.

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

Учебный проект: интерактивные макеты (часть 4/6)

Четвёртая статья из цикла о моём UX-дипломе в Нетологии. Рассказываю о макетах: с чего начал, как собирал и почему они так выглядят.

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

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

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

Принципиальные макеты

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

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

Регистрация и вход → Главная и разделы → Экстренный звонок и вызов мастера → Чат с оператором

Исходники Storyframes в Миро

Макеты в Фигме

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

Для учебного проекта я предположил, что целевая аудитория «Яркого» в массе своей айтишники и темно-серая гамма будет напоминать им среды разработки и Photoshop с DaVinci Resolve. А ещё тёмный фон помогал мне сберечь глаза, поскольку дипломом я занимался по вечерам после работы.

Главный экран приложения

После цвета я выбрал шрифты. Для основного текста взял системный шрифт iOS San Francisco Pro Text, а для кнопок — San Francisco Pro Display. Системные шрифты отлично выглядят и по-хорошему безлики. Для цифровых полей, напротив, взял IBM Plex Mono, чтобы его выразительная форма привлекала внимание к цифрам. Иконки — из бесплатного набора Font Awesome.

Основные шрифтовые стили

Поскольку я всё же писатель, а не дизайнер, я ограничился макетами для Айфона 8. Его экран удачно масштабировался на мой SE. Я поставил на телефон Figma Mirror и рисовал, регулярно проверяя интерфейс в реальном размере.

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

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

Макеты с переходами по событиям. От запуска и онбординга до звонка диспетчеру

Чтобы пользователь не запутался в последовательности экранов, разделы организованы с небольшой вложенностью. От главного экрана пользователя всегда отделяют максимум два, связанные общей логикой.

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

Главный ⇄ Вызов мастера ⇄ Описание проблемы / Подтверждение

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

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

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

Попробуйте «зарегистрироваться», увидите онбординг на главном экране :3

Немного сложностей

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

Первый сложный вопрос — сетка. У меня был только Айфон SE, на мокапах он выглядел кирпичом, поэтому я выбрал Айфон 8.

Ширина экрана у SE — 320 пикселей, можно использовать сетку с шагом в 8 пикселей. Получается 40 ячеек-микромодулей, которые бьются на удобное количество столбцов и строк. Можно выровнять шрифт по сетке и навести прочий pixel perfect.

У восьмёрки ширина 375 пикселей. Ни 10, ни 8 пикселей не подходят: базовая сетка обрывается на половине ячейки, колонка с контентом либо слишком узкая, либо с нечётным количеством столбцов, либо ещё что. Приходится добавлять отступы по бокам и терять ценное место.

Путём проб и ошибок подобрал сетку с базовой ячейкой в 5 пикселей, а строки и столбцы сделал с шириной и отступом по 15 пикселей. Строк на экране уместилось нечетное число, но главное — влезло 12 столбцов.

Получилось в меру ровно:

Сетка макета. Всё кратно 5 пикселям

Вторая сложность — новые фичи Фигмы. Дело было в феврале 2021, Фигма обновила библиотеки компонент, настройки Constraints и добавила Auto layout. В роликах на Ютубе всё выглядело здорово: блоки сами выравнивались, можно было сделать типовой компонент, а потом его заполнять текстом и ничего не ломалось. Но с выравниванием я провозился дольше, чем со всем остальным.

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

С экраном звонка оказалась такая же история. Пришлось позвонить и сделать скриншот, а нужное дописать поверх.

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

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

Ссылки

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

Макеты в Фигме, если хотите посмотреть на бардак в слоях

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты — вы находитесь здесь
  5. UX-исследование
  6. Как ставить задачи UX-писателю

Учебный проект: основы ToV (часть 3/6)

Третья часть рассказа о моей дипломной работе по курсу Нетологии «UX-писатель». Разрабатываю основы Tone of Voice — стиля, в котором будет написан весь текст приложения жильца ЖК «Яркий».

В этот раз текста особенно много, так что лонгрид-варнинг. Чтения на 9 минут.

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

Зачем нужен Tone of Voice

Tone of Voice (тон голоса или просто голос) — это стиль общения бренда или продукта. Он определяет, какими словами и в каком тоне мы пишем в различных ситуациях, как относимся к людям, как реагируем на события. Голос формирует впечатление от продукта и отражает ценности его команды.

Важно, что голос продукта — как имидж у человека — есть всегда, даже если им не заниматься. Пользователь всё равно сформирует образ из текста интерфейса, писем и ответов поддержки. Просто если не упорядочивать, образ сложится как повезёт.

Термином ToV или «голосом продукта» называют сам стиль общения и документ, который его описывает. Документ входит в редакционную политику и помогает команде придерживаться нужного тона.

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

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

Критерии оценки голоса

Для изучения требовались рациональные критерии оценки. Я выбрал упрощенную версию фреймворка Nielsen Norman Group с двумя измерениями вместо четырёх:

Серёзный — Весёлый

Формальный — Неформальный

Уважительный — Дерзкий

Игривый — Холодный

Так мне было бы проще наглядно распределить стили коммуникации по осям формальности и серьёзности:

Критериями формальности я выбрал синтаксис и наличие оборотов официально-делового стиля. Серьёзность оценивал по эмоциональной окраске.

Виды тональности с признаками:

Формальный — cложные конструкции с отглагольными существительными и страдательным залогом, модальные глаголы, официально-деловая лексика

Неформальный — естественный синтаксис, простые языковые конструкции, разговорная лексика, свойственная речи потенциальных пользователей

Серьёзный — обезличенное повествование без эмоций, сосредоточенное на передаче смысла

Весёлый — эмоциональное повествование с элементами разговорной речи. Позитивный настрой, энтузиазм и юмор

Как говорят конкуренты

Изучить детально конкурентов не вышло. Для доступа в похожие приложения требовали регистрировать квартиру в УК, поэтому я смотрел открытые источники: сайты, инструкции, скриншоты и страницы в App Store. Я не проводил лингвистического анализа, а на оценки повлиял дизайн приложений. Поэтому всё субъективно.

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

Голоса конкурентов на матрице тональностей:

Как говорят пользователи

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

Тональная матрица, построенная на основе личного общения:

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

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

Голос приложения «Яркого Дома»

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

Основной принцип:

«Яркий» не старается запомниться и произвести впечатление, а решает пользовательские задачи. Просто, спокойно и приветливо.

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

Тональная матрица с вариантами для различных событий:

Тональная матрица продукта поверх пользовательской

Чтобы понять стиль полнее, я добавил к основному тону дополнительные шкалы, тоже по Нильсену-Норману:

Дополнительные шкалы тональности по фреймворку Nielsen Norman Group

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

Основные идеи и примеры

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

Плохо Хорошо
Обновлена процедура оформления пропусков Чтобы оформить пропуск, отправьте курьеру или гостю QR-код
Для работы с приложением требуется разрешение на отправку уведомлений Разрешите отправку уведомлений. Будем оповещать о важных событиях, ремонтных работах и собраниях жильцов

Чтобы объяснять пользу было проще, задаём своему сообщению вопрос «ну и что с того?», пока ответ не станет ясным.

Уважение. Мы общаемся с пользователем вежливо и интеллигентно: без заискиваний, грубости или отстранённого формализма.

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

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

Плохо Хорошо
Для продолжения регистрации подтвердите номер телефона Введите номер телефона, чтобы зарегистрироваться. Мы пришлём вам СМС с кодом подтверждения
Заявка успешно отправлена Заявка принята. Электрик придёт в понедельник, 8 февраля, к 18:00.
Добавить в гугл-календарь

Говорим естественно. Стараемся выбирать подлежащие, способные совершать действия: мы, вы, мастер, компания. Добавляем глаголы действия: ремонтируем, работаем, выясняем.

Важные действия всегда совершает кто-то конкретный.

Плохо Хорошо
Ведутся ремонтные работы кабины лифта Лифт сломался, но мы его уже чиним

Пользу всегда выносим в начало, пишем максимально ясно и объясняем контекст. Расшаркивания — это не забота, а лишние буквы.

Плохо Хорошо
Уважаемые жильцы! Запланированы плановые ремонтные работы, возможны перебои в работе лифтовой группы. Заранее приносим извинения за возможные неудобства Отключение грузового лифта
Завтра мы проводим его профилактику с 9:00 до 23:00

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

Плохо Хорошо
Пожар в подъезде! Вызвана пожарная служба. Сохраняйте спокойствие В подъезде дымно!
Сработали датчики дыма. Оставайтесь на улице. Сообщим, когда станет безопасно
Упс! У нас упал сервер и кажется, ваши средства постигло обнуление. Но мы уже чиним, всё будет хорошо Вчера сломался сервер с данными, и ваш баланс мог обнулиться. Мы восстанавливаем данные из резервных копий, скоро всё станет как было

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

Плохо Хорошо
Ку-ку! Кто в домике живёт? Пройдите короткий опрос и узнайте, кто ещё не любит Кайло Рена. Приключение на 5 минут, пёс! Опрос: интересы жильцов
Заполните анкету и мы покажем, чем увлекаются ваши соседи. Будет о чём поговорить на детской площадке :)

В дополнение к идеям и примерам я составил примерную структуру редполитики на полторы страницы, но она в диплом не вошла. Посмотрите в домашке по ToV.

После ToV я сел за макеты, прототип и промежуточное исследование. О них расскажу в следующих частях.

Ссылки

Интерактивный прототип в Фигме. Смотрите в режиме презентации.

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

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей
  3. Основы ToV — вы находитесь здесь
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю

Учебный проект: потребности пользователей (часть 2/6)

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

Рекомендую начать с первой части. Там о работе UX-писателя, курсе Нетологии и продуктовых гипотезах проекта.

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

Онбординг на стартовом экране

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

Но сначала немного философии.

Зачем изучать потребности

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

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

Живые люди куда сложнее абстрактных персон, которые иногда собирают проектировщики с маркетологами. Люди субъективны и иррациональны. Иногда они готовы мириться с неудобствами в сложных процессах, но теряют самообладание от неочевидных мелочей, а иногда наоборот. Угадать сложно.

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

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

Как изучать: интервью и Job Stories

Для диплома было достаточно провести пять-шесть интервью и на их основе составить с десяток Job Stories.

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

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

Чтобы Job Stories несли пользу, их нужно правильно формулировать:

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

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

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

В первую очередь меня интересовали отправка показаний, оплата счетов и типичные проблемы в общении с управляющей компанией. Полученные сведения я перевёл в формат Job Stories и предположил необходимые функции.

Job Stories для дипломного проекта. На реальных проектах их могут быть сотни

Сбор фич на основе потребностей

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

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

Итоговое продуктовое решение звучало так:

Приложение жильца соберет в одном месте всё, связанное с домом и квартирой, и станет основным каналом коммуникации с управляющей компанией и экстренными службами.

На основе Job Stories и фич конкурентов я собрал полный список функций приложения:

  • передача показаний счетчиков и история потребления
  • оплата квитанций по карте и через платежные сервисы
  • архив квитанций, заявок и обращений в УК
  • автоплатёж
  • напоминания о сроках отправки показаний и оплате квитанций
  • вызов мастера с выбором даты и времени, возможность подбора мастера по описанию проблемы и по типовым ситуациям
  • чат с операторами УК, возможность прикладывать к сообщениям фото и видео
  • экстренная связь с диспетчером аварийных бригад
  • заявки в УК с отслеживанием статуса
  • информирование о предстоящих плановых работах, авариях и чрезвычайных ситуациях
  • опросы и собрания жильцов
  • настраиваемые пуш-сообщения
  • оформление временных пропусков для гостей и курьеров
  • доступ к видеокамерам в подъезде, дворе и парковке
  • управление шлагбаумом и дверями пожарных выходов, кладовыми и другой домовой инфраструктурой
  • справочник по законам и нормам в сфере ЖКХ с релевантным поиском и поисковыми подсказками
  • управление домофоном во дворе и на входной двери
  • профиль пользователя и персональные настройки
  • информация по квартире: план, площадь и размеры комнат, высота потолков, точки подведения коммуникаций

В рамках диплома реализовать всё было нереально, поэтому я взял самые основные:

  • новости и оповещения
  • передачу показаний и оплату квитанций
  • вызов мастера и звонок диспетчеру
  • чат с оператором
  • камеры видеонаблюдения
  • справочник
  • заявления в УК

Далее я нарисовал принципиальные макеты в Миро, продумал Tone of Voice и сел рисовать интерактивный прототип и проводить промежуточные исследования. Об этом будет в следующих частях.

Ссылки

Интерактивный прототип в Фигме. Смотрите в режиме презентации.

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

Все статьи об учебном проекте:

  1. Задачи и результат
  2. Потребности пользователей — вы находитесь здесь
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Бонус трек. Как ставить задачи UX-писателю
 311    Нет комментариев   4 мес   UX   кейс

Заметки беспечного путешественника

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

Всё сделали сами: придумали мир, написали историю, нарисовали иллюстрации и сверстали макет. Нам удалось напечатать небольшой тираж :3

Расскажу, о чём книга, зачем её читать и как мы её создавали. Ну, и где её купить, конечно же.

Глянцевая печать, 143×200 (A5), 96 страниц, клеевой переплёт

О чём книга

Это по-хорошему юмористическое фэнтези, какие пишут по мотивам игр D&D. Немного Толкиена, чуток Пратчетта и горсть отсебятины.

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

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

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

Зачем читать

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

У книги два достоинства: она короткая и в ней три десятка иллюстраций. Некоторые дополняют историю деталями, которых нет в тексте.

Каждый эпизод дополняет иллюстрация

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

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

История

С чего мы решили писать книгу.

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

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

Первая картинка, с которой всё началось. Инктобер-2019, день 28

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

Следующий Инктобер мы целиком посвятили новому походу троицы. Продумали мир и основные события, набросали персонажей и план публикаций.

На марафоне планы разъехались, вылезла куча трудностей и выпускать по эпизоду в день было тяжело. Местами мы отчаянно импровизировали, правили сюжет на ходу и закрывали логические дыры, чем могли. Что из этого вышло, можно посмотреть по тегу #ДневникМелентора.

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

Как купить

ВК-паблик Ulv Vind

Если вы живёте в Уфе — напишите мне в телеграм: @vitalyfilatov

Мы напечатали всего 50 штук, 4 апреля оставалось 37.

Чуть позже сделаем PDF-версию.

 

Над книжкой работали

Ulv Vind — иллюстрации

Я, Виталий — текст и вёрстка

Ирина Малкавиан — корректор

Учебный проект: задачи и результат (часть 1/6)

Рассказываю о своей дипломной работе по курсу Нетологии «UX-писатель». Почитайте, если вам интересно, чем занимаются UX-писатели и с чего можно начать работу над приложением.

Рассказ разбит на шесть частей. Эта часть о курсе, работе UX-писателя, задачах и результате. В конце — ссылки на следующие части и сам диплом.

Чем занимается UX-писатель

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

Как организован курс

UX-писатель — новая профессия, учиться приходится по книгам, статьям и рассылкам. На начало 2021 года в Рунете был только один курс Нетологии, где предлагали систематизировать знания под присмотром практикующих экспертов.

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

Личный кабинет Нетологии. До диплома осталось получить один зачёт

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

Заказчик и его гипотеза

Строительный холдинг «Яркий» всё делает сам: строит дома, продаёт квартиры и управляет коммунальным хозяйством. В «Ярком» считают, что современное жильё — это сервис, и ставят на технологии и автоматизацию. Это привлекает жильцов комфортом, снижает издержки и репутационные риски.

Чтобы жильцам было удобно общаться с управляющей компанией, передавать показания счётчиков и взаимодействовать с домовой инфраструктурой, «Яркий» разрабатывает собственное мобильное приложение жильца — «Яркий Дом».

Для начала заказчик хотел убедиться, что жильцу нужно именно приложение. Его продуктовая гипотеза звучала так:

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

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

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

Задачи

Я решил, что подключился к проекту до начала разработки и совмещаю роли UX-писателя и дизайнера.

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

Дополнительно я составил шаблон постановки задачи UX-писателю, чтобы менеджерам было проще со мной работать.

Подробнее о каждом этапе читайте в следующих статьях цикла.

Результат

Основная задача выполнена — создан прототип приложения на основе потребностей реальных людей.

Стартовый экран, дашборд, вызов мастера и чат с оператором

Проект длился 6 недель. На домашние работы и диплом ушло примерно 45 часов.

Работу похвалила преподаватель курса и мой дипломный руководитель Ирина Моторина, чем я теперь всюду хвастаюсь :3

Фрагмент письма о проверке дипломной работы. В комментариях я извинялся за пропущенную запятую в описании

После защиты я получил свидетельство об обучении. Удостоверение о повышении квалификации всё ещё идёт «Почтой России».

Я учился на шестом потоке, в группе UXCW-6

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

Ссылки

Интерактивный прототип в Фигме, смотрите в режиме презентации

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

Все статьи об учебном проекте:

  1. Задачи и результат — вы находитесь здесь
  2. Потребности пользователей
  3. Основы ToV
  4. Интерактивные макеты
  5. UX-исследование
  6. Как ставить задачи UX-писателю
 313    Нет комментариев   7 мес   UX   кейс

Блог обновился, а дизайн слетел

Если вы вдруг читаете мой блог напрямую, а не через RSS, то вот две новости:

  1. Я обновил движок и открыл комментарии. Раньше они были закрыты из-за ботов. Чтобы высказаться, войдите по учётке Телеграма, Твиттера, ФБ или ВК.
  2. Я не успел перенести старый дизайн на новый движок, так что блог пока побудет со стандартной темой. Ваши комментарии мне важнее.

Новый дизайн планирую прописать как положено, чтобы при следующих обновлениях ничего не переделывать. Подключение авторских тем в Эгее не самое очевидное. Разберусь — расскажу.

В некоторых статях могут сбоить картинки или ссылки. Найдёте такое — напишите, пожалуйста.

Вся драма с обновлениями, кому интересно

В Эгее 2.5 меня не устраивали мелкий текст, широкая колонка и масштабирование на смартфонах. Я нарисовал свой вариант и простоты ради вкрячил его прямо в код движка.

До 2019 всё шло неплохо, но потом спам-боты вконец озверели и стали неистово загаживать блог. Пришлось закрыть комментарии.

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

За пять лет вид блога перестал мне нравиться. Например, пора сменить Open Sans в заголовках на что-то выразительнее. Ну и раньше я рисовал в Фотошопе, а теперь у меня есть Фигма. Новая версия всяко выйдет лучше :3

К сожалению, переехать с версии 2.5 на 2.10 не получилось, что-то заглючило и база отказалась обновляться. К счастью, у меня была тестовая копия блога, которую я успел обновить до 2.9. На неё новая версия встала без проблем. В тестовой базе не хватало пяти статей, так что я опубликовал их заново. Вроде работает.

Очевидные выводы

  1. Костыли выгодны только в краткосрочной перспективе. Потом придётся переделывать.
  2. Отклик читателей важнее дизайна.
  3. Тестовое зеркало сайта — это правильно.
  4. Бэкапы нужны всем и везде.
  5. Проблема может оказаться возможностью, просто нужно читать больше мотивационных книжек.
 130    1 комментарий   8 мес  

Улучшаем Мейлчимп за 15 минут

Мейлчимп — популярный сервис почтовых рассылок. На бесплатном тарифе у него куча ограничений, в том числе на количество отправок тестового письма. Черновик можно отправить только 12 раз, потом Мейлчимп начнет ругаться и намекать. Ограничение вполне разумное, но безразличное отношение Мейлчимпа фрустрирует. Смотрите.

Сначала всё хорошо:

Письмо уходит, вас хвалят:

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

...и предлагают отправить ещё одно.

Вы закрываете окошко, диалог отправки тестовых писем не меняется.

В справке по сервису это ограничение где-то прописано, но я узнал о нём, только когда попытался отправить тринадцатое письмо ещё раз. Мейлчимп дал выбрать адресатов и туманно предложил почитать справку:

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

Если бы Мейлчимп прямо предупреждал о количестве тестовых писем и не давал попыток после превышения лимита, такого впечатления не возникало. Ясная демонстрация лучше передаёт главную идею:

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

Тем более что переменная с количеством попыток у Мейлчимпа уже есть. Её можно добавить двумя строчками кода, а заодно дать ссылку на справку. Например, так (накидал в код-инспекторе, за грамотность не ручаюсь):

Предупреждение в диалоге отправки. Осталось 12 писем
Сообщение об ошибке со ссылкой на справку
Вышли за лимит — почитайте справку

Мораль 01. Объясняйте, что происходит. Для этого не нужно рисовать новые страницы три спринта, достаточно написать под основной кнопкой.

Мораль 02. Если вы забыли вывести какое-то ограничение, пользователь обязательно на него когда-нибудь наткнётся, подумает, что вы специально с ним так, и напишет в бложик. А вы даже не узнаете :3

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

 126    Нет комментариев   8 мес   UX

Буги на Красной Поляне

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

В Сочи нужно прилетать утром, когда восходящее солнце вычерчивает длинные тени на Кавказском хребте, а воздух подернут лёгкой дымкой. Когда летишь лоукостером, есть на что отвлечься от затёкших коленей и зловещего скрипа шпангоутов. Немного успокаивало, что я выбрал Боинг 737-800, который не MAX и падает только от старости. Больше опасений вызывала набирающая обороты пандемия: перспектива попасть в карантин со случайно чихнувшем бурятом пугала абсурдным реализмом.

Зайдя с моря, самолёт пронёсся над просыпающимся Адлером, грузно плюхнулся на полосу и покатил к терминалу, потряхивая крыльями на стыках плит. Кто-то по старой традиции похлопал пилотам, но его не поддержали: появился LTE и обновилась лента.

Где-то над Кавказским хребтом

В Адлере стояло лето. Мягкий ветерок наверняка приносил с моря аромат соли и открывающихся кофеен, но я почти сразу прыгнул в такси, пахнущее отделом парфюмерии. Отсутствие лыж в багаже выдавало во мне делового человека, поэтому таксист кратко ввел меня в курс местных дел:

  1. Снег у моря бывает раз в год, падает ночью и к утру тает.
  2. После дождя дороги становятся чище.
  3. До зимней олимпиады тут ничего не было и дикий лось бродил меж дерев. К олимпиаде построили всё: горнолыжные курорты, трассы, подъёмники, новую дорогу, трамплин для прыжков в длину и бессчётное количество прочего.
  4. Каждый местный знает, что при строительстве трамплина чеченские подрядчики украли семь миллиардов. Сколько было украдено на трёх туннелях для новой дороги — не знает никто.
  5. Красная Поляна находится в селе Эстосадóк, там раньше жили эстонцы, греки и армяне. Теперь там живут московские дачники и уральские нувориши.
  6. Пристёгиваются только приезжие.
  7. Сочи — главный поставщик мимоз. Их собирают в каждом дворе и возят по всей России. Мы проехали двор с чем-то жёлтым, так что причин сомневаться не оставалось.

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

Яндекс-карты предлагают сразу ехать по новой дороге

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

Вид на Эстосадок и Красную поляну на 960 метрах с Вершины 2200

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

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

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

Выйдя из такси, я окунулся в сюр. Десять часов назад я смотрел с балкона, как по пустырю у церкви мусорный пакет гонялся за голубем. Здесь же всё было ярко, громко и вымыто с порошком. Портье в служебном пиджаке излучал корпоративные ценности сети отелей с офисом в Мэриленде. На площади перед канаткой играл Led Zeppelin. Вальяжные люди в лыжных ботинках ходили раскорякой и цокали. Кабинки подъёмника с тихим шелестом уплывали на северный склон Аибги.

В кабинке, едем на 960 по карточкам из отеля

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

Вид на площадь перед канатной дорогой. За площадью видны отели. Обзорная площадка между отелями покрыта вязью Покраса Лампаса

На следующий день мы забрались уже на 2200. Ехали с тремя пересадками: сначала на 960, потом на 1460, потом уже до конечной. В кабинку помещается восемь человек. Чтобы не ехать рандомно, объявляем себя командой по скоростной посадке. Первый раз садимся за 10 секунд, на обратном пути уже 7,5 — по 0,93 секунды на человека.

Чёрная пирамида — вершина в хребте Аибга, 2375 метров. Мы были на вершине справа, её нет в кадре

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

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

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

Игорь приехал первым и объяснил свой отрыв массой мозга

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

Часть команды Девхаба, добравшаяся до Сочи. Фото приглашенного фотографа

После обеда решаем посмотреть подвесной мост через ущелье в Скайпарке. Это огромный комплекс в двадцати минутах от Адлера. Предлагают кучу всего, от тандем-зиплайна до верёвочного парка, но главный аттракцион — прыжки со свободным падением. У начала моста прыгают с 69 метров, в середине — со всех 200. Пока нет желающих, инструкторы прыгают сами.

Вид на начало моста. В павильоне впереди — прыжковая станция на 69 метров

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

Середина моста

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

На четвёртый день экспедиция официально завершилась, команда начала разъезжаться по домам. В аэропорт меня отвозил таксист из Марий Эл, мы разговорились о Казани и культуре массовой застройки. Он спросил, как прошла командировка, а я ответил, что ездил не по работе. И это было чертовски здорово :3

Как написать отзыв о компании

В интернете ожесточённо борются за лайки и отзывы. Компании просят заказчиков, друзей и сотрудников оставлять отзывы всюду, где есть соответствующая форма: на Яндекс-картах, Маркете, Хабре и ещё в десятке мест.

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

Общие правила. Что такое хороший отзыв:

  1. Не хвалите компанию просто так. Пишите конкретику: что бы вам понравилось, будь вы заказчиком или соискателем. Такой отзыв будет честен и поможет другим принять взвешенное решение.
  2. В отзыве можно указывать на слабые стороны. Этим вы покажете, что отзыв настоящий. Главное не пересолить: слабости должны подчеркивать конкурентные преимущества.
  3. Пишите грамотно, избегайте эмодзи и восклицательных знаков. Не пишите капсом. Проверяйте текст спелл-чекерами или покажите вашему редактору. Уверен, он любит такое.
  4. Не пишите много. Достаточно одного-двух простых утверждений. Например, команда работает удалённо, но этого не ощущается.
  5. Не агитируйте. Высока вероятность, что читатель увидит в этом попытку манипуляции и проигнорирует смысл.

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

  1. Что вы хотели получить от взаимодействия с компанией и каким оказался результат?
  2. Для чего обращались? Решили ли свою задачу?
  3. Особенности. Что понравилось и не понравилось?
  4. Кому рекомендуете и не рекомендуете?

На все можно не отвечать, возьмите два-три.

Примеры. Заказчик мог бы написать так:

Грамотные и вежливые ребята (3). Обращался с проектом мобильного приложения под iOS (2), переписали под все платформы и помогли с дизайном интерфейса (1). Работают удаленно, поэтому общение через Скайп и Зум (3). Не рекомендую тем, у кого горит: писать код начинают только после исследования, поэтому за неделю не сделают, нужно закладывать время (4).

А соискатель примерно так:

Искал работу по UX-проектированию, нашел вакансию, решил написать (2). Быстро ответили, выслали тестовое. По результатам не прошел (1), но подробно ответили по тестовому и помогли найти ошибки (3). Попробую ещё раз через полгода.

Добавьте о людях

Зарисовка о писательском ступоре и смыслах. Выводы в конце.

В Девхабе выпустили приложение сервиса Попути и собрали кейс. В черновиках заголовок был такой:

Cервис удалённого заказа кофе на маршруте или в ближайшем заведении

Пока писал остальное, глаз замылился, заголовок казался рабочим. Утром коллеги пришли с критикой: заголовок звучит безграмотно и угловато, как киношный чиновник из села. «На маршруте» — так говорят, вообще? Перечитываю, пугаюсь «ближайшего заведения». Хочется легче и веселее.

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

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

Сервис удалённого заказа кофе для водителей и пешеходов

Вот, теперь хорошо. Было описание функций, стало — перечисление групп пользователей.

Вывод: проблема со словами чаще всего означает проблему со смыслами. Если не получается внятно описать что это, добавьте для кого это.

Картинка Ulv Vind
Ранее Ctrl + ↓
UX