Татьяна Рапанович
ТР
Привет, я Татьяна

Разбираю сложное,проектирую понятное

Продуктовый дизайнер. Проектирую B2B-платформы, админки с ролями и правами и мобильные приложения.

B2B и админкиМобильные приложенияАудит и редизайнСостояния экрановFigma Variables · Auto Layout
Избранные кейсы04

Обо мне

Я штатный UX/UI-дизайнер и веду несколько продуктов одновременно. Лучше всего мне даются задачи, где много данных, ролей и состояний. В таких интерфейсах хорошую структуру видно сразу: человек быстро находит нужное.

Начинала с мобильных приложений для людей с астмой и диабетом: напоминания о лекарствах, дневник сахара, аналитика показателей. Там я поняла: человек должен понимать, что происходит, даже когда что-то пошло не так. С тех пор пустые состояния и ошибки для меня так же важны, как главный экран.

Сейчас прохожу курс «Продуктовый дизайнер» в Университете SOVA. Ищу команду, которая делает сложный B2B-продукт.

Давайте познакомимся

Томск, работаю удалённоМестное время —
← Все кейсы Мобильное приложение · Редизайн · iOS и Android

Бронирование корта за один проход

Клуб падел-тенниса уже работал со своим приложением, но забронировать корт с тренером и инвентарём было сложно. Я провела аудит и пересобрала три сценария: бронирование, управление бронями и запись на мероприятия. Новая версия вышла в App Store и Google Play.

РольДизайнер
ПлатформыiOS и Android
ЗадачиАудит, сценарии, UI, состояния
КомандаМенеджер, мобильный и бэкенд-разработчики, тестировщик
13 → 6кликов до брони с тренером и инвентарём
18 → 4пункта меню → раздела навигации
14проблем нашла в аудите

Клиент обезличен. Логотип, названия, имена и фото тренеров скрыты. Цвета и шрифты — клиента. Сами экраны настоящие, из итогового макета.

Задача

Сделать главное действие главным

У приложения три задачи: арендовать корт, записаться на тренировку или турнир и управлять своими бронями. На деле к ним вели дублирующиеся кнопки, боковое меню на 18 пунктов и отдельные процессы для корта, тренера и инвентаря.

До Старая главная: крупный круг загруженности клуба вытесняет кнопки бронирования вниз Почему размыто?
Круг загруженности стоит в центре экрана, а «Аренда корта» уходит вниз.
После Новая главная: расписание кортов на сегодня со свободными слотами Почему размыто?
Первым идёт расписание на сегодня: свободные слоты видны сразу, загруженность понятна без отдельного виджета.
Аудит

14 проблем в пяти разделах

Я прошла приложение на iOS и Android: карточка клуба, расписание, бронирование, авторизация, личный кабинет. Для каждого замечания записала, почему оно мешает, как эту задачу решают другие приложения для падела и что предлагаю я. Несколько примеров:

Что мешалоЧто предложила
AndroidКрупный блок «Текущая загруженность» в центре главной вытесняет кнопки «Расписание» и «Аренда корта»Отдать приоритет бронированию. Загруженность видна по свободным слотам в расписании
В процессе аренды корта нельзя взять инвентарьОдин сценарий: корт, тренер и инвентарь как шаги одной брони
Фильтр «Утро / День / Вечер» без расшифровки, какие это часыПоказывать сами временные интервалы
iOSТри кнопки на главной ведут на один экран «Расписание»Одна точка входа, турниры и тренировки — в разных разделах
AndroidБоковое меню на 18 пунктовНижняя навигация на 4 раздела, «Мои тренировки» и «Моя аренда» — в профиле
Прошедшие события показываются как «Список пуст» с грустным смайликомСохранять историю и показывать прошедшее в неактивном виде
Вход только через WhatsApp, и код не приходитВход по телефону или почте с паролем и восстановлением доступа

Как было

Решения

Три главных решения

Вся бронь на одном экране

Раньше корт, тренер и инвентарь бронировались отдельно. Теперь это один экран, который собирается сверху вниз: дата, интервалы, корт, тип тренировки, тренер под каждый слот и оборудование.

  • Можно выбрать несколько интервалов подряд без повторного захода в расписание
  • Тренер подбирается под конкретный слот, а не на всю бронь
  • Итог разложен по строкам: видно, из чего складывается сумма
Экран бронирования: даты, интервалы, корт, тип тренировки, тренер, инвентарь и итог

Управление бронью без звонка в клуб

