Хардкодинг PRO — Гайд №08. Интерфейс и удобство для пользователя (Frontend / UI / UX)

Как читать этот гайд

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

ЧТО ЭТО ↓ ЗАЧЕМ ТЕБЕ ЭТО ЗНАТЬ ↓ ЧТО ДЕЛАЕТ ИИ ↓ ЧТО ПРОВЕРЯЕШЬ ТЫ

1. Главная карта понимания 2. HTML / CSS / JavaScript 3. UI и UX 4. Компоненты и состояния 5. Интерфейс и серверная логика 6. Сначала телефон 7. Загрузка / Пусто / Ошибка / Успех 8. Готовые UI-банки для AI 9. Как принимать работу ИИ 10. Готовые промпты 11. Непонятные слова 12. Чек-лист

1. Зачем понимать интерфейс (frontend), если код пишет ИИ?

Вот ключевой вопрос этого гайда.

Если ИИ пишет код, зачем мне знать HTML, CSS, components, API и все эти слова?

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

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

С AI-разработкой то же самое.

ИИ делаетКод, CSS, компоненты, адаптивность, API-вызовы, тесты.

Ты решаешьЧто должен получить пользователь, что важно, что лишнее, что считается «готово».

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

Самая простая карта продукта

ПОЛЬЗОВАТЕЛЬ ↓ FRONTEND — то, что он видит ↓ API — передача просьбы ↓ BACKEND — скрытая логика ↓ БАЗА / AI / СЕРВИСЫ ↓ РЕЗУЛЬТАТ ВОЗВРАЩАЕТСЯ ПОЛЬЗОВАТЕЛЮ

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

2. HTML, CSS, JavaScript: зачем тебе знать эти три слова

Не чтобы писать их руками. А чтобы понимать, какого типа проблема перед тобой.

HTMLЧто вообще есть на странице. Например: заголовок, форма, кнопка.

CSSКак всё выглядит и где стоит: размеры, цвета, отступы, mobile.

JavaScriptЧто происходит после действий: клик, запрос, открытие окна, обновление данных.

Зачем тебе это?
Если кнопка есть, но не нажимается — проблема не такая же, как «кнопка слишком маленькая». Ты должен уметь хотя бы описать ИИ, что именно не так.

Что делает ИИ: сам пишет HTML, CSS и JavaScript, выбирает структуру, исправляет код.

Что проверяешь ты: нужный ли элемент вообще есть, удобно ли он выглядит, происходит ли после него правильное действие.

3. Внешний вид и удобство (UI / UX): почему «красиво» ещё не значит «хорошо»

UI — как выглядит. UX — насколько удобно человеку получить результат.

Зачем тебе это знать?
ИИ очень легко умеет сделать «вау-визуал». Но он так же легко делает лишние поля, непонятные кнопки, перегруженные экраны и странные сценарии.

Например, регистрация может выглядеть премиально, но если человек должен заполнить 14 полей, UX плохой.

ХОРОШИЙ ЭКРАН ОТВЕЧАЕТ НА 3 ВОПРОСА: 1. Где я? 2. Что я могу сделать? 3. Что произошло после моего действия?

Что делает ИИ: рисует layout, typography, buttons, cards, transitions.

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

4. Компоненты и состояния интерфейса (Components / State)

Компонент (Component)

Это повторяемый кусок интерфейса. Например одна нормальная кнопка, которую можно использовать в 30 местах.

Зачем тебе?
Чтобы AI не создал 30 почти одинаковых кнопок, 7 разных карточек и хаотичный дизайн, который потом невозможно поддерживать.

Состояние (State)

Это текущее состояние элемента или экрана.

КНОПКА МОЖЕТ БЫТЬ: обычная ↓ нажата ↓ заблокирована ↓ загрузка ↓ успех ↓ ошибка

Зачем тебе?
Если пользователь нажал «Оплатить», а экран не показывает загрузку, он нажмёт второй раз. Потом третий. И ты получишь три оплаты или три запроса.

Что проверяешь ты: что пользователь всегда понимает, что сейчас происходит.

5. Интерфейс и серверная логика (frontend / backend): что происходит после клика

Тебе не надо становиться backend-разработчиком. Но нужно понимать границу.

