Раздражает не клиент — раздражает то, что один и тот же косяк повторяется снова и снова в разных проектах.
Проект с клиентом редко проваливается из-за одной крупной ошибки. Чаще он расшатывается в нескольких конкретных точках — на старте, при разговоре о деньгах, на сроках, в правках и на сдаче — и в каждой из них есть свой механизм провала, который повторяется почти у всех, кто работает с клиентами напрямую. Если разложить весь цикл проекта по этим точкам, видно, что почти любая «сложность с клиентом» сводится к одной из пяти типовых ситуаций.
Самая частая причина провала на этом этапе — не плохие вопросы, а порядок, в котором они задаются. Большинство брифов начинаются с вопросов про внешний вид: цвет, стиль, настроение. Клиент на этом этапе ещё не сформулировал задачу для себя, и вопрос про стиль попадает в пустоту — ответ получается случайным, потому что у клиента нет основания, от которого можно отталкиваться.
Рабочий порядок идёт в обратную сторону: сначала бизнес-контекст — кто покупатель, что человек должен сделать после того как увидит результат, какое целевое действие стоит за всем проектом. Потом — опыт и ограничения: что не понравилось в предыдущем решении, какие сроки и бюджет. И только в конце — референсы и визуальные ожидания, когда у дизайнера уже есть рамка, в которую референс можно поместить.
Человеку проще критиковать существующее, чем описать словами идеал с нуля. «Что не понравилось в прошлом сайте» почти всегда даёт более точный ответ, чем «какой стиль вам нравится» — потому что критика конкретна, а описание вкуса абстрактно.
Если бриф собран в правильном порядке, но ответы всё равно расплывчатые — проблема не в брифе, а в том, что у клиента ещё нет словаря для описания результата. В этом случае помогает не более подробный вопрос, а замена вопроса на выбор между двумя готовыми вариантами: сравнивать человек умеет даже тогда, когда сформулировать разницу словами не может.
Разговор о предоплате почти у каждого начинающего дизайнера вызывает неловкость, и причина не в характере, а в структуре самой работы: дизайнер просит деньги до того, как результат показан, и это ощущается как просьба поверить в долг. На фултайм-позиции зарплата приходит после отработанного месяца, и привычка просить вперёд там просто не успевает сформироваться.
Формулировка-факт звучит так же естественно, как срок сдачи или формат файлов. Формулировка-извинение сигнализирует клиенту, что условие необязательное, и провоцирует торг.
Стоимость самой работы тоже решается на этом этапе, и здесь сталкиваются два подхода: почасовая ставка честно отражает потраченное время, но наказывает за рост навыка — чем быстрее работает опытный дизайнер, тем меньше он зарабатывает на той же задаче. Фиксированная цена за объём снимает это противоречие, но требует уметь оценить объём заранее, а это умение само нарабатывается только с опытом нескольких проектов.
Отказ клиента от любой формы предоплаты без внятной причины, кроме «я не знаю вас» — отдельный сигнал, который стоит учитывать сразу, а не разбираться с ним постфактум: это не повод соглашаться на условия из страха потерять клиента, а повод присмотреться к проекту внимательнее ещё до его начала.
Дедлайн почти никогда не срывается в последний день — он срывается в момент, когда срок называется клиенту наугад, без реального расчёта. Дальше всё держится на серии хрупких допущений: проект пойдёт по плану, клиент пришлёт материалы вовремя, ничего непредвиденного не случится. Стоит одному из допущений не сработать, и комфортный срок превращается в горящий.
Правильный расчёт срока складывается не из одной цифры «сколько займёт макет», а из трёх отдельных частей: время на саму работу, время на ожидание реакции клиента и буфер на непредвиденное. Большинство дизайнеров считают только первую часть — отсюда системное расхождение между заявленным и реальным сроком на каждом проекте.
У задержки есть два разных источника, и с ними нужно работать по-разному. Если задерживает клиент — не присылает тексты, не согласовывает вовремя — дизайнер должен закладывать эту зависимость в график заранее, иначе он автоматически принимает чужую задержку на свой счёт. Если оценка объёма работы изначально была неверной — единственное рабочее решение — сообщить о риске сдвига заранее, за несколько дней до дедлайна, а не молчать до последнего момента в надежде уложиться.
Правки расходятся на два разных типа проблем, и важно различать их, потому что решения для них противоположны. Первая проблема — путаница между правкой и новой задачей: клиент не видит разницы между «поменять цвет кнопки» и «пересобрать структуру страницы», потому что обе просьбы формулируются одним коротким предложением и выглядят одинаково простыми на словах. Решает это не молчаливое согласие на всё подряд, а прямое называние границы в моменте — что считается правкой по уже утверждённому решению, а что новым этапом работы, который оплачивается отдельно.
Вторая проблема — правки, которые формально укладываются в рамки утверждённого объёма, но не заканчиваются. Каждая отдельная правка крошечная, но пятый круг начинается через неделю после третьего, и конца не видно. Здесь не помогает разбор границы правка-задача, потому что формально каждая правка легитимна. Помогает заранее объявленное количество бесплатных кругов — после которого дальнейшие правки оплачиваются — или, если такая договорённость не была зафиксирована заранее, собрать всё накопившееся в единый финальный список и закрыть макет этим заходом.
Большинство проектов не имеют резкого перехода от «в работе» к «готово» — работа просто плавно затихает, дизайнер перестаёт что-то менять и переходит к следующему проекту. Для клиента эта граница незаметна: он видит тот же чат, тот же макет, который вроде бы можно ещё чуть-чуть улучшить. Без явной точки завершения любая будущая мысль клиента о макете автоматически попадает в категорию «он же ещё в работе, можно попросить» — отсюда «доделай вот это» через неделю после оплаты.
Правильная сдача состоит из трёх частей, и пропуск любой из них оставляет лазейку для будущих просьб: итоговые файлы без недостающих исходников, короткое объяснение логики ключевых решений, и прямая фраза о завершении проекта. Без третьей части первые две выглядят как очередной промежуточный этап, а не финал.
Если просьба «доделать» приходит уже после объявленного закрытия, дизайнер реагирует по тому же принципу, что применялся бы во время работы: мелкая правка либо делается бесплатно из доброй воли, либо называется новой задачей и считается отдельно. Разница с тем, что было бы до сдачи — теперь оба варианта одинаково законны, потому что проект формально закрыт и никакая дальнейшая работа не входит в него по умолчанию.
В каждой из пяти точек провал почти никогда вызван злым умыслом клиента или непрофессионализмом дизайнера. Он вызван тем, что момент перехода — от вопроса к ответу, от работы к оплате, от черновика к финалу — не был назван явно вслух. Бриф работает, когда вопросы заданы в правильном порядке. Деньги работают, когда условие звучит как факт, а не просьба. Сроки работают, когда расчёт честный с самого начала. Правки работают, когда граница названа в моменте. Сдача работает, когда финал объявлен прямо.
Устал собирать бриф в переписке? Отправляешь заказчику ссылку — и через пять минут у тебя готовый PDF вместо трёх дней переписки.
@briefburo_bot