Отменить или перенести бронь раньше можно было только через администратора. Я добавила историю броней со статусами, а отмену и перенос пользователь теперь делает сам.

  • Статусы читаются сразу: ожидает оплаты, подтверждено, оплачено, отменена
  • Отмена с причиной, чтобы клуб понимал, почему люди отказываются
  • Перенос пересчитывает стоимость и заранее предупреждает о разнице
История посещений со статусами броней
Карточка брони с кнопками Оплатить и Отменить бронь

Турниры и занятия отдельно от аренды

В старой версии турниры и тренировки лежали в одном списке. Мероприятия получили свой раздел и понятные состояния карточки.

  • Цветовая метка отличает турнир от группового занятия
  • Количество мест видно до записи
  • Отдельные состояния «Нет мест» и «Запись только офлайн»
Раздел Мероприятия с турнирами и групповыми занятиями
Состояния

Каждый сценарий доведён до конца

Для разработки я описала состояния экранов: пустые, промежуточные, ошибки, подтверждения. В макете больше 100 экранов и состояний. Перенос брони, например, заканчивается понятным ответом: цена изменилась, разницу вернёт менеджер, заявку можно найти в «Обратной связи».

Результат

Что изменилось

13 кликов → 6

Корт, тренер и инвентарь оформляются на одном экране, без переходов между разделами.

Брони в руках пользователя

Перенос и отмена делаются в приложении, без звонка администратору. Версия уже в сторах.

Основа для дизайн-системы

Единая семантика цвета для статусов и общие компоненты вместо разрозненных экранов.

Что бы сделала иначе

Договорилась бы о метриках до старта

Раньше договорилась бы с командой о метриках. Тогда эффект редизайна можно было бы показать не только числом кликов, но и конверсией в бронь до и после.

Следующий кейс

Конструктор экспертных правил

B2B-платформа мониторинга оборудования: правила диагностики без программиста.

← Все кейсы
Конструктор экспертных правилСмотреть кейс →
← Все кейсы Web · B2B · Промышленность

Конструктор экспертных правил

Платформа мониторинга промышленного оборудования для инженеров и диспетчеров. Экспертные правила по показаниям датчиков распознают типовые дефекты. Я спроектировала конструктор, в котором эксперт собирает такое правило сам, без программиста. Решения обсуждала с дизайн-лидом и разработчиком.

РольUI/UX-дизайнер в паре с дизайн-лидом
ПользователиИнженеры и диспетчеры
Мои задачиКонструктор правил, отдельные разделы, тёмная тема
ПродуктЖивой, развивается
4типа блоков, из которых собирается правило
2режима ввода формул: визуальный и текстовый
3уровня, на которых видна ошибка

Проект под NDA. Логотип, названия объектов, организаций и имена в тестовых правилах скрыты. Сами экраны настоящие, из макета.

Задача

Логику диагностики описывает эксперт, а не программист

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

Список экспертных правил с деревом организационной структуры, типовыми дефектами, статусами и кнопками проверки Почему размыто?
Список правил. Слева организационная структура до конкретного агрегата. У каждого правила виден типовой дефект, статус включения и кнопка «Проверить». Правило с ошибкой помечено иконкой с подсказкой.
Устройство правила

Правило как цепочка блоков

Правило читается сверху вниз, как алгоритм. Сначала маппинг связывает переменные правила с параметрами конкретного актива. Дальше идут блоки: вычисления, ветвление, действие (отправить событие или записать в базу) и переназначение переменных. Слева дерево блоков, справа содержимое выбранного блока. В шапке всегда видно, к какой организации и активу относится правило.

Редактор правила: дерево блоков слева, таблица маппинга параметров справа Почему размыто?
Маппинг параметров: какой параметр актива попадает в какую переменную правила.
Выбор нового блока: вычисления, ветвление, действие, переназначение переменных
«Добавить блок» показывает все четыре типа сразу. У блока действия два варианта, поэтому кнопки выбора стоят прямо в карточке.
Формулы

Два способа написать формулу

Эксперты по-разному привыкли работать с формулами. Поэтому я предложила два режима в окне «Вычислить переменную», между которыми можно переключаться.

Визуальный режим: выражение из чипов, вкладки Литерал, Переменная, Формула
Визуальный. Выражение собирается из чипов: число, переменная или функция вставляются кнопкой, без риска опечатки.
Текстовый режим с подсказками: параметры, переменные, функции с описанием и примером
Текстовый. Для тех, кто пишет быстрее руками: подсказки сгруппированы по параметрам, переменным и функциям, у функции есть описание и пример.
Ошибки и проверка

