Автор: Юлия Цапок, Senior UX-desinger в компании Promodo. Более шести лет опыта в проектировании систем онлайн-платежей, бронирования билетов (ж/а, авиа), интернет банкингов, информационных ресурсов. Работала над e-commerce проектами ведущих компаний Украины (Rozetka, Mobilluck, Золотой век и др.).
Какой бы информационный продукт вы ни создавали или улучшали, рано или поздно возникнет вопрос — а что в результате увидят пользователи?
Когда нет отлаженного процесса разработки, и отсутствует компетентный специалист, обычно прибегают к следующим ложным решениям:
Руководитель компании решает, что должны видеть пользователи.
Он по себе оценивает, что удобно и привлекательно. Однако этот подход может быть правильным только в одном случае – если главным пользователем продукта будет сам директор. Во всех других случаях — это ошибочное решение, поскольку ЦА продукта обычно сильно отличается от директора.
Также начальству часто бывает сложно противоречить, а значит невозможно вести конструктивный диалог и, следовательно, принимать взвешенные решения.
Внешний вид и функционал продукта – компиляция из решений «позаимствованных» у конкурентов.
Изучать рынок и конкурентов необходимо, но наследование «в лоб» понравившихся фишек, внешнего вида может принести вам массу проблем. Главные из них: стать безликим клоном, а также скопировать и ошибки вместе с хорошими решениями.
Отдавать интерфейсы на откуп дизайнерам или разработчикам без опыта проектирования.
В этом подходе плохо то, что людям с «профдеформацией» сложно при принятии решений абстрагироваться от своих представлений об удобстве и красоте. Программистов не пугают сложные настраиваемые системы, а дизайнеры готовы внедрять бесполезные экраны и функции ради красоты и анимации.
Думаю, многие из вас смогут вспомнить другие проблемные пути создания интерфейсов – их тысячи. Но я искренне верю, что, даже не занимаясь полноценным проектированием, можно заботиться о своих пользователях и создавать продукты для людей.
В этой статье я не буду рассматривать классический путь проектирования интерфейсов, поскольку его невозможно корректно описать в рамках одной статьи. Также постараюсь обойтись без модной терминологии, а-ля user centered design, empathy map, service design и так далее. Поскольку залог хорошего продукта — это здравый смысл, понимание целей и задач вашего бизнеса в рамках создаваемого продукта и умение отказаться от амбиций в пользу счастья ваших пользователей. Описанная методика поможет командам стартапов, дизайнерам, разработчикам и всем тем, кто не является UX-дизайнером, но хотел бы взглянуть на разрабатываемый продукт с точки зрения его конечных потребителей.
Дополнительно повторю, думая о пользователях, важно отказаться от личных амбиций. Это сложнее, чем кажется на первый взгляд. Когда команда не работает над проектом, а занимается выяснением кто из них умнее, лучше, опытнее — это сильно затягивает сроки, ухудшает результат, а что там на самом деле нужно пользователям никого не волнует.
Теперь продолжаем. Сильно упрощенный процесс проектирования опыта взаимодействия пользователей состоит из трех этапов:
1. Гипотеза (решается что, для кого и зачем создается, определяем критерии эффективности)
2. Реализация (работа над созданием продукта)
3. Проверка (измеряется эффективность и решается что нужно улучшать)
На этапе гипотезы и происходит проектирование. Вне зависимости от проработанности этого процесса важно помнить о следующем:
1. Проектирование всегда является первым этапом в создании продукта.
2. Проектирование — это всегда о пользователях.
3. Проектирование — это не отдельные экраны или функции, это процесс.
Приступать к проектированию следует с определения целевой аудитории продукта.
Удачно, что в большинстве случаев создается не уникальный продукт, а аудиторией является массовый потребитель. Например, создавая интернет-магазин, нет необходимости подстраиваться под индивидуальные особенности пользователей, важно найти универсальные решения, понятные большинству.
Соответственно, в этом случае можно пренебречь созданием персон, а ограничиться составлением списка задач.
Где взять задачи:
1. Общение со знакомыми. Люди, которые потенциально могут пользоваться вашим продуктом или пользуются продуктами конкурентов, возможно, натолкнут вас на интересные идеи.
2. Служба поддержки. Если бизнес существовал до создания продукта или была его предыдущая версия — обязательно поговорите со службой поддержки и менеджерами. Проблемы и вопросы пользователей (клиентов) — это то, что нужно учесть обязательно
3. Брейн шторм с командой. Можно предлагать самые дурацкие задачи.
Все полученные задачи собираются в один список, похожие задачи объединяются в одну и, по возможности, обезличиваются.
Например, для сервиса доставки разливного крафтового пива задачи «хочу светлого пива» и «хочу темного пива», объединяются в задачу «хочу пива с определенными параметрами». Однако, к ним нельзя примешивать задачу «хочу самого горького пива» — это уже задача «хочу особенного пива».
Далее, чтобы проверить, учтены ли основные задачи, их можно разбить на четыре группы:
1. Эмоциональные формализованные («Ищу ближайший ко мне ресторан с уютным интерьером»)
2. Эмоциональные неформализованные («Хочу почитать что-то интересное»)
3. Рациональные формализованные («Ищу телефон с процессором на 8 ядер»)
4. Рациональные неформализованные («Ищу подарок рыбаку»)
Оптимально, чтобы задачи равномерно распределялись по все четырем группам. Если в одной из групп собралось, например, 10 задач, а в других по одной, то имеет смысл повторить процесс поиска задач с акцентом на недостающие группы.
Не стоит думать, что ваш продукт уникален и, ему, например, не нужны эмоциональные задачи. Даже часы на руке не только показывают время (рациональная задача), но должны нравиться, и являться частью вашего имиджа (эмоции).
Итак, получен список основных задач, для решения которых пользователи могут обращаться к продукту, и, тем самым выполнять целевые действия для бизнеса.
Но это еще не все — необходимо учесть сопутствующие задачи, которые возникают у пользователей в ходе вовлечения в процесс решения основных задач, взаимодействия с продуктом. Например, если пользователь хочет купить товар на сайте, то у него возникает необходимость узнать об условиях доставки, оплаты. Если пользователь обратился к биллинговой системе и хочет совершить платеж, то его волнует размер комиссии, безопасность данных.
Если у бизнеса, есть задачи, не пересекающиеся с задачами пользователей, то их тоже нужно перечислить. Например, повысить узнаваемость бренда.
Итого мы имеем три списка задач:
1. Основные задачи пользователей
2. Сопутствующие задачи
3. Задачи бизнеса
Далее для каждого вида задач в списке необходимо определить приоритет и то, как она будет решаться. Приоритет позволяет ранжировать задачи и определить, какие из них должны решаться наиболее просто, а процесс решения быть максимально очевидным, а от каких задач и вовсе можно отказаться.
Приоритет задачи формируется из 3-х факторов:
1. Важность для бизнеса. Например, задача, приносящая прямую прибыль (покупка товара), важнее, чем задача, формирующая положительный имидж компании.
2. Популярность у пользователей (чем большее число пользователей будет обращаться к продукту для решения данной задачи — тем она важнее)
3. Блокирующие задачи — задачи, без решения которых, затруднено решение задач из предыдущих двух пунктов.
Теперь важно, хотя бы для приоритетных задач, проделать анализ лучших практик (бенчмаркинг), причем это могут быть не только продукты конкурентов, но и просто продукты со схожим функционалом или схожей тематики.
Качество конкурентного продукта определяется за счет решения с его помощью ключевых задач вашего проекта. Полученный опыт в виде проблем и решений — то, что необходимо учесть уже в своем продукте.
Важно фиксировать найденные интерфейсные решения и сопоставлять их с задачами проектируемого. Для задач, которые не тестировались на продуктах конкурентов, можно просто указать с помощью чего их можно решать (справочный текст, пункт меню, некий функциональный элемент).
Далее для задач, где это возможно, прописываются экраны, на которых они будут решаться. Некоторые задачи будут требовать несколько экранов (например, процесс перевода средств с одной карты на другую), а у некоторых экраны будут повторяться.
Собрав всю информацию воедино «задача – решение – экран», создается пул данных, на основании которых можно приступать к практической работе над продуктом. Перечень экранов позволяет сформировать информационную архитектуру продукта, а описание решений — понимать наполнение экранов и, соответственно, создавать прототипы и дизайн страниц.
Ключевой результат аналитической проработки задач пользователей — это осмысленный подход к созданию проекта. Каждое решение: функционал, экран — имеют обоснование в виде задачи пользователя, а значит, у всех участников проектной команды будет понимание, почему продукт именно такой. Также, это позволяет уйти от аргументов для решений «нравится/не нравится» и перевести большинство дискуссий в конструктивное русло.