ЧЕЛОВЕК НАЖАЛ КНОПКУ ↓ FRONTEND ПОКАЗАЛ ДЕЙСТВИЕ ↓ ОТПРАВИЛ ЗАПРОС ↓ BACKEND ПРОВЕРИЛ ПРАВА И ВЫПОЛНИЛ ЛОГИКУ ↓ AI / БАЗА / ВНЕШНИЙ СЕРВИС ↓ ОТВЕТ ↓ FRONTEND ПОКАЗАЛ РЕЗУЛЬТАТ

Зачем тебе это?
Когда «кнопка не работает», нужно понимать: проблема может быть в самой кнопке, в передаче запроса, на сервере, в базе или у AI-провайдера.

Твоё правило: frontend может скрыть кнопку, но безопасность всегда должна проверяться backend. Спрятать кнопку — не защита.

6. Сначала телефон (mobile-first): почему это важно сразу

Большая часть твоих пользователей может открыть продукт с телефона. Поэтому интерфейс нельзя принимать только по красивому desktop screenshot.

Зачем тебе знать размеры 320 / 390 / 768 / 1440?
Не чтобы учить пиксели. А чтобы у ИИ были конкретные контрольные точки, где он обязан показать, что layout не развалился.

На телефонеПалец вместо мыши, клавиатура перекрывает экран, меньше места, safe-area, fixed-кнопки.

На desktopБольше места, можно использовать колонки, sidebar, большие таблицы.

Что делает ИИ: сам пишет media queries, перестраивает layout, адаптирует navigation.

Что проверяешь ты: удобно ли реально пользоваться пальцем. Не «уместилось ли» — а удобно ли.

7. Загрузка, пусто, ошибка, успех: четыре состояния, которые ИИ часто забывает

LoadingСистема работает. Человек понимает, что надо подождать.

EmptyДанных пока нет. Интерфейс объясняет, что делать дальше.

ErrorЧто-то пошло не так. Человек получает понятный следующий шаг.

SuccessДействие завершилось. Человек уверен, что всё получилось.

Зачем тебе?
Потому что реальный пользователь чаще видит не идеальный экран с готовыми данными, а загрузку, пустой аккаунт и ошибки.

Приёмка: если AI показывает тебе только идеальный screenshot с заполненными данными — frontend ещё не принят.

8. Не заставляй AI изобретать UI с нуля

Вот здесь начинается сильный подход через ИИ подход.

Главная идея: сначала ищем готовый хороший компонент, pattern, skill, registry или starter repo. Только потом пишем своё.

Это ровно тот же сначала исследование подход, который мы уже проходили в Гайде №02.

Как использовать это ученику

ТЫ: "Мне нужен dashboard" ↓ AI СНАЧАЛА ИЩЕТ: что уже есть в проекте shadcn/ui 21st MCP готовые starter repos актуальные docs через Context7 ↓ ПОКАЗЫВАЕТ ВАРИАНТЫ ↓ ТЫ ВЫБИРАЕШЬ ПОДХОД ↓ AI АДАПТИРУЕТ ПОД ТВОЙ ПРОДУКТ ↓ QA

Тебе не нужно руками ставить каждую библиотеку. Тебе нужно знать, что можно попросить AI сначала исследовать экосистему, а не генерировать очередной велосипед.

9. Как принимать интерфейс, если код писал ИИ

Вот это самый важный блок всего гайда.

НЕ СПРАШИВАЙ: "Ты закончил?" СПРАШИВАЙ: "Покажи доказательства"

Визуально4 screenshot: 320 / 390 / 768 / 1440.

ФункциональноГлавные кнопки и формы реально выполняют действие.

СостоянияLoading, Empty, Error, Success реально существуют.

Связь с backendNetwork показывает правильные запросы и ответы.

ОшибкиConsole без критических ошибок.

E2EПолный главный путь пользователя реально пройден.

Главный принцип: screenshot — это доказательство только внешнего вида. Он ничего не доказывает про кнопки, backend, ошибки, права и реальные данные.

10. Готовые промпты

Эти промпты специально написаны так, чтобы AI не просто «кодил», а сначала объяснял тебе систему и показывал доказательства.

