Инструменты программирования с ИИ становятся всё мощнее: почему созданные сайты всё ещё выглядят плохо? Полное решение — от генерации кода ИИ до дизайна интерфейса

На этой неделе выберите одну ключевую страницу и сначала зафиксируйте для неё аудиторию, главную задачу и визуальные правила, а затем меняйте интерфейс по скриншотам. Генерация кода ИИ помогает получить работающую страницу, но сама по себе не создаёт понятную иерархию, единую дизайн-систему и критерии хорошего результата. Этот подход подходит вам, если вы делаете сайт с помощью ИИ и хотите понять, что именно исправлять, а не просить инструмент «сделать покрасивее».

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

Работает, но выглядит случайно: причины разрыва

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

Обычно проблема складывается из нескольких факторов.

• Задача задана слишком общо. Просьба «сделай современный сайт» не объясняет, кому он нужен, какую задачу человек решает и какие сведения важнее. Инструменту приходится выбирать направление без критериев. Заголовок, декоративное изображение и большая кнопка могут оказаться заметнее самого предложения продукта.
• Нет утверждённого визуального направления. Если вы не задали характер интерфейса, примеры или правила, результат может соединить разные стили: строгие карточки, случайные градиенты и несколько конкурирующих акцентных цветов.
• Код создаётся по частям. Отдельный блок может выглядеть приемлемо, но собранная страница окажется несогласованной. Например, карточки различаются внутренними отступами, кнопки — высотой, а заголовки — размером и насыщенностью.
• Локальная правка нарушает общий ритм. Добавление нового раздела ради одной страницы способно увеличить длину макета, вытеснить важный текст и сделать стартовый экран перегруженным.
• Вместо реального содержимого стоит заглушка. Короткие примеры текста не показывают, как ведут себя длинные заголовки, неодинаковые карточки или сообщения об ошибке. Поэтому проблемы обнаруживаются лишь после заполнения страницы.

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

Почему страница может быть функциональной, но визуально слабой? Потому что выполнение действия и его визуальное представление — разные части работы. Кнопка может отправлять форму, но иметь тот же цвет и вес, что и необязательная ссылка. Исправление здесь не «добавить больше стиля», а разделить главные и второстепенные действия, а затем проверить, заметно ли нужное действие на снимке страницы.

Дизайн до кода: направление вместо случайного выбора

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

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

Для первой версии ответьте письменно на четыре вопроса:

1. Кто приходит на страницу и что ему нужно сделать?
2. Какой один главный результат должен быть понятен на первом экране?
3. Какие два или три факта человек должен увидеть до перехода дальше?
4. Что в интерфейсе должно поддерживать доверие: подробное объяснение, примеры, простая форма или иная конкретная информация?

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

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

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

Единые правила вместо набора несвязанных эффектов

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

Начните с небольшого набора правил:

• Цвета по роли. Назначьте цвет для фона, основного текста, вспомогательного текста, границ и главного действия. Не вводите новый акцентный цвет для каждого раздела.
• Типографическая иерархия. Определите роли заголовка страницы, заголовков блоков, основного текста и подписей. Укажите, что должно отличаться: размер, насыщенность или межстрочное расстояние. Не делайте каждый заголовок самым заметным элементом.
• Ритм отступов. Выберите ограниченный набор значений и применяйте его повторно. Важнее последовательное различие между внутренними отступами карточки и расстоянием между разделами, чем точность произвольного числа.
• Сетка и ширина содержимого. Задайте границы колонки, правила выравнивания и поведение блоков при уменьшении экрана. Иначе компоненты могут хорошо выглядеть только в исходном размере окна.
• Состояния компонентов. Опишите не только вид кнопки в покое, но и состояние при наведении, фокусе, отключении и ошибке. Форма должна оставаться понятной, когда пользователь уже взаимодействует с ней.

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

Для проверки цветового контраста можно опираться на пояснение минимального контраста текста в WCAG 2.2: для обычного текста в нём указано соотношение 4,5:1, а для крупного текста — 3:1. Это проверяемое требование к читаемости, но оно не заменяет выбор подходящих цветов для всего интерфейса.

Как перевести требования к дизайну в инструкции для инструмента? Укажите объект, ограничение и ожидаемую проверку: «Для всех основных кнопок используй общий компонент; главное действие должно визуально отличаться от второстепенного; проверь, что кнопки одного типа имеют одинаковую высоту». Такой запрос точнее, чем «сделай кнопки красивыми», и позволяет оценить результат по странице и коду.

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

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

