Когда у тебя в команде пять человек и вы делаете небольшие проекты, проблем с процессами не возникает: каждый на виду, все сидят за одним столом, задачи можно удержать в голове.

Но в один момент мы поменяли концепцию: слили две компании в одну, отказались от разработки, стали делать только дизайн и UX-исследования, резко выросли до 25 сотрудников. А когда взялись за крупные проекты, начали косячить: и мы, и заказчик. Оказалось, чтобы работать большой командой над масштабными задачами, надо постоянно эволюционировать и оптимизировать процессы.

В основу этого текста лёг наш опыт и ошибки, которые вели к улучшениям. В результате мы в Angry научились быстро согласовывать идеи, доказывать свои решения заказчику и не вносить правки по девяти кругам ада, как это бывает, если ты аутсорсер и работаешь с крупными проектами.

Как мы изменили процессы, чтобы работать с корпорациями

В любой сфере дизайнер — не просто человек, который рисует или делает красиво, особенно в финансовых сервисах. Мы продумываем все детали взаимодействия с продуктом — от логики и бизнес-процессов до текстов при взаимодействии с продуктом (SMS, пуши, email). И полностью отвечаем за конечный результат.

Чтобы он получился достойным, приходится лавировать между техническими ограничениями, потребностями пользователей, требованиями бизнеса. Для этого и нужны чёткие правила, к которым мы пришли.

Не берём людей без аналитического склада ума

В UX-дизайне не работает подход без погружения: «Я менеджер, мне всё равно, чем руководить» или «Я продажник: загоню хоть гараж, хоть ракету». Мы на этом обожглись во время расширения: брали перспективных, но неопытных ребят, а они подходили с вопросами каждые 20 минут, выполняли задачи непозволительно долго или слишком поверхностно. В итоге на найме наша компания потеряла 7 млн рублей и четыре месяца.

Опытным путём выяснили: чтобы человек начал разбираться в том, что проектирует (а у нас это финтех и банки), у него должен быть аналитический склад ума и порог вхождения четыре-шесть месяцев. Полагаем, это правило работает в любой сложной сфере.

Составляем пул вопросов для начала работы

С заказчиком важно сразу договориться, кто за что отвечает, чтобы выстроить прозрачный и эффективный процесс. На берегу проекта мы всегда выясняем:

• Есть ли технические требования, которым нужно жёстко следовать? Это важно, чтобы продумать логику сервиса: в одних банках мы делаем проекты с нуля и там полная свобода (ограниченная только техническим прогрессом сферы), а другие банки не планируют изменять бэк-системы и надо это учитывать.
• Кто целевая аудитория? Мы проектируем банки и финансовые сервисы, но у каждого своя стратегия и аудитория: кто-то больше про диджитал, а кто-то идёт в узкий сегмент и делает продукт для непродвинутых пользователей. Мы отстраиваем концепцию от ЦА: продумываем визуальную часть, UX и иллюстрации под аудиторию и восприятие.
• Есть ли дизайн-кит? Узнаём, нужно ли ему жёстко следовать или можно сделать уникальный стиль и свой кит под проект.

Большие компании — большая политика

В работе с корпорациями нужно понимать, с кем говорить, как убеждать и какими данными оперировать при общении с каждым участником. Например, с юристами и службой безопасности важно знать больше, чем они, — не просто что на практике и у конкурентов, а в каком законе и как это написано. Поэтому в команде должен быть опытный человек, который умеет разговаривать и выстраивать отношения с заказчиком: у нас эту роль выполняет PM.

Сразу договариваемся, за кем последнее слово

Заказчик любит говорить: «А я вот так делаю, а вот этого я не понял» — но это классическая ошибка «проектирования под себя». Вся команда проекта (и клиент, и мы) — погруженные в сферу люди, наши представления резко отличаются от опыта пользователей.

Поэтому теперь перед началом работы мы сразу обозначаем, что UX — область, где на нас полностью можно положиться, а вот в визуальной части можно спорить. И вместо споров о вкусах проводим юзабилити-тест, который проверяет все решения на ЦА.

Устанавливаем сроки работы с правками

Изначально мы работали спринтами — по средам показывали статус по всем задачам и получали комментарии от заказчика. Правда, на правки не было никаких сроков: их оставляли постоянно.

Прибавлялись люди и команды — правки прилетали снова и снова. Они могли повторяться, противоречить друг другу или продукту, иногда их вносили после того, как задача была сдана.

Однажды мы три недели подряд возвращались к правкам на одни и те же задачи: 5 дизайнеров по 12 раз в неделю меняли всякие мелочи. Получалось как в китайской пытке: вода по капле стекала на макушку узнику. Выматывает.

Чем больше компания заказчика, тем больше бесконтрольного хаоса. Поэтому мы придумали систему: в среду показываем проект, а в пятницу утром разбираем правки. У заказчика есть два дня, чтобы всё внести и прийти к единому решению. Сроки дисциплинируют, а со стороны клиента появляется ответственный за комментарии от всех команд. Так работа идёт быстрее, а люди на проекте не выгорают.

Пользуемся чек-листами для внутренних задач

У нас есть чек-листы с правилами работы — они помогают дизайнерам двигаться в хорошем темпе. Мы написали их по четырём блокам:

• Текст: как писать и проверять в интерфейсах 
• Типографика — ключевые детали про символы, переносы, сокращения и так далее.
• Дизайн — работа с атомарным китом, компоненты, констрейнсы.
• Проектирование — чек-лист о том, как должен выглядеть прототип и что в нём нельзя терять.

