UX — это больно: как мы учились делать дизайн для корпораций
Каждый провал ведёт к улучшениям: рассказали, как увеличили дизайн-команду с 5 до 25 человек и настроили процессы для работы с большими проектами.
Когда у тебя в команде пять человек и вы делаете небольшие проекты, проблем с процессами не возникает: каждый на виду, все сидят за одним столом, задачи можно удержать в голове.
Но в один момент мы поменяли концепцию: слили две компании в одну, отказались от разработки, стали делать только дизайн и UX-исследования, резко выросли до 25 сотрудников. А когда взялись за крупные проекты, начали косячить: и мы, и заказчик. Оказалось, чтобы работать большой командой над масштабными задачами, надо постоянно эволюционировать и оптимизировать процессы.
В основу этого текста лёг наш опыт и ошибки, которые вели к улучшениям. В результате мы в Angry научились быстро согласовывать идеи, доказывать свои решения заказчику и не вносить правки по девяти кругам ада, как это бывает, если ты аутсорсер и работаешь с крупными проектами.
Делимся выводами: они пригодятся тем, кто занимается UX-дизайном, сотрудничает с большими компаниями, хочет поработать с нами или у нас.
Как мы изменили процессы, чтобы работать с корпорациями
В любой сфере дизайнер — не просто человек, который рисует или делает красиво, особенно в финансовых сервисах. Мы продумываем все детали взаимодействия с продуктом — от логики и бизнес-процессов до текстов при взаимодействии с продуктом (SMS, пуши, email). И полностью отвечаем за конечный результат.
Чтобы он получился достойным, приходится лавировать между техническими ограничениями, потребностями пользователей, требованиями бизнеса. Для этого и нужны чёткие правила, к которым мы пришли.
Не берём людей без аналитического склада ума
В UX-дизайне не работает подход без погружения: «Я менеджер, мне всё равно, чем руководить» или «Я продажник: загоню хоть гараж, хоть ракету». Мы на этом обожглись во время расширения: брали перспективных, но неопытных ребят, а они подходили с вопросами каждые 20 минут, выполняли задачи непозволительно долго или слишком поверхностно. В итоге на найме наша компания потеряла 7 млн рублей и четыре месяца.
Опытным путём выяснили: чтобы человек начал разбираться в том, что проектирует (а у нас это финтех и банки), у него должен быть аналитический склад ума и порог вхождения четыре-шесть месяцев. Полагаем, это правило работает в любой сложной сфере.
Составляем пул вопросов для начала работы
С заказчиком важно сразу договориться, кто за что отвечает, чтобы выстроить прозрачный и эффективный процесс. На берегу проекта мы всегда выясняем:
- Есть ли технические требования, которым нужно жёстко следовать? Это важно, чтобы продумать логику сервиса: в одних банках мы делаем проекты с нуля и там полная свобода (ограниченная только техническим прогрессом сферы), а другие банки не планируют изменять бэк-системы и надо это учитывать.
- Кто целевая аудитория? Мы проектируем банки и финансовые сервисы, но у каждого своя стратегия и аудитория: кто-то больше про диджитал, а кто-то идёт в узкий сегмент и делает продукт для непродвинутых пользователей. Мы отстраиваем концепцию от ЦА: продумываем визуальную часть, UX и иллюстрации под аудиторию и восприятие.
- Есть ли дизайн-кит? Узнаём, нужно ли ему жёстко следовать или можно сделать уникальный стиль и свой кит под проект.
Опыт, который нас научил.
Один из наших крупнейших проектов может не выйти в изначальной дизайн-концепции, потому что мы взяли шрифт не из брендбука. В самом начале мы всё защитили и утвердили, три раза отвоевали концепцию и преодолели барьеры заказчика, а на четвёртый раз внутренняя команда продукта решила не воевать с командой бренда.
Пять месяцев работы, много политики и разговоров, несколько защит, и в конце заказчик просто устал протягивать это решение внутри себя — теперь дизайн может выйти с нативным шрифтом из брендбука, который делает дизайн-решение полным дном.
Большие компании — большая политика
В работе с корпорациями нужно понимать, с кем говорить, как убеждать и какими данными оперировать при общении с каждым участником. Например, с юристами и службой безопасности важно знать больше, чем они, — не просто что на практике и у конкурентов, а в каком законе и как это написано. Поэтому в команде должен быть опытный человек, который умеет разговаривать и выстраивать отношения с заказчиком: у нас эту роль выполняет PM.
Сразу договариваемся, за кем последнее слово
Заказчик любит говорить: «А я вот так делаю, а вот этого я не понял» — но это классическая ошибка «проектирования под себя». Вся команда проекта (и клиент, и мы) — погруженные в сферу люди, наши представления резко отличаются от опыта пользователей.
Поэтому теперь перед началом работы мы сразу обозначаем, что UX — область, где на нас полностью можно положиться, а вот в визуальной части можно спорить. И вместо споров о вкусах проводим юзабилити-тест, который проверяет все решения на ЦА.
Устанавливаем сроки работы с правками
Изначально мы работали спринтами — по средам показывали статус по всем задачам и получали комментарии от заказчика. Правда, на правки не было никаких сроков: их оставляли постоянно.
Прибавлялись люди и команды — правки прилетали снова и снова. Они могли повторяться, противоречить друг другу или продукту, иногда их вносили после того, как задача была сдана.
Однажды мы три недели подряд возвращались к правкам на одни и те же задачи: 5 дизайнеров по 12 раз в неделю меняли всякие мелочи. Получалось как в китайской пытке: вода по капле стекала на макушку узнику. Выматывает.
Чем больше компания заказчика, тем больше бесконтрольного хаоса. Поэтому мы придумали систему: в среду показываем проект, а в пятницу утром разбираем правки. У заказчика есть два дня, чтобы всё внести и прийти к единому решению. Сроки дисциплинируют, а со стороны клиента появляется ответственный за комментарии от всех команд. Так работа идёт быстрее, а люди на проекте не выгорают.
Пользуемся чек-листами для внутренних задач
У нас есть чек-листы с правилами работы — они помогают дизайнерам двигаться в хорошем темпе. Мы написали их по четырём блокам:
- Текст: как писать и проверять в интерфейсах — спасибо Ильяхову за доступность контента.
- Типографика — ключевые детали про символы, переносы, сокращения и так далее.
- Дизайн — работа с атомарным китом, компоненты, констрейнсы.
- Проектирование — чек-лист о том, как должен выглядеть прототип и что в нём нельзя терять.
Это основы основ — их точно нужно прописать, чтобы лидер-дизайнеры не тратили своё время, а ребята в команде могли перепроверять друг друга.
Проверяем решения командой проекта
Чтобы быстрее найти ошибки, мы с командой проекта устраиваем ревью на трёх этапах — и вместе смотрим, всё ли в порядке: схема данных, логика, дизайн, коммуникация.
К этой концепции мы тоже пришли через ошибки — большая задача может занимать неделю-две, и, если дизайнер изначально пошёл неправильным путём, он потратит время зря и всё придется начинать заново.
Итак, каждая задача (эпик) проходит через три этапа ревью:
- Разрабатываем инфосхему или бизнес-процесс — когда дизайнер проектирует процесс, он должен понять его логику и весь набор данных: например, в КПП девять цифр, а адреса берутся из справочника КЛАДР. Все детали и ограничения мы прописываем заранее, чтобы не возвращаться к этому при проектировании логики.
Отрисовываем основные экраны. Дизайнер готовит основные экраны и защищает идею перед командой. На них уже видна логика и её можно быстро поправить, не копаясь в других 70 экранах.
Проверяем все состояния всех элементов: проектируем и проверяем сценарии от входа в функциональность до выхода из неё: как если бы очень дотошный пользователь решил настроить и заполнить всё, до чего может дотянуться. Мы назвали эту метафору «пользователь-задрот». Она помогает вжиться в персонажа и детально проверить логику, сценарии и тексты.
Такой отсмотр экономит время и помогает скорректировать отставание, если оно случилось. А ещё увеличивает ответственность и сплачивает команду.
Пишем коммуникационную схему продукта
Правильный текст — половина успеха, именно он задаёт тон продукту. Мы сами пишем тексты по всем каналам взаимодействия с продуктом (пуши, SMS, почта, чат), потому что знаем: 70% всех ошибок в юзабилити-тестах — непонятные формулировки.
На помощь снова приходит Ильяхов и исследования: у нас выстроена система обучения по текстам в интерфейсах с лекциями и домашними заданиями, а благодаря большой базе знаний из UX-исследований мы знаем, на каком языке говорят пользователи, что для них важно и в какой момент.
Текст — это ваш язык общения, от него зависит, как пользователь будет воспринимать компанию и продукт.
Если ты говоришь: «Эй, чувак, сделай свой аккаунт безопаснее», а потом выдаёшь ошибку: «Аутентификация не пройдена» — у пользователя случится когнитивный диссонанс.
Именно так получается, когда дизайнер не продумывает все состояния — альтернативные, негативные, все ошибки и тексты в продукте. И разработчик закрывает эти дыры самостоятельно.
Описываем функциональность
То, что нельзя показать в дизайне или анимации, — должно быть описано. Так в комментариях к отдельным экранам мы рассказываем: что здесь произошло, откуда берутся данные (внешние справочники), как работает сортировка или фильтр. Иногда на основе цифр и пользовательского опыта аргументируем, почему сделали именно так, если решение нестандартно для сферы.
В итоге уже через две недели после старта проекта мы выдаём прототипы, которые помогают техническим аналитикам начать писать ТЗ для разработки, а разработчикам — кодить бэк-процессы.
Это позволяет начать разработку уже на третьей-четвёртой неделе проекта вместо того, чтобы ждать три-четыре месяца, пока он завершится.
Включаем исследования в проект
Раньше мы продавали исследования как дополнительную услугу к дизайну, но потом начали просто включать юзабилити-тест или полноценное исследование в проект. Без них не делаем.
Юзабилити-тест дизайна занимает месяц, но полностью оправдывает свои сроки: даже с нашим опытом попадаются критичные вещи.
Исследование потребности в новом сервисе тоже занимает месяц, но полностью снимает вопрос, нужен ли такой продукт пользователю.
Самый наш любимый пример — про контрастность цвета и текстов: пользователи часто не видят тонкий серый шрифт, который так любят дизайнеры. Ещё всегда вылезает проблема, что люди не понимают некоторые тексты — не критично, но можно улучшить и упростить.
После юзабилити-тестов мы вносим правки, а заказчику показываем по факту: что нашли и изменили, какие практики были удачными и как пользователи воспринимают продукт. Так работа подкрепляется цифрами, фактами, аргументами, и мы не тратим время на споры. А дизайнеры, которые проектировали продукт, присутствуют на тестах и напрямую получают обратную связь о своей работе.
Накапливая знания и цифры о пользовательском опыте, мы обучаемся сами и обучаем заказчика.
Саммари: о чём стоит помнить в работе с большими заказчиками
- Большие компании — большая политика. В команде должен быть опытный специалист, который знает, с кем говорить, как убеждать и какими данными оперировать при общении с каждым участником. Без таких навыков не получится работать с корпорациями.
- Договаривайтесь на берегу — о процессах и ответственных с каждой стороны, о зонах ответственности и принятии решений. Составьте пул вопросов для начала работы, чтобы не упустить важные детали.
- Пропишите чек-листы качества — так команда сможет проверять друг друга и не тратить время лидер-дизайнера на исправление типовых ошибок.
- Учитесь обосновывать, не прогибайтесь в решениях — сначала к вам обратятся за хорошим сервисом, потом будут говорить «а я по-другому работаю». Если согласитесь делать сервис для заказчика, а не для пользователя, в результате получите неудобный продукт. Поэтому аргументируйте: помогут цифры, знания и юзабилити-исследования.
- Помните, что вы в одной команде — ответственность лежит не только на вас, но и на заказчике. И сроки есть как у вас, так и у него. Поэтому чтобы не тратить время на вкусовщину, обозначьте время для правок и закрепите право последнего слова.
Согласен, главное не прогибаться под заказчика, и аргументировать свои решения: помогут цифры, знания и юзабилити-исследования +++
Даже с цифрами это отнимает много времени и нервов ))
Комментарий недоступен
Спасиба :)
Приятно было почитать, только хотелось бы больше живых примеров из вашего опыта, Вообще конечно жалко, что информацию приходится по крупицам вытаскивать с разных ресурсов, в обучение много времени отнимае поиски реально хорошей информации, спасибо за спасательный круг :)
На здоровье :) Живых примеров чего?
Покажите чек-лист для текстов в интерфейсе, пожалуйста? Понимаю, что там на 80% Ильяхов наверняка один, но все же было бы круто - переобуваюсь в ЮХ-райтера.