Ошибку видно, не открывая каждый блок

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

Блок вычислений: переменная с ошибкой подсвечена красным в таблице и в дереве блоков
Ошибка в переменной видна сразу в двух местах: в строке таблицы и в дереве блоков слева.
Окно Проверить правило с выбором даты и времени
Проверка правила на данных за выбранный момент.
Подтверждение смены типа параметра: введённое выражение удалится
Смена типа параметра удаляет выражение, поэтому сначала окно предупреждает об этом.
Тёмная тема

Вторая тема на тех же токенах

Дизайн-систему с нуля собрал другой дизайнер команды. Я сделала её тёмную версию: вторую моду семантических токенов в Figma Variables. Компоненты и экраны переключаются между темами без отдельных макетов.

Результат

Что получилось

Логика без кода

Эксперт собирает правило из блоков и проверяет его сам, без программиста.

Ошибки не теряются

Проблема видна в переменной, в блоке и в списке правил одновременно.

Одна система, две темы

Тёмная тема на токенах без дублирования макетов.

Что бы сделала иначе

Проверила бы, какой режим формул выбирают

Посмотрела бы, каким режимом формул эксперты пользуются чаще: визуальным или текстовым. Самый популярный можно было бы открывать по умолчанию, а второй оставить переключателем.

Следующий кейс

Каталог музейного фонда

Публичный поиск по фонду и админка для сотрудников.

← Все кейсы
Каталог музейного фондаСмотреть кейс →
← Все кейсы Web · B2B · Публичный портал и админка

Каталог музейного фонда

Информационно-поисковая система архивно-библиотечного центра музея. В публичной части посетители и исследователи ищут книги, периодику, фотографии и документы фонда. В админке сотрудники управляют структурой фондов, коллекциями и атрибутами.

РольUI/UX-дизайнер
ЧастиПубличный портал и админка
Адаптив1366, 768 и 360 px
СтатусЗапущен
2интерфейса: для посетителей и для сотрудников
3вида каталога: плитка, таблица, превью
3роли с разными правами в админке

Проект под NDA. Название и логотип музея скрыты, как и тексты, которые на него указывают. Сами экраны настоящие, из макета.

Задача

Одна система для двух очень разных людей

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

Публичный каталог: быстрый поиск, сортировка, доступность и карточки материалов
Публичный каталог: быстрый поиск, сортировка и доступность. У каждой карточки видно тип материала и степень оцифровки, а при наведении — просмотр изображения.
Компоненты

Сначала навести порядок

Я пришла на проект на смену другому дизайнеру. В библиотеке компонентов был беспорядок, поэтому сначала я пересобрала компоненты, а потом прошла по всем экранам и перевела их на обновлённую библиотеку. Только после этого взялась за новые сценарии.

Фильтры

Фильтр в три колонки

Атрибутов у материалов фонда много, и значения устроены по-разному: иерархические справочники, строки, линейные справочники, диапазоны лет. Поэтому фильтр разделён на три колонки: категории, значения выбранной категории и выбранное. Выбранное собирается справа сразу при вводе, а у значения из иерархии виден путь, например «Тип единицы хранения / Библиотека / Периодика».

Фильтр: категории слева, значения в центре, выбранные значения справа
Даже при десятке выбранных значений видно, что именно отфильтровано, и любое можно снять крестиком.
Админка

Структура фонда на одном экране

Вместе с иерархическими справочниками этот раздел был самым сложным в проекте. Фонд делится на коллекции, коллекция — на типы единиц хранения с подтипами, а у типа есть атрибуты. Слева список фондов, справа коллекции выбранного фонда. Первый фонд выбирается сразу, поэтому экран не бывает пустым. В карточке коллекции собраны аннотация, обложка, типы и атрибуты. У каждого атрибута видно, справочник это или строка, обязателен ли он и показывается ли посетителям.

Управление фондами: список фондов со статусами слева и коллекции выбранного фонда справа Почему размыто?
Фонды и коллекции рядом: статус каждого виден в списке, типы единиц хранения — тегами в строке коллекции.
Карточка коллекции: аннотация, типы единиц хранения с подтипами и атрибуты с переключателем видимости Почему размыто?
Карточка коллекции. Видимость атрибута для посетителей переключается прямо в списке, без открытия редактирования.
Запросы в админке

Запросы переехали в каталог

