Figma при разработке сайта: зачем нужна заказчику и что в ней смотреть
Разбираем Figma глазами заказчика: чем прототип отличается от макета, где оставлять правки, как проверить мобильную версию и что передать разработчику.

Figma при разработке сайта нужна заказчику для контроля будущего результата до вёрстки. В ней можно увидеть структуру страниц, пройти сценарий заявки, проверить мобильную версию и оставить комментарии на конкретных элементах. Это помогает обнаружить непонятные тексты, лишние блоки и ошибки в логике до того, как решения попадут в код.
Что Figma даёт заказчику при разработке сайта
Figma даёт заказчику доступ к актуальному дизайну по ссылке: ничего не нужно устанавливать, а замечания можно привязать к конкретному месту на экране. До начала разработки вы проверяете не только цвета и фотографии, но и логику страниц, тексты, кнопки, формы, адаптацию под смартфон и готовность макета к передаче.
Набор картинок или PDF подходит для презентации, но неудобен для согласования сайта. На изображении нельзя нормально проверить переходы, состояния кнопок и поведение меню. В Figma страницы, экраны и комментарии собраны в одном файле, поэтому команда работает с одной актуальной версией, а не ищет последний вариант по перепискам.
Для владельца бизнеса Figma закрывает несколько практических задач:
- Увидеть, как посетитель найдёт нужную услугу и куда нажмёт для заявки.
- Поймать ошибки до вёрстки: непонятный заголовок, лишний блок, слабый призыв или неудобную форму.
- Согласовать визуальный стиль без постоянной пересылки файлов в мессенджерах и почте.
- Зафиксировать состав сайта, включая мобильные экраны и состояния элементов.
Figma не заменяет проверку готового сайта. В браузере отдельно проверяются скорость загрузки, отображение шрифтов, работа формы, интеграций и админки. Но макет помогает заранее согласовать замысел и уменьшить число дорогих изменений после начала разработки.
Прототип или макет: что вы принимаете первым
Обычно сначала утверждают прототип, затем визуальный макет. Прототип показывает структуру и путь пользователя без детальной графики, а макет фиксирует внешний вид страниц. Если пропустить первый этап, спор о логике сайта часто возникает уже после отрисовки и затрагивает согласованные дизайн-решения.
Прототип похож на план помещения: в нём видны вход, комнаты и проходы, но ещё нет отделки. На сайте обозначают шапку, меню, первый экран, блоки услуг, форму, контакты и подвал. Иногда прототип делают в оттенках серого, чтобы обсуждение не свелось к выбору цвета кнопки.
На этом этапе оценивайте понятность маршрута. Посетитель должен быстро понять, чем занимается компания, где находится нужная услуга, какое действие доступно и как связаться. Если сайт рассчитан на локальный спрос, заранее проверьте адрес, карту, ориентиры и способы связи с менеджером.
| Этап | Что в нём проверять | Цена ошибки |
|---|---|---|
| Прототип | Структуру, порядок блоков, меню, путь к заявке, состав страниц | Исправляется быстрее, пока нет детальной графики |
| Макет | Цвета, шрифты, изображения, тексты, кнопки, отступы, мобильные экраны | Переделки затрагивают дизайн и согласованные решения |
| Вёрстка | Реальное отображение, скорость, формы, адаптивность, интеграции | Изменения могут затронуть код и сроки запуска |
В прототипе особенно полезно проверить список страниц. Для корпоративного сайта это могут быть главная, услуги, отдельная страница услуги, о компании, проекты, контакты и блог. Для интернет-магазина добавятся каталог, карточка товара, корзина, оформление заказа и служебные состояния.
Не утверждайте прототип фразой «в целом нормально». Зафиксируйте, какие страницы входят в работу, где находится форма, какие поля обязательны, куда ведут кнопки и что доступно с телефона. Так разные участники проекта не будут по-разному трактовать одну и ту же задачу.
Как открыть ссылку и не потеряться в Figma
Для просмотра макета достаточно открыть ссылку в браузере. Регистрация пригодится, если вы хотите оставлять комментарии и получать уведомления. В режиме просмотра элементы нельзя случайно сдвинуть, а страницы и экраны находятся в левой панели. Начинайте со структуры файла, а не с увеличения логотипа или выбора оттенка.
После открытия найдите страницы и фреймы - отдельные экраны или области макета. Названия вроде «Главная desktop», «Главная mobile», «Услуга» и «Контакты» помогают понять, что подготовлено. Если файл открывается с просьбой запросить доступ, попросите режим просмотра или комментирования, а не создавайте самостоятельную копию.
- Левая панель показывает страницы файла и группы экранов.
- Центральная область содержит макет; его можно приблизить или отдалить.
- Правая панель открывает свойства выбранного объекта, но заказчику не нужно разбираться в каждом параметре.
- Кнопка запуска прототипа открывает кликабельный сценарий, если дизайнер его настроил.
- Инструмент комментария позволяет поставить отметку на конкретном элементе и написать замечание.
Проходите макет в двух режимах. Сначала откройте прототип и кликайте как обычный посетитель. Потом вернитесь к отдельным экранам и проверьте детали. Такой порядок помогает сначала оценить логику сайта, а уже затем обсуждать шрифты, изображения и отступы.
Что смотреть в макете перед согласованием
Приёмку макета начинайте с бизнес-задачи, а не с вопроса, нравится ли вам дизайн. Проверьте, понятно ли за первые секунды, чем занимается компания, кому она помогает и какое действие предлагает. Затем пройдите путь клиента от первого экрана до формы, звонка, мессенджера или другого согласованного канала.
Для услуг проверьте четыре слоя макета:
- Смысл - заголовок говорит о пользе, рядом есть понятное продолжение или призыв.
- Навигация - посетитель понимает, где находится, может вернуться назад и быстро найти контакты.
- Доверие - показаны условия работы, документы, адрес, реальные фотографии или другой согласованный контент.
- Конверсия - форма не просит лишнего, кнопка заметна, после отправки предусмотрен понятный ответ.
Проверьте тексты отдельно. В макете могут остаться заглушки, слишком длинные заголовки или обещания, которые компания не готова выполнять. Если у бизнеса несколько филиалов, адреса и контакты не стоит прятать в одном общем поле. Согласуйте, какие сведения должны быть видны на странице услуги и в контактах.
Посмотрите на поведение меню. На компьютере оно может быть горизонтальным, а на телефоне - открываться по кнопке. Важна не сама иконка, а её содержимое: нужные разделы, заметная связь с компанией и понятный способ закрыть меню.
Отдельно проверьте формулировки кнопок. «Отправить» сообщает только техническое действие. «Получить расчёт», «Записаться на замер» или «Уточнить наличие» объясняют следующий шаг, если он действительно соответствует процессу компании.
Мобильная версия - не уменьшенный десктоп
Мобильную версию принимайте как отдельный сценарий, а не как уменьшенную копию компьютера. На телефоне проверяют порядок блоков, размер текста, меню, кнопки, формы и отсутствие горизонтальной прокрутки. Если мобильного макета нет, разработчику приходится самостоятельно решать, что скрыть, перенести или заменить.
Откройте все экраны с пометкой mobile и последовательно проверьте:
- Не обрезаются ли заголовки, цены, названия услуг и кнопки.
- Можно ли нажать на элемент пальцем, не попав в соседнюю ссылку.
- Не превратилась ли длинная таблица в нечитаемый набор мелких колонок.
- Видна ли кнопка связи без долгой прокрутки, когда она нужна для заявки.
- Понятно ли, что произойдёт после нажатия: откроется форма, звонок, чат или следующий экран.
- Что показывается при ошибке формы, успешной отправке, пустом каталоге и отсутствии товара.
Для бизнеса в Казахстане мобильный сценарий часто связан со звонком, мессенджером, картой и быстрым поиском адреса. Проверьте, что номер телефона нажимается, ссылки ведут на актуальные аккаунты, а кнопка маршрута открывает нужную карту. Способ оплаты и соответствующая кнопка должны быть описаны без двусмысленности.
Не ограничивайтесь первым экраном. Ошибки часто прячутся в длинной форме, выпадающем списке, карточке товара или подвале. Попросите показать состояния элементов: обычное, наведённое, нажатое, неактивное, с ошибкой и после успешного действия.
Как оставлять правки в Figma, чтобы их поняли
Хорошая правка описывает место, проблему и желаемое изменение. Комментарий «не нравится» не даёт команде критерия для работы. Формулировка «в первом экране заменить обещание на согласованный вариант из брифа и сделать кнопку ведущей к форме» экономит переписку и снижает риск субъективных переделок.
Поставьте комментарий на конкретный объект: заголовок, кнопку, изображение или поле формы. Для одного экрана создавайте отдельные замечания, а не складывайте несколько задач в одном сообщении. После исправления отметьте комментарий решённым только после проверки результата.
- Сначала укажите экран: «Главная, мобильная версия, первый экран».
- Назовите объект: «заголовок над формой» или «кнопка в карточке услуги».
- Опишите действие: заменить, удалить, перенести, сократить или добавить ссылку.
- Если текст утверждён, приложите точную формулировку, а не пересказ голосовым сообщением.
- Отдельно выделяйте обязательные исправления и пожелания, которые можно обсудить позже.
Не отправляйте правки одновременно в Figma, общем чате и личных сообщениях. Выберите один основной канал, иначе часть замечаний потеряется, а команда будет искать финальную версию по нескольким перепискам. Если проект согласуют несколько руководителей, назначьте одного человека для сбора итоговых решений.
Число кругов правок лучше зафиксировать до старта. У нас предусмотрено два бесплатных круга правок. Рациональнее сначала полностью просмотреть экран и собрать замечания, чем отправлять их по одному в течение недели: так проще увидеть взаимосвязи и избежать противоречий.
Что должно попасть из Figma к разработчику
Передача макета считается полноценной, когда вместе с визуальными экранами переданы структура, мобильные версии, тексты, изображения, шрифты, состояния элементов и правила поведения. Одной картинки недостаточно: без этих деталей разработчик будет принимать решения сам, а итог может отличаться от согласованного дизайна.
В Figma разработчик смотрит размеры, отступы, цвета, типографику и взаимное расположение блоков. Из интерфейса можно получить технические значения и экспортировать подготовленные изображения или иконки. Но макет не заменяет отдельное описание интеграций, обработки заявок, ролей в админке, SEO-текстов и нестандартных ситуаций.
- Все страницы из согласованного списка, а не только главная.
- Версии desktop и mobile для ключевых экранов.
- Состояния меню, кнопок, полей, карточек, ошибок и успешных действий.
- Финальные тексты или список материалов, которые ещё готовятся.
- Исходные фотографии, логотип, иконки и сведения о лицензиях на шрифты.
- Ссылки на формы, мессенджеры, карты, оплату и другие внешние сервисы.
Попросите отдельно перечислить то, чего в файле пока нет. Например, не прорисованы состояния фильтра, не согласованы тексты каталога или отсутствует сценарий оплаты. Такая фиксация честнее, чем считать макет готовым, а затем спорить о недостающих экранах уже во время разработки.
В нашей практике хороший дизайн-файл становится рабочей инструкцией для команды, а не только презентацией. При разработке мы используем Next.js и React, закладываем SEO-структуру с первого дня и переносим дизайн в быструю адаптивную вёрстку с удобной админкой.
Сколько внимания уделять Figma и когда нужен подрядчик
Владельцу бизнеса не нужно становиться дизайнером или изучать все панели Figma. Выделите отдельное время на прототип, затем пройдите desktop- и mobile-версии по чек-листу. Для небольшого сайта хватит нескольких последовательных сессий, а каталог, магазин или сложный сервис лучше проверять по разделам.
Заранее решите, кто отвечает за контент и финальное согласование. Когда директор, маркетолог и менеджер отправляют противоречивые комментарии, даже хороший макет превращается в спор. Один ответственный может собрать мнения коллег, убрать дубли и передать исполнителю единый список решений.
Если подрядчик прислал один экран без мобильной версии, не показывает прототип и не объясняет состав передачи, уточните процесс до оплаты следующего этапа. Плохие признаки - обещание «всё адаптируем потом», отсутствие списка страниц, правки только голосовыми сообщениями и нежелание фиксировать согласованные решения.
Спросите перед заказом:
- Какие этапы будут в Figma и когда принимается прототип?
- Сколько экранов и версий входит в дизайн, включая мобильные?
- Кто собирает комментарии и как фиксируются утверждённые решения?
- Что произойдёт, если в макете не хватает состояния формы или страницы?
- В каком виде разработчик получит изображения, шрифты, тексты и технические параметры?
- Как проверяется совпадение готового сайта с согласованным дизайном?
Для ориентира: сайт-визитка начинается от 150 000 ₸ со сроком от 5 дн., лендинг под ключ - от 200 000 ₸ со сроком от 7 дн. Корпоративный сайт начинается от 500 000 ₸, срок - от 21 дн. Точная цена фиксируется после брифа. Домен .kz, хостинг и SSL на первый год входят в разработку.
Если нужен не новый сайт, а обновление существующего, редизайн начинается от 350 000 ₸ со сроком от 14 дн. Интернет-магазин - от 500 000 ₸, срок от 30 дн. После запуска действует гарантия 12 месяцев, а поддержку и доработки можно подключить от 50 000 ₸ в месяц.
Частые вопросы
Большинство вопросов о Figma связано не с интерфейсом, а с границами ответственности. Заказчику нужно понимать, что он принимает в макете, какие решения проверяет сам и что команда должна описать отдельно. Ниже - короткие ответы на ситуации, которые чаще всего возникают во время согласования дизайна.
- Нужно ли заказчику регистрироваться в Figma? Для просмотра обычно достаточно ссылки. Регистрация нужна, если вы хотите оставлять комментарии, получать уведомления и участвовать в согласовании.
- Можно ли открыть Figma с телефона? Да, но подробную приёмку удобнее проводить на компьютере или большом планшете. Мобильный экран лучше проверять в режиме, близком к реальному размеру смартфона.
- Что делать, если макет выглядит хорошо, но непонятно, куда ведут кнопки? Попросите включить кликабельный прототип и показать основные сценарии: заявку, звонок, меню, карточку услуги и успешную отправку формы.
- Обязательно ли прорисовывать все состояния кнопок? Для простого лендинга достаточно согласовать основные состояния, но формы, меню, фильтры и магазин требуют более подробной проработки.
- Можно ли вносить правки после начала вёрстки? Можно, но они могут повлиять на срок и стоимость, особенно если меняется структура или уже готовые блоки. Поэтому сначала лучше принять прототип и макет.
- Figma гарантирует, что сайт будет работать так же, как макет? Нет. Она фиксирует дизайн и сценарии, но скорость, SEO, формы, интеграции и админку проверяют на готовом сайте.
С чего начать проверку макета
Начните с ссылки на Figma и не оценивайте всё одновременно. Найдите список страниц, пройдите прототип как клиент, затем проверьте тексты, формы, мобильную версию и состояния элементов. Соберите замечания в одном месте, привяжите их к объектам и только после этого подтверждайте переход к вёрстке.
Если нужно разработать сайт или обновить существующий, мы разберём задачу на брифе, подготовим структуру и объясним, что именно вы будете принимать в Figma. Pozhidayev работает из Алматы с компаниями по всему Казахстану удалённо; согласование проходит по ссылке, без обязательных встреч в офисе.



