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

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

Позднее Ctrl + ↑

Анализ сайта DocsHouse

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

Продукт и задача

DocsHouse — платформа управления контентом (CSP). Это такая система корпоративного электронного документооборота на открытых библиотеках, микросервисах и облачных решениях.

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

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

Заказчик опередил меня с уточняющими вопросами :3

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

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

На момент анализа сайт выглядел так:

Общее впечатление

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

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

Основные проблемы

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

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

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

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

Например, какую конкретную пользу даёт парадигма CSP? Понятно, что она составляет описание продукта, но термину не хватает наглядного объяснения. Например, парадигма позволяет be agile уже на этапе внедрения.

В преимуществах много общих слов без конкретики. Они сформулированы не в мире читателя, а как некие параметры, не имеющие прямого отношения к его контексту и проблемам.

Иконки слишком абстрактны и не согласуются с текстом

Например, «Современное решение <...>, построенное на открытых технологиях» ничего толком не говорит. Чем открытые технологии лучше проприетарных? Все ли открытые технологии актуальны? Как это помогает в управлении предприятием? Техническому директору это понятно, но финансовому уже нет.

Другой пример: «100% отечественное решение, входит в Реестр ПО, разработано лидером ИТ-рынка компанией ЛАНИТ». Значит ли это, что в коде нет ни одной библиотеки, написанной иностранными разработчиками? Почему тогда используется Vue.js? Что означает 100 % отечественность?

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

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

Что такое Паутина, зачем нужна Связанность, что за Мониторы. Как это поможет мне снять десяток филиалов с иглы Битрикса? — может подумать читатель

Демо-версия ничего не показывает, а предлагает оставить заявку. Это сбивает с толку и не выглядит дорого. Таких кнопок много, все они ведут на форму заявки, а не куда-то, где рассказано подробнее о продукте.

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

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

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

Предлагаемое решение

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

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

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

Можно составить несколько сценариев, под разные типы аудитории: финдиров, техдиров, CEO и т. д. Главная страница будет кратко рассказывать о платформе вообще, а дополнительные страницы — объяснять суть конкретным группам.

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

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

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

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

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

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

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

Проработать мелочи. Согласовать иконки с текстом, убрать со скриншотов неинформативные детали, уделить внимание типографике и вёрстке.

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

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


Анализ и составление отчёта заняли 4 часа, уточнение задачи и согласование ещё полтора.

Заказчик положительно отозвался о результате и переслал мой отчёт маркетингу. Маркетинг согласился с частью выводов, а часть забраковал, как непригодные в B2B. Наверняка из-за упоминания Apple. Сейчас я бы привёл в пример Confluence.

Если вам нужен такой анализ, напишите мне в Телеграм: @vitalyfilatov

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

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

Ситуация

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

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

ВНИМАНИЕ!

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-писателю

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

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

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

UPD. Теперь и на Бусти

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

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

О чём книга

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

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

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

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

Зачем читать

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

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

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

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

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

История

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

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

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

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

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

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

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

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

Как купить

ВК-паблик Ulv Vind

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

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

PDF-версия в ВК-паблике Ulv Vind

 

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

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

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

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

Ранее Ctrl + ↓
UX