Дизайн и разработка сайта: единый процесс

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

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

Содержание

• чем прототип отличается от визуального макета;
• как проектировать вокруг контента;
• что включает UX/UI и проектирование от мобильной версии;
• зачем нужны дизайн-токены и компоненты;
• как учесть доступность и состояния;
• как организовать передачу в разработку;
• как проверить соответствие реализации.

Начинайте со сценария, а не с референса

Референс помогает обсудить вкус, но не объясняет задачу. До оформления команда отвечает:

1. кто использует страницу;
2. с каким ожиданием приходит;
3. какое решение должен принять;
4. какая информация для этого нужна;
5. какое действие является главным;
6. что происходит после действия;
7. как измеряется успешность пути.

Один и тот же визуальный стиль может обслуживать совершенно разные процессы. Красивая карточка товара бесполезна, если она скрывает единицу измерения или недоступный вариант. Эффектный первый экран мешает лендингу, если оффер появляется только после длинной анимации.

Прототип проверяет логику

Прототип фиксирует структуру, иерархию и переходы без стоимости детального визуального слоя. Он позволяет быстро переставить разделы, убрать лишнее и увидеть пробелы в данных.

На прототипе полезно проверить:

• один ли главный смысл у страницы;
• понятен ли следующий шаг без объяснения менеджера;
• есть ли доказательства перед моментом решения;
• где появляются цена и ограничения;
• что увидит пользователь после отправки;
• как устроены меню и возврат назад;
• какие блоки повторяются и могут стать компонентами.

Для сложного приложения прототип включает не только счастливый путь, но и ветвления. Например: файл не подходит, данных нет, доступ ограничен, операция выполняется долго, внешний сервис недоступен.

Контент — входные данные дизайна

Макет с Lorem ipsum скрывает реальную длину, иерархию и доказательства. Заголовок на две строки, список из семи пунктов и таблица с длинными значениями создают другие требования, чем демонстрационные заглушки.

До детального дизайна собирают контентную матрицу:

• Заголовок. Источник — редактор, ответственный — маркетинг. На мобильном он должен сохранять смысл.
• Цена. Источник — публичный прайс, ответственный — бизнес. Нужно указать дату актуальности и состав предложения.
• Кейс. Источник — проектные данные, ответственный — руководитель. Используем только подтверждённые факты.
• Изображение. Источник — съёмка/генерация, ответственный — контент. Проверяем права, формат и alt-текст.
• Форма. Источник — бизнес-процесс, ответственный — менеджер. Оставляем только необходимые поля.

Компонент проектируют на минимальном, обычном и предельном содержимом. Нужно увидеть карточку без изображения, длинный заголовок, отсутствующий optional-текст и большое число элементов. Ограничения после этого можно передать CMS и валидаторам.

Информационная архитектура и UX

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

Хорошая структура:

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

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

UI: визуальная иерархия вместо декора

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

В базовую систему входят:

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

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

Дизайн-токены и компоненты

Токен — именованное решение, например основной цвет текста или стандартный отступ. Он связывает дизайн и код лучше, чем набор случайных чисел.

Компонент оправдан, если повторяет смысл и поведение: кнопка, поле, карточка кейса, аккордеон FAQ. Не стоит создавать универсальный компонент из двух визуально похожих блоков, если у них разные данные и правила.

Для компонента описывают варианты и состояния:

• Button. Предусмотрите варианты primary, secondary, link и состояния hover, focus, disabled, loading.
• Input. Предусмотрите варианты text, phone, textarea и состояния empty, filled, error, disabled.
• Card. Предусмотрите варианты article, case, service и состояния с/без изображения, длинный текст.
• Accordion. Предусмотрите варианты closed, open и состояния keyboard focus, expanded semantics.

Названия в макете и коде должны отражать назначение. BlueButton2 перестаёт быть понятным после изменения темы, а PrimaryAction сохраняет роль.

Проектирование от мобильной версии и адаптивность

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

На узком экране решают:

• какой контент виден без прокрутки;
• как меню открывается и закрывается;
• где располагается главное действие;
• как таблица или сравнение остаётся читаемым;
• что происходит при появлении клавиатуры;
• не перекрывают ли интерфейс фиксированные элементы;
• сохраняется ли удобный размер нажатия.

Нельзя проверять только две ширины из макета. Между ними карточки могут получить неудобный остаток места, заголовок — внезапно перенестись, а сетка — создать горизонтальную прокрутку. Реализацию тестируют на диапазоне размеров.

Доступность входит в качество

Доступность не является отдельной косметической опцией. Семантика, контраст и клавиатурная навигация влияют на людей с разными устройствами и обстоятельствами.

Минимальный набор:

• логичный порядок заголовков;
• настоящие кнопки для действий и ссылки для переходов;
• видимый focus;
• подписи полей и понятные ошибки;
• альтернативный текст для смысловых изображений;
• декоративная графика скрыта от вспомогательных технологий;
• управление доступно без мыши;
• цвет не является единственным сигналом;
• анимация учитывает настройку уменьшения движения.

Контраст проверяют инструментом, а не на глаз. placeholder не заменяет label: после ввода он исчезает и не объясняет назначение поля.

Состояния, которые забывают в макете

