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