Зачем нужно это знать?
Я UX-дизайнер в большой продуктовой компании, и я очень не люблю правки, а вы уже пролистываете дальше, потому что «так нельзя, ты не художник» и «ничего нового, никто не любит». Я ценю своих коллег, заказчиков и пользователей. Но 10 этапов согласования макетов, где каждый участник высказывается о том, что ему не нравится в дизайне — это не только сложно, но и нерезультативно. Вместо того, чтобы обсуждать продукт, почему им будут пользоваться, а почему — нет, что важно для пользователя, а что — наши собственные домыслы, мы часто уходим в холивары и обсуждение наших вкусов и предпочтений. Это нормальная история для больших компаний: заинтересованных в продукте лиц много, все хотят сделать что-то достойное или принять участие.
Как при этом дизайнеру выдать качественный результат, не растягивать сроки, не обозлиться на весь мир и не сойти с ума?
Мне помогают эвристики Нильсена, пользовательские исследования, интервьюирование заказчика и UX-артефакты. Об артефактах я вам и расскажу. Мой путь скорее подойдёт UX-ёрам в продуктовых компаниях с большим количеством стейкхолдеров, чем веб-дизайнерам из маленьких студий.
В работе над продуктом у нас участвует от 8 до 20 человек: заказчик (часто несколько представителей клиента), продакт оунер, руководитель проекта, бизнесовый и системный аналитики, верстальщик, фронтэнд и бэкэнд разработчики, тестировщики. Все они имеют свой взгляд на то, над чем они работают: хотят сделать как-то классно (у разных людей понятие «классно» отличается), руководители проектов хотят выдержать сроки и бюджет проекта, продакт оунеры хотят повышения всех метрик сразу, разработчики — писать чистый код.
Какова вероятность, что ваше видение продукта совпадёт с видением всех этих людей? Нулевая.
Если вы думаете, что вы дизайнер, и внешний вид продукта — это только ваша вотчина, вы ошибаетесь. Пара неудачных проектов и проблем в общении с командами и заказчиками приведут вас в чувство или помогут понять, что лучше применить свои навыки в какой-то другой сфере.
В нашей компании обязанность дизайнера — удостовериться, что команда и клиент договорились об ожиданиях. Желательно сделать это до того, как появятся макеты. По макетам разбираться в том, как должен выглядеть и работать продукт бывает уже поздно и больно.
Макеты — это всего лишь вершина айсберга и часть работы дизайнера. За ними лежит ещё очень много вопросов, о которых нужно договориться всей команде.
Артефакты — это решение проблемы: с их помощью мы обсуждаем бизнес-цели и пользовательский опыт, дизайнер может опираться на них при защите проекта как на зафиксированные договорённости. По артефактам могут работать другие дизайнеры и члены команды, потому что в основном артефакты говорят на понятном, человеческом языке, а не на языке графики, бизнес-аналитики или кода. Я изучала артефакты в БВШД и по блогу UX-дизайнера Насти Щебровой (спасибо, Настя!) и активно применяю их в своей работе. Их использование спасло мне много нервов и ускорило разработку многих продуктов (хотя кажется, что должно быть наоборот).
Что такое артефакт?
Артефакт — описание продукта с определённой точки зрения по заданному формату. Он помогает договориться всем участникам процесса, но его не увидит конечный пользователь.
Какие бывают артефакты?
Не все артефакты генерирует дизайнер: часть артефактов делает продакт оунер или другие члены команды. Всё, что не является готовым продуктом, — это артефакт, в том числе и макеты в Фигме, и ТЗ.
Хороший UX-ёр работает с такими артефактами
Не все существующие артефакты могут и должны применяться на проекте. Задача в том, чтобы затратив минимум усилий, максимально прояснить картину для всех участников проекта. С опытом вы сможете оценить, какие артефакты нужно использовать для конкретной задачи. Классно попробовать все: вы поймёте, с чем вам комфортно работать, сколько времени и сил занимает составление того или иного артефакта.
Тем, кто пока не сталкивался с артефактами, я предлагаю схему, которую разработала для себя: составляю персонажа или карту эмпатии, прописываю его сценарии, объединяю сценарии в карты сценариев (если продукт новый) или раскладываю на карте путешествия пользователя (если продуктом уже пользуются). По ним рисуем прототипы, тестируем их, снова прототипируем и тестируем до тех пор, пока не будем довольны результатом.
Персонажи
Описывать персонажей можно по-разному, но как правило они состоят из:
- портрета пользователя: возраст, пол, род деятельности, стиль жизни;
- его проблем, целей и ожиданий по теме нашего продукта;
- описания среды, в которой он находится, и его действий по теме нашего продукта.
Персонажей делают, чтобы:
- лучше понять пользователей: кто они, как они думают, почему они делают то, что делают — и смотреть на продукт через призму их интересов, потребностей и ограничений, а не своих;
- синхронизировать видение продукта внутри команды. До тех пор, пока у нас нет единого представления о тех людях, для которых мы делаем продукт, мы принимаем решения через призму своих когнитивных искажений. «Если это удобно мне, то всем так удобно», — не может служить аргументом в коммерческой разработке, если только вы не делаете продукт для таких же дизайнеров или разработчиков;
- все члены команды, в том числе те, кто с пользователями не общается, помнили, для кого они делают продукт;
- пока вы рисуете персонажа, вы понимаете, на какой выборке людей нужно будет тестировать свои UX-решения.
Персонаж для банковского сервиса, который помогает сравнивать ДМС и продавать их.
Как создать персонаж:
- Соберите гипотезы. Не полагайтесь только на себя или заказчика в этом вопросе. Соберитесь с командой и заказчиком и накидайте основных гипотез о том, для кого делаем продукт. Это займёт около часа.
- Проверьте свои гипотезы. Найдите тех, кто похож на вашего персонажа (среди знакомых или на Фейсбуке, например). Проведите исследовательское интервью: ваши гипотезы подтвердятся (или нет). Выборка для такого интервью — 4-7 человек. На это заложите от 4 часов до 2 дней.
- Дополните персонажа и «продайте» его команде. Соберите все инсайты и дополните своих персонажей. Персонажей может быть несколько, если они сильно отличаются своими желаниями, целями и функциями. Не расписывайте персонажа слишком подробно: вам нужно понять его стиль жизни, желания и цели. Не плодите слишком много персонажей на продукте, потому что вы скорее всего запутаетесь. Очень рекомендую распечатать персонажей и повесить в кабинете: так вся команда будет чаще думать о людях, ради которых работает, и проявлять к ним больше эмпатии. Скорее всего вы справитесь с этим за 2-3 часа.
Сколько времени занимает
Если вам удастся быстро собрать респондентов и провести с ними интервью, то на это уйдёт 1-2 рабочих дня дизайнера.
Подводные камни
Есть проекты, которые направлены на очень широкую аудиторию. Тогда у них либо слишком много персонажей, либо их сложно выделить. Для таких проектов лучше использовать карту эмпатии или джобз ту би дан (дальше расскажу, чем они отличаются).
Метод персонажей хорошо работает, когда вы работаете с понятной аудиторией и рынком. Но когда нужно придумать передовой продукт, открывать новые рынки и делать то, что до вас ещё не делали, метод персонажей приведёт вас к созданию более быстрых лошадей вместо автомобиля.
Если вы не проверяете персонажей и другие свои гипотезы, вы рискуете очень сильно просчитаться. Помните, что любая непроверенная гипотеза — это лишь плод вашего воображения.
«Мужчины и женщины от 16 до 65 с высоким достатком, которым непременно нужен наш продукт» — это не персонаж, это копипаста плохого маркетолога.
Джобз ту би дан
Невозможно строить продукты будущего, ориентируясь только на запросы и ожидания пользователей от существующего продукта. Хорошие метрики и продажи — это лишь состояние рынка на текущий момент. На какие цифры смотрела компания Эпл, когда убирала кнопки клавиатуры со своих телефонов? На что опирался Генри Форд, когда захотел сделать автомобиль в то время, когда все вокруг просили быстрых лошадей? Люди любили лошадей и кнопочные телефоны, но они больше никому не нужны. Чтобы искать прорывные решения, можно использовать джобз ту би дан.
Что такое джобз ту би дан
В джобз ту би дан не думают о пользователях и их желаниях, не проводят ретроспективные исследования. Это проверка бизнес-гипотезы: сейчас этого нет, мы создаём новый рынок. Продукт, который вы создаёте, решает проблему пользователя — «выполняет работу». Пользователи покупают, то есть «нанимают на работу» ваш продукт, чтобы он сделал их жизнь немного счастливее. Условный Иван Васильевич покупает не телефон с кнопками, а возможность быть на связи с близкими, если копнуть поглубже — то и со всем внешним миром.
Зачем нужны джобз ту би дан:
- Правильно определить конкурентов. В реальной жизни пользователи редко выбирают между тем, где поужинать: в Макдональдсе или в Киэфси. В реальной жизни пользователь выбирает между тем, чтобы приготовить дома, заказать продукты с рецептом в сервисе типа Яндекс.Шеф, прийти на ужин к друзьям, сходить в ресторан со своей второй половиной, или вообще пропустить ужин. Пока мы стараемся перегнать КиЭфСи, мы упускаем огромное количество людей, которые ищут решения простой проблемы: а что на ужин?
- Понять мотивации пользователей. Если у пользователя есть проблема, он уже как-то её решает. Если не решает, — значит, проблемы нет. Мы часто сосредотачиваемся на том, как пользователь пользуется продуктом, и пропускаем то, что происходит вне его: как он вообще пришёл к тому, чтобы им воспользоваться.
Как пользователь может решать свою проблему сейчас, и с чем нам нужно работать:
- у него уже есть инструмент, но он им недоволен (например, я пользуюсь Люсид Чартом для составления диаграмм. Диаграммы составляются, но выглядят плохо);
- у него уже есть инструмент, но новый — привлекательнее (я пользуюсь Люсид Чартом, но есть Миро, и им пользуются мои коллеги);
- у него уже есть инструмент, он не очень им доволен, но боится его сменить (я пользуюсь Люсид Чартом, мои диаграммы выглядят плохо, но переходить на Миро и обучаться пользоваться им — боль, время, я сопротивляюсь);
- у него уже есть инструмент, он к нему привязан и больше не ищет решений (я пользуюсь Люсид Чартом, у меня там лежит 100500 диаграмм, я создаю их за 5 минут, они плохо выглядят, но выполняют свою задачу).
Все эти вещи нужно учитывать, и персонажи никак нам в этом не помогут.
Формула джобз ту би дан:
Когда (описание ситуации),
Я хочу (мотивация),
Чтобы (результат).
Пример джобз ту би дан
Познакомьтесь с Олегом Ивановым. Ему 28 лет, он один из двух дизайнеров мобильных приложений под Айос в небольшой продуктовой компании. Каждое утро он пьёт кофе, садится за свой Макбук и делает макеты (хотя сначала, конечно, продумывает персон). Иногда работает в кофейне, 3 раза в год ездит в отпуск. Он знает основы Свифта, учился в Британке. Носит крутые свитшоты и цветные носки, ходит на митапы, а по выходным занимается каллиграфией.
И вот Олег покупает себе Фигму для макетов и Миро для дорожной карты продукта. Почему именно такой набор? Почему не Фотошоп или Скетч плюс Люсидчарт? Повлияла ли на его выбор любовь к кофе, цветным носкам и митапам? Нет, скорее повлияло то, что в Фигме и Миро можно работать командно вместе с коллегой. Вот это «работать командно и одновременно онлайн» — и есть джоб ту би дан.
Если мыслить глобальнее, то дизайнер Олег Иванов покупает себе не просто возможность работать командно над макетами и дорожной картой, а возможность быстро получать обратную связь от коллег и работать удалённо из любой точки мира, а не в офисе — то есть более удобные условия работы.
Пример джоб ту би дан
Как создать джобз ту би дан
Так же, как персонажей:
- Формируем гипотезы по джобз ту би дан;
- Проверяем гипотезы в интервью;
- Анализируем данные;
- Составляем джобз ту би дан;
- Придумываем решения.
Подводные камни
Джоб ту би дан лучше всего делать на инноваторских продуктах, когда у них есть большая степень неизвестности, или когда персонажей не удаётся выделить или их слишком много.
Карта эмпатии
Карта эмпатии — инструмент визуализации идей, позволяющий поставить себя на место пользователя, взглянуть на проблему его глазами.
Может быть использован как в качестве альтернативы персонажам, так и как дополнение к ним. Карта эмпатии представляет собой схему, в центре которой размещается представитель определенного пользовательского сегмента, по разные стороны от него — 4 блока («думаю и чувствую», «говорю и делаю», «вижу», «слышу»). Выводы приводятся в двух дополнительных блоках: «проблемы и болевые точки» и «ценности и достижения».
Пример карты эмпатии
Зачем использовать
- Карта эмпатии поможет составить персонажа.
- Иногда создать персонажа сложно, потому что сложно выделить какой-то общий архетип. Тогда поможет карта эмпатии: люди могут быть разные, а боли и желания у них — одни.
- Для того, чтобы проверить, решает ли текущий продукт проблемы пользователей.
Как создать карту эмпатии
- Тут я обычно начинаю с интервью: боли и цели у людей зачастую неочевидны, лучше спрашивать напрямую. По собранным данным заполняю карту эмпатии.
- Думаю и чувствую. Что беспокоит пользователя? Какими словами он думает о проблеме? Насчет чего сомневается? Эту информацию лучше искать там, где пользователи жалуются: например, на форумах. Если у продукта есть служба поддержки, стоит пообщаться с ее представителями/почитать, что туда пишут пользователи.
- Говорю и делаю. Как пользователь ведет себя публично? Что говорит? Какими способами решает проблему? Как ищет информацию по ней? Эту информацию стоит искать в социальных сетях. Особенно в этом плане полезен Linkedin: там можно относительно легко найти представителей самых разных профессий и изучить, какие события/конференции/обучающие мероприятия они посещают, в каких сообществах состоят, какие вопросы в них поднимают, какими навыками обладают и т.д. и т.п.
- Вижу. На что похожа среда, в которой находится пользователь? С какими предложениями и альтернативами вашему продукту он сталкивается? Источник информации для этого блока — сама система и системы-конкуренты, онлайн и оффлайн реклама, статьи в профессиональных сообществах, официальные обзоры, и т.п.
- Слышу. Как среда, в которой находится пользователь, воздействует на него? Что говорят ему коллеги, знакомые, авторитетные для него источники? Какие медиаканалы имеют влияние на пользователя? В отличие от блока «вижу», информация здесь не обязательно соответствует действительности. Но пользователь ей доверяет. Где искать информацию для этого блока: слухи и мнения на форумах (а собственно из соц. сетей можно узнать, что это за форумы), истории успеха, стереотипы и даже городские легенды.
- Проблемы и болевые точки. Что тревожит пользователя? Чего он опасается? Что может стать причиной того, что он откажется от вашего продукта? Часто источником информации для этого становится блок «Думаю и чувствую». Все эти страхи и сомнения нужно будет развеять, и сделать это можно кучей способов: от «правильного» текста в интерфейсе до индивидуальных консультаций.
- Ценности и достижения. Что поможет пользователю избавиться от проблем и сомнений? За какие возможности продукта он готов платить? Какие ценности мы должны транслировать? Выводы из этого блока влияют на продукт с самых разных сторон: они могут повлечь как мелкие изменения в интерфейсе или в тексте, так и добавление/исключение определенных функциональных особенностей, и иногда — даже изменение в позиционировании продукта.
Выводы
- Артефакты — это способ понять, в одном ли направлении думает команда и договориться самым дешевым и эффективным способом: не на макетах, не в коде, а буквально на словах.
- Артефактов много, нужно подбирать их под свои нужды. Ими может заниматься почти каждый член команды, но обычно — продакт оунер, аналитик и дизайнер.
- В начале проекта классно начинать с персонажей, карты эмпатии или джобз ту би дан.
- Джобз ту би дан хороши, когда у нас инновационный продукт или новый рынок.
- Персонажи отлично подходят для увеличения эмпатии к пользователям у всех членов команды. Их можно повесить в кабинете и апеллировать к их архетипам в спорах.
- Карта эмпатии может помочь в построении персонажей или быть отдельным артефактом, если персонажа составить сложно.
В следующих статьях я расскажу про сценарии, карты сценариев и карты путешествия пользователя, мудбордах и референсных подборках, интервью со стейкхолдерами, отчёты по юзабилити-аудиту, сравнению конкурентов, прототипах, макетах и UI-китах. Если вы примените их на своём продукте, то вы сможете сильно выделиться на фоне других похожих продуктов, потому что они позволяют найти бреши в логике.
Буду очень рада, если вы попробуете поработать с артефактами на практике и поделитесь со мной своими результатами в комментариях.