Дизайн сайта раздувается без общих правил

Дизайн сайта редко раздувается потому, что дизайнер нарисовал слишком много. Чаще в проекте нет общего ответа, что сайт должен объяснить, к какому действию привести аудиторию и по каким признакам команда признает решение удачным. Тогда каждый новый комментарий звучит правдоподобно: «сделайте дороже», «здесь скучно», «давайте ещё блок», — но спор идёт о вкусе, а не о задаче.

Дизайн — не набор красивых экранов. Он помогает человеку найти нужное, понять предложение, сравнить варианты, оставить заявку или получить информацию без звонка. Эти задачи раскрывает UX/UI-дизайн. Чтобы макеты не переделывали по кругу, до начала работы нужны правила: сценарии, компоненты, ограничения бренда, критерии выбора и понятный порядок согласования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Полезно проверить прототип до визуальной полировки. Дайте человеку задачу: найти услугу, сравнить два варианта, понять условия, оставить заявку. Если он не понимает маршрут на чёрно-белой схеме, дорогая фотография не исправит логику.

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

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

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

У правки должна быть причина: она помогает выполнить сценарий аудитории, соблюсти ограничение бренда, исправить техническое состояние или отражает новую бизнес-информацию. Комментарий «не цепляет» может быть началом разговора, но не техническим заданием. Его полезно развернуть: кого не убеждает, в какой момент и каких доказательств, ясности или эмоции не хватает.

Зафиксируйте этапы. Сначала утверждаются цели и сценарии, затем структура, прототип, визуальное направление и состояния компонентов. На каждом этапе обозначьте, кто собирает комментарии и кто принимает итоговое решение. Если после утверждения прототипа команда добавляет новую функцию, это новая задача с оценкой влияния, а не бесконечная правка макета. Такой порядок не запрещает изменения, а делает их последствия видимыми.

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

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

Чтобы дизайн не раздувался от субъективных правок:

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

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