UX — это больно: как мы учились делать дизайн для корпораций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опыт, который нас научил.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На помощь снова приходит Ильяхов и исследования: у нас выстроена система обучения по текстам в интерфейсах с лекциями и домашними заданиями, а благодаря большой базе знаний из UX-исследований мы знаем, на каком языке говорят пользователи, что для них важно и в какой момент.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласен, главное не прогибаться под заказчика, и аргументировать свои решения: помогут цифры, знания и юзабилити-исследования +++

Ответить
Развернуть ветку
Natalya Sturza

Даже с цифрами это отнимает много времени и нервов ))

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
ANGRY
Автор

Спасиба :)

Ответить
Развернуть ветку
Валерий Корзенников

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

Ответить
Развернуть ветку
Natalya Sturza

На здоровье :) Живых примеров чего? 

Ответить
Развернуть ветку
Валерий Корзенников

Вы расписали технологию и как вы ее используете, хотелось бы услышать историю о том как эти технологии применялись с одним из ваших клиентов, хотя наверное это уже тема новой статьи

Ответить
Развернуть ветку
Natalya Sturza

Хочется больше конкретики и подробностей?
или хочется историй, типа: а вот так наши процессы сработали с вот этой компанией?

Ответить
Развернуть ветку
Валерий Корзенников

В идеале и то и другое))

Ответить
Развернуть ветку
Павел Архипов

Покажите чек-лист для текстов в интерфейсе, пожалуйста? Понимаю, что там на 80% Ильяхов наверняка один, но все же было бы круто - переобуваюсь в ЮХ-райтера.

Ответить
Развернуть ветку
Natalya Sturza

Покажем, следующую статью как раз про первый уровень в текстах пишем ))

Ответить
Развернуть ветку
Павел Архипов

подписался на вас

Ответить
Развернуть ветку
Максим Мостовой

В чем рисуете инфосхему и БП?

Ответить
Развернуть ветку
Natalya Sturza

Рисовали во всем, в том числе в с помощью кита в figma. Сейчас в miro, просто для статьи сделали её посимпатичнее. Очень хочется чтоб в фигме появился плагин для подобных штук

Ответить
Развернуть ветку
Evgeny Troitsky

Спасибо, было интересно почитать. Сами сейчас впервые работаем с крупной компанией, есть боли, которые вы упоминаете, про зоны ответственности. Удачи вам!

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Dmitry Bushkov

Я не понял, это статья или рекламный буклет? Через абзац "мы делаем", "мы отвечаем", "наш опыт", "мы не тратим время". Ильяхова не только важно цитировать, но еще и читать. К тому же, так много написано про важность анализа и планирования; почему автор не использовал те же рекомендации при написании статьи. Рекомендации, несомненно, выстраданы, но они не выходят за рамки любого PMBoK, начиная с первого издания (в смысле все это уже давно продумано и разработано на более высоком уровне). В целом, количество комментариев говорит само за себя. 

Ответить
Развернуть ветку
Kurbatov Sasha

Ребята работают, а значит это уже здорово. Но вы абсолютно правы, похоже на джинсу. Товарищи из ANGRY, а вы видели компании, которые как то по другому работают на рынке услуг? Всему этому уже 100 лет. За статью минус.  

Ответить
Развернуть ветку
Dmitry Bushkov

У меня весьма сложное отношение к "работают значит это здорово". С одной стороны, конечно, люди работают, в силу своих возможностей стараются делать хороший продукт. Это правда хорошо. С другой стороны, я часто вижу банальщину, непрофессионализм и низкий уровень компетентности, особенно на российском рынке, выдаваемые за "мастерство и класс". И тогда мне тяжело сказать "работают и хорошо", потому что у нас половина страны если не "номера один", то как минимум эксперты, а, условно, сделать два одинаковых мотоцикла не можем. Я в итоге сделал выводы сходные с вашими: ребята хотели сделать контент, получилась плохая реклама, а в итоге своими рекомендациями показали свой реальный уровень и экспертизу.

Ответить
Развернуть ветку
Утка-хрутка

Дельно. И какой у вас средний внешний рейт человекочаса?

Ответить
Развернуть ветку
Кирилл Параска

Мы отказались от рейтов по часам, потому что это аутстаф(  Средний чек по проектам в этом году чуть больше 6 млн.

Ответить
Развернуть ветку
Eugen S.

а чем такую работу организуете? 

Что используете?

Ответить
Развернуть ветку
Natalya Sturza

Ты про инструменты и как построили работу с ними?
Вчера думали, что об этом тоже можно написать ))

Ответить
Развернуть ветку
Eugen S.

Жду :)

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Посторонний

Прототипировать будешь? Опробуй https://pidoco.com/, интересна оценка начинающего.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Посторонний

Главная фишка для меня там, возможность составлять интерактивные прототипы, включающие тригеры (например, клик, наведение мышкой, выпадающий список).

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
ANGRY
Автор

Спасибо за мнение :)

Ответить
Развернуть ветку
Читать все 27 комментариев
null