админка
Конструктор статусной модели
JTBD, СJM, аналитика, проектирование бизнес-процессов
Постановка задачи
Есть API для изменения статусной модели заявления и для этого редактора нужен UI.
- Сбор требований, анализ кейсовСамостоятельный разбор API, выделение основных сущностей, выяснение заложенных возможностей. Сформировала логическое описание задачи, уточнила корректность собственного понимания у источника постановки. Внесла предложения по незатратному улучшению функциональности.01
- Сценарии, бумажные эскизы и low-level прототипыНа основе сценариев и бумажных зарисовок были проверены предложения по улучшению функциональности. На основе прототипов можно было обсуждать с потенциальными пользователями (коллегами-аналитиками) их понимание и ожидания от интерфейса для этой задачи. На этом этапе были поставлены задачи на улучшение API.02
- Первичные макеты и коридорное тестированиеОбсуждение главных экранов с коллегами по отдельности за чашкой кофе. Выявление общего понимания интерфейса потенциальными пользователями.03
- UI и документацияUI был реализован на существующей компонентной базе с небольшим количеством новых элементов. Поэтому шаг от прототипа к окончательному макету был самым малозатратным по времени. Документирование в Confluence.04
- Сопровождение реализации и тестирование usabilityАвторское ревью и фидбэк, фиксирование выявленных кейсов, пополнение документации. Наблюдение за аналитикам в процессе выполнения задач, анализ обратной связи, внесение улучшений во взаимодействие.05
Статусная модель
- это свойство сущности, отражающее ее состояние в каждой точке бизнес-процесса.
Например, вы заказали еду доставке. Приложение вам сообщает о каждом шаге: заказ создан, заказ оплачен, отдали готовить, выдали курьеру, доставлен.
Перечень этих состояний, возможность и условия переходов из состояния в состояние - и есть статусная модель заказа.
Например, вы заказали еду доставке. Приложение вам сообщает о каждом шаге: заказ создан, заказ оплачен, отдали готовить, выдали курьеру, доставлен.
Перечень этих состояний, возможность и условия переходов из состояния в состояние - и есть статусная модель заказа.
01
Сбор требований, анализ кейсов
Требования были обобщенными. Задача состояла из одного предложения: «спроектировать конструктор статусной модели». Логика на бэке и API для клиента уже были реализованы. Поэтому в первую очередь я проанализировала реализованный объем, что дало мне достаточное погружение для конкретных вопросов источнику задачи (руководитель отдела разработки). На этом проекте не было аналитиков, и эту роль мы делили вдвоем с backend-разработчиком.
- Мы продумали статусную модель до мелочей, и на ней базируется статическая часть портала. Если убрать важные статусы, UI посыпется. Кто и зачем будет вносить изменения?
- Кто: наши аналитики, которые будут сопровождать проекты в других регионах или продвинутые админы заказчика.
Зачем: у регионов могут незначительно отличаться регламенты по необходимым статусам. Будут добавляться промежуточные информативные статусы, типа «на рассмотрении оператора». - Как мы себя обезопасим от нежелательных изменений? Вижу, что можно создать коллизию, например если …
- Это зона ответственности разработчика, все решается условиями установки нередактируемых статусов. Это в том поле, где лежит json-фильтр условий.
- 1. Предлагаю добавить в API поле для словесного описания условия. Json-фильтр быстро не считаешь, и он не отражает дополнительных обстоятельств, которые знает только команда разработки.
2. Предлагаю добавить семантические теги к статусам, чтобы админ мог управлять смысловой составляющей статуса. По тегам фронт смог бы определять как визуализировать статус заявителю на портале. Например, оплата — синий рубль в статусах об оплате, ошибки — красные крестики, все хорошо — зеленая галочка. Это и так есть, но мы могли бы уйти от лишнего хардкода.
Итог первого этапа: сформировано логическое описание функциональности:
02
Сценарии, бумажные эскизы и low-level прототипы
Приоритизация задач и выявление основных сценариев для их решения
- основа для будущих эскизов и исследований.
- основа для будущих эскизов и исследований.
От владельца продукта поступило пожелание видеть статусную модель в виде графа.
Чтобы показать, как аналитики используют графы статусных моделей, какие задачи ими решают и почему используют привычные им инструменты, я проводила отдельные исследовательские интервью и делала зарисовки CJM.
С помощью них мы пришли к тому, что эта дополнительная функциональность обойдется дорого, но не улучшит продукт: граф в вакууме аналитикам не нужен. В итоге они продолжат пользоваться своими продвинутыми инструментами, позволяющими делать с графами дополнительные манипуляции, а в нашей системе эти графы останутся только дополнительной малоиспользуемой визуализацией.
Чтобы показать, как аналитики используют графы статусных моделей, какие задачи ими решают и почему используют привычные им инструменты, я проводила отдельные исследовательские интервью и делала зарисовки CJM.
С помощью них мы пришли к тому, что эта дополнительная функциональность обойдется дорого, но не улучшит продукт: граф в вакууме аналитикам не нужен. В итоге они продолжат пользоваться своими продвинутыми инструментами, позволяющими делать с графами дополнительные манипуляции, а в нашей системе эти графы останутся только дополнительной малоиспользуемой визуализацией.
Качественные исследования на коллегах-аналитиках
На первой фокус-группе я рассказывала коллегам-аналитикам о планируемой функциональности и ее задачах. Моя цель была выяснить, сложна ли задача в понимании для потенциального пользователя (админ, аналитик), если он не принимал участия в разработке.
Интервью с респондентами и дали следующие инсайты:
— редактируемых статусов и переходов будет немного, и хочется их видеть сразу, т. к основные задачи связаны с ними;
— предложенные мною поля словесного описания условий можно и нужно широко использовать: подсвечивать в тултипах при наведении на переходы и статусы, а так же в связанных частях проекта, вне разрабатываемого интерфейса;
— подготовленное описание функциональности нужно кратко изложить на стартовом экране, чтобы любой админ понимал свои возможности.
Интервью с респондентами и дали следующие инсайты:
— редактируемых статусов и переходов будет немного, и хочется их видеть сразу, т. к основные задачи связаны с ними;
— предложенные мною поля словесного описания условий можно и нужно широко использовать: подсвечивать в тултипах при наведении на переходы и статусы, а так же в связанных частях проекта, вне разрабатываемого интерфейса;
— подготовленное описание функциональности нужно кратко изложить на стартовом экране, чтобы любой админ понимал свои возможности.
Бумажные эскизы и прототипирование
Если есть возможность живых встреч с командой и пользователями, максимум мозговых штурмов я провожу на основе бумажных эскизов. Чем полнее корзина отброшенных вариантов, тем выше вероятность, что мы выбрали верный путь.
03
Первичные макеты и коридорное тестирование
Первичные макеты я показывала как пользователям, принимавшим участие в фокус-группах, так и не вовлеченным в процесс коллегам, которым тоже предстоит в будущем пользоваться этой функциональностью. Я специально оставила для себя «свежий взгляд» и не вовлекала в первичные обсуждения сразу всех.
- Привет! У нас новый конструктор планируется. Вот пара экранов.
1) Что здесь можно настраивать?
2) Что происходит на втором экране?
3) Как попасть с первого на второй экран? - Привет! Ого, статусные модели теперь настраиваем))) Так, что тут у нас…
На этом этапе были внесены небольшие правки в формулировки, подробнее продуманы необходимые фильтры и сортировки в списках. В целом, интерфейс и его функциональность были понятны для целевой аудитории.
04
UI и документация
Я оформляю макеты так, чтобы разработчику не нужно было держать документацию в Confluence постоянно открытой. Большое количество контролов в интерфейсе обязует использовать флоу поверх отрисованных экранов, чтобы разработчик не искал, какая кнопка вызывает следующий экран. Мой подход к оформлению макетов:
- Минимум экрановЧем меньше экранов, тем проще ориентироваться и поддерживать актуальное состояние макетов. Все локальное описывается отдельно.
- Флоу по экранам с комментариямиЭкономит время разработчику и тестировщику, практически заменяет кликабельный прототип.
- Все слои проименованы, библиотеки подключеныПозволяет говорить с разработчиком на одном языке и ускоряет процесс донесения фидбэка по авторскому ревью.
05
Сопровождение реализации и usability тестирование
В процессе реализации порой всплывают неудобные кейсы и мы с разработчиками вместе ищем оптимальный выход.
Я всегда самостоятельно пробегаюсь по свежим правкам и проверяю пограничные состояния:
— различные комбинации сортировок, фильтров и активных элементов,
— адаптив и переполнение компонентов,
— переключение в темный мод (выявляет, все ли цвета прописаны)
Если появились новые компоненты, проверяю наглядность состояний (hover, active), зоны наведения и клика. Глобально по новому флоу — наличие необходимых тултипов, расстояния между элементами соседних действий.
Сначала прохожу сценарии самостоятельно, а затем наблюдаю прохождение пользователем. В данном случае обращала внимание на моменты:
— не теряет ли пользователь элементы, которые в фокусе?
— какие поля меняются чаще других, и почему?
— какие ошибки совершаются пользователем, и может ли интерфейс их предупредить?
После тестирования дорабатывалась система валидации и немного корректировался порядок настроек в панели справа.
Я всегда самостоятельно пробегаюсь по свежим правкам и проверяю пограничные состояния:
— различные комбинации сортировок, фильтров и активных элементов,
— адаптив и переполнение компонентов,
— переключение в темный мод (выявляет, все ли цвета прописаны)
Если появились новые компоненты, проверяю наглядность состояний (hover, active), зоны наведения и клика. Глобально по новому флоу — наличие необходимых тултипов, расстояния между элементами соседних действий.
Сначала прохожу сценарии самостоятельно, а затем наблюдаю прохождение пользователем. В данном случае обращала внимание на моменты:
— не теряет ли пользователь элементы, которые в фокусе?
— какие поля меняются чаще других, и почему?
— какие ошибки совершаются пользователем, и может ли интерфейс их предупредить?
После тестирования дорабатывалась система валидации и немного корректировался порядок настроек в панели справа.