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