6 лет наша компания занимается дизайном и разработкой мобильных приложений. Мы много экспериментировали с оптимизацией процессов как внутри компании, так и при работе с клиентами. В итоге у нас сформировался свой, во многом уникальный, стиль работы.
Я руковожу отделом дизайна и хочу поделиться нашим подходом к работе. В этой статье расскажу, как построить работу с клиентом так, чтобы она была эффективной и комфортной для обеих сторон.
Мы — аутсорс-компания. Степень удовлетворенности заказчиков — один из важнейших критериев качества работы. Думаю, это справедливо для любой сферы услуг. В этом отношении наши процессы сильно отличаются от продуктового дизайна.
Сразу хочу отметить, что роль дизайнера в нашей компании многогранна. Он присутствует на всех стадиях проекта: от этапа продажи и до релиза. Помимо непосредственных обязанностей — проектирования и дизайна интерфейса, он принимает участие в аналитике, общении с клиентом, сопровождении разработки и тестировании.
На проекте должен быть человек, который хорошо понимает бизнес-требования и ожидания клиента, может соотнести их с техническими возможностями платформ и при этом не забывает про пользователей.
Формализуем ожидания
Большая часть проблем, с которыми я сталкивался во время работы, была связана с непониманием между заказчиком и исполнителем. Перед началом проекта нужно четко понимать, что клиенту нужно, в какие сроки, за какие деньги и что он ожидает получить как результат работы. Если в ходе проекта одно из этих условий меняется — не забывайте об этом сообщать.
Узнаем, зачем клиент к вам обратился
Первое что нужно понять — зачем к вам пришли, какие компетенции хотят закрыть с вашей помощью. От этого во многом будет зависеть состав команды, которая будет работать над проектом. Всех клиентов, которые к нам обращаются, можно условно разбить на три категории:
- Нужны головы. У заказчика есть уникальная задача или проблема. Он ищет команду, которая разбирается в мобильных приложениях, новых технологиях, рынке и способна предложить ему решение.
- Нужен опыт. Ищут ребят, у которых есть опыт в решении подобных задач. Ничего сверхъестественного не требуется. В таких проектах вас будут слушать и учитывать ваше мнение, так как именно за этим к вам и пришли.
- Нужны руки. Все ясно-понятно, техническое задание есть, все везде согласовано-утверждено и нужны прямые руки, которые все это быстро воплотят в жизнь. Меньше слов, больше дела.
Для каждого типа клиента нужен свой подход. Например, когда клиенту нужны головы, можно взглянуть на проблему шире и предложить переосмыслить саму задачу, если на то есть причины. И точно не нужно такое проворачивать с заказчиками, которые ищут руки. Это вызовет только раздражение.
Деление крайне условно и к тому же часто меняется по ходу проекта. Чем больше вам доверяют, тем чаще прислушиваются. Всегда стоит проявлять инициативу и предлагать свои решения, если вы видите в них уверены. Но если клиент несколько раз обратил внимание, что ему не важно ваше мнение, то предлагать «улучшения» имеет смысл только в рамках производственной необходимости.
Озвучиваем сроки
Когда вы озвучиваете оценку проекта и сроки его реализации, всегда нужно проговаривать условия, при которых они будут соблюдены. Особенно это касается ситуаций, когда у вас нет достаточной информации о проекте или не хватает каких-то материалов.
Дизайнер: Мы оцениваем данную работу в 80 часов. С учетом обсуждений и согласования это займет около 3 недель. При условии, что на проекте будет человек с вашей стороны, который в течение дня будет ответчать на оперативные вопросы.
И не стесняйтесь напоминать, кто и что вам должен и почему это важно. Ситуация, когда вы срываете сроки и постфактум говорите, что причиной стала нехватка информации — недопустима.
Оговариваем результат
Всегда нужно обговаривать, что именно заказчик получит в конце работы. Это не так критично, если заказ на дизайн и разработку. Конечный результат в этом случае — рабочее приложение, и никому нет никакого дела, как вы передаете макеты разработчикам.
Но если клиент заказывает только дизайн приложения, то нужно все разложить по полочкам. Какие артефакты в каких форматах он получит и что он с ними сможет дальше делать, а что нет.
Будет обидно, когда в конце работы окажется, что разработчики на стороне клиента работают на винде, а вы отгрузили макеты в скетче.
Клиент: Все отлично! Сегодня будет презентация совету директоров. Как мне открыть файл brandnewapp.flinto? Не смог найти приложение для андроида :(
Учимся отказывать
У каждой компании есть свой «идеальный» клиент. Который разделяет ваши принципы и согласен с вашим подходом к работе. Чем дальше потенциальный заказчик от этой модели, тем сильнее вы рискуете не оправдать ожиданий.
Плохая стратегия — хвататься за каждого клиента, который к вам обратился. Учитесь отказывать, если понимаете, что под нового клиента придется перестраивать внутренние процессы или менять стандарты качества. А ресурсов на это нет.
Особенно опасно, когда клиент просит снизить стандарты для быстрого запуска проекта или сокращения бюджета. В долгосрочной перспективе это может привести к тому, что люди привыкнуть делать плохо.
Хочется быстрее запустить проект — нужно выпиливать фичи и упрощайте интерфейс. Жертвовать качеством нельзя. Если заказчик не готов на это пойти — отказывайтесь или убедитесь, что осознаете все последствия и готовы к ним.
Понимаем контекст
Любая задача вне контекста имеет бесконечное число решений. Важно понять контекст, чтобы сузить зону поиска оптимального решения. В противном случае, вам придется уповать на везение и догадки.
Абсолютно любая информация от клиента важна. Ведь вам не только нужно решить поставленную задачу и обосновать свое решение, но и «продать» это решение заказчику. А эта часть работы не всегда напрямую связана с проектом.
Главное — максимально синхронизировать знания с клиентом, чтобы вы понимали его бизнес, ограничения и мотивы, которые им движут. А он понимал, как устроен процесс дизайна.
Задаем вопросы
Многие дизайнеры боятся показаться глупыми, задавая слишком много вопросов. «Они подумают, что я тупой». Возможно. Зато когда вы предложите решение, которое сэкономит им время и деньги, они будут относиться к вопросам более лояльно.
Важно задавать правильные вопросы и задавать их правильно. Вы должны быть готовы обосновать, почему вас интересует та или иная информация. А лучше сразу говорить, почему вы что-то спрашиваете. Правильный вопрос многое говорит об исполнителе и его опыте.
Изучаем клиента
Общая информация. Всегда полезно узнать, с кем вам предстоит встреча, а в дальнейшем и работа. Можно посмотреть открытую информацию в соцсетях. Если это публичный человек, то посмотреть интервью или почитать статьи. Это поможет быстрее найти общий язык.
Опыт. Был ли у клиента опыт работы с подобными проектами и мобильными приложениями в целом? Если нет, значит часть времени вам нужно будет уделять обучению и это стоит учитывать при оценке проекта.
Формулируем цель
Первое, с чего стоит начать допрос с пристрастием — это выяснить цель. Какую пользу клиент хочет получить, заказывая приложение. Как он будет оценивать успешность проекта. Почему он считает, что именно приложение поможет ему в достижении намеченных целей. Как сейчас его клиенты решают аналогичные задачи.
Это очень простые вопросы. Но они хорошо показывают, насколько клиент понимает, что ему нужно. Иногда бывает, что техническое задание на разработку приложения есть, а точного понимания, для чего же его делать — нет. В этом случае нужно совместно с клиентом сформулировать цель и, при необходимости, переработать ТЗ. Важно донести мысль, что приложение — не самоцель, это лишь средство.
Дизайнер: Вы знаете, с учетом полученной информации, достаточно сделать мобильную версию сайта. Она решит все ваши проблемы.
Да, вы можете не получить заказ. Но это не тоже самое, что потерять клиента. Он к вам вернется, когда ему действительно нужно будет приложение. А вот работать с заказчиком, у которого нет необходимости в мобильном приложении, будет очень непросто. Особенно, когда он это осознает.
Изучаем бизнес
Желательно хорошо разбираться в бизнесе клиента. Поэтому во время общения необходимо выяснить максимум информации: бизнес-процессы, ценности, особенности, аудитория, конкуренты.
Для клиента его бизнес — это данность. При всем желании, он не сможет рассказать всю подноготную. Многие детали всплывут уже в процессе работы. И, возможно, новые вводные перечеркнут много крутых идей. Главное в такой ситуации оставаться гибким и открытым, не зацикливаться на своих решениях.
Разбираемся с ресурсами
Понимание того, какие ресурсы есть в распоряжении заказчика и какие ограничения, может сократить зону поиска решения. И речь не только о деньгах и времени.
Клиент: Вы предложили решение, которое основывается на чате. Но у нас пока нет собственной службы поддержки, это слишком затратно.
Предложенное вами решение должно максимально опираться на существующие ресурсы. В противном случае вы создаете новые проблемы.
Если у вас идея, но вы не уверены, есть ли на это ресурсы — обсудите. Возможно, ваш замысел окажется интересным и клиент сможет выделить средства на его воплощение.
Анализируем вводные
Речь идет о любых материалах, которые вам передал заказчик. Это могут быть брендбуки, исследования, референсы приложений, прототипы, существующее приложение или техническое задание. Внимательно все изучите и после попросите клиента рассказать, что со всем этим добром делать.
Если речь идет про брендбук, то насколько жестко нужно ему следовать. Как правило, в гайдах нет четких правил по оформлению приложений, поэтому нужно понять, какие константы фирменного стиля обязательно должны присутствовать, а какие нет.
Референсы приложений. Что именно в них понравилось и почему. Возможно, из всего приложения нравится только один элемент, какой-то интересный способ взаимодействия или «общее ощущение легкости».
ТЗ от клиента — ограничение, которого нет. Не стоит воспринимать его как аксиому. Кто писал, когда и зачем, на что опирались, выбирая те или иные фичи. Там точно есть полезная информация, но важно понять, какая у вас степень свободы.
Дизайнер: В ТЗ достаточно много логических несостыковок. Насколько четко нужно ему соответствовать? Мы готовы предложить свое видение, исходя из цели проекта. Оно будет проще в реализации и соответствовать гайдлайнам платформ.
Alarm!
На что нужно обратить особое внимание внимание при сборе информации:
- Нет сроков. Может означать, что вообще-то на проект всем наплевать. Дедлайны способствуют эффективной работе с обеих сторон. Без них согласование может проходить вяло и простои неизбежны.
- Плохая коммуникация. Если еще на момент переговоров заказчик пропадает, не берет телефон и не отвечает на письма — плохой знак. В процессе работы все это может повториться. Стоит задуматься, нужно оно вам или нет.
- Нет ответственного. Или нет с ним прямого контакта. Тут все понятно. Будет непрерывный испорченный телефон. А в сочетании с первыми двумя пунктами проект будет тянуться бесконечно.
- Неопределенность. Если после всех обсуждений вы так и не поняли, что от вас хотят, возможно, дело и не вас. Некоторые люди очень импульсивны и часто меняют свои решения. Готовьтесь к тому, что все решения придется документировать и часто переделывать. По фиксированной стоимости в таких случаях лучше не работать.
Приступаем к работе
Процесс дизайна интерфейса — тема отдельной статьи. В этой расскажу только те моменты, которые касаются взаимодействия с клиентом.
Формируем команду
Клиент — часть команды. Все начинается с людей. Какие бы услуги вы ни оказывали, за каждой компанией, каждой должностью стоит реальный человек. И часто именно от этого человека зависит, насколько хорошо вы справитесь со своей частью работы.
Мы стараемся строить отношения таким образом, чтобы отойти от формальных ролей заказчик/исполнитель. Роли хорошо работают, когда вы продаете «коробку». Но когда речь идёт о создании уникального продукта, такое не прокатывает. Гораздо эффективнее выступать единой командой, когда решения являются результатом обсуждения, а не прилетают от неизвестного «сверху». На стороне исполнителя компетенции в области реализации, на стороне клиента — бизнеса.
Презентуем решения
Если есть возможность проводить ключевые встречи лично — отлично. Но подойдет и скайп или аналогичный софт с возможностью поделиться экраном. Презентовать нужно в реальном времени, заранее для ознакомления ничего не отправлять. Иначе на момент презентации у человека уже будет сформировано мнение. И не всегда положительное. Что-то он поймет по-своему, а что-то не поймет совсем. Исправить это будет очень сложно.
После презентации можно отправить макеты и основные тезисы. Для принятия решения нужно время, чтобы все обдумать и посоветоваться с коллегами. Удобно, когда есть документ, в который можно заглянуть и восстановить причинно-следственную связь.
Особенно это важно, когда вы работаете с человеком, не принимающим конечное решение. В этом случае важно вооружить его достаточным количеством аргументов, которые он будет использовать, презентуя вашу работу. Убедитесь, что он все понял и разделяет вашу позицию.
Фокусируемся на главном
Каждый элемент интерфейса несет какой-то смысл, решает какую-то задачу и именно об этом нужно говорить. Как только русло вашего повествования уйдет в сторону «красивых иконок» и «модных цветов», вы тут же получите противоположное мнение на этот счет.
Эстетика — понятие очень относительное и с ним всегда можно поспорить. У каждого свое представление о «красивом». Если вы дадите шанс об этом рассказать, вам обязательно расскажут.
Оставайтесь в рамках решений, которые напрямую влияют на эффективную работу с интерфейсом. Графика, шрифты, цвета — все это говорит само за себя, нет смысла лишний раз акцентировать на этом внимание.
Вовлекаем клиента
В процессе работы дизайнер принимает сотни микро-решений. Многие остаются за кадром. Важно рассказывать, как вы пришли к тем или иным решениям, какие были альтернативы и почему вы выбрали именно такой вариант. Это сделает вашу позицию более убедительной.
Старайтесь погружать клиента в процесс работы. Узнавайте мнение, оставляйте открытые темы для обсуждения. Он должен понимать и разделять все решения, которые были приняты. Если он будет принимать активное участие, то эмоциональная связь с проектом будет гораздо сильнее.
Не забываем, кто эксперт
Но у вовлечения клиента в процесс есть и ограничения. Не стоит спрашивать его о том, как лучше реализовать ту или иную функциональность. Вы эксперт в области производства мобильных приложений, а не он. Заказчик не разбирается в этом и не должен.
Но все-таки бывают ситуации, когда без клиента не обойтись. Например, выбранное вами решение гораздо дороже прочих. В этом случае нужно: описать ситуацию → рассказать какие есть варианты и почему именно они → какие у них сильные и слабые стороны → какой из вариантов вы рекомендуете и почему.
Обходим острые углы
Не стесняйтесь отстаивать свою позицию, если вы убеждены в её правильности. Но не всегда получается убедить клиента, даже при наличии аргументов. Иногда проще пойти от противного: разобрать другие варианты. В процессе работы вы уже наверняка это сделали и знаете их слабые места. А если нет, то совместно найдете вариант, который устроит обе стороны.
Бывают и обратные ситуации, когда уже клиент отстаивает свою позицию по какому-то решению. Тут все немного сложнее, ведь последнее слово за ним. Если вы не согласны, нельзя просто сказать «Это плохая идея». Лучше всего, чтобы он сам пришел к такому выводу. Можно смоделировать ситуацию, в которой решение окажется нерабочим или будет проигрывать вашему. Попробовать найти компромисс и объединить их в одно. Ещё раз проговорить вводные и убедиться, что все понимают задачу одинаково. Главное не давить авторитетом и идти на диалог.
Решаем проблемы вместе
Проблемы на проекте — общие, вне зависимости от того, на чьей стороне косяк. Поиск виновных не приблизит вас к решению, а только накалит атмосферу. Проанализировать ситуацию во избежание повторений конечно же нужно, но не переходя на личности.
Но если вы откровенно зафакапили или случилось что-то непредвиденное — извинились и сказали, когда и как будете исправлять. Обманывать и что-то скрывать категорически запрещается.
Дизайнер: Ребят, у нас небольшой завал из-за релиза одного из проектов. Не успеем к пятнице сделать все задачи. Сори, что так получилось, на следующей неделе подключим ещё одного человека и нагоним план.
Не путаем цели
У вас, как исполнителя, есть свои цели на проекте. Вам нужен кейс. И чем больше в нем будет «дизайна» и технологий, тем лучше. Нельзя допускать, чтобы это приводило к усложнению проекта и увеличивало бюджет.
Достижение собственных целей должно быть следствием работы над задачами клиента. Не каждый проект сгодится для дрибббла. Но практически в любом можно найти место интересным решениям и экспериментам.
Ответственность
Получается, что клиент всегда прав?
Да, если он не выходит за рамки договора и уголовного кодекса. Вам платят деньги за услугу и вы эту услугу оказываете. Если ваше мнение обосновано и подтверждено, а клиент все равно настаивает на своем — у него есть на это причины. Заказчик принимает решение, исходя из своего опыта, и рискует своими средствами.
Ещё есть вероятность, что человек просто глупый, но это нужно отслеживать до начала проекта. Если начали работать с таким клиентом — значит глуп не он один.
И что, вот это все должен делать дизайнер?
Вовсе нет, можете поручить это менеджеру или попросить клиента самого написать подробное техническое задание. В такой ситуации вы можете потерять контроль над происходящим, работая со следствиями и не зная причин. Конечно, в случае неудачи можно переложить всю вину на заказчика, который «сам не знает, чего хочет». Или на менеджера, который не смог убедить его в ваших решениях.
Но будем честными — если в итоге получается плохой проект и недовольный клиент, то обосрался именно ты.
Автор: Александр Юдин
