СтратегияДизайн Интерфейсов

Если заказчик говорит, что всё говно

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

⛔️ Чего не надо делать

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

Бессмысленно спорить и огрызаться. Самый бессмысленный в этой ситуации вопрос — «Почему?» Его проблема в том, что он реагирует на заявление на том же уровне, на котором оно прозвучало. «Говно получилось» — это не та плоскость, в которой имеет смысл спорить, потому что масштаб заявления слишком космический. А нам надо откалибровать его до масштаба «Что надо делать».

✅ Что делать

Это повод закинуть проблему в блендер и разбить её на много мелких. Дыма без огня не бывает. Наша задача — найти огонь и эффективно потушить его.

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

1. Локализуем. Следует сделать шаг назад и посмотреть на ситуацию с максимально общего ракурса. Предложи обозначить границы, из чего состоит это «всё». Это позволит локализовать проблему. Запиши признаки проблемы в список, фильтруя эмоциональную реакцию. По хорошему такой список должен совпадать с изначальным ТЗ к данной задаче. Если совпадает, значит, видение заказчика после просмотра неудачно выполненной работы не изменилось. Это хороший знак: он знает чего хочет. Если изменилось, это может быть полезным для калибровки.

2. Декомпозируем. Любую дизайн-задачу можно разделить на несколько, по условным уровням детализации. Уже писал о них в Стратегическом дизайне интерфейсов:

  • Логический уровень — Что должен сделать пользователь
  • Уровень проектирования — на какие экраны мы разделим его шаги? Что будет в этих шагах? Как расположить кнопки?
  • Визуально-эмоциональный — какой стиль мы будем использовать? Как сделать, чтобы было «Вау»?

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

3. Исправляем и получаем новую обратную связь. Нашли источник дыма. На этом этапе опасно поддаться соблазну сделать работу в реальном времени вместе с заказчиком. Минусы:

  • Если у него много влияния и харизмы, в этом случае он будет пытаться водить нашими руками, приравнивая свои действия к тому, что такое «как надо». Это испортит результат.
  • Если мы занимаем время заказчика, у него складывается впечатление, что мы не справляемся без него и только он может спасти ситуацию.

Задаём три вопроса и действуем. Строим фундамент:

1. Какую возможность мы дадим пользователю, спроектировав этот сценарий?

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

Определившись с проблемой, проектируем её решение:

2. Логично ли стоят кнопки? Логична ли визуальная иерархия? Видны ли они и достаточно ли на них удобно нажимать?

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

3. Как поймать стиль?

Красиво-уродливо, не то? Допустим, на уровне проектирования заказчик принял работу и не нравится только стиль. Если у интернет-магазина есть какой-то UI-кит, в логике которого собираются макеты, он послужит нам защитой: ты работал в рамках принятого стиля и чтобы улучшить стиль, нужно менять его по всей системе.

Если стиль менять всё-таки нужно, собираем мудборд. Об этом хорошо рассказал Глеб Кузнецов. Мудборд — виртуальная доска с картинками, похожими на то, что нужно заказчику. В мудборд как сорока-ворона тянем всё, что нравится на сайтах для дизайн-вдохновения. Из разных картинок дёргаем разные понравившиеся аспекты: цвет, шрифт, композицию, анимацию, технику.

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

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

Я веду /designer — телеграм-канал и сайт о интерактивном дизайне. В нём пишу о том, как использовать инструменты: Фигму, Скетч, Фреймер и другие. Для профи и начинающих.

Также я веду UX-гайд — телеграм-канал о проектировании и дизайн-паттернах.