Промпт 1

Объясни мне мой интерфейс как владельцу продукта

Ты работаешь как технический наставник по моему проекту.

Я НЕ frontend-разработчик и не собираюсь писать frontend руками.
Мне нужно понять систему, чтобы правильно ставить задачи ИИ и принимать результат.

Сначала ничего не меняй.

Изучи frontend моего проекта и объясни мне простым русским языком:

1. Что именно видит пользователь.
2. Какие главные экраны есть.
3. Что на каждом экране человек должен сделать.
4. Какие кнопки и формы действительно важны.
5. Какие действия уходят на backend.
6. Где frontend получает данные.
7. Какие состояния интерфейса есть: загрузка, успех, ошибка, пусто.
8. Что происходит на телефоне.
9. Что сейчас выглядит запутанно для пользователя.
10. Где AI уже переусложнил интерфейс.

Для каждого технического термина сразу напиши:
ТЕРМИН → что это по-человечески → зачем мне это знать.

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

Промпт 2

Сделай нормальный интерфейс из моей идеи

Я дам тебе идею продукта.

Ты сам проектируешь frontend, но сначала НЕ пиши код.

Мне как владельцу продукта нужен понятный пользовательский путь.

Сначала ответь:
1. Кто пользователь.
2. Какой результат он хочет получить.
3. Какой самый короткий путь к этому результату.
4. Какие экраны действительно нужны.
5. Что можно вообще убрать.

После этого создай:
- User Flow простыми словами;
- список экранов;
- главное действие на каждом экране;
- какие состояния нужно показать пользователю;
- что должен делать frontend;
- что должен делать backend.

Потом предложи минимальный интерфейс для MVP.

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

Промпт 3

Сделай по референсу, но не тупо копируй

Изучи приложенный screenshot / Figma / сайт-референс.

Моя цель: получить похожее качество и логику, но не слепую копию.

Сначала не пиши код.

Разбери:
1. Что здесь визуально хорошо.
2. Почему человеку понятно, куда смотреть.
3. Где главное действие.
4. Какие элементы повторяются.
5. Что удобно на desktop.
6. Что может сломаться на mobile.
7. Что screenshot вообще не показывает: loading, error, empty, mobile, modal, API behavior.

После этого предложи:
- что стоит повторить как принцип;
- что адаптировать под мой продукт;
- что не копировать;
- какие components нужны;
- какие состояния нужны.

Только после моего подтверждения переходи к коду.

Промпт 4

Проверь интерфейс сначала на телефоне (mobile-first)

Проведи реальную проверку frontend на:
320 px,
390 px,
768 px,
1440 px.

Не просто сделай screenshots.

Для каждого размера проверь:
- нет ли горизонтального скролла;
- читается ли текст;
- удобно ли нажимать кнопки пальцем;
- не перекрывает ли fixed-кнопка контент;
- работает ли меню;
- помещаются ли формы и modal;
- не ломаются ли таблицы и изображения;
- видно ли главное действие.

Каждую проблему объясни простым языком:
ЧТО НЕ ТАК → ПОЧЕМУ ЭТО ПЛОХО ДЛЯ ПОЛЬЗОВАТЕЛЯ → КАК ИСПРАВИЛ.

Не уменьшай desktop-версию механически.
Сделай мобильный интерфейс удобным сам по себе.

Промпт 5

Добавь все важные состояния

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

Найди все действия, где пользователь ждёт ответ системы.

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

Если состояния нет, добавь его.

Для каждой правки объясни:
1. Что пользователь делает.
2. Что он должен увидеть.
3. Что было непонятно раньше.
4. Что стало понятнее после исправления.

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

Промпт 6

Покажи путь одного клика до серверной логики

Выбери одно главное действие пользователя в моём продукте.

Например:
"Создать изображение",
"Оплатить",
"Загрузить файл",
"Отправить сообщение".

Покажи мне путь простыми словами:

ПОЛЬЗОВАТЕЛЬ
↓
ЧТО ОН НАЖАЛ
↓
ЧТО ДЕЛАЕТ FRONTEND
↓
КАКОЙ ЗАПРОС УХОДИТ
↓
ЧТО ДЕЛАЕТ BACKEND
↓
КАКИЕ ДАННЫЕ / AI / БАЗА УЧАСТВУЮТ
↓
ЧТО ВОЗВРАЩАЕТСЯ
↓
ЧТО ВИДИТ ПОЛЬЗОВАТЕЛЬ

