UX/UI и дизайн
Разработка дизайна сайта: из чего состоит UX/UI и что передают в разработку
Дизайн сайта — это не набор красивых экранов. Это способ сделать предложение понятным, сценарий коротким, а интерфейс — предсказуемым на каждом устройстве.
Коротко
Разработка дизайна сайта включает разбор аудитории и задачи, структуру, прототип ключевых сценариев, визуальную систему, адаптивы, состояния интерфейса и передачу в разработку. Качественный дизайн позволяет проверить логику до кода и снижает количество решений, которые приходится принимать во время верстки.
Дизайн начинается с цели и сценария, а не с референса
Для сайта услуг дизайн должен быстро объяснить предложение и провести к обращению. Для интернет-магазина — помочь выбрать товар и оформить заказ. Для CRM или личного кабинета — сократить количество ошибок в ежедневной работе. Один и тот же визуальный прием может быть уместен на лендинге и вреден в рабочем интерфейсе.
На старте полезно собрать контекст: аудиторию, источники трафика, контент, ограничения бренда, список экранов, интеграции и показатели, по которым команда поймет, что интерфейс стал лучше. Это дает дизайнеру не только картинку, но и критерии выбора между вариантами.
UX-этап: сначала путь пользователя и структура
UX определяет, какие страницы нужны, как пользователь попадает между ними и какую информацию получает до действия. Команда собирает карту сайта, тексты ключевых блоков, прототип и правила для сценариев. На этом уровне проще обнаружить, что одна важная услуга спрятана в меню или что форма просит данные, которые не нужны для первого контакта.
Для продуктов и админок UX охватывает роли, статусы, таблицы, фильтры, пустые экраны, ошибки и уведомления. Дизайн должен показать не только идеальный путь, но и то, что увидит человек, когда данных нет, доступ ограничен или внешняя система вернула ошибку.
- Карта страниц или экранов.
- Основной путь пользователя и альтернативные действия.
- Прототип ключевых блоков без финальной графики.
- Тексты для заголовков, форм, ошибок и подтверждений.
UI-этап: визуальная система делает интерфейс целостным
После проверки структуры появляется визуальная система: типографика, сетка, отступы, цвета, иконки, кнопки, поля, карточки и правила работы с фотографиями или иллюстрациями. Это важно не ради «единого стиля», а чтобы один и тот же элемент вел себя одинаково на разных страницах.
Для сложного проекта из повторяющихся компонентов развивается дизайн-система: токены, варианты, состояния и документация. Для небольшого лендинга достаточно компактного UI-kit. Масштаб выбирают по количеству экранов, участников и будущих изменений, а не по модному названию.
| Артефакт | Для чего нужен | Кому помогает |
|---|---|---|
| Сетка и типографика | Удерживать читаемую иерархию | Дизайнеру и верстке |
| Компоненты | Не рисовать кнопки и поля заново | Команде продукта |
| Состояния | Предусмотреть ошибку, загрузку и disabled | Пользователю и QA |
| UI-kit / дизайн-система | Управлять ростом интерфейса | Нескольким командам и будущим релизам |
Адаптивы и состояния — часть макета, а не постскриптум
Мобильная версия не должна быть просто уменьшенной копией desktop. На телефоне меняются приоритеты, длина строк, размер зон нажатия, навигация, фильтры и способ показывать сложную таблицу. Это проверяют в макете до верстки, иначе адаптив превращается в набор компромиссов на финальной неделе.
Также фиксируют состояния: загрузка, пустой список, ошибка, успешная отправка, недоступное действие, ограниченные права. Такие экраны редко попадают в презентацию, но именно они определяют, будет ли пользователь доверять продукту в реальной работе.
Интерфейс считается спроектированным не тогда, когда красиво выглядит главный экран, а когда пользователю понятно, что делать в обычной и нестандартной ситуации.
Передача дизайна в разработку должна сохранять замысел
Перед началом сборки команда сверяет компоненты, адаптивы, тексты, ссылки, данные и критерии готовности. Разработчик должен понимать не только размеры в Figma, но и поведение элемента: когда кнопка неактивна, какой текст показывать при ошибке, что происходит после успешной отправки формы.
Для существующего продукта начните с UX/UI sprint: он помогает проверить ключевые экраны и собрать минимальную систему для команды. Если интерфейс растет быстрее, чем его успевают поддерживать, посмотрите когда нужна дизайн-система.
FAQ
Частые вопросы
01Что входит в разработку дизайна сайта?
Обычно: разбор задачи, структура, прототип, ключевые экраны, визуальная система, адаптивы, состояния и передача в разработку. Точный состав зависит от типа сайта и готовности контента.
02Можно ли заказать только дизайн без разработки?
Да. Важно заранее определить, кто будет собирать макеты в код и какие материалы ему нужны: компоненты, адаптивы, состояния и комментарии по поведению.
03Сколько вариантов дизайна нужно делать?
Обычно эффективнее быстро согласовать направление на одном ключевом экране, а затем развивать выбранную систему. Много несвязанных вариантов редко улучшает решение.
04Нужна ли дизайн-система маленькому сайту?
Полная система не всегда нужна. Но даже небольшому проекту полезны правила для типографики, отступов, кнопок, форм и адаптивов.
Источники и документация
Материал подготовлен редакцией ХЭМС на основе проектной практики. Цены и технические условия актуальны на дату публикации и уточняются после разбора задачи.
Обсудить проект
Спроектируем интерфейс, который можно собрать без догадок
Разберем цель, сценарий и существующий продукт. Предложим формат: аудит, UX/UI sprint или дизайн для полного запуска.