Проектирование интерфейсов
Серия 01. Определяем сценарии.

Способов, методов и прочих подходов к созданию use cases на самом деле хватает, я не буду грузить пересказами условного JTBD или CustDev один-в-один — тем более, что Вы можете это прочитать сами. В гораздо более авторитетных источниках. Тем более, что я-то и не очень хорошо их помню.

Я расскажу, как я сам это понимаю и делаю. Не претендуя на уникальность и новаторство. Всего лишь частное мнение.

Каждый сценарий должен плюс-минус укладываться в одно из утверждений
➡️Мне нужен доступ к информации, чтобы быть в курсе
➡️Мне нужен доступ к информации, чтобы принять решение о выполнении действия
➡️Я должен выполнить действие, чтобы достичь ожидаемого результата

Главное — соблюдать атомарность: не пробрасывать утверждение от точки входа в один сценарий к точке выхода из другого

Определение подходящего утверждения даёт понимание сразу двух свойств

▪️Назначение. Информация или функция. Характеристика точки входа в сценарий
▪️Залог. Почему залог? Потому что активный или пассивный. Это не совсем идентично грамматике, но я уже как-то писал: мы, разработчики, обожаем пиздить чужие слова, чтобы понемногу менять их смысл в своих целях. Активный подразумевает активацию функциональности внутри используемой системы, пассивный — пользователь просто оценивает или переиспользует вне системы некую информацию

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

Почему рейс? Ну потому что очень много слов, связанных с периодичностью чего-либо в моей работе уже задействовано (собственно, период, расписание), а нужно было слово, чтобы не путаться в собственных мыслях и записях. Как хочу, так и называю

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

Таким образом, каждый пользовательский сценарий можно вполне достаточно охарактеризовать исходя из этого набора свойств. К примеру, Важный Обязательный Информационный Сценарий или Функциональный Сценарий-Исключение

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

Еще очень важная характеристика сценариев — связность. Это когда точка выхода из одного сценария означает точку входа в другой. Я выделяю два вида

▪️Туннель — когда действия пользователя удобнее и возможно выстроить таким образом, чтобы он не покидал одного слоя доступности. Как правило связаны с многоступенчатым получением разнородной информации (поиск контрагента, его данные, открытые сделки, приоритетные товары/услуги, доступность товаров, информация по аналогам) и последующим выполнением небольшого количества тесно связанных по смыслу, но архитектурно с точки зрения системы обособленных действий (выставление счёта, заказ недостающего объёма товаров, бронирование товаров в наличии)

▪️Цепочка — действия по смыслу и архитектуре системы выполняются одно за другим и могут быть разнесены по слоям или местам в этих слоях. Цепочка документов закупки: потребность, заказ, приобретение, заявка на оплату, списание денежных средств

#медведьразмышляет #проектированиеинтерфейсов