Проектирование веб-интерфейсов: от прототипа до готового макета

А бизнес потом гадает, откуда провал в воронке.

Решение — не в «красивом дизайне». Решение — в системном проектировании интерфейса, где каждый отступ работает на конверсию, а каждый экран спроектирован под поведение реального человека. Дальше — разбор процесса от первого вайрфрейма до финального Hi-Fi макета. Без воды. С конкретными инструментами и методиками. Бери и внедряй.

Эволюция концепции: от вайрфрейма до интерактивного прототипа

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

Вайрфрейм (wireframe). Схематичный каркас. Чёрно-белый. Без стилистики, без брендинга, без реальных текстов. Его задача — зафиксировать структуру и иерархию контента. Где заголовок, где CTA, сколько блоков на экране, какая навигация. Это скелет. И только скелет.

Мокап (mockup). Визуализация финального стиля. Цвета, типографика, реальные изображения, брендинг. Но — статичная картинка. Кликнуть нельзя. Скроллить — тоже. Это то, что ты показываешь заказчику на утверждение, чтобы он перестал мучить тебя правками после верстки.

Прототип (prototype). Мокап, оживлённый интерактивностью. Кнопки кликабельны. Переходы анимированы. Пользовательский сценарий можно «прожить» от лендинга до чекаута. Это инструмент тестирования, а не презентации.

Разница — не в уровне детализации, а в функции. Вайрфрейм отвечает на вопрос «что где стоит». Мокап — «как это выглядит». Прототип — «как это работает».

Смешиваешь вайрфрейм и мокап — получаешь гору правок. Пропускаешь прототип — получаешь гору багов после релиза.

Пропуск любого из трёх этапов — это не экономия. Это перекладывание стоимости на следующую фазу. И стоимость эта растёт экспоненциально.

Считай математику: правка вайрфрейма стоит 1 час. Правка мокапа — 4–6 часов. Правка на этапе верстки — 15–40 часов. Правка после релиза — от 80 часов и выше. Каждый пропущенный этап — это нули в бюджете. Принцип простой: дешевле ловить ошибки на экране в Figma, чем в продакшн-баг-трекере.

Как менялся инструментарий

Любопытный исторический штрих: вайрфреймы как методология появились задолго до веба. Axure RP вышел в начале 2000-х — вместе с книгой Джесса Джеймса Гарретта «Элементы пользовательского опыта», которая заложила слоистую модель UX. С тех пор инструменты изменились кардинально: Balsamiq и карандаш уступили место Figma и FigJam, а ручная верстка HTML-прототипов — фреймворкам вроде Framer и Principle. Но принцип остался прежним: думай слоями. Стратегия → содержание → структура → скелет → поверхность. Эту последовательность Джесс Гарретт заложил в 2000 году, и она до сих пор работает как опорная рамка для любого проекта.

Математика интерфейса: зачем нужна 8-пиксельная сетка и как её применять

Забудь слово «попадать в пиксель». Это прошлое. Сегодня стандарт — 8pt grid. И это не мода, а инженерная гигиена.

Стандарт 8pt — это не про физику экрана, а про инженерную конвенцию. Когда отступы, размеры компонентов и высоты контролов кратны одному базовому шагу, дизайнер и разработчик говорят на одном языке: 8, 16, 24, 32 — без расшифровок и согласований. Меньше правок, меньше сюрпризов на этапе верстки. Это соглашение между участниками проекта, которое масштабируется вместе с дизайн-системой: один раз прописал шаги — и компоненты собираются как конструктор.

Как это работает на практике

На практике кратными 8 обычно делают отступы между блоками, размеры крупных компонентов, высоты кнопок и стандартные межсекционные промежутки. Внутри компонента — на уровне паддингов и микро-отступов — допустим шаг 4px. Это особенно заметно, когда речь о тексте: браузер рендерит шрифты субпиксельно, и жёсткая привязка каждого размера шрифта к базовой линии 8pt даёт артефакты и неестественные межстрочные интервалы. Поэтому чистая кратность восьми — это идеал, а не догма: отступай от неё там, где тексту это полезно.

