Макетирование: инструменты и методы для создания прототипов

Макет — это способ договориться о продукте до того, как написана первая строка кода. Инструментов для макетирования много, и они отличаются не «удобством вообще», а тем, какую задачу решают: быстро набросать идею, согласовать структуру, показать сложную логику или собрать почти рабочий интерфейс для теста. Ниже разбор основных инструментов и методов и того, как выбирать их под проект и команду.

Точность макета определяет выбор инструмента

Первое, что стоит определить, — уровень точности, который сейчас нужен. Принято выделять три: низкий (наброски и схемы без оформления), средний (структура с реальными текстами и сеткой) и высокий (макет, близкий к финальному виду, иногда с интерактивом).

Ошибка, которую мы регулярно видим, — сразу браться за высокую точность. Красиво оформленный экран сложно обсуждать: разговор уходит на оттенки и фотографии, а структура остаётся непроверенной. И чем аккуратнее макет, тем труднее его выбросить, хотя выбрасывать ранние варианты нормально.

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

Бумага и доска: инструменты нулевого уровня

Бумага, маркер и стикеры остаются самым быстрым способом получить первые варианты. Их сильная сторона — скорость и отсутствие соблазна выравнивать пиксели. За час на бумаге проходят через десяток решений, из которых в редактор попадает одно-два.

Онлайн-доски (Miro, FigJam и аналоги) заменяют бумагу, когда команда распределена. На доске удобно держать карту экранов, сценарии, стикеры с замечаниями и черновые схемы рядом. Доска плохо подходит для точных макетов — в ней нет сетки и нормальной работы с компонентами, — но хорошо работает как место, где собирается вся подготовка перед макетированием.

Редакторы интерфейсов

Основную часть работы делают в специализированных редакторах. Различия между ними сегодня меньше, чем принято думать: все умеют компоненты, автослои, сетки и простые переходы между экранами.

• Figma работает в браузере и рассчитана на совместную работу: несколько человек редактируют файл одновременно, заказчик комментирует прямо в макете, разработчик открывает файл по ссылке и снимает размеры. Для команды с внешним клиентом это чаще всего решающий довод.
• Sketch много лет был стандартом для интерфейсной работы на Mac, вокруг него собрана большая библиотека плагинов. Ограничение очевидное — только macOS.
• Adobe XD удобен тем, кто уже живёт в экосистеме Adobe и переносит материалы из Photoshop и Illustrator; в нём с самого начала были простые прототипы и голосовые сценарии.
• Penpot — открытая альтернатива, которую выбирают, когда файлы должны храниться на своих серверах.

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

Инструменты для сложной логики и анимации

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

• Axure RP исторически применяют для сложных корпоративных систем: переменные, условия, динамические таблицы, подробная документация к макету. Прототип получается близким к техническому заданию, но и порог входа выше.
• ProtoPie и Principle нужны для проработанной анимации и жестов, чаще всего в мобильных приложениях.
• Framer занимает промежуточное положение между макетом и кодом и позволяет собрать интерактивную страницу, близкую к рабочей.

Использовать такие инструменты имеет смысл, когда без интерактива решение не принимается. Для сайта услуг из семи страниц Axure не нужен.

Сравнение: что чем удобнее делать

Как выбирать инструмент под задачу и команду

Мы исходим из четырёх вопросов, и они почти всегда дают однозначный ответ.

1. Кто смотрит макет. Если заказчик, нужна ссылка в браузере и комментарии прямо в файле. Если только команда, подойдёт что угодно.
2. Какое решение принимается. Согласование структуры требует схем, проверка сценария — кликабельного прототипа, оценка вёрстки — макета с сеткой и стилями.
3. Кто будет поддерживать файл. Инструмент, которым владеет один человек в команде, становится узким местом при первом же отпуске.
4. Что получит разработчик. Из макета должны сниматься размеры, цвета и состояния элементов без переписки.

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

Методы макетирования, а не только инструменты

Инструмент сам по себе макет не делает. Порядок работы у нас выглядит так.