Счастливый путь занимает небольшую часть продукта. До передачи в разработку нужны решения для:

• загрузки и долгой операции;
• пустого списка;
• отсутствующего изображения;
• частичной ошибки;
• недоступного действия;
• успешной отправки;
• повторного запроса;
• истёкшей сессии;
• очень длинного или короткого контента;
• мобильной клавиатуры.

Для CMS-страниц дополнительно определяют fallback: что показывать, если редактор не заполнил SEO-изображение, excerpt или optional-блок. Fallback не должен создавать ложные данные.

Передача дизайна в разработку

Handoff — не ссылка на файл, а общий контракт. В нём должны быть:

1. актуальная версия и статус экранов;
2. компоненты и переменные;
3. размеры контейнеров и правила сетки;
4. состояния и интерактивное поведение;
5. адаптивная логика;
6. экспортируемые ассеты и права;
7. реальный контент или ограничения полей;
8. критерии проверки;
9. список сознательно отложенных решений.

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

Реализация в коде

Разработка переводит решение в работающий интерфейс. Важно сохранить смысл, но не копировать абсолютные координаты макета.

Качественная реализация учитывает:

• семантический HTML;
• повторно используемые компоненты по назначению;
• токены вместо несвязанных значений;
• responsive images и оптимизацию загрузки;
• серверные и клиентские границы;
• реальные данные CMS;
• состояния формы и интеграции;
• аналитику подтверждённых действий;
• тесты критических сценариев.

CMS-контент не должен ломать сетку. Если редактор может добавить шесть пунктов, код не вправе молча рассчитывать ровно на три. Либо компонент адаптируется, либо ограничение валидируется и объясняется.

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

Проверка начинается с поведения и содержания:

1. пользователь выполняет согласованный сценарий;
2. все данные и тексты соответствуют источнику;
3. состояния успеха и ошибки работают;
4. структура доступна с клавиатуры;
5. мобильная версия сохраняет приоритеты;
6. повторяемые компоненты ведут себя одинаково;
7. изображения и шрифты не создают заметных сдвигов;
8. аналитика фиксирует правильное событие;
9. метаданные и превью соответствуют странице;
10. визуальные расхождения проверены на контрольных размерах.

Скриншотное сравнение полезно для регрессий, но не заменяет интерактивный тест. Страница может совпасть с макетом и при этом не отправлять форму или терять фокус.

Цена и границы работы

На публичном прайсе Za IT лендинг стоит 4 999 ₽, корпоративный сайт — 19 999 ₽, интернет-магазин — 29 999 ₽. В базовые форматы входит соответствующий адаптивный дизайн, но объём зависит от числа уникальных шаблонов и состояний.

Отдельной оценки требуют:

• исследование сложного процесса;
• большая дизайн-система;
• множество ролей и состояний;
• уникальная иллюстрация, 3D и видео;
• анимационный сценарий;
• пользовательское тестирование;
• сложная миграция контента;
• нестандартные интеграции.

Инженерная работа сверх пакета может оцениваться по 2 999 ₽/час либо отдельным этапом. До оценки фиксируют результат: количество шаблонов само по себе не показывает число состояний и сложность данных.

Этапы совместной работы

• Discovery. На согласовании — цель, аудитория, состав работ. На проверке — полный ли главный сценарий.
• Прототип. На согласовании — структура и действия. На проверке — логика и контентные пробелы.
• Визуальная система. На согласовании — токены и компоненты. На проверке — иерархия и повторяемость.
• Адаптивные макеты. На согласовании — правила изменения. На проверке — mobile и промежуточные ширины.
• Разработка. На согласовании — данные и поведение. На проверке — состояния и интеграции.
• QA. На согласовании — критерии готовности. На проверке — сценарий, доступность, визуал.
• Запуск. На согласовании — домен и аналитика. На проверке — production-путь и наблюдение.

Срок появляется после понимания числа уникальных решений, готовности контента и интеграционных рисков. Обещание даты до этого является ориентиром, а не планом.

Практический сценарий

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

Реальные тексты проверяются на мобильной ширине, FAQ проектируется как доступный аккордеон, а форма получает состояния ошибки и успеха. Поля SEO и cover приходят из CMS с безопасным fallback. Приёмка включает контрольную заявку и HTML-разметку, а не только визуальную сверку. В результате дальнейшая статья или кейс добавляются без нового дизайна каждой карточки.

Что принять до публикации

• утверждённые сценарии работают на реальных данных;
• структура и тексты не содержат заглушек;
• компоненты имеют нужные варианты и состояния;
• mobile и desktop прошли интерактивную проверку;
• клавиатурный фокус видим, поля подписаны;
• формы фактически доставляют тестовые обращения;
• изображения оптимизированы и имеют корректный alt;
• владелец получил макеты, код и аккаунты;
• известные ограничения записаны;
• определён процесс исправлений и развития.

Следующий шаг

Для оценки пришлите цель, пользовательский сценарий, примерный состав страниц, имеющийся контент и референсы с пояснением, что именно в них полезно. На странице разработки сайтов под ключ можно сравнить базовые форматы.

Сложные интерфейсы и роли относятся к разработке веб-приложений. В качестве примера продукта посмотрите кейс rocketrush, а соседняя статья поможет подготовить бриф, договор и приёмку сайта.