Работа с крупными заказчиками часто сопряжена с трудностями: они отвергают идеи, заваливают правками и не прислушиваются к аргументам. Для успешной защиты решений разработана система, основанная на пяти правилах:
5 правил защиты UX-дизайна
Правило 1: Выбор клиентов и договорённости на берегу
Изначально брались все проекты, но затем приоритетом стали сложные задачи. Сейчас работа ведётся преимущественно с банками из топ-20 и финансовыми проектами. Отказ от сотрудничества с клиентами, чьи цели сводятся к освоению бюджета, а не созданию качественного продукта, позволяет сэкономить силы, время и нервы. Ключевой момент – работа с теми, кто разделяет ценность качества и ориентирован на пользователя. Важно чётко обозначить зону ответственности: например, конкретную область UX-дизайна, где команда полностью отвечает за решения, опираясь на исследования и данные о пользовательском поведении. Визуальную часть и бизнес-процессы готовы обсуждать и искать компромиссы.
Правило 2: Валидные аргументы – сила цифр
Убедительность обеспечивается данными. Еженедельно анализируются задачи, исследователь собирает статистику и инсайты, и продукт создаётся на основе данных. Эта работа занимает до 50% времени проекта, но позволяет аргументированно защищать решения. Если цифр недостаточно, спорные моменты проверяются юзабилити-тестированием – самым весомым аргументом, подтверждающим удобство и понятность продукта для пользователя.
Правило 3: Тотальное погружение менеджеров в детали
Плохая подготовка может испортить даже лучшую концепцию. Менеджеры проекта участвуют во всех этапах, включая review, где дизайнер защищает свои решения перед командой. В review участвует исследователь, выступающий «адвокатом пользователя». Это помогает менеджерам понять принятые решения, собрать фактуру и задавать вопросы, которые могут возникнуть у клиента. Проработка возможных вопросов клиента заранее минимизирует сюрпризы на защите.
Правило 4: Передача знаний заказчику
Важно, чтобы заказчик понимал, что команда работает на его стороне. Прозрачный дизайн-процесс, демонстрация текущей ситуации на рынке, подбор аргументов – всё это способствует взаимопониманию. Делимся экспертным знанием в области UX и дизайна, объясняя принятые решения. Цель – не подавить заказчика своей компетенцией, а использовать её для конструктивного диалога, переведя фокус с эстетических предпочтений на функциональность и ценность продукта.
Правило 5: Чёткие сроки на правки
В крупных проектах участвует много людей, каждый со своим мнением. Для оптимизации процесса установлены жёсткие сроки на внесение правок: неделя на сбор комментариев от всех отделов, после чего правки не принимаются. В конце проекта остаётся две недели на финальную доработку. Это дисциплинирует процесс и удовлетворяет как заказчика, так и исполнителей.
Лайфхаки для защиты решений
Даже лучшие аргументы не всегда работают. Вот несколько лайфхаков:
- Акцент на изменениях: при повторной защите акцентировать внимание на местах, где были внесены правки, чтобы избежать повторного обсуждения уже решённых вопросов.
- Защита с экспертом: для сложных деталей привлекать эксперта (старшего дизайнера, исследователя), чьи аргументы повышают уровень доверия.
- Вопрос «зачем?»: этот вопрос помогает отделить полезные идеи от ненужных.
- Кликабельный прототип: предоставление кликабельного прототипа позволяет заказчику оценить продукт с точки зрения пользователя.
- Прислушиваться к заказчику: заказчик может быть прав частично, лучше проверить варианты, чем сразу отказывать.
- Аргументация рисками и статистикой: важно говорить на языке цифр, учитывая сроки и бюджет.
- Поиск доказательств: использовать законы, нормативные акты и разъяснения регулирующих органов.
- Третейский судья: при необходимости привлекать дополнительного сотрудника со стороны клиента для разрешения спора.
- Сообщать о проблемах: своевременно информировать о технических сложностях, чтобы избежать проблем на поздних этапах проекта.
Система описанных правил и процессов помогает уменьшить количество правок и выпускать качественные продукты. Однако, человеческий фактор остаётся, и на этапе продаж приходится отказываться от проектов, если заказчик не готов работать по предложенной системе. Иногда на обучение заказчика уходит до 50% времени проекта. Несмотря на трудности, придерживаемся принципа выпускать работающий продукт в срок, даже если это означает компромиссы, предпочитая это идеальному, но затянувшемуся проекту. Главный страх – создать продукт, за который будет стыдно перед пользователем.