Эмпатия или «Я — UX-дизайнер, и... ненастоящий геолог, и еще... немного аудитор»
Часть 1: Запуск эмпатии. Погружение в контекст. Выбор проблемы.
В профессиональных приложениях для UX-дизайнера проект начинается с этапа, когда требуется быстро понять, что нужно пользователю, и начать разговаривать с геологами на их геологическом, с аудиторами на аудиторском. Для этого и нужна эмпатия.
В статье, на примере двух приложений для геологов и аудиторов, расскажу, как я себе представляю эмпатию. Как она помогала мне проектировать совершенно разные по своей философии и инструментам приложения. И о том, зачем мне фреймворки — наборы инструментов и шаблонов, как и где я их использую.
Для кого статья:
Для любого человека, если ты интересуешься как рождаются приложения (любые, не только профессиональные) и хочешь узнать откуда берется креативность — я стараюсь писать человеческим языком и кратко расшифровывать все профессиональные термины прямо в тексте.
Если этого окажется недостаточно для понимания, в конце статьи есть ссылки. «UX-дизайн» все же придется погуглить. А еще в эру ИИ, я бы рекомендовала гулить все и получать краткую выжимку быстро.
Графическому дизайнеру — если ты подумываешь о переходе в продуктовый дизайн — понять стоит оно того или нет.
Начинающему UX-дизайнеру — посмотришь как работает более опытный дизайнер.
Опытному UX-дизайнеру, аналитику и продакт-менеджеру — ну вдруг найдешь у меня инструмент, которым ты еще не пользовался.
Меня зовут Маша Абрамович, я UX-дизайнер и амбассадор дизайнерских фреймворков. Это дизайн-спринты, персоны, карта пути пользователя и другие. Я применяю их всегда — в разных объемах и с разной степенью вовлечения команды, но никогда не пропускаю этот этап. Не начинаю работу с дизайн-макетов — это кажется очевидным, но многие коллеги подтвердят: на практике так бывает не всегда.
Набор фреймворков помогает проявить эмпатию, минимизировать предвзятость и влияние собственного опыта, чтобы выстроить приложение вокруг пользователя (User-Centered Design), максимально учитывая его особенности и цели.
Запускаю эмпатию
Эмпатию, как и креативность, в профессиональных приложениях я запускаю по устоявшемуся уже фреймворку:
- Слушаю профессионалов и гуглю странные слова: «Ачимовка, качки, ежи».
- Расшифровываю аббревиатуры и профессиональный жаргон: «ТЛ, ОН, РБ, КГМ, SIRA, ОПОРА, МУС, СФОЦ».
- Ищу однозначность там, где ее нет: «Концептуальная геологическая модель» — сколько геологов, столько мнений.
- Смотрю референсы: интерфейсы 2007 года или галюционирование от ИИ.
- Читаю то, что рекомендуют профессионалы, ну или пытаюсь читать… : «Справочник по математическим методам в геологии» и «Указание Банка России № 6291-У».
- Переношу инсайты на доски — клею стикеры.
- Почти всегда выясняю, что услышала, увидела и поняла не то, что мне хотели сказать. Мои замечательные пользователи и эксперты поправляют и даже не сердятся, потому что я же ненастоящий геолог и аудитор.
Всё это похоже на изучение иностранного языка: если я в среде, начинаю думать на другом языке.
В остальном, как и в разработке приложений для массового пользователя, применяю фреймворк — Design Sprint Methodology от Google. Он помогает сохранить эмпатию, не потерять фокус на пользователе и не перейти на «тёмную сторону» бизнеса и разработчиков, ведь разработка продукта — многошаговый, кросс-функциональный процесс. В команде у каждого участника своя роль, своя область знаний, а ещё — способность очаровывать и убеждать.
Свою эмпатию я вижу так: «Смотрю на мир или его кусочек глазами другого человека, думаю его мысли и чувствую его чувства». Всё просто.
Профессиональные приложения в этом смысле — лучший тренажёр: из-за отсутствия личного опыта в профессиональной области, я приобрела замечательный навык находиться в режиме слушателя. У меня нет собственных аргументов в пользу того или иного мнения.
Погружаюсь в контекст
На геологе
Геологи нефтегазовой компании разработали методику расчёта и оценки наличия флюида под землёй. Методикой пользовались отдельные эксперты — она довольно сложная и требовала их непосредственного участия. Компания запатентовала методику и хотела сделать из неё продукт. Аналогов на рынке не существовало.
На входе наша команда разработки получила математическую модель на базе байесовской сети и прототип. У прототипа были критичные ограничения по скорости расчётов и недружелюбный интерфейс. Для работы с прототипом всё ещё нужно было привлекать высококлассных экспертов. Наша команда должна была создать продукт, который помогал бы командам геологов разного уровня опыта и экспертизы прорабатывать геологические гипотезы, а высококлассных экспертов привлекать только для усовершенствования методики и консультаций.
На Аудиторе
Компания с многолетней историей, культурой и устоявшимися процессами проводит аудит и оказывает консалтинговые услуги. Организация процесса аудита, документирование и хранение документов происходили в приложении, владелец которого ушёл из России вместе с приложением. Тысяча сотрудников остались без рабочего инструмента. Подходящих аналогов не нашлось. Решили делать свой продукт.
Пришли к нам с задачей сделать «как было раньше», но немного докрутить и улучшить там, где «болело», сделать более современным.
Отличия приложений
Определяем и выбираем проблему
Проблема (Problem Statement) — это краткое описание главной трудности, с которой сталкиваются пользователи. Формулируется по фреймворку: «Я как... (геолог), делаю... (например,наношу на карту), чтобы... (например,рассчитать количество флюида)»
Не стоит путать с Барьерами/болевыми точками — препятствиями, которые мешают пользователю достичь своей цели.
На Геологе
Когда я пришла на Геолога, этап понимания проблемы подходил к концу: уже были проведены глубинные интервью с заказчиком и экспертами-геологами, Персоны были спроектированы. USM (User Story Map – карта пути пользователя) находилась на финальном согласовании. Персоны и USM помогли мне быстро погрузиться в контекст.
За четыре релиза USM и Золотой путь пользователя (Gold Path — самый короткий путь, необходимый для достижения цели) стали длиннее.
Главная причина — влияние внешних интеграций. Геолог — одино из приложений, в составе длинной и сложной цепочки поиска, разведки добычи и переработки нефти и газа. Эти системы сами были на разных этапах разработки и не могли предоставить требования для интеграций. На старте мы только приблизительно понимали какие данные сможем получать на входе, а что передавать дальше.
В последних релизах команды смежных проектов сформулировали и нам пришлось добавить в Геолога дополнительные этапы. От некоторых интеграций мы отказались. И это вторая причина: мы не смогли получать данные из одного из таких приложений — проект по его разработке закрыли, и нам пришлось делать функционал внутри Геолога.
Третья причина — смена команды экспертов от заказчика. В геологии мнение конкретных экспертов играет решающую роль. Цель, которую одни эксперты считали конечной, другие посчитали промежуточной. И мы дополнили нашу USM новым этапом.
Но вначале пути мы, конечно, не знали всего этого — Золотой путь пользователя был определён, и мы взялись за проработку 7 шагов из первоначальной USM.
На Аудиторе
На Аудитор я пришла на старте и провела там 7 месяцев. Моя роль на проекте — UX-лид. Общее количество человек в команде доходило до 18. За 2 релиза мы спроектировали, разработали и вывели приложение 11 сценариев в продакшен.
Эти 11 сценариев заложили фундамент приложения разработка которого активно продолжалась еще 2 года.
Чтобы узнать об аудите и аудиторах, мы провели Глубинные интервью.
Для подготовки и проведения интервью я применяю Когнитивное картирование: намечаю ход беседы (именно беседы) и продумываю тайминг, но не готовлю конкретные вопросы. Такой способ непредсказуем, требует гибкости и импровизации.
Я использую виртуальную доску со стикерами для основных тезисов; стикеры клею прямо во время интервью. Участники видят, что я услышала, и могут поправить меня, если я поняла их неверно. Записываю видео, пересматриваю и дополняю доску новыми стикерами.
Материалы удобно переиспользовать для Аффинити-мэп (Affinity map — карта схожести), где я группирую стикеры всех участников, и для проектирования Персон — обобщенного, реалистичного образа пользователя.
Стикеры из когнитивной карты участника я скопировала в Aффинити-мэп, где сгруппировала их в Problem statement (Утверждения о проблеме) в формате: «Я (как пользователь приложения) хочу (делать что-то), чтобы...».
Меняю цвета стикеров. Розовые и голубые использую для формулирования проблемы. А вот желтые на этапе формулировки проблем я намеренно игнорирую и, более того, когда пользователи на интервью уходят в идеи, я стараюсь выяснить «зачем», чтобы на выходе не получить только «хотелки» с неочевидной целью, к тому же сложные в реализации. Еще мой лайфхак по минимизации «хотелок»: я прошу привести кейсы — реальные примеры ситуаций, когда тот или иной инструмент мог бы быть полезен.
Проблемы в свою очередь группирую в смысловые блоки — часто они становятся этапами USM (карты пути пользователя).
Стикеры из когнитивной карты использую для проектирования профилей персон, например чтобы привести цитату или кейс. Персона — это обобщенный, но реалистичный образ пользователя.
По результатам интервью стало понятно: в аудите регламентируется вообще всё, и аудиторы неукоснительно следуют установленным правилам. Что и понятно: ставки высоки. Это накладывает отпечаток на весь продукт. Если аудитор знает, как надо, очень сложно его в этом разубедить. Они привыкли опираться на букву закона или внутреннего регламента.
Мы выбрали Ключевую персону и сформулировали ее историю и проблему, которую будет решать приложение.
История пользователя и проблема, сформулированные на начальном этапе, сохранялись на протяжении многих релизов. Этапы USM оставались стабильными.
Продукт вышел в продакшен, сильно разросшись вглубь, сохранив при этом основные этапы. Это произошло за счёт уточнения и детализации этапов — особенно это заметно на последних этапах.
Требования к методологической поддержке и хранению данных оказались выше, чем мы планировали, и потребовался отдельный функционал взамен двух существующих инструментов. Требования к методологии и хранению со стороны внешнего регулятора и жёсткая регламентация процессов внутри компании оказались даже выше, чем мы видели это в начале. Мы добавили два отчуждаемых модуля, смогли получить дополнительные ресурсы на разработку, чтобы не двигать сроки выхода в продакшен.
Ещё один фактор, повлиявший на предсказуемость разработки, – это стабильность команды заказчика. Руководство не менялось, группа экспертов не меняла подходов.
Интересный факт, что команда заказчика всё больше и больше проникалась продуктовым итерационным подходом к разработке. Т. е. эмпатия начинала работать в обе стороны – они понимали, как работаем мы, а мы всё больше погружались в их язык и профессиональную культуру.
Отличия приложений
Завершаю Часть 1, в ней я рассказала, как запускаю эмпатию и какими фреймворками пользуюсь на этапе понимания и определения проблемы. Я постаралась показать на скриншотах, что фреймворки — это лишь модель для запуска креативности, а используемые артефакты — только рекомендуемая форма. Главное в них — это скорость, сфокусированность и возможность выровнять понимание внутри команды.
Как только я понимаю, что бизнес-заказчик, команда и я мыслим в одном направлении и все одинаково видим, куда двигаться дальше, я «бросаю» артефакт. На скриншотах видно, что элементы не расставлены «по линеечке» и я не заморачивалась красивыми графическими решениями — оставляю это для макетов и прототипов. Мне не зазорно не иметь ни одной красивой и аккуратной USM или CJM.
В Части 2 расскажу о роли эмпатии на этапах генерации и выбора идей.
Ссылки на фреймворки и артефакты, которые я упоминаю: