Короткий ответ
Дизайн SaaS-продукта покрывает роли и права, которые решают, кто что видит, повторяющиеся сценарии ежедневной работы и все состояния, в которых может оказаться каждый экран: пустой, загрузка, ошибка, только чтение, частичные данные, плотность и переполнение. Он описывает поведение компонентов, а не их вид, покрывает работу с клавиатуры и вспомогательные технологии и заканчивается передачей, по которой разработка соберёт продукт. Он не покрывает экраны, которых нет в объёме.
Проверенные факты
- Проверка источников
- 7 сентября 2026 года
- Задача читателя
- требования к дизайну SaaS-продукта
Результат работы — не количество экранов
Спросите, что даёт проект по дизайну SaaS-продукта, и честный ответ — не количество экранов. Это набор решённых ситуаций: кто смотрит, что он пытается закончить и что делает интерфейс в каждом состоянии, в котором система реально бывает. Заполненный экран со счастливым путём — тот, который все смотрят на ревью, и тот, который потом создаёт меньше всего проблем.
Основная работа сидит в семи состояниях ниже. Перечислить их — механическая задача, и здесь подготовка с ИИ-ассистированием быстрая и недорогая. Решить, что должно происходить в каждом, — нет: ответ зависит от того, как ваша система отказывает и что ваши пользователи могут позволить себе потерять. Для этого нужен человек, с которого за ответ спросят.
Пустое
Как выглядит: экран до появления данных, с одним действием, которое создаёт первую запись, и простым описанием того, что появится после. Без него: новые аккаунты открываются на пустую таблицу, и поддержка каждую неделю отвечает на один и тот же вопрос.
Загрузка
Как выглядит: решённое поведение при медленном ответе — скелет строк, постепенное заполнение или блокирующий индикатор — и что меняется после заявленного порога. Без него: на каждом экране появляется тот индикатор, который выбрал разработчик, а медленные пути читаются как сломанные.
Ошибка
Как выглядит: что видит пользователь, когда действие не прошло, что можно повторить и что сохраняется, пока он повторяет. Без него: неудавшееся сохранение молча выбрасывает то, что человек набрал, — и именно это запоминается дольше всего.
Только чтение
Как выглядит: тот же экран глазами того, кто может смотреть, но не менять, где «скрыть» и «сделать неактивным» выбраны осознанно, а не по экрану. Без него: права держатся на бэкенде и протекают в интерфейс.
Частичные данные
Как выглядит: как экран признаётся, что один источник не ответил или цифра старее остальных. Без него: наполовину загруженный экран выглядит так же уверенно, как полный, и по нему принимают решения.
Масштаб
Как выглядит: та же таблица на тысяче строк — страницы или виртуализация, сортировка, фильтры и то, какие колонки выживают на узком экране. Без него: вёрстка работает в демо и не работает на втором месяце.
Переполнение
Как выглядит: каждая подпись и каждое значение в самой длинной правдоподобной форме, включая переведённую строку. Без него: кнопки переносятся, обрезка прячет самое важное, а починка приезжает после запуска.
Роли и права идут раньше экранов
Экран — это не один макет, если две роли видят его по-разному. Перечислите все роли, включая операторские и поддерживающие, которых никогда не бывает в презентации, и для каждой скажите, что она может видеть, что менять и куда ей нельзя вообще. Эта таблица определяет, сколько макетов существует на самом деле, и написать её несравнимо дешевле, чем обнаружить.
Осознанно решите, скрывается запрещённое действие или остаётся видимым, но неактивным. Скрытие делает интерфейс тише и лишает человека возможности узнать, что он мог бы запросить; неактивность объясняет границу и признаёт, что возможность есть. Оба варианта защитимы. Случайный выбор на каждом экране — то, как один продукт в итоге делает и так и так.
Реальные данные ломают вёрстку, которой льстят тестовые
Попросите обезличенную выгрузку до первого макета. Десять придуманных строк делают любую таблицу сбалансированной; реальные записи приносят длинные имена, пустые поля, почти-дубликаты, смешанные языки и куда больше строк, чем любое демо. Именно эти условия вёрстке предстоит выдержать, и все они известны уже в первый день.
Две цифры важнее остальных: самая длинная величина, которую поле реально может содержать, и сколько строк накапливает обычный аккаунт за год. Проектируйте под них — интерфейс держится. Проектируйте под демо — и первый настоящий клиент становится первым баг-репортом.
Прорабатывать стоит те сценарии, которые повторяются
Большая часть рабочего дня внутри инструмента — это две-три задачи, сделанные снова и снова. Они заслуживают детализации: каждый шаг, каждое ветвление, что происходит, когда человека прервали на середине и он вернулся, и как отменить только что сделанное. Страница настроек, которую открывают дважды в год, такого не требует, и делать вид, что требует, — способ незаметно удвоить объём.
Скажите вслух, какие сценарии выбраны для этой глубины, а какие сознательно оставлены легче. Незаявленная разница в проработке читается на ревью как незаконченная работа, хотя это было решение о том, куда потратить усилие.
Описывайте поведение, а не только внешний вид
Компонент не описывается тем, как он выглядит. Он описывается тем, что он делает: куда уходит фокус, что означает неактивное состояние, когда срабатывает валидация и что она говорит, что происходит при медленном ответе и как через него движется клавиатура. Внешний вид можно срисовать с картинки. Поведение, если его не записали, придумывается в коде — и дальше отличается от экрана к экрану.
Это не то же самое, что строить дизайн-систему. Описать поведение один раз и переиспользовать — результат этой работы; поднять систему, которую несколько команд поддерживают годами, — отдельное решение со своей стоимостью и своим вопросом о готовности, и его стоит задавать отдельно, а не вносить в объём по умолчанию.
Клавиатура и вспомогательные технологии здесь — функциональное требование
Люди работают в инструменте целый день, и это меняет расчёт. Работа с клавиатуры перестаёт быть галочкой соответствия и становится быстрым путём для всех, кто вводит данные, — и она же ломается первой, когда нативный элемент заменяют самописным. WebAIM описывает, какое поведение с клавиатуры нужно интерактивным элементам и как его проверять.
Самописным элементам нужно явно задать семантику, а не подразумевать её. Стилизованный div, ведущий себя как выпадающий список, не сообщает вспомогательным технологиям ничего, пока ему не задали роль, состояние и подпись; что ARIA ожидает от каждого, документирует MDN. Решайте это на этапе дизайна, потому что добавлять потом обычно значит пересобирать компонент.
Что разработке нужно в передаче
Передача закончена, когда человек, которого не было на ревью, собирает экран, не задав ни одного вопроса. Значит: каждое состояние отдельным кадром, настоящие тексты для пустого экрана и для отказа вместо заглушек, отступы и типографика как переиспользуемые значения, а не числа, снятые линейкой с картинки, и правила, которые интерфейс обязан соблюдать, записанные как правила.
Включите и то, что сознательно не описано, и назовите, кто это решает. Разработчики всё равно примут эти решения, когда придёт срок; разница между хорошей и плохой передачей в том, знали ли они, что принимают их.
Что покрывает срок 15–30 дней, а что нет
Работа такой длительности покрывает таблицу ролей, повторяющиеся сценарии от начала до конца, состояния для экранов внутри этих сценариев, поведение компонентов, которые эти экраны используют, и передачу. Она не покрывает все экраны зрелого продукта, полноценную дизайн-систему, продолжение итераций после выпуска и исследование, которое никто не заказывал.
Честный вопрос об объёме — не сколько экранов, а сколько состояний на сколько ролей. Две роли и восемь экранов в семи состояниях — это другой проект, чем пять ролей и те же восемь экранов, и второй не немного больше работы, а другая смета.
Запишите исключения
Перечислите то, что вне объёма, в том же документе и до начала работы. Не как отговорку, а как общую карту того, что существует, но пока не делается, с условием, которое вернёт каждый пункт внутрь. Большинство споров в конце продуктового дизайн-проекта — не разногласия о качестве, а два разных воспоминания о том, что входило.
Этот список исключений — ещё и самый дешёвый плановый артефакт, который вы получите из проекта. Это бэклог следующего этапа, уже обсуждённый, с приложенными причинами, а такого у большинства бэклогов нет.
Практический чеклист
- Каждая роль перечислена: что видит, что меняет и куда ей нельзя вообще
- Каждый экран описан во всех семи состояниях, а не только в заполненном
- Вёрстка проверена на обезличенной реальной выгрузке, а не на десяти строках
- Два-три ежедневно повторяющихся сценария проработаны до конца, включая прерывание
- Поведение компонентов записано: фокус, неактивность, валидация, медленный ответ, клавиатура
- Работа с клавиатуры и семантика для вспомогательных технологий покрыты у каждого элемента
- В передаче есть состояния, переиспользуемые значения, реальные тексты отказа и правила
- Исключения перечислены явно, у каждого — условие, которое вернёт его в объём
Вопросы и ответы
Что в итоге получаешь в конце дизайн-проекта SaaS?
Сценарии для повторяющейся работы, каждый экран во всех его состояниях, записанное поведение компонентов, тексты для пустого экрана и для отказа и передачу, по которой разработка соберёт продукт без догадок. Количество файлов с картинками значит куда меньше, чем то, описано ли поведение.
Зачем дизайнеры просят реальные данные до старта?
Потому что тестовые данные прячут проблемы. Десять аккуратных строк делают любую таблицу правильной; реальная выгрузка приносит длинные имена, пустые поля, дубликаты и тысячу записей — и решают вёрстку именно они. Обезличенной выгрузки обычно достаточно.
Сколько экранов ожидать?
Меньше, чем вы думаете, но в большем числе состояний, чем вы думаете. Восемь экранов по семь состояний — это пятьдесят шесть спроектированных ситуаций, и работа с риском сидят в состояниях. Счёт по экранам систематически занижает объём.
Нужна ли нам для этого дизайн-система?
Не обязательно. Этой работе нужно поведение компонентов, описанное один раз и переиспользуемое, а это другое, чем строить и поддерживать дизайн-систему. Если несколько команд будут годами разрабатывать параллельно, это отдельный вопрос, который стоит задать отдельно.
Что подготовить до начала проекта?
Обезличенную выгрузку данных, список ролей с правами, две-три задачи, которые люди делают ежедневно, и человека, который может ответить, что должно происходить при отказе. Эти четыре вещи разблокируют большую часть работы.