Аргументы и правки: как защитить UX-дизайн перед заказчиком

Рассказали про систему защиты, которая помогает отстоять до 80% функциональных решений и не прогибаться под градом правок. В статье — о том, как аргументировать позицию и передать заказчикам часть своей экспертизы.

Они отвергают идеи, закидывают правками, не прислушиваются даже к самым резонным аргументам. Убедить их так трудно, что вы сдаётесь и говорите: «ОК, сделаем». Знакомо каждому, кто работает с крупными заказчиками.

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

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

Начнём с пяти правил, которых придерживаемся в работе.

Год назад мы брали все приходящие проекты, но потом поняли, что лучше быть небольшой компанией и делать 12 сложных продуктов в год, чем распыляться на мелкие и неинтересные задачи. Сейчас работаем только с банками из топ-20 и финансовыми проектами.

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

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

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

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

Но бывает, что цифр недостаточно, поэтому в течение проекта собираем спорные моменты и в финале проверяем на юзабилити-тестировании, которое всегда входит в проект.

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

Результаты юзабилити-теста — самый валидный аргумент на данном этапе. Правильно = удобно и понятно для пользователя, поэтому финальные правки оставляем за ним.

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

Проджект участвует во всех этапах проектирования решений. Например, присутствует на ревью, где дизайнер защищает свою задачу перед командой.

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

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

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

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

Найти взаимопонимание помогает прозрачный дизайн-процесс. Мы не раз убеждались, что если показать бенчмаркинг по текущей ситуации на рынке и подобрать аргументы, то заказчики попадают в контекст и начинают смотреть на дизайн-концепцию не с точки зрения «ой, красиво», а с позиции «я понимаю, зачем приняты такие решения».

Для защиты дизайн-концепции мобильного приложения я наравне с дизайнерами читала про тренды управления одним пальцем и thumb driven design, а затем рассказывала теорию о том, как люди управляют телефоном.
Я всегда готова объяснить, как что устроено, потому что это помогает перевести разговор в конструктивное русло: заказчик перестаёт спорить о вкусах и больше думает про функциональность.
Анна

Заказчик всегда предпочтёт обоснованный элемент своему «а я вот так хочу». Но нам как исполнителям не стоит забывать, что свои бизнес-процессы по продукту он знает лучше, а нам надо их принимать во внимание. Цель — не задавить компетенцией, а использовать её адекватно.

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

Раз в неделю мы показываем статус задач и решений. Допустим, это утро среды.
До утра пятницы ждём правки и комментарии от всех отделов. У заказчика есть человек, ответственный за SLA и единые решения всех команд.
После утра пятницы правки и комменты по этой задаче не принимаются. Но в конце проекта у нас есть ещё две недели, чтобы всё пересмотреть и поправить.

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

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

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

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

Задаём вопрос: «А зачем это нужно?» Бизнес бывает далёк от реальных условий и просит что-то сделать просто потому, что видел такое решение у конкурентов.

Однажды заказчик предложил: «Давайте добавим в личный кабинет клиента его рейтинг, который мы делаем в нашей системе?»
Когда мы спросили, зачем это нужно, оказалось, что рейтинг ни на что не влияет. Более того, у только что зарегистрированных клиентов он будет до обидного низким, поскольку о них почти ничего не известно. Клиенту это ценности не принесёт, а некоторых может обидеть. От идеи пришлось отказаться.

«А зачем» — хороший вопрос-маркер, который помогает отличить полезную идею от шальной.

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

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

Прислушиваемся к заказчику (он может быть прав). Не всем правкам нужно сразу говорить нет. Если прислушаться, заказчики нередко говорят полезные вещи.

На одном из первых проектов мы сделали общий поиск по всему продукту — он искал и по сообщениям, и по документам, и по операциям, и по тарифам с услугами. Заказчик сказал: «А зачем всё это? Давайте дадим поиск только по операциям».
Мы попробовали, и в результате юзабилити-тест показал, что клиент был частично прав. Если людям надо что-то найти, они идут не на главную страницу, а в нужный раздел, и ищут там. Поэтому в следующей версии мы убрали общий поиск и сделали поиск в операциях и чате.

Лучше сделать вариант и проверить, чем сразу говорить твёрдое нет.

Аргументируем в мире бизнеса. Менеджмент мыслит цифрами, поэтому мы подбираем аргументы о рисках и статистике. С продактами важны сроки и KPI: «Если продолжим спорить об этой функции, не уложимся в сроки, давайте оставим и протестируем на пользователях». С безопасниками и юристами ищем доказательства в законах и разъяснениях ЦБ.

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

Находим третейского судью. Когда человека со стороны клиента сложно переубедить, можно зайти с другой стороны и пригласить ещё одного сотрудника из их команды.

Клиент хотел, чтобы в приложении была вкладка «Уволенные сотрудники», но мы настаивали на формулировке «Отключенные сотрудники», ведь здесь были все, кого отключили от сервиса по разным причинам, не только из-за увольнения. Пошли решать вопрос к продуктологам, а они сказали: «Всё равно как, главное, чтобы работало». Оказалось, по мелочи спорили — оставили название списка «Отключённые сотрудники»

Сообщаем о проблемах (даже если придётся кого-то уволить). Твой дизайн всегда потом кто-то верстает и разрабатывает. Есть разработчики, которые в конце проекта (а не на еженедельном ревью) внезапно говорят: «Так сделать нельзя». Не из-за систем, а из-за того, что они не могут. Тогда надо идти наверх и рассказывать о проблеме.

Наш технический бэкграунд помогает отстоять позицию и объяснить, как можно реализовать проект и где это уже применяется.

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

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

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

Описанные нами процессы облегчают жизнь, но они не безупречны. У такого подхода есть свои минусы:

На этапе продаж, а иногда и на первых задачах мы отказываемся от проектов, если заказчики не готовы работать в наших процессах и философии «делаем для пользователя».
Иногда на аргументы и обучение заказчика уходит до 50% времени проекта. Что тоже не хорошо, ведь мы не проектированием занимаемся, а политотой.
Всё равно приходится где-то уступать, что-то менять из-за сроков, новых технических вводных или изменившихся бизнес-процессов. Лучше выпустить работающий продукт через два месяца, чем идеальный через полтора года.
Круги правок никто не отменял. Такие система и процессы помогают их уменьшить, но человеческий фактор всё равно вмешивается.

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

#ux #клиенты