03 / Веб-приложение, MVP или административный интерфейс
Разработка веб-приложений и дашбордов
Ключевой сценарий не помещается в готовый сервис и требует собственных ролей, состояний и данных?
Готовая система
Пользователь видит только доступные ему данные, понимает состояние объекта и выполняет главное действие с предсказуемым результатом.
ПЕРВЫЙ РАБОЧИЙ СРЕЗ
Первая версия проверяет ядро, а не количество экранов
Одна роль получает данные, проходит ключевое состояние и завершает действие, которое сохраняется и корректно отображается после повторного входа.
03 / ПЕРЕХОД СОСТОЯНИЯ
Роль → состояние → данные → ключевое действие
Интерфейс строится вокруг изменения системы, а не вокруг списка желаемых страниц.
СОСТОЯНИЯ
Система объясняет каждый переход
-
Пусто
Система объясняет, почему данных ещё нет и какой следующий шаг доступен.
-
Загрузка
Ожидание сохраняет контекст и не разрешает повторять незавершённое действие.
-
Ошибка
Пользователь видит, что не сохранилось, и получает безопасный способ повторить попытку.
-
Конфликт
Параллельное изменение не перезаписывается молча: система просит сверить актуальную версию.
ДАННЫЕ
Данные имеют источник
Каждое значение связано с источником истины, временем обновления и правилом изменения.
ДЕЙСТВИЕ
Ключевое действие меняет состояние
Доступное роли действие проходит проверку и возвращает понятный результат, а не только визуальный отклик.
ВХОД
Данные и ограничения до проектирования экранов
- один приоритетный пользователь и его ключевое действие
- сущности, источники данных и правила изменения состояния
- ограничения текущей архитектуры, если продукт уже существует
- критерии, по которым первая версия считается рабочей
КОНТРОЛЬ
Состояния, на которых ломается продукт
- роли и разрешения задаются до сборки экранов
- пустые, загрузочные, ошибочные и конфликтные состояния имеют осмысленное поведение
- главное действие нельзя выполнить дважды случайным повтором
- данные имеют определённый источник истины