Применяй два подхода:

Soft grid (мягкий метод). Кратными 8 делаются отступы между блоками, размеры компонентов, высоты крупных контролов. Текст живёт своей жизнью — его размеры и межстрочные интервалы не привязаны жёстко к сетке. Это рабочий стандарт для веб-интерфейсов. Большинство современных дизайн-систем — Material Design, Apple HIG, Tailwind UI — используют именно мягкий подход.

Hard grid (жёсткий метод). Всё, включая текст, привязано к сетке. Подходит для иконочных сетов, иллюстраций, брендовых UI-китов. Для веб-страниц — избыточно и усложняет коммуникацию с верстальщиком.

8pt grid — не про «красиво». Это про скорость. Дизайнер и разработчик говорят на одном языке: отступ 16, 24, 32 — и всё сходится без переписки.

Конкретный набор значений, который живёт в большинстве современных дизайн-систем:

• 4px — микро-отступы, толщина бордеров, мелкие корректировки внутри компонента.
• 8px — базовый шаг. Отступы между иконкой и текстом, внутренние паддинги кнопки.
• 16px — стандартный отступ между элементами в карточке, межсекционные промежутки.
• 24px — отступы между крупными блоками, внутренние поля карточек.
• 32px — секционные промежутки, высоты строк в таблицах.
• 48px — высоты кнопок, крупных элементов управления.
• 64px и выше — заголовочные зоны, hero-секции.

Если у тебя нет дизайн-системы — заведи хотя бы таблицу с этими значениями. Это заметно сократит время на макетирование и уберёт большинство конфликтов с версткой на этапе сдачи макета. В Figma — через Variables или простую страницу со swatch-переменными. В Sketch — через Symbols с фиксированными размерами. В коде — через CSS custom properties или токены в дизайн-токен-системе вроде Style Dictionary. Главное — задокументировать шкалу один раз и больше к ней не возвращаться как к предмету споров.

Адаптивная архитектура: 12 колонок и точки перехода в современном вебе

Bootstrap задал стандарт, и рынок его проглотил. 12-колоночная сетка — это не про «используй Bootstrap». Это про логику раскладки, которая работает везде: Figma, Sketch, кастомная верстка.

Почему 12? Потому что делится на 2, 3, 4, 6. Любой макет — двухколоночный, трёхколоночный, шестиколоночный — ложится в 12 без остатка. Это математика делимости, а не вкусовщина. Когда клиент просит «а давайте четыре колонки блоков услуг на десктопе и две на планшете» — ты мгновенно пересчитываешь: 12 / 4 = 3, 12 / 2 = 6. Без калькулятора.

Пять точек перехода, которые закрывают большинство экранов

Ключевой инсайт: не адаптируй всё под все разрешения. Сфокусируйся на трёх контрольных точках:

1. 375px — минимальный мобильный экран. Тут проверяешь, что контент не ломается, кнопки кликабельны (минимум 44×44px по Apple HIG), текст читаем.

2. 768px — планшетная зона. Тут обычно происходит «перелом» с одноколоночного на двухколоночный макет.

3. 1440px — десктоп. Тут проверяешь, что контент не растягивается на всю ширину ультраширокого монитора, а живёт в комфортной читаемой зоне.

Остальные брейкпоинты — промежуточные. Дизайнер проверяет, верстальщик фиксит. Но контрольные три — это твой чек-лист приёмки. Современная практика mobile-first идёт дальше: проектируешь базу под минимальный экран, потом расширяешь вверх — добавляешь колонки, увеличиваешь отступы, появляется место для второстепенного контента. Это не философия mobile-first как лозунг, это прагматика: на десктопе контент можно разрядить, на мобильном — нет.

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

