Заказчик предлагает интерфейсное решение: использовать или отказать

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

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

Заказчик должен концентрироваться на задачах, то есть думать высокоуровнево.

Подобное бывает.

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

Но заказчик чувствует, что здесь что-то не то, только доказать этого не может. И все равно настаивает на своем. Что делать?

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

Дизайнер должен понять, почему заказчик не принимает его решения. Иногда причина может вообще не относиться к интерфейсу. А дизайнер про нее не знает. Ну так надо разговорить заказчика и узнать.

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

У нас получаются примерно такие диалоги:

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

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

Допустим, заказчик убедился, что интерфейс решает его задачу, и отказался от своего решения. Но все равно ему что-то не нравится, прямо спать не может. То ли задачу можно решить элегантнее, то ли чего-то не хватает. В общем, есть над чем поработать еще — так ему кажется.

Что делать?

Проверять, как интерфейс решает задачи.

Допустим, к нам пришел фотобанк. Его бизнес-цель — увеличить количество новых покупателей. Именно новых.

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

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

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

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

Техника «Пять почему» не помогла, заказчик стоит на своем и плевать ему на ваши решения с бизнес-шмизнес-задачами. Делайте или уходите. И как поступать в таких ситуациях? Использовать его интерфейсное решение.

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

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

Дизайнеры тоже придут с аргументами. Не используем решение, потому что мы попробовали и вот что получилось. Или наоборот. Да, ваше решение действительно лучше нашего. Мы его используем.

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

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