Модуль 7.1. Быстрые прототипы: low-fi / high-fi
Темы: user flows, wireframes, контроль состояний и ошибок. Артефакты: прототип экрана/процесса. Практика: прототип 3 ключевых экранов.
Прототип — это доказательство поведения, а не шедевр пиксель-арта. Задача системного аналитика (SA) — быстро зафиксировать пользовательские потоки (user flows), каркас экранов (wireframes) и критические состояния/ошибки, чтобы:
- согласовать с бизнесом и командой что именно делаем;
- выявить риски и «дыры» (валидация, пустые состояния, деградации);
- заложить артефакты, которые легко связать с AC/BDD, API/событиями и NFR.
Итог модуля — набор low-fi (быстрых) и/или high-fi (подробных) прототипов ключевых экранов процесса с учётом всех состояний.
Уровни детализации: когда low-fi, когда high-fi
|
Критерий |
Low-fi (ч/б, каркас) |
High-fi (детализировано) |
|---|---|---|
|
Цель |
Быстро проверить поток/логику, споры о составе |
Проверить тексты, плотность, состояния, пиксели |
|
Скорость |
часы |
дни |
|
Кому показывать |
внутренняя команда, быстрые созвоны |
стейкхолдеры, UAT/юзабилити-пробы |
|
Когда |
ранняя стадия, неопределённость |
перед разработкой/версткой |
|
Инструменты |
Miro/FigJam, бумага, low-fi UI-киты |
Figma/Sketch, дизайн-система, интерактивность |
Правило: начинаем с low-fi на поток, затем повышаем до high-fi на «счастливую тропу» + ошибки/пустые состояния/деградации.
User Flow: как фиксировать путь пользователя
Мини-методика (15–45 мин)
- Определите персону/роль и «работу пользователя» (JTBD).
- Разложите сценарий на шаги: намерение → ввод → подтверждение → результат.
- На каждом шаге отметьте альтернативы (ошибка, пусто, отмена, повтор).
- Для каждого шага укажите ответ API/события, таймауты/ретраи, фичефлаги.
Нотейшн (Mermaid, можно вставлять в Confluence)
flowchart LR A[Каталог] --> B[Корзина] B --> C[Чекаут: адрес/способ] C -->|Оплата успешна| D[Экран Успех] C -->|PSP timeout| E[Экран Ожидание (202)] C -->|Отказ банка| F[Экран Ошибка + Retry/Изменить метод] E -->|Вебхук пришёл OK| D E -->|Истёк SLA| F
Wireframes: каркас «что где лежит»
Обязательные элементы
- Иерархия: заголовок/секции/первичные и вторичные действия.
- Навигация: где я? как вернуться?
- Состояния: loading/skeleton, empty, content, partial failure, error, offline, permission.
- Валидация: где и как показываем ошибку/подсказку.
- Микротекст (microcopy): что пользователь видит при ошибке/пустом наборе.
Шаблон состояния формы (анти-дубли)
|
Состояние |
Что показываем |
Действия |
|---|---|---|
|
Loading |
skeleton, disabled primary |
отмена/назад |
|
Content |
поля, подсказки, доступная primary |
«Сохранить/Оплатить» |
|
Empty |
«У вас пока нет …», CTA |
«Добавить…» |
|
Error (вал.) |
inline error у поля + summary |
исправить → повторить |
|
Error (сеть) |
«Проблемы со связью…» |
Retry + «Сохранить черновик» |
|
Partial failure |
тост/баннер с деталями |
«Повторить неуспешные» |
|
Offline |
оффлайн-стаб + кеш последнего |
«Повторить позже» |
Контроль ошибок и состояний (как сотруднику — к исполнению)
Валидация (правила)
- Валидация на клиенте (формат/диапазон) и на сервере (правила/авторизация).
-
Ошибка поля — под полем, человеческим языком + код (для QA):
«Сумма должна быть от 0,01 до 100 000,00 (AMOUNT_BELOW_MIN)». - Кнопки: disabled только при гарантированно неверных данных; иначе активна → сервис ответит 4xx с подсказкой.
- Обязательное предотвращение двойной отправки (спиннер, idempotency key).
Деградации и ретраи
- При 202 Accepted — экран «Ожидаем подтверждение», авто-обновление/поллинг, канал «вернуться позже».
- При падении зависимостей — предложение альтернативы (изменить метод, отложить операцию).
- Идемпотентность: повтор не должен плодить сущности.
Пустые состояния (empty states)
- Не «пустота», а обучающий контент: иллюстрация, 1–2 шага, CTA.
- Примеры: «Заказов пока нет. Создайте первый заказ — это займёт 2 минуты.»
Длинные тексты/локализация
- Проверяем обрезку/перенос (de, fr), валютные/датовые форматы, направление (если актуально).
Прототипирование в инструментах
- Low-fi: Miro/FigJam (стикеры/карты потоков), Figma Wireframe Kit (ч/б блоки).
- High-fi: Figma + компоненты дизайн-системы (кнопки, инпуты, модалки, тосты), интерактивность (Prototype).
- Состояния в Figma: Variants для кнопок/полей (default/hover/focus/disabled/error/loading), Component Properties для переключения.
- Аксессибилити: контраст 4.5:1 для текста; фокус-стейт; чтение экранных ридеров для ошибок.
Пример домена: «Заказ → Оплата → Возврат»
Мы спроектируем 3 ключевых экрана и их состояния:
Экран 1. «Оформление заказа (чекаут)»
- Поля: email, адрес, способ оплаты, чекбокс «согласен».
- Состояния: loading, content, error(валидация), error(сеть).
-
Микротекст ошибок:
- Email: «Проверьте формат адреса (например, name@domain.ru)».
- Адрес: «Заполните улицу и дом».
- Действия: «Оплатить», «Назад».
- Технические: при submit → POST /payments с Idempotency-Key.
Экран 2. «Оплата — результат»
- Успех: «Оплата прошла. № заказа 12345», CTA: «Вернуться в магазин».
- Ожидание (202): «Платёж в обработке… Это может занять до 2 минут», авто-обновление, «Продолжить покупки».
- Ошибка (5xx/decline): баннер с кодом/советом и кнопки «Повторить», «Изменить метод».
- Пусто/ретри: «Мы не получили подтверждение. Попробуйте позже — мы пришлём письмо».
Экран 3. «Частичный возврат (кабинет оператора)»
- Поля: сумма возврата, причина (select), комментарий.
- Валидация: 0.01 ≤ amount ≤ capturedAmount, причина обязательна.
- Ошибки: превышение суммы, отсутствие прав (403), истечение окна возврата.
- Действия: «Создать возврат», «Отмена».
- Тех: POST /refunds → 201/422; аудит-лог.
Шаблоны артефактов
Карточка прототипа экрана (шаблон)
# Прототип: <Экран/Процесс> vX.Y Цель: <что подтверждаем> Персоны/Роли: <кто пользуется> Связи: AC-…, RTM-…, OpenAPI /events, фичефлаги ## Состояния - Loading: <skeleton/спиннер, таймауты> - Content: <основные поля/элементы> - Empty: <копирайтинг + CTA> - Error (валидация): <правила, тексты, коды> - Error (сеть/зависимости): <retry/backoff, альтернативы> - 202/Async: <экран ожидания, SLA, автообновление> - Offline: <поведение> ## Управление действиями - Primary: <условия enabled/disabled> - Secondary: <…> - Двойной клик/повтор: <идемпотентность> ## Инструментация - События аналитики: <что логируем> - Метрики UX: completion rate, avg time, ошибки форм - Доступность: фокус-стейты, контраст, aria-labels ## Примечания к реализации - API: <эндпоинты/коды/схемы> - События: <имена/версии> - Фичефлаги: <kill switch/rollout>
Чек-лист прототипа (короткий)
- Есть user flow с альтернативами (ошибка/ожидание/пусто).
- В каждом экране прописаны состояния и тексты ошибок.
- Валидация: inline + summary, правила и коды.
- Деградации: 202, таймауты, retry, идемпотентность.
- Аксессибилити: фокус/контраст/ARIA.
- Локализация/форматы (валюта/дата).
- Метрики UX и события аналитики.
- Связи с AC/BDD/OpenAPI/RTM.
Типовые ошибки и как их избежать
|
Ошибка |
Симптом |
Как лечить |
|---|---|---|
|
Прототип только «счастливая тропа» |
В проде падаем на ошибках/пустых состояниях |
В чек-лист добавить все состояния; требовать экраны ошибок |
|
Без валидации/текстов |
Пользователь не понимает, что делать |
Шаблон ошибок + библиотека microcopy |
|
Нет идемпотентности |
Дубликаты при повторах |
Кнопка блокируется + ключ идемпотентности |
|
Пиксель-перфекционизм на старте |
Срыв сроков |
Сначала low-fi, затем high-fi на согласованной тропе |
|
Нереалистичные данные |
«Сломанная» верстка на длинных строках |
Фикстуры: длинные имена, другие локали/валюты |
|
Игнорируем доступность |
Жалобы, неиспользуемость |
Контраст, фокус, читабельные сообщения |
|
Смешение ролей и прав |
Пользователь видит лишнее |
Прототипы по ролям, RLS-правила |
Вопрос–Ответ
В: Сколько экранов достаточно на первом цикле?
О: Для процесса — 3–5 ключевых (включая экраны ошибок/ожиданий). Больше — только после согласования ядра потока.
В: Нужно ли сразу high-fi?
О: Нет. Быстрый low-fi экономит недели. High-fi — когда поток согласован и требуется уточнить тексты/плотность/адаптив.
В: Прототип должен быть «кликабельным»?
О: Для потоков — да (минимальная интерактивность: переходы, ошибочные ветви). Для схем/форм — достаточно статик + чёткие состояния.
В: Как показать деградацию 202 Accepted?
О: Отдельный экран «Ожидание» с авто-обновлением, таймером, SLA и CTA. В прототипе — переход на «Успех/Ошибка» после задержки.
В: Надо ли рисовать разные роли?
О: Да, если различаются права/контент. Разные варианты в одном файле (варианты компонентов) или отдельные страницы.
В: Где хранить тексты ошибок?
О: В отдельной вкладке Figma/таблице проекта (словарь ошибок), связать с кодами и AC.
Практика: «Прототип 3 ключевых экранов» (90–150 мин)
Кейс: «Заказ → Оплата → Возврат» (или ваш домен).
Задача:
- Нарисовать user flow (Mermaid/Miro) с альтернативами PSP timeout, decline, empty.
- Сделать low-fi wireframes трёх экранов: «Чекаут», «Результат оплаты», «Частичный возврат».
- Повысить fidelity до high-fi для «Чекаута» со всеми состояниями (loading/content/empty/error/202/offline).
- Заполнить карточку прототипа (шаблон выше) + чек-лист.
- Связать экраны в Figma-Prototype (минимальная интерактивность).
- Приложить микротексты ошибок и правила валидации.
Критерии зачёта
- Поток покрывает счастливую и ошибочные ветви.
- У экранов описаны все состояния и тексты ошибок.
- Видна стратегия деградации 202 и предотвращение дублей.
- Прототип кликабелен, понятен без автора.
- Есть ссылки на AC/BDD/OpenAPI/RTM.
Шпаргалка (коротко)
- Начните с user flow → затем wireframes → потом high-fi на важные ветви.
- Всегда рисуйте ошибки/пустые/ожидание/оффлайн — это реальные состояния.
- Валидация: inline + summary, понятные тексты + коды.
- Деградации и идемпотентность — обязательны для действий с сетью/деньгами.
- Храните тексты/схемы/AC рядом, линкуйте из прототипа.
- Думайте о доступности и локалях сразу.