• Карта экранов. Сначала список страниц и связей между ними, потом отдельные экраны. Без карты появляются страницы, на которые ниоткуда нет ссылок.
• Схемы без оформления. Структура, реальные подписи кнопок, черновые тексты. Это основной предмет согласования.
• Состояния. К каждому экрану — пустой список, загрузка, ошибка, длинный текст, отсутствие изображения. Раздел, о котором чаще всего забывают.
• Кликабельная сборка. Переходы между экранами для проверки сценария на людях.
• Оформление. Цвет, шрифты, изображения — после того, как структура принята.

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

Ошибки, которые встречаются чаще всего

• Макет собран копированием, без компонентов: любая правка растягивается на часы.
• В схемах стоят заглушки вместо текстов, и после копирайтинга вёрстка перестаёт сходиться.
• Нарисован только десктоп, а мобильную версию оставляют «на усмотрение вёрстки».
• Файл существует в пяти вариантах без указания актуального, и разработка ведётся по устаревшему.
• Прототип показывает только успешный путь, поэтому ошибки и пустые экраны придумываются на ходу.
• Инструмент выбран по моде, а не по задаче: для лендинга собирают сложный интерактив, для системы с ролями обходятся статичными картинками.

Зачем прототип, если будет дизайн

Дизайн отвечает на вопрос «как это выглядит», прототип — «как это работает». Схема без оформления переводит разговор из области вкуса в область задач: на ней видно, найдёт ли человек нужное и сколько шагов ему придётся сделать от рекламы до заявки.

• Заказчик видит состав страниц до того, как потрачен бюджет на графику.
• По схеме оценивают объём работ: сколько типов страниц рисовать и верстать.
• Копирайтер получает задание: где нужен заголовок в шесть слов, а где абзац в три строки.
• Появляется список того, что надо подготовить: тексты, фотографии, прайс, документы.

Сколько стоит поздняя правка

Стоимость изменения растёт по мере готовности проекта, поэтому прототип окупается почти всегда: основная часть споров переезжает в самое дешёвое время.

Что подготовить до первой схемы

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

• Три-пять таких фраз — по одной на каждую группу посетителей.
• Главное для бизнеса действие: заявка, звонок, заказ, регистрация.
• Возражения, с которыми приходят: дорого, долго, не доверяю, не понял, подойдёт ли мне.
• Основное устройство аудитории. Если это телефон, схему рисуем сначала для телефона.

На бумаге полезны два приёма. Рисовать в рамке размером с телефон — в узкую колонку лишнее не помещается, и приоритеты расставляются сами. И рисовать не блоки, а ответы на вопросы посетителя, по одному на блок: тогда в схеме не появляются разделы, которые есть только потому, что они есть у конкурентов. Заказчику показывают два-три варианта, а не один, — иначе обсуждение превращается в согласование, а не в выбор.

Какой точности хватит вашему проекту

Сайту-визитке и типовому сайту услуг обычно хватает схем без оформления: сценарии простые, картинок в документе достаточно. Интернет-магазину нужны те же схемы плюс кликабельные фильтры и корзина. Сервис с личным кабинетом, многошаговой заявкой или расчётом стоимости без кликабельного прототипа не обойдётся: по нему заказчик сам проходит путь пользователя и видит, где сценарий буксует. Собирать все переходы с первого дня не стоит — после первой правки структуры связи придётся переделывать заново.

Как проверить и принять прототип

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

При приёмке смотрите на каждую страницу как посетитель, а не как владелец, и задайте три вопроса: понятно ли за пять секунд, куда я попал; видно ли следующее действие; хватает ли информации, чтобы его сделать. Прототип готов, когда по нему можно оценить работу и написать тексты: понятен состав страниц, известно поведение на мобильном, описаны нестандартные состояния. Простая проверка — отдать его человеку, который не участвовал в работе, и попросить пересказать, что делает каждая страница и что происходит после нажатия главной кнопки. Всё, что приходится объяснять словами, в прототипе не описано.

С чего начать, если макетов ещё нет

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

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