1. Соберите требования и содержание. Запишите аудиторию, главную задачу, разделы и реальные тексты. Отметьте, какой информации не хватает для решения пользователя. Не поручайте визуальной правке исправление неясного предложения продукта.
2. Подготовьте структурный каркас. Определите порядок блоков, главный заголовок, пояснение и действие. На этом этапе не добавляйте декоративные эффекты. Проверьте, можно ли понять цель страницы по одним заголовкам и названиям блоков.
3. Выберите направление для одной ключевой страницы. Опишите компоновку, тон, цвета и визуальные ориентиры. Сначала добейтесь согласованного первого экрана. Когда он понятен и соответствует задаче, используйте его правила для следующих разделов.
4. Создайте компоненты и закрепите правила. Передайте определения цветов, типографики, сетки, кнопок, карточек и форм. Попросите применять одинаковые компоненты повторно, а не создавать отдельный вариант каждого элемента без причины.
5. Добавьте реальные материалы. Подставьте длинные заголовки, обычные описания, подписи, предупреждения и тексты кнопок. Проверяйте не только заполненный макет, но и пустое, ошибочное или ограниченное состояние тех элементов, где это уместно.
6. Адаптируйте компоновку. Заранее определите, какие блоки меняют порядок, какие колонки складываются, а какие элементы требуют отдельной компоновки на узком экране. Документация по медиазапросам CSS объясняет, как использовать условия для адаптации стилей к характеристикам устройства и области отображения.
7. Проверьте путь пользователя. Пройдите основное действие от первого экрана до результата: переход, отправку формы, подтверждение или сообщение об ошибке. Зафиксируйте, где пользователь может потерять контекст или не понять следующий шаг.
8. Сделайте итоговую проверку. Просмотрите страницу при разных размерах окна и на реальном содержимом. Устраните найденные проблемы, прежде чем поручать инструменту новые декоративные улучшения.

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

Скриншоты и проверяемые правки

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

Перед следующей правкой выберите один главный тип замечания:

• Иерархия: какой элемент должен первым привлекать внимание и что сейчас отвлекает?
• Выравнивание: какие края или оси должны совпадать?
• Отступы: где блоки выглядят слитыми или, наоборот, разорванными?
• Цвет: какой текст, граница или действие недостаточно различимы?
• Типографика: какой текст трудно сканировать и что именно нужно изменить?
• Плотность: какие сведения перегружают экран или, напротив, оставляют большие пустоты?
• Содержание: в каком месте требуется реальный текст вместо заглушки?

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

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

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

Приёмка: не «выглядит дороже», а выполняет задачу

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

Прочитайте страницу, увеличив межбуквенные и межстрочные интервалы. В руководстве по интервалам текста WCAG 2.2 описаны значения, при которых содержимое должно сохранять работоспособность: межстрочный интервал до 1,5 высоты шрифта, расстояние между абзацами до 2 высот шрифта, между буквами до 0,12 высоты шрифта и между словами до 0,16 высоты шрифта. Проверьте, не обрезается ли текст и не ломается ли компонент при этих настройках.

Если на странице есть движение, проверьте, можно ли уважать системное предпочтение пользователя уменьшить анимацию. Документация по prefers-reduced-motion объясняет, как использовать это условие в CSS. Анимация должна помогать понять переход, а не быть обязательной для восприятия действия.

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

Используйте список перед выпуском:

• [ ] Первый экран объясняет назначение страницы, главную пользу и следующее действие.
• [ ] Заголовки, основной текст, подписи и кнопки различаются по роли и читаются без догадок.
• [ ] Похожие компоненты используют согласованные цвета, шрифты, отступы и состояния.
• [ ] Реальные тексты не обрезаются, не перекрывают элементы и не создают случайную перегрузку.
• [ ] Узкое окно не вызывает горизонтальную прокрутку, наложение блоков или исчезновение важного действия.
• [ ] Основной путь пользователя работает, а состояние фокуса заметно при навигации с клавиатуры.
• [ ] Сообщения об ошибках и подтверждениях понятны и размещены рядом с нужным действием.
• [ ] Проверены страницы с самой сложной компоновкой и самым длинным содержимым, а не только главная.
• [ ] Скриншот после последней правки соответствует записанным целям, а не просто личному ощущению «так лучше».

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

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