Недавно мы обсудили, как принять задачу заказчика, а теперь разберёмся, как показать готовую работу, почему появляются замечания и как с ними работать.

Презентация

Я придерживаюсь двух простых принципов.

Первый принцип. На встрече должен присутствовать человек, который примет финальное решение по проекту. Сотрудник, не принимающий решение, может всё согласовать, а через неделю макет увидит ЛПР и скажет всё переделать. Таких ситуаций нужно избегать, потому что затягиваются сроки и в команде проекта растёт напряжение.

Второй принцип. Показывать работу можно только на совместных встречах онлайн или офлайн.

Это важно по нескольким причинам:

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

2. Заказчик не может самостоятельно оценить уникальность и важность дизайнерских и структурных решений — каждый элемент нужно презентовать как мини-проект и рассказывать, рассказывать, рассказывать.

3. Заказчику для принятия решения нужна поддержка: возможно, он и сам не понимает, нравится ему созданный макет или нет. Тут я придерживаюсь такой логики: менеджер объяснит, почему картинка хороша, коллеги заказчика — почему плоха.

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

Работа с замечаниями

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

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

1. У заказчика иное представление о том, как должно быть. Такое бывает, это нормально. Если мы твёрдо уверены, что наше решение лучше, чем то, что предлагает клиент, мы должны перепрошить представление клиента. Нужно привести аргументы, показать примеры.

2. У заказчика в голове содержится база знаний о своём бизнесе, процессах, сотрудниках, покупателях и т. д. Возможно наше решение не совпадает с текущими процессами, стратегией. В таком случае нужно спрашивать, как обстоят дела прямо сейчас, и придумывать решения на ходу.

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

Разобраться в сомнениях клиента поможет довольно известная техника «5 почему». Её суть в том, что нужно примерно 5 вопросов для выявления первопричины возникшей проблемы на производстве. Чтобы разобраться в мотивах, эта техника тоже подходит.

Второй тезис заключается в том, что обсуждение замечаний — это не доказывание своей правоты и крутости картинки. Это ещё один способ поговорить с клиентом о его бизнесе, объяснить решение команды и шанс научиться друг у друга важным вещам. Генеральный директор наверняка отлично знает, как управлять компанией, но может не знать, как работают интерфейсы, — это разные области знаний.

Почему клиент не всегда прав

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

Он: вот смотри. Можешь рассказать, что думаешь о логотипе, и оценить его?

Я: цвета не медицинские, апельсин на коктейльной рюмке не уместен в этом случае, название сомнительное, весь логотип сомнительный.

Он: ок, а теперь посмотри на эту картинку, можешь рассказать, что думаешь, и оценить?

Я: ну это, видимо, код на джаваскрипте, есть пояснения от разраба, описаны какие-то условия, обычный разработческий вайб, может, это нейросеть даже писала.

Он: это не джаваскрипт. Просто этот и предыдущий артефакты — штуки одного уровня, но когда мы смотрим картинку, мы можем сказать «так, ну цвета не те, я бы пошел в другую сторону», а когда смотрим на код «так, ну у меня, конечно, нет компетенций, ничего сказать не могу». Но фактически, что тут 10 лет опыта, что там. Эффект Даннинга — Крюгера работает одинаково.

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

После встречи

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

Затем жду подтверждение от клиента, что ни одна правка не упущена.

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

О доверии

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

Хорошо сделанная работа требует доверия. Например, дизайнер сдаёт макет. Сперва руководитель не доверяет, задаёт много вопросов, пишет замечания, просит переделать. Ему кажется, что он лучше знает, он же руководитель. Если макет продуман и дизайнер — профессионал, то он доказывает свою правоту, а не бежит править и злиться. Через некоторое время менеджер начинает доверять дизайнеру (и подучивается в дизайне сам) и больше не задаёт вопросов.

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

Выводы и принципы

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

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

В идеале клиент должен давать комментарии только по бизнес-логике или юридическим аспектам. Макеты — дизайнерам, тексты — редакторам и т. д.

С заказчиком нужно выращивать доверительные отношения, тогда работать станет комфортнее, а результат будет лучше.