Это основы основ — их точно нужно прописать, чтобы лидер-дизайнеры не тратили своё время, а ребята в команде могли перепроверять друг друга.

Проверяем решения командой проекта

Чтобы быстрее найти ошибки, мы с командой проекта устраиваем ревью на трёх этапах — и вместе смотрим, всё ли в порядке: схема данных, логика, дизайн, коммуникация.

К этой концепции мы тоже пришли через ошибки — большая задача может занимать неделю-две, и, если дизайнер изначально пошёл неправильным путём, он потратит время зря и всё придется начинать заново.

Итак, каждая задача (эпик) проходит через три этапа ревью:

• Разрабатываем инфосхему или бизнес-процесс — когда дизайнер проектирует процесс, он должен понять его логику и весь набор данных: например, в КПП девять цифр, а адреса берутся из справочника КЛАДР. Все детали и ограничения мы прописываем заранее, чтобы не возвращаться к этому при проектировании логики.
• Отрисовываем основные экраны. Дизайнер готовит основные экраны и защищает идею перед командой. На них уже видна логика и её можно быстро поправить, не копаясь в других 70 экранах.
• Проверяем все состояния всех элементов: проектируем и проверяем сценарии от входа в функциональность до выхода из неё: как если бы очень дотошный пользователь решил настроить и заполнить всё, до чего может дотянуться. Мы назвали эту метафору «пользователь-задрот». Она помогает вжиться в персонажа и детально проверить логику, сценарии и тексты.

Такой отсмотр экономит время и помогает скорректировать отставание, если оно случилось. А ещё увеличивает ответственность и сплачивает команду.

Пишем коммуникационную схему продукта

Правильный текст — половина успеха, именно он задаёт тон продукту. Мы сами пишем тексты по всем каналам взаимодействия с продуктом (пуши, SMS, почта, чат), потому что знаем: 70% всех ошибок в юзабилити-тестах — непонятные формулировки.

Текст — это ваш язык общения, от него зависит, как пользователь будет воспринимать компанию и продукт.

Если ты говоришь: «Эй, чувак, сделай свой аккаунт безопаснее», а потом выдаёшь ошибку: «Аутентификация не пройдена» — у пользователя случится когнитивный диссонанс.

Именно так получается, когда дизайнер не продумывает все состояния — альтернативные, негативные, все ошибки и тексты в продукте. И разработчик закрывает эти дыры самостоятельно.

Описываем функциональность

То, что нельзя показать в дизайне или анимации, — должно быть описано. Так в комментариях к отдельным экранам мы рассказываем: что здесь произошло, откуда берутся данные (внешние справочники), как работает сортировка или фильтр. Иногда на основе цифр и пользовательского опыта аргументируем, почему сделали именно так, если решение нестандартно для сферы.

В итоге уже через две недели после старта проекта мы выдаём прототипы, которые помогают техническим аналитикам начать писать ТЗ для разработки, а разработчикам — кодить бэк-процессы.

Это позволяет начать разработку уже на третьей-четвёртой неделе проекта вместо того, чтобы ждать три-четыре месяца, пока он завершится.

Включаем исследования в проект

Раньше мы продавали исследования как дополнительную услугу к дизайну, но потом начали просто включать юзабилити-тест или полноценное исследование в проект. Без них не делаем.

Юзабилити-тест дизайна занимает месяц, но полностью оправдывает свои сроки: даже с нашим опытом попадаются критичные вещи.

Исследование потребности в новом сервисе тоже занимает месяц, но полностью снимает вопрос, нужен ли такой продукт пользователю.

Самый наш любимый пример — про контрастность цвета и текстов: пользователи часто не видят тонкий серый шрифт, который так любят дизайнеры. Ещё всегда вылезает проблема, что люди не понимают некоторые тексты — не критично, но можно улучшить и упростить.

После юзабилити-тестов мы вносим правки, а заказчику показываем по факту: что нашли и изменили, какие практики были удачными и как пользователи воспринимают продукт. Так работа подкрепляется цифрами, фактами, аргументами, и мы не тратим время на споры. А дизайнеры, которые проектировали продукт, присутствуют на тестах и напрямую получают обратную связь о своей работе.

Накапливая знания и цифры о пользовательском опыте, мы обучаемся сами и обучаем заказчика.

Саммари: о чём стоит помнить в работе с большими заказчиками

1. Большие компании — большая политика. В команде должен быть опытный специалист, который знает, с кем говорить, как убеждать и какими данными оперировать при общении с каждым участником. Без таких навыков не получится работать с корпорациями.
2. Договаривайтесь на берегу — о процессах и ответственных с каждой стороны, о зонах ответственности и принятии решений. Составьте пул вопросов для начала работы, чтобы не упустить важные детали.
3. Пропишите чек-листы качества — так команда сможет проверять друг друга и не тратить время лидер-дизайнера на исправление типовых ошибок.
4. Учитесь обосновывать, не прогибайтесь в решениях — сначала к вам обратятся за хорошим сервисом, потом будут говорить «а я по-другому работаю». Если согласитесь делать сервис для заказчика, а не для пользователя, в результате получите неудобный продукт. Поэтому аргументируйте: помогут цифры, знания и юзабилити-исследования.
5. Помните, что вы в одной команде — ответственность лежит не только на вас, но и на заказчике. И сроки есть как у вас, так и у него. Поэтому чтобы не тратить время на вкусовщину, обозначьте время для правок и закрепите право последнего слова.