Раньше сложные запросы в админке собирались на отдельной странице «Запрос»: сотрудник уходил из каталога, собирал условия и возвращался к результатам. Я перенесла фильтр прямо на страницу каталога, над таблицей единиц хранения. Теперь запрос и результаты на одном экране.

Основные поля — шифр, заглавие, коллекция и год — видны сразу. «Расширенный фильтр» добавляет блок по любому атрибуту: значение, заполненность и связь И/ИЛИ. Частый набор условий можно сохранить шаблоном и потом выбрать в один клик.

Каталог админки с раскрытым расширенным фильтром: основные поля, блок по атрибуту Авторы, кнопки Сохранить шаблон, Сбросить фильтр и Поиск Почему размыто?
Фильтр над таблицей: запрос и результаты на одном экране. Пункта «Запрос» в меню больше нет.
Список атрибутов для нового блока фильтра
«Добавить фильтр»: блок по любому атрибуту из списка.
Список сохранённых шаблонов фильтра
Сохранённые шаблоны частых запросов.
Роли и права

Каждый видит то, что ему нужно

В админке три роли. Методист создаёт и редактирует единицы хранения. Сотрудник в основном просматривает, и часть разделов ему недоступна. Суперадминистратор может всё то же, что методист, и дополнительно управляет пользователями и смотрит статистику.

Что можно делатьСотрудникМетодистСуперадмин
Просматривать каталог и единицы храненияДаДаДа
Создавать и редактировать единицы храненияНетДаДа
Работать во всех разделах админкиЧастичноДаДа
Управлять пользователямиНетНетДа
Смотреть статистикуНетНетДа
Статусы

Ничего не пропадает случайно

В фонде годами копятся связи между коллекциями и единицами хранения, поэтому объекты не удаляются сразу. У них три статуса: активен, не активен и архивирован, то есть мягко удалён. Из неактивного или архивного фонда нельзя завести новые коллекции. Архивные объекты скрыты, пока не включён переключатель «Показать архивированные», и их можно восстановить. Новая коллекция по умолчанию создаётся неактивной, чтобы посетители не увидели её до заполнения.

Список фондов с включённым показом архивированных объектов Почему размыто?
Архивный фонд: коллекции видны, но кнопка «Добавить» недоступна.
Окно добавления коллекции: название, аннотация, видимость по умолчанию Не активен
Новая коллекция по умолчанию скрыта от посетителей.
Результат

Что получилось

Система запущена

Публичный каталог и админка работают у посетителей и сотрудников музея.

Порядок в компонентах

Библиотека пересобрана, все экраны переведены на неё.

Права по ролям

Методист, сотрудник и суперадмин видят только свои разделы и действия.

Что бы сделала иначе

Договорилась бы о метриках поиска

До запуска договорилась бы с командой, как измерять поиск: например, какая доля запросов заканчивается найденным материалом. Тогда можно было бы показать, насколько расширенный поиск и новый фильтр помогают посетителям и сотрудникам.

Следующий кейс

Дневник питания без подсчёта калорий

Исследование и MVP мобильного приложения.

← Все кейсы
Дневник питанияСмотреть кейс →
← Все кейсы Mobile · Исследование · MVP

Дневник питания без подсчёта калорий

Проект, который я веду на курсе «Продуктовый дизайнер» в Университете SOVA и на фрилансе. Еду записывают фото, текстом или голосом, а вместо калорий приложение показывает баланс тарелки и отмечает, с какими эмоциями человек ест. Исследование и MVP готовы, интерфейс сейчас в работе.

РольПродуктовый дизайнер, весь цикл сама
ФорматКурс SOVA и фриланс
ПлатформаМобильное приложение
ЭтапИнтерфейс в работе
3глубинных интервью с респондентками
9этапов в CJM: от решения следить до попытки вернуться
17функций приоритизировала для MVP

Респондентки обезличены. В цитатах они обозначены как Р1, Р2 и Р3.

Проблема

Дневник бросают из-за самой записи

Многие бросают счётчики калорий в первые недели, и все три респондентки это подтвердили. Причина не в мотивации, а в процессе: нужно искать продукт в базе, взвешивать порции и считать граммы. У одной из респонденток ввод обычного обеда занял около 5 минут, и она сказала: «Если каждый раз так делать, я долго не выдержу».

Я искала способ вести дневник, который не превращает человека в бухгалтера: записать еду за секунды, увидеть, чего не хватает в тарелке, и не ругать себя за срыв.

Исследование

Сначала гипотезы, потом люди

