Как распознать «сложных» заказчиков

Есть у меня две страсти: составление списков и UX. Несколько лет работы над последним дали мне достаточно материала для первого, так что далее список тревожных звоночков, сигнализирующих о том, что перед вами сложный заказчик. Сразу скажу, что «сложные» заказчики – это не то же самое, что заказчики неадекватные. Бывают и такие. С первыми делать успешные проекты реально, если учитывать некоторые особенности, со вторыми невозможно.

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

«А пришлите мне PSD, я сам попробую»

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

Чем чревато:

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

Если после серии правок заказчик вызывается попробовать сам, это означает, что вы потерпели неудачу в том, чтобы его услышать. Он отчаялся получить достойный результат настолько, что сам лезет «под капот». И да, скорее всего в итоге получится говно. Если бы клиент умел делать что-то иное, он бы не пришел к вам. И уйдет от вас он недовольным. Либо сразу поймет, что результат плох, либо через некоторое время задаст себе вопрос: а зачем, собственно, ему были нужны вы?

Как лечить:

Ищите другие способы коммуникации. В общем – меньше переписки и больше живого общения. Задавайте вопрос «зачем» почаще, особенно когда какие-то замечания кажутся вам бессмысленными.

Попробуйте вернуться на шаг назад, к прототипу, если он был, а если не было ничего (бывает и такое) – к скетчам. В обсуждениях делайте отсылки к целям проекта и пользователей и аргументируйте все свои решения. Вот тут можно как раз отделить сложных клиентов от неадекватных. Первые говорят на языке аргументов – даже если они не согласны, спорят обоснованно; вторые вообще не слушают, а то и явно говорят «я понимаю, что правильно так, но все равно хочу так, как хочу».

И будьте готовы отказываться от своих решений: не за все надо сражаться до последней капли крови.

«Мы хотим все как у amazon, только другого цвета, без картинок и мобильное приложение»

Сначала с такими клиентами работать – одно удовольствие. Они приходят с очень четким представлением о том, что им нужно. Но довольно скоро оказывается, что ничего из того, что им нравится у других, нельзя применить для их конкретного проекта. Общего между этими двумя нет чаще всего ничего.

Чем чревато:

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

Как лечить:

Почаще задавать вопрос «Зачем». У сложных заказчиков страсть к копированию появляется от нехватки времени на анализ и рефлексии над своим продуктом: грубо говоря, у них не было возможность продумать все в деталях. Тут очень помогает заполнение Business Model Canvas и Impact Map: последний артефакт хорош тем, что сразу показывает, какие фичи не приносят никакой пользы бизнесу, а какие, пусть их и нет у сайта, на который молится заказчик, добавят уникальную ценность. Иногда помогает возврат к обсуждению целевой аудитории продукта и потребностей пользователей и вообще всё, что позволяет вернуться на «шаг назад» от «что» и «как» к «зачем», «для кого» и «чем отличаемся».

Для неадекватных заказчиков копирование — это «верняк» в плане успешности проекта. Амазон выстрелил? Делаем второй Амазон! Они никогда не могут ответить на вопрос «чем ваш проект будет лучше», потому что на самом деле он не будет. С ними лучше не связываться совсем.

«Это уже третья попытка, остальные были плохие. Нет, не покажем»

В начале проекта заказчик вам говорит (если вы его спросили, конечно – а то может и скрыть), что вы у него не первый. До вас была скромная попытка сделать самим, обращение к фрилансеру за 50 долларов или еще куда-нибудь. Результат, очевидно, не понравился. Но вам его показывать не хотят. Причины могут разные: «все равно получилось плохо, нам не нравится», «нам интересно, что вы сделаете, а потом сравним», «не хочу, чтобы старый вариант влиял на ваш».
Вот тут нужно насторожиться.

Чем чревато:

Этот симптом может указывать на то, что заказчик не просто сложный, а неадекватный. Если посмотреть на работу ваших предшественников, возможно 3 варианта, и про все полезно знать:
1) Там действительно не на что посмотреть.

1. Если заказчик делал своими силами, ничего удивительного. Но полезной информации можно извлечь массу.
2. Если заказчик нанимал кого-то другого и все плохо, ему либо не повезло нарваться на дилетанта, либо подвела жадность, либо (тут ещё список причин) – тоже полезно знать.

2) Работа сделана на неплохом уровне. Вот тут нужно пообщаться детальнее и выяснить, что в старом варианте нравилось, а что – нет. Иначе окажется, что «вон ту страницу вообще не надо было менять» или «если бы мы хотели, чтобы эта форма оставалась такой же, мы к вам бы не пошли»

3) К работе вообще трудно придраться. Вот это симптом заказчика неадекватного. Есть шанс, что как бы вы ни старались, ни один вариант его не устроит.

Как лечить:

Начать с того, что анализ прошлых вариантов поможет сэкономить время и избежать ошибок предшественников. Объяснить, что умение абстрагироваться от всего, что видели/создавали раньше и находить новые решения – это часть вашей профессии. Будет ещё лучше, если вы не просто сможете взглянуть на прошлые варианты, а ещё и проговорить с заказчиком, какие и чем не устраивают, чем устраивают, и как ему вообще понравился процесс взаимодействия с соответствующим исполнителем. Совсем идеально, конечно, будет выслушать и другую сторону, правда, честно признаюсь, это редко получается.

