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

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

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

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

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

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

Правило первое: выбираем клиентов и договариваемся на берегу

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

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

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

Правило второе: вооружаемся валидными аргументами

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

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

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

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

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

Правило третье: тотально погружаем менеджеров в детали

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

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

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

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

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

Александр, Project manager

Правило четвёртое: передаём знания заказчику

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

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

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

Я всегда готова объяснить, как что устроено, потому что это помогает перевести разговор в конструктивное русло: заказчик перестаёт спорить о вкусах и больше думает про функциональность.

Анна, Product manager

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

Правило пятое: ставим четкие сроки на правки

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

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

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

Защита решений: как работать со сложными клиентами

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

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

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

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

Однажды заказчик предложил: «Давайте добавим в личный кабинет клиента его рейтинг, который мы делаем в нашей системе?»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иногда защита решений — это защита принципов и процессов

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

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

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

Принципиальный подход не избавляет от всех проблем

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

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

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

0
30 комментариев
Написать комментарий...
Peters Wolfgang
Ответить
Развернуть ветку
Natalya Sturza

такой клиент за два года у нас был только один ))

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

Одна из немногих статей, где все структурировано, полезно и нет воды. Спасибо!

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

это наш редактор бьёт нас палкой ))

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

А пряники хотя бы дает или сам съедает? :)

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

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

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

ой спасибо, в самое сердечко :) 

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

Классно было бы увидеть пару каких-нибудь интересных кейсов, где аргументы подкрепляются цифрами. 

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

Да нам самим хочется их скорее увидеть ))) Но надо ждать выхода в прод каждого сервиса. У нас проходит в среднем год после сдачи проекта до выхода его в прод, когда мы можем залить кейс 

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

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

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

На самом деле мы объединили два компании, которым по 3-5 лет и сфокусировались на дизайне год назад. 

То что мы проектировали 1-2 года назад для банков сейчас только выходит в прод. 

Ответить
Развернуть ветку
Игорь Дмитриев

Хоть сам и не дизайнер, прочитал материал с интересом. Обобщения по существу выстраивания отношений с заказчиком, как таковым, верны. Многое стоит не только обдумать, но и заимствовать. Спасибо. Комфортных вам заказчиков!)

Ответить
Развернуть ветку
Игорь Маркелов

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

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

прогиНаться? это точно русский язык?

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

это я влезла

Ответить
Развернуть ветку
Wladimir
что всё затевается для освоения бюджетов, а сервис вряд ли дойдет до пользователей

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

Получается они плохи только тем, что команда не увидит как счастливые пользователи пользуются созданным дизайном?

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

Если можно выбирать среди таких и не таких — хочется выбирать и работать с теми, кто твои ценности и позицию разделяет.

Ответить
Развернуть ветку
Дари Гребенникова

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

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

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

Никто :) Они так и будут работать из под философии "вылизывайте нас" и "мы знаем как надо делать". 

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

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

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

Топов пока нет, по существу) Хотя говорят, наши по дезигну приложений для банков уже давно обогнали западных колег  

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

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

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

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

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

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

спасибо за "а зачем это нужно?"

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

Полезно. Но конкретики маловато

Ответить
Развернуть ветку
Даша Дмитренко

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

На улице 2020. Быть ориентированным на удобство клиента - это значит быть на 200% ориентированным на хорошие результаты для компании, потому что довольный клиент явно принесёт больше профита, чем тот, который вынужден был продираться через дебри дизайна "нам удобно именно так"

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

В статье есть отсылка к внутренней базе знаний. Что в ней? Как устроена? По какому принципу наполняется и на базе какого сервиса работает? 

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

Нет конечно и не будет. Это наш ресурс, который конкурентное преимущество. Все структурировано в notion+ Ссылки на google drive, YouTube 

Ответить
Развернуть ветку
Саша Южный

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

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

Думаю об этом второй день - пока сложно сформулировать так чтоб никого не обидеть и без мата. 

Ответить
Развернуть ветку
27 комментариев
Раскрывать всегда