И ещё один момент: точки перехода проектируй от контента, а не от устройств. В Figma Auto Layout позволяет задавать правила «при ширине меньше X — перестроиться в одну колонку». Это убирает ручную работу и снижает риск ошибок, когда заказчик приходит с устройством, которого не было в твоём списке брейкпоинтов.

Доступность как стандарт: внедрение уровней WCAG в дизайн-процесс

WCAG — не рекомендация для «когда-нибудь». Это международный стандарт W3C, и если ты его игнорируешь, ты теряешь аудиторию и деньги. Существуют юридические нормы (например, ADA в США, EN 301 549 в ЕС, национальные стандарты в РФ), и суды по ним реально выносят решения в пользу истцов. Это не абстрактная этика — это регуляторный и коммерческий риск.

Три уровня соответствия:

Уровень A — минимум. Базовая читаемость: альтернативные тексты для изображений, навигация с клавиатуры, корректная структура заголовков. Если твой сайт не проходит даже A — у тебя не сайт, а барьер. Этот уровень — безусловный минимум, без которого проект вообще не должен выходить в продакшн.

Уровень AA — рабочая планка для коммерческих продуктов. Контраст текста минимум 4.5:1 для обычного и 3:1 для крупного текста. Фокусные состояния видны. Элементы управления не меньше 44×44px на тач-устройствах. Это то, что проверяют аудиты и что предъявляют в спорах о доступности. Все коммерческие продукты должны целиться в AA — это отраслевой стандарт де-факто, которого ожидают и пользователи, и регуляторы.

Уровень AAA — повышенные требования. Контраст 7:1, расширенные аудиоописания, языковая разметка, увеличенные интервалы. Практически недостижим для большинства коммерческих продуктов в полном объёме: даже типографика и контраст нормальных заголовков часто его не проходят. Но для государственных сервисов и платформ с особыми требованиями к доступности — это рабочая планка, к которой стоит стремиться. В отдельных юрисдикциях и сегментах — здравоохранение, образование, финансы, транспорт — именно AAA требуют регуляторы. Уточняй локальные нормы под свой рынок: универсального «обязательного» уровня для всех стран не существует.

Что внедрить прямо сейчас

1. Проверяй контраст. Плагин Stark в Figma или WebAIM Contrast Checker. Три минуты — и ты знаешь, проходят ли твои цвета.

2. Проектируй фокусные состояния. Каждый кликабельный элемент должен показывать, что он в фокусе. Кольцо, подсветка, outline — что угодно, но оно должно быть. Дефолтный outline браузера часто режут дизайнеры — а зря, это критический сигнал для клавиатурной навигации и пользователей скринридеров.

3. Не используй цвет как единственный индикатор. Ошибка не только красная — рядом иконка и текст. Зелёный статус — не только зелёный кружок, но и лейбл. Это правило WCAG 1.4.1, и оно касается не только дальтоников.

4. Альтернативные тексты. Каждое значимое изображение описывается. Декоративные — помечаются как пустые alt="".

5. Минимальные тач-таргеты. 44×44px по Apple HIG, 48×48dp по Material Design. Это не «удобно» — это физическое требование пальца среднего размера.

Доступность — не про «для слабовидящих». Это про 15 % населения с инвалидностью, про пожилых пользователей, про людей с временной травмой руки, про тебя самого в тёмном метро с яркостью на минимуме.

И ещё: хорошо структурированный сайт с правильной семантикой и доступной навигацией проще сканировать поисковым роботам. Google публично поддерживает принципы доступности, и косвенные корреляции между качеством разметки и видимостью в поиске прослеживаются в отраслевых наблюдениях. Но прямой причинно-следственной связи «WCAG AA = рост позиций» Google официально не подтверждает — это рабочая гипотеза, а не гарантированный фактор ранжирования. Делай ради пользователей. Алгоритм — приятный побочный эффект, а не цель.