«UX сделали, дальше сами, спасибо»

Удивительный факт: на дворе 2015 год, больше почти никто не путает UX, юзабилити и дизайн, но все равно десятки компаний (и среди них – множество по-настоящему крутых продуктовых компаний!) смотрят на UX как на шаг в цикле разработки: прошли – и двигаемся дальше.

Чем чревато:

Вас привлекают для этого шага. Как только вы закончили свою часть, вас выбрасывают из процесса и продолжают уже без вас. Потом проект запускается, и вы об этом узнаете. В предвкушении открываете сайт/скачиваете приложение и сердце замирает в ужасе. Если вы делали только прототип, дизайнер заказчика переделал все, что мог: компоновку элементов, контент, даже навигацию. Если дизайн делали тоже вы, наслаждаемся кривой версткой. И везде, везде сотня изменений, о которых вы ни сном ни духом.  Однако за результат все еще отвечаете вы: вы же сделали UX!

Как лечить:

Никогда не оставляйте проект без присмотра, даже если ваша часть работ закончена. Для этого существует замечательная вещь, которую мы называем «авторским надзором». Да, придется выделять несколько часов в неделю все те месяцы, пока проект в разработке. Но это убережет вас от неприятных сюрпризов. Актуально это и для тех проектов, где вы проводили юзабилити-тестирование. Я верю, что тестирование само по себе не несет никакой пользы, если ничего не сделать по его результатам. Считайте, что ваша часть работы закончена не тогда, когда вы презентовали отчет, а только тогда, когда заказчик внедрил рекомендации (хотя бы их часть!).

Помогает также обучение заказчика. Опыт преподавания дает о себе знать: как я, так и мои коллеги зачастую на этапе pre-sale и в рамках самого проекта неявно или открыто обучаем заказчика некоторым аспектам UX и HCD. Если делать всё правильно, то вы получаете и более качественный продукт, и более лояльного клиента, и больше заказов.

«Вы тут рисуйте, а мы параллельно начнем работу»

Соратники по духу предыдущим клиентам. Для них – UX и «всякие картинки» отдельно, а настоящая работа – отдельно. Чтобы не тратить время, ожидая, пока вы закончите свою часть, такие заказчики хотят как можно скорее загрузить разработчиков (ну а че они штаны просиживают).

Чем чревато:

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

Как лечить:

Желание сократить общую длительность и всех обеспечить работой понятно. Если не получится загрузить разработчиков теми задачами, которые не повлияют на вашу работу, придется работать вместе. Но с обязательной синхронизацией! В каких-то задачах придется ускоряться (например, больше проектировать на бумаге), чтобы пораньше дать материал на вход разработчикам. И договориться, что чем раньше вы будете видеть их результаты и давать свою обратную связь, тем больше времени, денег и нервов вы сэкономите всем. В общем, будьте более гибкими и плотнее работайте с командой разработки!

«Нам не нужно исследование, мы и так знаем, что делать»

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

Чем чревато:

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

Как лечить:

Часть заказчиков отказывается от этих этапов потому, что просто не видит в них ценности. Для таких случаев лучшим объяснением себя показала пирамида Гарретта. Правда, если бюджет все равно ограничен, придется выкручиваться. Например, опять обучать. Можно провести несколько консультаций, рассказать, какую информацию и как нужно собрать для вашей работы (скажем, показать примеры заполненных Персон), и отправить заказчика «в поле» самостоятельно. Лучше также предусмотреть несколько точек синхронизации в процессе, когда вы посмотрите на прогресс и дадите обратную связь по нему. Конечно, заказчик в этом неспециалист. Но: лучше провести неидеальное исследование, чем не проводить вообще никакое. Если уж и так совсем не получается из-за ограничений (ведь бывает и такое), то алгоритм может быть такой: рассказать заказчику про работу с гипотезами, самостоятельно или вместе с ним сформулировать гипотезы относительно ЦА, обязательно синхронизировать эти гипотезы с ним, разъяснить, чем это чревато, увидеть в его глазах понимание и продолжить работу на основе гипотез.

«Кстати, это Вася, ему не понравилось, что вы сделали»

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

Чем чревато:

«Вася» ничего не знает о работах, проделанных на предыдущих этапах, и тратит ваше время на странные вопросы: «А почему у нас нет фичи А?», «Может попробуем другие цвета?», «А почему вы решили сделать меню сбоку, а не сверху?». Потратите ли вы время на исправления или на объяснения – это все равно потраченное время.

Как лечить:

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

Выводы

Дальше я скажу то, что обычно не говорят при зачислении в ряды UX специалистов: общение с людьми – это и есть основная и самая сложная часть работы в нашей профессии. Я считала и считаю, что работать на приличном уровне в Axure можно научить за неделю даже обезьяну. С остальными скиллами посложнее, но ничего нереального.

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

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

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