Если используешь слова API, endpoint, JSON, state, request, response - сразу расшифруй их.

В конце покажи 3 места, где эта цепочка чаще всего ломается и как это проверить.

Промпт 7

Не изобретай UI с нуля

Перед тем как писать новый UI-компонент, сначала проведи поиск готовых решений.

Проверь:
1. Что уже есть в моём проекте.
2. Что есть в shadcn/ui.
3. Что есть через shadcn MCP.
4. Что есть через 21st MCP.
5. Есть ли подходящий open-source repository.
6. Есть ли готовый skill / registry.
7. Есть ли актуальная документация через Context7.

Ничего не устанавливай без анализа.

Верни таблицу:
ЧТО НУЖНО | ЧТО УЖЕ ЕСТЬ | ГОТОВОЕ РЕШЕНИЕ | ЗАВИСИМОСТИ | ЛИЦЕНЗИЯ | РЕКОМЕНДАЦИЯ

После выбора:
- используй существующий стиль проекта;
- не тащи вторую UI-библиотеку без причины;
- добавь loading / error / empty / disabled;
- проверь mobile;
- проверь accessibility;
- сделай visual QA.

Промпт 8

Проверь формы как пользователь

Проведи UX-аудит всех форм.

Я не хочу знать теорию форм. Я хочу понять, удобно ли ими пользоваться.

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

Для каждой формы дай:
ПРОБЛЕМА → ЧТО ЧУВСТВУЕТ ПОЛЬЗОВАТЕЛЬ → ИСПРАВЛЕНИЕ.

Промпт 9

Доступность интерфейса (accessibility) без академизма

Проведи базовый аудит доступности интерфейса.

Не пиши длинную теорию WCAG.

Проверь только практические вещи:
- можно ли пройти интерфейс клавиатурой;
- видно ли, где сейчас focus;
- читается ли текст на фоне;
- есть ли подписи у полей;
- кнопки ли это, а не случайные div;
- понятны ли ошибки;
- есть ли alt у важных изображений;
- достаточно ли большие touch targets на телефоне.

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

Промпт 10

Скорость работы глазами пользователя

Проверь frontend на скорость.

Мне не нужны абстрактные миллисекунды.
Мне нужно понять, где пользователь ждёт.

Найди:
- тяжёлые изображения;
- лишний JavaScript;
- тяжёлые шрифты;
- внешние скрипты;
- элементы, которые можно грузить позже;
- долгие API-запросы.

Для каждой проблемы напиши:
ЧТО ТОРМОЗИТ → ЧТО ВИДИТ ПОЛЬЗОВАТЕЛЬ → ЧТО ИСПРАВИТЬ → КАКОЙ ЭФФЕКТ ОЖИДАЕТСЯ.

Сначала исправляй самые большие реальные тормоза.

Промпт 11

Визуальная проверка по скриншотам

Сделай visual QA моего frontend.

Сними 4 screenshot:
320
390
768
1440

Сравни с утверждённым референсом.

Проверь:
- layout;
- отступы;
- alignment;
- размеры текста;
- кнопки;
- карточки;
- цвета;
- изображения;
- mobile behavior.

Раздели отличия:
КРИТИЧНО
ЗАМЕТНО
МЕЛОЧЬ

Не правь всё подряд.
Сначала исправь то, что реально ухудшает интерфейс.

Промпт 12

Финальная приёмка без доверия к словам AI

Проведи финальную приёмку frontend.

Не верь предыдущим сообщениям "готово".
Нужны доказательства.

Проверь:
1. Главный пользовательский сценарий.
2. 320 / 390 / 768 / 1440.
3. Navigation.
4. Главные кнопки.
5. Forms.
6. Loading.
7. Empty.
8. Error.
9. Success.
10. API.
11. Auth / permissions.
12. Console.
13. Network.
14. Accessibility baseline.
15. Performance baseline.
16. E2E.

Для каждого пункта:
PASS / FAIL / NOT TESTED

