Последние два года я работаю продуктовым дизайнером в отделе управления частным капиталом крупного банка North American. Меня часто спрашивают: каково это быть дизайнером в банке? Как строится процесс работы? Есть ли у меня опыт применения Agile? Сегодня я постараюсь ответить на все вопросы, рассказав одну увлекательную историю:
Что сложного в работе UX-дизайнера в крупной компании
Прежде всего, хочу рассказать, с какими сложностями мне, как UX-дизайнеру постоянно приходится сталкиваться, работая в корпорации.
1. UX против Agile
Все продуктовые команды, в которых мне довелось работать, используют методологию Agile. Но мне кажется, что UX-дизайн не совсем вписывается во вселенную Agile. Дизайн нельзя просто взять и преобразовать в код и алгоритмы. В дизайне зачастую нет точных решений под возникающие проблемы.
На воркшопах по дизайн-мышлению, пользовательским исследованиям, исследованиям рынка и т.п. UX-дизайн обычно прорабатывают в процессе одного большого “спринта 0”, а потом отмечают галочкой и редко к нему возвращаются в ходе следующих релизов. В результате продуктовые команды выпускают функцию за функцией, не особо задумываясь о качестве пользовательского опыта. То есть пока мы концентрируемся на проектировании краткосрочных проектов, по продукту в целом накапливается “дизайнерский долг”.
2. Образ мышления
Молодые и активные финтех компании откусывают все более крупные куски от пирога под названием “финансовая индустрия”, и корпорации — в попытке угнаться за уплывающим рынком — все активнее внедряют цифровые технологи. Одна из мер, к которым они прибегают — найм все большего количества дизайнеров.
Нам, UX-ерам, как “дочернему предприятию” дизайна, приходится постоянно доказывать свою значимость и важность.
Как переключить образ мышления с A на B?
A — “Вот список требований. Сделайте красиво!”
Дизайнер = инструмент визуального дизайна
В — “Есть такая проблема: …. Сделайте что-то, что решит проблему!”
Дизайнер = специалист по решению проблем
Я уверена, что с такими сложностями дизайнеры сталкиваются во всех сферах. Изменить образ мышления коллег по отношению к дизайну очень сложно. Как дизайнер с активной профессиональной позицией, я всегда рвусь в бой, отстаиваю интересы пользователей и не соглашаюсь на решения, которые удобны компании, но не пользователям.
Как я проектировала UX в банке — по уму
Моя история началась с огромного списка запросов по функционалу. Он пришел мне на почту однажды утром, когда я как раз наслаждалась чашкой кофе в лучах теплого солнца. Перед глазами сразу нарисовались две дороги, по которым я могла пойти в контексте этой задачи:
Дорога 1: Сделать что-нибудь по-быстрому → Показать заказчику → Умыть руки
Дорога 2: Провести интервью с представителями компании и с пользователями → Понять проблему → Проанализировать конкурентов → Оптимизировать информационную архитектуру → Наметить путь пользователя → Исследовать возможности → Провести несколько итераций по разработке дизайна → Собрать прототип и протестировать на пользователях
Делать или не делать — вот в чем вопрос. На этот раз я решила выбрать извилистую дорожку: сделать все по уму и продемонстрировать всем ценность UX-дизайна.
Процесс и сроки
Дизайн — это поиск выхода из неопределенности. Проще говоря, это как вязать свитер. Все начинается с одного спутанного клубка шерсти. Прежде всего, нужно понять, где именно нитка запуталась. Потом можно придумать несколько способов распутать узел. Потом нужно распутать другие узлы — на клубках из других цветов и материалов. И в итоге, из этих ниток получится отличный свитер.
Я основывалась на дизайн-процессе, который мы сформировали с моим руководителем, и также учитывала временные рамки по проекту. У меня получился план на 8 дней в формате временной шкалы с ключевыми результатами по каждому этапу.
1. Выявить проблему — 2 дня
UX находится на пересечении целей бизнеса и целей пользователей. Задача UX-дизайнера — не только понять пользователей, но и погрузиться в тонкости бизнеса, чтобы максимально увеличить площадь этого пересечения. Очень часто дизайнеры работают над продуктом, не имея никакого представления о бизнес-стратегии компании. В результате они вынуждены действовать строго в размах требований, полученных от заказчика, а не придумывать лучшие решения.
1.1 Интервью с представителями бизнеса
Общение — ключ ко всему. В нашем случае, основная задача общения с представителями бизнеса — понять цели бизнеса и собрать гипотезы о пользователях. Вот какие вопросы я задавала в ходе интервью:
- Какую проблему мы намерены решить? Почему?
- С какими сложностями мы столкнулись на данный момент?
- Какие цели в приоритете, а какие вторичны? Пожалуйста, расскажите и о краткосрочных, и о долгосрочных целях.
- С какими проблемами чаще всего сталкиваются пользователи?
- Что мы точно знаем о наших пользователях?
- Какой исход по проекту лично вы назвали бы успешным?
1.2 Интервью с пользователями и сортировка карт
В ходе пользовательских интервью, я задавала те вопросы, которые приоткрывали контекст и помогали понять, почему пользователи ведут себя определенным образом. Эта информация нужна, чтобы правильно определить цели пользователей и подтвердить (или опровергнуть) гипотезы. Вот несколько примеров вопросов:
- Как вы сейчас поступаете, когда возникает эта [проблема/задача]? Пожалуйста, расскажите по шагам.
- Что самое неприятное в текущем алгоритме действий? Почему?
- Какие еще инструменты вы используете, параллельно с [продуктом X]? Как вы их применяете?
- Что вы делаете, чтобы упростить процесс? Вы пробовали какие-нибудь альтернативные подходы?
Большинство методов глубокого исследования основываются на анализе поведения пользователей, а не на интервью — ведь то, что человек говорит, очень часто разительно отличается от того, что он делает.
И все же некоторые альтернативные методы, основанные на самоанализе, тоже могут быть полезны при проектировании. Например, сортировка карт помогает лучше понять ментальную модель пользователей и, как результат, оптимизировать информационную архитектуру продуктов.
После интервью, я провела сессию по сортировке карт на основании моего списка запросов по функционалу. Я просила пользователей разложить карты по группам “обязательно”, “желательно” и “неплохо бы” и приоритизировать. Обработав все результаты, я собрала диаграммы информационной архитектуры, чтобы визуализировать скелет продукта.