Почему страница рассыпается на этапе вёрстки: wireframe прототип
Правки на вёрстке дороже всего: макет согласован, разработка идёт, и тут выясняется, что два блока претендуют на главный акцент, а порядок карточек на узких экранах никто не продумал. Дизайнер рисовал композицию, а не структуру страницы — и каждый спор решается заново, уже в коде, где смена разметки тянет за собой стили и логику.
Вторая точка переделок на вёрстке — неописанные состояния. Пустой список, заголовок в две строки, ошибка загрузки, отсутствие прав у пользователя, тысяча записей вместо десяти: если прототип интерфейса показывает только идеальный случай, вёрстка обрастает догадками. Каждый участник придумывает поведение сам, и на приёмке всплывает, что фильтры на списке и на детальной работают по-разному, а возврат к результатам сбрасывает выбор.
Расхождение логики между экранами — третья статья расходов. Шаг формы, поведение всплывающего окна, постраничный переход, реакция на повторное нажатие — всё это должно быть зафиксировано на уровне каркаса, до визуальной части, иначе один и тот же сценарий верстается дважды и по-разному.
Wireframe прототип снимает эти вопросы заранее: каркас страницы сайта задаёт сетку, иерархию блоков, их порядок на разных ширинах и все состояния каждого элемента. Правка на этом этапе занимает минуты, на вёрстке — дни. Разбираем, как это закрывается.
Что даёт каркас страниц: измеримый эффект для проекта
Сроки согласования. Каркас фиксирует состав блоков и их приоритет до появления визуального дизайна, поэтому спор о месте формы заявки решается на одной схеме, а не на трёх готовых макетах. Согласование интерфейса перестаёт растягиваться на недели переписки: правка в каркасе вносится за минуты.
Объём переделок. Правка на этапе каркаса затрагивает один блок; та же правка в собранном интерфейсе — разметку, логику и тексты сразу в нескольких местах. Большая часть замечаний, которые обычно всплывают на приёмке, закрывается заранее, до строчки кода.
Порядок в требованиях. Каждый экран каркаса — это перечень полей, состояний и переходов между ними. Разработчик получает его как задание, а не восстанавливает логику по картинке, поэтому вопросы вида «а если данных нет» задаются до старта, а не в середине работы.
Стоимость доработок. Доработка, найденная на каркасе, — это один разговор и одна правка схемы. Та же доработка после запуска превращается в отдельную задачу с повторной сборкой, проверкой соседних экранов и повторным тестированием.
Количество спорных правок. Согласованный каркас — общий документ, на который ссылаются и команда, и заказчик. Правки «по вкусу» после него почти не возникают: приёмка идёт по заранее оговорённым состояниям экранов, а не по субъективным ощущениям.
Wireframe прототип: форматы работы от эскиза до кликабельной модели
Формат прототипа выбирают не по вкусу, а по типу неопределённости в задаче: где риск ошибки выше — в структуре страницы, в логике переходов или в визуальном языке. Мы держим несколько уровней детализации и не переходим на следующий, пока не сняты вопросы предыдущего.
Сравнение подходов
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Эскиз страницы | Нужно быстро проверить состав блоков и порядок смыслов | Нет сетки и пропорций, по нему нельзя верстать |
| Статичный каркас | Согласование структуры с несколькими участниками, тексты ещё не готовы | Не показывает поведение элементов и переходы между экранами |
| Детализированный каркас | Зафиксированы состояния форм, таблиц, пустых и ошибочных экранов | Не даёт почувствовать динамику, нужен макет для оценки визуала |
| Кликабельная модель | Проверка сценария целиком: пользователь проходит путь до результата | Больше времени на сборку и синхронизацию с логикой продукта |
Эскиз и статичный каркас отвечают на вопрос «что на странице», кликабельная модель — «как пользователь доходит до цели». На практике форматы совмещают: каркас фиксирует структуру, иерархию и правила отображения данных, поверх собирается интерактивная модель для проверки ключевых сценариев — регистрации, оформления заявки, оплаты.
За рамками остаются визуальный стиль, анимации и финальные тексты. Их решают на макетах, чтобы переделка каркаса не задевала уже согласованную вёрстку.
Как строится работа: этапы от аудита до передачи
Порядок шагов задаёт цена ошибки: чем позже промах в структуре всплывает, тем дороже его исправлять. Поэтому wireframe-прототип собирают до дизайна и вёрстки — на нём проверяют сценарии, а не оформление. Каждый этап заканчивается артефактом, который можно открыть и обсудить, а не устным «вроде норм».
- Разбор задачи и аудит структуры сайта: цели, роли пользователей, текущая карта разделов, пути из аналитики. Результат — перечень экранов с приоритетами и план работ по этапам создания прототипа.
- Схема экранов. Каждый сценарий раскладываем в цепочку: откуда пришёл, что видит, куда идёт дальше. Фиксируем развилки, тупики и точки возврата.
- Сборка каркаса. Каркас собираем в Figma: блок — это рамка, подпись и логика содержимого. Без цвета и типографики, чтобы спор шёл о структуре, а не о вкусах.
- Проверка сценариев. Прогоняем кликабельный прототип по ключевым путям — заявка, поиск, оформление, возврат — и смотрим, где теряется контекст и не хватает состояний «пусто», «ошибка», «загрузка».
- Правки и согласование. Замечание превращаем в задачу с формулировкой и приоритетом, а не в «сделайте покрасивее»; история версий каркаса сохраняется.
- Передача в разработку. Отдаём не картинки, а экраны с описанием состояний и поведением элементов — дизайнер и разработчик видят одну картину, а оценки сроков становятся точнее.
Что остаётся у команды заказчика: документация и регламенты
Прототип без сопроводительных материалов живёт до первого спора: разработчик трактует макет по-своему, правка ломает уже согласованную логику, а через полгода никто не помнит, почему блок стоит именно так. Поэтому у команды заказчика остаётся не набор картинок, а документация по wireframe-прототипу — её можно передать другому подрядчику и продолжать развитие без нас.
- Схемы всех экранов с сеткой и иерархией блоков, включая служебные: вход, восстановление доступа, состояния отказа.
- Спецификация экранов: назначение, обязательные элементы, источник данных, доступные действия для разных ролей.
- Правила состояний: пустой список, загрузка, ошибка сети, частично заполненные данные, результаты проверки форм.
- Правила адаптива: как перестраиваются блоки на контрольных ширинах, что сворачивается и меняет порядок.
- Регламент передачи: состав материалов, форматы файлов, момент готовности к разработке и кто её подтверждает.
- Порядок правок: как фиксируются изменения, как нумеруются версии прототипа, кто согласует и в какие сроки.
- Инструкция для разработки и тестирования: привязка экранов к логике, точки интеграции, перечень проверок перед сдачей.
Комплект хранится в общем репозитории проекта, а не в переписке: макет и документация обновляются одним изменением, поэтому спецификация не расходится с интерфейсом.
Кейс: каркас личного кабинета и переделки, которых не случилось
Клиент — сеть клиник МедАльянс с личным кабинетом для пациентов: запись на приём, результаты анализов, история визитов, оплата. Разделы делали разные команды, навигация в каждом жила по своей логике, а структуру согласовывали на словах и поверх почти финальных макетов. Любая уточнённая деталь тянула за собой пересборку нескольких страниц.
Что показывали до вёрстки
Собрали каркас из 16 экранов: серые блоки, реальные подписи, без цвета и оформления. На каждом обозначили зоны, приоритет содержимого и переходы — пустой список, загрузка, ошибка, нет доступа, длинная выдача.
Кликабельный прототип прошли вместе с координатором пациентов и администратором стойки, то есть с теми, кто ведёт человека от заявки до результата. Их возражения снимали правкой каркаса, а не перерисовкой готового интерфейса.
Что изменилось
По структуре набралось 41 спорное место. Тридцать четыре закрыли на этапе каркаса: переставили блоки, объединили дублирующиеся разделы, вынесли оплату в отдельный шаг.
Согласование структуры заняло девять дней вместо пяти недель — два круга правок вместо шести. До вёрстки дожили семь замечаний, а переделки затронули два экрана вместо одиннадцати: остальное к моменту сборки было уже решено и в работу не возвращалось.
Чем отличается каркас страницы от готового дизайн-макета
Каркас отвечает на вопрос «что и в каком порядке», макет — «как это выглядит». На уровне каркаса фиксируются состав блоков, их приоритет на странице, число состояний у формы и поведение при нехватке данных: пустой список, ошибка загрузки, длинное название в две строки. Визуальные решения здесь намеренно не принимаются — иначе обсуждение структуры утонет в спорах о цвете кнопки.
Дизайн-макет — следующий уровень детализации. В нём появляются типографическая шкала, сетка и отступы, состояния элементов (наведение, неактивное, ошибка валидации), правила для узких экранов. Каркас оперирует блоками-заглушками, макет — реальными размерами и контрастом, по которым страница собирается без догадок.
Между ними часто ставят кликабельную модель: переходы между экранами собираются прямо на каркасе, и заказчик проходит путь целиком — от входа до подтверждения. Так проверяются сценарии, а не картинка: где теряется контекст, сколько шагов до цели, что происходит при возврате назад.
Каркас (wireframe-прототип) нужен, когда сценарий новый или спорный: несколько ролей, ветвление, ответы внешних систем. Для типовой страницы по уже принятой системе достаточно эскиза состава блоков — дальше сразу макет.
Уровни детализации задают цену правки. Перестановка блоков на каркасе занимает минуты, та же правка после вёрстки тянет пересборку шаблонов и повторную проверку адаптива — поэтому спорное дешевле закрыть на самом грубом уровне.
Частые технические сомнения по каркасам страниц
Каркас фиксирует не внешний вид, а договорённость между дизайном и разработкой: сетку, порядок блоков, приоритет контента и поведение на разных ширинах. Поэтому большинство технических вопросов по нему возникает не на этапе рисования, а когда каркас начинает расходиться с реальными данными, состояниями экранов и уже написанным кодом.
Ниже — то, что чаще всего уточняют инженеры и руководители, прежде чем каркасы уходят в вёрстку.
Каркас рисуется один раз под широкие экраны?
Нет. Адаптивные каркасы описывают одну сетку с точками перестроения: сколько колонок остаётся, что переносится вниз, что скрывается, где блок превращается в горизонтальную прокрутку. Для каждой контрольной ширины фиксируется порядок блоков и поведение длинных текстов, таблиц и форм — иначе при вёрстке эти решения принимаются наугад.
Что показывать, пока данных нет?
Состояния экранов проектируются вместе с каркасом: пустое состояние с подсказкой и действием, загрузка со скелетоном вместо пустоты, ошибка запроса с повтором, частично заполненный список, переполнение. Это те же каркасы, просто для других условий — позже их не приходится дорисовывать в спешке.
У нас часть разделов уже свёрстана — переделывать всё?
Нет. Каркас накладывается на существующие страницы: мы разбираем текущую структуру, отмечаем блоки, которые остаются как есть, и описываем точечные доработки интерфейса — новые модули, изменённый порядок, перестроение сетки. Так объём правок остаётся предсказуемым и не тянет за собой переписывание рабочего кода.
Что происходит с каркасами дальше, при поддержке сайта?
Они остаются рабочим документом. Каркасы передаются в виде исходных файлов и текстовой спецификации по блокам и состояниям, поэтому новые разделы собираются по той же логике, а доработки интерфейса не ломают уже согласованные решения. При поддержке сайта изменения сначала отражаются в каркасе, потом уходят в код.
Опишите задачу — вернёмся с оценкой и планом работ по каркасам и вёрстке.Обсудим задачу и вернёмся с планом работ
Чтобы вернуться с оценкой работ, а не с общими словами, нам нужно понять продукт и контекст. Опишите задачу в свободной форме: что за сервис, кто им пользуется, какие сценарии важнее остальных. Этого достаточно, чтобы предложить структуру wireframe-прототипа и назвать порядок старта.
На входе полезны:
- перечень страниц или экранов — хотя бы по разделам, без детализации;
- роли пользователей и их задачи на каждом шаге;
- что есть сейчас: старые макеты, аналитика, брендбук, тексты, требования согласующих;
- ограничения: обязательные блоки, интеграции, форматы передачи в разработку;
- приоритеты: что нужно в первой итерации, что можно отложить;
- состав согласующих и режим, в котором они дают обратную связь;
- ориентиры по срокам, если они уже есть.
В ответ вы получаете не общие обещания, а разбор: какие блоки входят в план прототипирования, в каком порядке они собираются, что потребуется от вашей стороны на каждом шаге и сколько времени займёт каждый этап. Если часть данных отсутствует, скажем, чем её заменить и как это повлияет на точность оценки.
Опишите задачу письмом, документом или коротким разговором — вернёмся с оценкой работ, планом прототипирования и понятным порядком старта.