PASS ставь только если реально проверил.

В конце ответь:
- что точно работает;
- что не проверено;
- что может сломаться в production;
- что мне лично стоит открыть и проверить глазами.

11. Непонятные слова простыми словами 😄

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

Термин	Что это значит для тебя
Frontend	Всё, что видит пользователь в браузере и с чем он взаимодействует.
Backend	Скрытая серверная часть: логика, база, AI, права, данные.
Browser	Chrome, Safari и т.п. Программа, которая показывает web-интерфейс.
HTML	Каркас страницы: какие элементы на ней есть.
CSS	Внешний вид: цвета, размеры, отступы, расположение.
JavaScript	Поведение: что происходит после клика или другого действия.
UI	Как интерфейс выглядит.
UX	Насколько человеку удобно им пользоваться.
Компонент (Component)	Повторяемый кусок интерфейса: кнопка, карточка, форма.
Состояние (State)	Текущее состояние интерфейса: загрузка, ошибка, успех и т.д.
API	Способ, которым frontend просит backend что-то сделать или вернуть данные.
Request	Запрос: frontend отправляет просьбу серверу.
Response	Ответ сервера на запрос.
Endpoint	Конкретный адрес функции backend.
JSON	Формат, в котором часто передаются данные.
Responsive	Интерфейс нормально перестраивается под разные экраны.
Mobile-first	Сначала делаем удобно на телефоне, потом расширяем.
Viewport	Та часть страницы, которую прямо сейчас видно на экране.
Breakpoint	Размер экрана, на котором layout начинает перестраиваться.
Loading	Состояние, когда система ещё работает.
Empty	Состояние, когда данных пока нет.
Error	Состояние ошибки с понятным следующим шагом.
Success	Подтверждение, что действие получилось.
Accessibility	Чтобы интерфейс был понятен и доступен большему числу людей.
Focus	Какой элемент выбран клавиатурой прямо сейчас.
DevTools	Встроенные инструменты браузера для проверки сайта.
Console	Место, где видны ошибки JavaScript.
Network	Место, где видны запросы frontend к серверу.
Design System	Общие правила интерфейса: кнопки, цвета, размеры, компоненты.
Registry	Каталог готовых компонентов.
Skill	Инструкция, которая учит AI работать определённым способом.
MCP	Способ дать AI доступ к внешним инструментам и базам знаний.
llms.txt	Документация, подготовленная так, чтобы её было удобно читать AI.
Starter repo	Готовый проект, который можно взять за основу.
E2E	Проверка полного пути пользователя от первого действия до результата.

13. Домашка на реальном проекте

Не делай отдельный учебный сайт.

Возьми один реальный пользовательский сценарий своего продукта.

ВОЙТИ В АККАУНТ или СОЗДАТЬ ПРОЕКТ или ЗАГРУЗИТЬ ФАЙЛ или СГЕНЕРИРОВАТЬ ИЗОБРАЖЕНИЕ или ОПЛАТИТЬ

Попроси AI нарисовать путь пользователя простыми словами.
Попроси найти готовые UI-решения.
Попроси сделать loading / empty / error / success.
Проверь 4 размера экрана.
Проверь Network и Console.
Пройди сценарий E2E.

Что принести на разбор: 4 screenshot, карта «клик → backend → результат», один screenshot ошибки, один loading, один success и финальный E2E PASS.

Главная мысль

Тебе не надо становиться программистом.

Но тебе надо стать человеком, который понимает систему достаточно хорошо, чтобы управлять AI-разработчиком.

ТЫ: понимаешь пользователя ↓ ставишь задачу ↓ AI исследует готовые решения ↓ AI пишет код ↓ AI тестирует ↓ ТЫ проверяешь последствия ↓ ПОЛУЧАЕТСЯ ПРОДУКТ, А НЕ ДЕМО

Следующий гайд: надёжность ИИ-сервиса — фоновые задачи, очереди, retries, fallback, rate limits и рост нагрузки.

Перед следующим гайдом — практика: закрепи тему на реальной задаче «Собери Telegram Mini App». После практики маршрут сам приведёт тебя к гайду 11.

Frontend и UI/UX
для вайбкодера