Заказчик предлагает интерфейсное решение. Принять или отказать?

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

Приходит представитель компании, человек очень компетентный и ответственный, просто идеально знающий свою отрасль, и говорит: вот здесь нужна папочная структура в виде дерева, чтобы было удобно хранить файлы. А здесь — кнопка «Сохранить», иначе на сервере все сбросится. Он уже кое-что придумал, подойдет идеально.

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

Но почему это ошибка?

Вроде заказчик лучше знает, что ему надо. Где же тут ошибка?

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

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

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

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

А если дизайнер предлагает ерунду?

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

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

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

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

Заказчик настаивает на своем решении и отвергает идеи дизайнера

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

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

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

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

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

Интерфейс работает, но чего-то не хватает

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

Что делать?

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

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

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

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

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

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

Заказчик все равно хочет свое решение

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

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

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

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

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

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