Я начала с прото-персон: например, мама в декрете, которая днём держится, а вечером заедает усталость. Затем провела три интервью с женщинами, которые вели дневник в FatSecret и Foodvisor или бросили его. После интервью обновила персоны: какие черты подтвердились, а какие пришлось поправить. Параллельно разобрала конкурентов, чтобы понять, что для пользователей уже норма рынка, а что раздражает.

CJM

Самая глубокая яма — эмоции, а не интерфейс

Путь пользователя я разложила на девять этапов: от решения начать следить до попытки вернуться после отказа. Кривая эмоций проваливается не на сложном интерфейсе, а на пропуске записи и срыве: там появляются стыд, самообман и желание «отработать».

CJM дневника питания: девять этапов, цели, действия, цитаты, кривая эмоций, боли, возможности и связь с гипотезами
CJM: для каждого этапа цели, действия, точки контакта, цитаты, эмоции, боли, возможности и связь с гипотезами.
Момент истины — время записи

Секунды на фото против 5 минут ручного ввода решают, останется ли человек в продукте.

Невидимые приёмы пищи

Перекусы на бегу и доедание за ребёнком не попадают в дневник. Нужен ввод в один тап.

Мягкий рестарт

С нутрициологом дисциплины хватало на 2 месяца, самостоятельный рестарт — меньше чем на 3 дня.

Гипотезы

Что проверяем

ГипотезаМетрикаЧто показали интервью
Г1. Фото вместо граммов и калорий удержит дольше, чем классический счётчикRetention D30 +15% к счётчикам калорийПодтверждено: все три респондентки называют ручной ввод главной усталостью
Г2. Оценка AI как предложение, которое можно поправить, сохранит доверие к фото+20% пользуются фото-записью через 14 днейР1 прощает ошибки AI, потому что правка быстрее поиска
Г3. Сложные блюда вроде борща и плова требуют отдельного сценарияПроверяется вместе с Г2На сложных блюдах исправлять нечего: AI не даёт результата
Новые из CJM: экстренный режим, безоценочная запись срыва, мягкий совет вместо компенсацииДоля дней с записьюВыросли из этапов «Пропуск» и «Стыд и компенсация»
MVP

17 функций, четыре способа отбора

Из CJM я собрала Job Stories и User Stories и разложила их по Story Map вдоль этапов пути. Чтобы провести линию MVP, прогнала функции через Impact / Effort, RICE, Kano и MoSCoW. Быстрые победы — фото с текстом или голосом, экстренный режим, тег эмоции, запись без регистрации — идут первыми. Ядро продукта и главный риск — AI-распознавание, точечная правка и итог дня.

В MVP сознательно не вошли калории, граммы и КБЖУ на экранах, стрики и экраны «вы пропустили 14 дней», поиск по базе продуктов и пейволл.

Story Map дневника питания: этапы CJM, истории Must, Should и Could, линия MVP
Story Map: над красной линией то, без чего продукт не живёт.
Матрица Impact / Effort: 17 функций в четырёх квадрантах и выводы
Impact / Effort: быстрые победы, большие ставки, пожиратели времени и «добить позже».
Архитектура

Слова респонденток вместо терминов

Информационную архитектуру я собрала из объектов (OOUX): запись, ингредиент, эмоция, итог дня и моё блюдо. В таб-баре четыре пункта: «Сегодня», «Записать» центральной кнопкой, «Дневник» и «Профиль». Названия я брала из интервью: «Записать», а не «Зарегистрировать еду»; «Итог дня», а не «Анализ», который звучит как экзамен; «Овощи · Белок · Гарнир», а не «клетчатка и углеводы», потому что люди думают тарелкой, а не нутриентами.

Карта приложения: первый запуск, Сегодня, Записать, Дневник, Профиль; функции MVP, релиза 1.1 и после MVP

Карта приложения. Пунктиром отмечено то, что выйдет в релизе 1.1 и после MVP. Прокрутите вбок.

Что дальше

Интерфейс и проверка

Интерфейс

Проектирую экраны MVP по Story Map, начиная с записи по фото и правки распознавания.

Проверка нейминга

Закрытая карточная сортировка или тест первого клика на 5–7 людях до финального дизайна.

Метрики гипотез

Доля дней с записью и доля принятых или исправленных распознаваний.

Следующий кейс

Бронирование корта за один проход

Редизайн приложения клуба падел-тенниса.

← Все кейсы
Бронирование кортаСмотреть кейс →