Итеративный цикл: от дизайн-мышления до тестирования с пользователями

Проектирование интерфейсов — не линейный процесс. Это цикл. И чем быстрее ты его прокрутишь, тем раньше получишь профит.

Пять фаз цикла

1. Эмпатия и исследование. Изучи аудиторию. Не «мне кажется, пользователь хочет» — а данные. Аналитика, тепловые карты, записи сессий, интервью. Гипотеза без данных — догадка. Догадка — это деньги на ветер.

2. Определение проблемы. Сформулируй конкретную pain point. Не «интерфейс неудобный», а конкретное наблюдение: пользователи теряются на пути к оплате, не видят ключевую кнопку, путаются в формах. Чем точнее формулировка — тем проще искать решение.

3. Генерация идей. Sketching, crazy eights, вайрфреймы. Быстро, дёшево, без привязки к стилю. Цель — найти 3–5 вариантов структуры и выбрать лучший. Не один — несколько. А потом протестировать.

4. Прототипирование. Сделай кликабельный прототип. Lo-Fi, если проверяешь концепцию. Hi-Fi, если идёшь на юзабилити-тестирование или презентацию заказчику. Не трать время на анимации на этапе Lo-Fi — это не та переменная, которую ты сейчас проверяешь.

5. Тестирование. На практике небольшая группа пользователей — обычно пять-семь человек — выявляет основной пласт проблем юзабилити в рамках одного сценария. Это рабочая цифра для большинства продуктов: больше — дороже, меньше — растёт риск пропустить ключевые баги. Качественные инсайты важнее количества участников: пять человек с правильным сценарием дают больше, чем тридцать наобум. После каждого раунда тестирования — фиксируй находки и возвращайся на фазу 3.

Lean UX: когда бюджет не резиновый

В 2013 году Готелф и Сейден издали книгу «Lean UX», которая перевернула подход. Суть: не рисуй идеальный макет за три недели — сделай MVP-прототип за три дня, протестируй, получи инсайты, итерируй.

Работает это так:

1. Гипотеза. «Если мы перенесём CTA выше fold, конверсия вырастет».

2. MVP-прототип. Минимальный кликабельный макет. Не Hi-Fi, а достаточно проработанный, чтобы пользователь понял, что происходит.

3. Тест. 5–8 пользователей. Запись сессий. Количественные метрики (время на задачу, клики до цели, ошибки).

4. Инсайт. «CTA выше fold сработал, но пользователи не видят подзаголовок — нужна визуальная иерархия».

5. Итерация. Правим, тестируем снова.

Не стройте собор — стройте сарай, тестируйте, перестраивайте в дом. Lean UX — это не про «дёшево». Это про скорость обучения.

Цикл «гипотеза → прототип → тест → инсайт» можно прокрутить за неделю. Три таких цикла — и у тебя данных больше, чем у конкурента, который месяц рисовал «идеальный» макет в вакууме.

Что взять из этого материала

Три вещи, которые нужно внедрить прямо сегодня:

Первое. Заведи таблицу отступов. 4, 8, 16, 24, 32, 48, 64. Повесь на стену (или в FigJam). Каждый новый элемент — в эту сетку. Это не ограничение. Это ускоритель, который через месяц сэкономит тебе недели.

Второе. Проверяй контраст каждого макета. Три клика в плагине Stark. Экономия — десятки часов на переделках после аудита доступности, плюс ноль рисков получить письмо от юристов.

Третье. Тестируй на пяти-восьми пользователях перед каждым релизом. Не после. До. Один час сессий — и у тебя достаточно данных, чтобы найти основные проблемы и поправить их до того, как их увидит рынок.

Проектирование интерфейсов — не «рисование картинок». Это инженерия пользовательского поведения. Каждый пиксель — гипотеза. Каждый отступ — решение. Каждый прототип — эксперимент.

Ставь гипотезы. Тестируй. Считай метрики. Получай профит.