Рома Климычев, продуктовый дизайнер, проектирую high-load сервисы, кабинеты, дашборды и много-ролевые сценарии для реального мира, а не для презентаций.

Интерфейс для плотной авиационной работы: планировщик открывает систему, понимает текущее состояние, сужает данные, проверяет статус и переходит к действию без потери контекста. Это не кейс про один красивый экран. В большой операционной системе пользователь почти никогда не решает задачу одним прямым шагом. Он держит в голове роль, раздел, выбранную сущность, фильтры, статус, ограничения, таблицу и действие, которое можно выполнить сейчас. Если эти слои живут отдельно, интерфейс заставляет собирать контекст вручную. Моя задача была в том, чтобы собрать повторяющиеся части продукта в понятную рабочую систему: хедер, фильтры, таблицы, сохраненные представления и большие сценарии редактирования.

Медицинский продукт, где запись, анамнез, медкарта, консультация и консилиум связаны в один контекст между пациентом, врачом и клиникой. Clinio нельзя объяснить как набор медицинских экранов. Его ценность в том, что разные роли работают с одной историей: пациенту нужен следующий шаг, врачу нужен контекст, клинике нужна управляемая структура сервиса, а консилиуму нужен общий пакет данных для обсуждения. Моя задача была собрать эту ролевую архитектуру в продуктовую систему: от записи и первичных вводных до медкарты, консультации, рекомендаций и консилиумов.

Карта для руководителя полевой команды: маршрут, заявки, история действий и простои собраны в один рабочий экран. Проблема была не в том, чтобы показать людей на карте. Руководителю нужно было понять рабочий день: где сотрудник находится, какие заявки взял, где возникла задержка, что закрыто и какой маршрут сложился по факту. Этот кейс можно сделать сильным операционным примером после metric gate. Пока он остается supporting case: есть визуальные источники и понятная продуктовая рамка, но точный смысл 2x нужно подтвердить отдельно.

Личный кабинет, где частые действия вынесены вперед: оплата, показания и важный статус не должны теряться среди справочных разделов. Пользователь приходит в такой продукт не изучать интерфейс. Чаще всего у него есть одна задача: оплатить, передать показания, проверить состояние счета, найти документ. Если эти действия спрятаны в общей навигационной массе, кабинет начинает ощущаться тяжелее, чем сама задача. Этот кейс лучше держать компактным: он не про большую трансформацию, а про ясную информационную архитектуру массового сервиса.

ERP для проектной компании: роли, проекты, время, документы и финансы собираются в один рабочий контур. Corely не стоит подавать как полноценный визуальный кейс, пока нет сильных интерфейсных источников. Его честная ценность в другом: показать, как внутренний продукт раскладывается на роли, модули, сущности и рабочие связи. Это supporting case про архитектуру, а не про красивый набор экранов.

Сценарий фиксации аварии: оператору нужно быстро передать инженеру контекст, статус и следующий шаг. Это потенциально хороший кейс про срочный операционный сценарий. Но текущий источник слишком тонкий: нет подтвержденных экранов, деталей формы, старого флоу и результата теста. Поэтому текст ниже - не готовая runtime page, а full-copy draft для будущего source gate.