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