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

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

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

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

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

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

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

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

Заказчик предлагает решение, хотя должен только сформулировать проблему

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

0
40 комментариев
Написать комментарий...
Александр Савинов

Неоднозначное впечатление от прочтения статьи.
По большому счету, автор всерьез рассказывает( или пытаются обосновать ), почему заказчик всегда не_прав, а исполнитель - всегда прав( даже если у него есть какой-то свой шаблон и он просто откровенно палец о палец не хочет ударять, отдаляясь от него и все-таки слушая, чего конкретно хочет заказчик ).

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

Ответить
Развернуть ветку
Майк Майсон

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

Ответить
Развернуть ветку
Егор Демешко
И его нужно уметь слушать. Это отдельный навык.

Навык на все случаи жизни

Ответить
Развернуть ветку
Агишев Андрей

Вам платят деньги, вы работаете. В чем проблема ?

Ответить
Развернуть ветку
Сергей Копылов

Проведу аналогию:

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

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

Ответить
Развернуть ветку
Агишев Андрей

Аналогия мимо

Ответить
Развернуть ветку
Sergey Surikov

аналогия в точку.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Александр Савинов

"быдлятское мировоозрение" - это беспочвенно делить подобным образом всех по мировоззрению.
Тем более, что у заказчика, сильно погруженного в свою тему, могут быть свои, вполне конкретные причины, применять какие-то элементы дизайна, которые ну_так_и_быть_снизошедшему_до_него_господину_дизайнеру не совсем понятны( и в этом смысле "быдлятским мировоззрением" будет именно мировоззрение дизайнера всерьез полагать, что он, будучи далеко от целевой темы, по определению знает лучше заказчика, что ему нужно ).

Ответить
Развернуть ветку
Собака Павлова
Автор

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

Деньги — условие сотрудничества, но они не определяют формат отношений. 

Ответить
Развернуть ветку
Александр Савинов

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

Ответить
Развернуть ветку
Anton Z.

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

Ответить
Развернуть ветку
Александр Александр

Я в данном вопросе пришел к такому выводу:
1) выслушиваем заказчика
2) просим обосновать его решение
3) берем паузу
4) принимаем решение по интерфейсу и аргументированно защищаем его.

Плюсы такого подхода:
1 - как минимум вы проявите уважение к позиции заказчика.
2 - иногда заказчик может предложить годную идею
3 - из предложения заказчика можно лучше понять, что нужно сделать. Возможно задача изначально была неверно понята. Так часто бывает, тк не все далеко люди умеют доносить свою мысль + взгляд дизайнера может быть зашорен
4 - предложение заказчика может "перезадать" вопрос и помочь найти (синтезировать) новую, более крутую идею.
5 - решения будут приниматься на основе аргументов

Ответить
Развернуть ветку
Собака Павлова
Автор

У нас похожий опыт :)

Ответить
Развернуть ветку
Name Company

Автору статьи: ваша компания называется "Собака Павлова" или "Собака Павловой"? На одной странице вашего сайта одно название, на другой уже другое:)

Ответить
Развернуть ветку
Собака Павлова
Автор

«Собака Павлова». А на какой странице вы увидели другое название?

Ответить
Развернуть ветку
Евгений Евстафьев
Ответить
Развернуть ветку
Name Company

Да им и отзывы пишут также, бедная собака Павлова

Ответить
Развернуть ветку
Собака Павлова
Автор

Спасибо, что заметили. Сегодня исправим. 

Ответить
Развернуть ветку
Евгений Евстафьев

Наверное надо так: Портфолио "Собаки Павлова"

Ответить
Развернуть ветку
Собака Павлова
Автор

Нет, мы сознательно склоняем оба слова в названии. Никакой ошибки нет. «Собака Павлова», портфолио «Собаки Павловой». 

Ответить
Развернуть ветку
Евгений Евстафьев

В таком случае это сознательно приводит к тому что написано в корневом комментарии) выглядит как ляп)

Ответить
Развернуть ветку
Собака Павлова
Автор

Наверное, вы думаете, что есть какая-то собака у какого-то Павлова. И что она принадлежит ему, поэтому «Собака (какого-то там) Павлова». Отсюда и возникает ощущение, что ляп. 

На самом деле никакого Павлова нет. Есть «Собака (по кличке) Павлова». 

Ответить
Развернуть ветку
Name Company

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

Ответить
Развернуть ветку
Mikhail Che

Осталось только узнать какая сволочь обзывает Павлову Собакой.

Ответить
Развернуть ветку
Pixel Lens
Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Собака Павлова
Автор

Да, у нас почти всегда почасовая оплата. А что вас смутило?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Собака Павлова
Автор

Заказчик приходит к нам, чтобы купить решение его задач. То есть, ему нужны компетенции там, где не хватает собственных.  

Роль заказчика в команде — рассказывать про проблемы и делиться знаниями о продукте. Наша — думать головой и решать задачи. Если заказчик начнет делать нашу работу, он перестанет успевать делать свою. Это навредит проекту. 

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Гриша Булыжников

картинок нет, читать не интересно

Ответить
Развернуть ветку
Майк Майсон

"Все, что в этот список не входит, то есть не работает на увеличение количества новых покупателей, мы не делаем"

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

Ответить
Развернуть ветку
Собака Павлова
Автор

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

Если заказчик аргументирует свое желание так же, как вы, скорее всего, возьмемся. Будет круто, если он это сможет еще и показать на каких-то данных. 

Ответить
Развернуть ветку
Pixel Lens

вы кроссафчеги, но почему на странице дизайн-задачника юзается Roboto для основных текстов? Везде вродь Монцерат, а тут нет.

Ответить
Развернуть ветку
Собака Павлова
Автор

Спасибо, что заметили. Передадим кому надо. 

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Собака Павлова
Автор

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

Ну и, с другой стороны, если заказчик чего-то очень сильно хочет, то у него явно есть для этого причина. И мы, как дизайнеры, должны докопаться до нее. 

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Олег Ващуков

Я бы заменил технику "5 почему" на lean ux canvas. А так норм.

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

Ответить
Развернуть ветку
37 комментариев
Раскрывать всегда