Специализированный пользовательский слой
Одна цифровая логика — разные рабочие поверхности
Надстройка адаптирует навигацию, данные и действия под роль, отрасль или продуктовый сценарий, сохраняя платформу источником истины и не дублируя её бизнес‑логику.
Руководитель программы
6целевых типов поверхности
7слоёв паспорта интерфейса
0дублированной бизнес‑логики
Граница продукта / 01
Надстройка меняет опыт, но не источник истины
Все критичные данные, правила, состояния и права остаются в платформенной системе и конфигурации. Пользовательская поверхность управляет тем, что человек видит и как выполняет разрешённое действие.
Интерфейсная надстройка
Текущий разделНавигация · ролевые представления · визуальный язык · управляемые сценарии
Конфигурация
Открыть ↗Роли · процесс · состояния · показатели · правила · интеграции
Шаблоны
Открыть ↗Карточки · программы · анкеты · шкалы · отчёты · представления
Информационная система
Открыть ↗Объекты · функции · данные · транзакции · предметная модель
Архитектурное правило
Если интерфейс сам хранит критичные данные, воспроизводит права или принимает управленческое решение без вызова платформы, он перестаёт быть надстройкой и становится отдельной информационной системой.
Типы поверхности / 02
Форма интерфейса зависит от роли и частоты действия
Это целевая типология каталога, а не перечень готовых коммерческих продуктов. Каждая надстройка требует проверки платформенных API, прав, версии конфигурации и пользовательского сценария.
01 / WORKSPACEРолевое рабочее место
Сосредоточенный интерфейс для регулярной операционной работы одной роли.
+
Примеры
Кабинет трекера · рабочее место эксперта · панель организатора
Ключевой принципМинимум переходов между решением, основанием и действием.
02 / PORTALБрендированный портал
Единая точка входа в программу, организацию или экземпляр экосистемы.
+
Примеры
Портал акселератора · университетская среда · кабинет партнёра
Ключевой принципБренд меняет поверхность, но не нарушает единый профиль и права.
03 / SHOWCASEПубличная витрина
Отбор и представление разрешённых данных о проектах, услугах, экспертах или событиях.
+
Примеры
Витрина проектов · каталог экспертов · афиша · маркетплейс решений
Ключевой принципПубликация управляется источником данных и моделью согласий.
04 / DASHBOARDУправленческий дашборд
Сводное состояние объектов, отклонений, рисков и решений для руководителя.
+
Примеры
Портфель проектов · ход программы · компетентностный профиль команды
Ключевой принципКаждый показатель раскрывается до данных и правила расчёта.
05 / GUIDEDУправляемый маршрут
Пошаговая поверхность для редкого или сложного действия без знания структуры системы.
+
Примеры
Подача заявки · вход в программу · адаптация · экспертное заключение
Ключевой принципПользователь видит следующий шаг, причину и ожидаемый результат.
06 / EMBEDВстраиваемый модуль
Ограниченная функция платформы внутри сайта, портала или партнёрского продукта.
+
Примеры
Форма регистрации · карточка события · статус заявки · блок профиля
Ключевой принципБезопасный контекст доступа и явная граница ответственности.
Проектировщик / 03
Начните с роли и главного решения
Маршрутизатор показывает первичную гипотезу поверхности. Он не заменяет UX‑исследование, проектирование API, модель доступа и проверку на реальных пользователях.
SURFACE-MGR / DASHBOARD
Центр решений по программе
Ведущий источникBusinessChain
ГЛАВНЫЙ ВОПРОС
Гипотеза интерфейсаОбсудить пилот ↘
Паспорт надстройки / 04
Семь слоёв удерживают целостность опыта
Паспорт связывает дизайн с платформенными объектами и правилами. Благодаря этому поверхность можно тестировать, обновлять и переносить без скрытого дублирования логики.
- 01Роль и контекст
Кто действует, в какой организации, процессе и точке маршрута.
- 02Информационная архитектура
Навигация, приоритеты, объекты и связи между представлениями.
- 03Модели представления
Какие платформенные данные нужны экрану и как они преобразуются.
- 04Действия и обратная связь
Команды, подтверждения, ошибки, состояния ожидания и результат.
- 05Доступ и безопасность
SSO, роль, контекст, видимость полей и проверка полномочий ядром.
- 06Дизайн‑система
Токены, компоненты, контентные правила, бренд и адаптивность.
- 07Аналитика и эксплуатация
События использования, ошибки, производительность, версии и поддержка.
Архитектура / 05
Интерфейс обращается к возможностям платформы
Надстройка не должна напрямую изменять базу данных или повторять правила доступа. Все команды проходят через согласованный контракт и проверяются системой‑владельцем объекта.
роль · контекст · намерение
навигация · view model · действие
команда · запрос · ответ · ошибка
права · правила · данные · транзакция
COMMON CONTEXTSSO+Единый личный кабинет+EventFlow
единая идентичность · ролевой контекст · цифровой след
Дизайн‑система / 06
Общий язык — разные бренды и сценарии
Надстройки наследуют доступность, сетку, поведение компонентов и состояния из общей системы. Бренд экземпляра меняет токены и контент, но не разрушает предсказуемость взаимодействия.
ActionAccentStatusInk
07Проектов на контроле
summary + drill downКритерии качества / 07
Поверхность готова, когда работает весь маршрут
Красивый макет не является готовой надстройкой. Проверяются пользовательский результат, доступность, безопасность, корректность данных, производительность и эксплуатация.
Пользователь завершает главный сценарий и понимает, что произошло дальше.
task successКлавиатура, фокус, контраст, подписи, масштабирование и понятные ошибки.
inclusive UXПрава проверяются ядром, контекст не подменяется, чувствительные данные ограничены.
least privilegeПоказатель и статус раскрываются до источника, версии и времени обновления.
traceable dataКлючевой экран и действие остаются пригодными при реальном объёме данных.
response budgetЕсть владелец, мониторинг, журнал версии, поддержка и путь отката.
operableПилот / 08
Одна роль. Один маршрут. Одно доказательство ценности.
Первый пилот ограничивает поверхность критичным сценарием. Так можно проверить опыт пользователя и архитектурный контракт до масштабной разработки портала.
Запросить пилот- 01 / FRAMEРоль и решениепаспорт сценария
Контекст, главный вопрос, частота работы, данные и ожидаемый результат.
- 02 / FLOWИнтерактивный прототипкликабельный маршрут
Навигация, состояния, ошибки и действия на реалистичных данных.
- 03 / CONTRACTПлатформенный стендрабочий контур
Интеграция с ролью, данными и командами одного цифрового ядра.
- 04 / EVIDENCEПроверка пользователямиgo / refine / stop
Наблюдаемый результат, ограничения, метрики и решение о следующем масштабе.
Целевая модель каталога / 09
Каждой надстройке нужен архитектурный паспорт
Текущая страница задаёт типологию и требования. До публикации конкретных предложений необходимо подтвердить реальный состав, совместимость, владельцев, сроки и условия эксплуатации.
- 01Название, тип, владелец и продуктовая роль
- 02Аудитория, сценарий и измеримый результат
- 03Система, конфигурация, API и версия
- 04Роли, права, данные и контекст доступа
- 05Дизайн‑система, бренд и адаптивность
- 06Тесты, производительность и ограничения
- 07Развёртывание, мониторинг, SLA и стоимость
Запрос на проектирование / 10
Опишите роль — соберём поверхность пилота
Форма подготовит письмо команде ИПИ‑ЛАБ. Отправка произойдёт только после вашего подтверждения в почтовой программе.
Черновик подготовленИнтерфейсный пилот
Открыть письмоПроверьте письмо, дополните его при необходимости и отправьте из почтовой программы.