Дизайн
ANGRY
6348

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

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

В закладки
Аудио

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "ANGRY", "author_type": "editor", "tags": ["\u044e\u0437\u0430\u0431\u0438\u043b\u0438\u0442\u0438"], "comments": 27, "likes": 60, "favorites": 263, "is_advertisement": false, "subsite_label": "design", "id": 91429, "is_wide": true, "is_ugc": false, "date": "Thu, 07 Nov 2019 11:53:16 +0300", "is_special": false }
0
{ "id": 91429, "author_id": 389770, "diff_limit": 1000, "urls": {"diff":"\/comments\/91429\/get","add":"\/comments\/91429\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/91429"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199114, "last_count_and_date": null }
27 комментариев
Популярные
По порядку
Написать комментарий...
6

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

Ответить
0

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

Ответить
3

Хорошие вы ребята!

Ответить
0

Спасиба :)

Ответить
2

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

Ответить
0

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

Ответить
1

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

Ответить
0

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

Ответить
2

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

Ответить
1

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

Ответить
2

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

Ответить
2

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

Ответить
1

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

Ответить
2

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

Ответить
1

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

Ответить
1

Полезно, спасибо за статью.

Ответить
–1

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

Ответить
–1

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

Ответить
1

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

Ответить
0

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

Ответить
1

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

Ответить
–1

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

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

Ответить
1

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

Ответить
0

Жду :)

Ответить

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

0

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

Ответить

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

0

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

Ответить

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

0

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

Ответить
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "Article Branding", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cfovx", "p2": "glug" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Баннер в ленте на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "disable": true, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } }, { "id": 20, "label": "Кнопка в сайдбаре", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "cgxmr", "p2": "gnwc" } } } ] { "page_type": "default" }