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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— Здесь обязательно нужен поп-ап.

— Хорошо. А почему?

— Нужно, чтобы человек обратил внимание, это важно.

— А почему он должен обратить на это внимание?

— Потому что потом будет поздно.

— А почему потом будет поздно?

— Потому что у нас в этот момент записываются данные, они отправляются на сервер и потом все, ничего не изменить. Технический момент.

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

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

Что делать?

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

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

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

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

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

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

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

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

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

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

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

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

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