Я бы хотел рассказать о решении одной важной проблемы в продуктовой команде. Проблема — мы делаем задачи слишком долго. Одна из причин — слишком глубокий уровень проработки каждой. Причем это касается не только проектирования, но технической команды.
Как бы времени у нас совсем нет, а функциональность урезать нельзя. Остается только снизить уровень проработки. Мы решили понижать его не для всех задач, а только для некоторых. Тут на помощь пришёл Купер, а с ним и три уровня проработки.
Пользовательские сценарии в любом продукте можно разделить на три уровня. Уровень первый — сценарии, которыми люди пользуются чуть ли не каждый день. Мы такие сценарии назвали магистральными. Второй — важные, но нужные не часто. Эти сценарии назвали промежуточными. Третий — скорее исключения, это как раз те сценарии про которые обычно совсем забывают.
Магистральные сценарии
Это самые важные сценарии, которые пользователь использует каждый день. Например, поиск товаров в магазине или чтение новостей в журнале. Проработка таких сценариев должна быть на высочайшем уровне. Тут необходимо потратить время на проверки и тестирование. Продумать все исключения, сделать анбординг для новых пользователей. Сделать анимации и хоткеи. Таких сценариев обычно не много, от одного до десяти.
Промежуточные сценарии
Это сценарии важные, но при этом ими пользуются не так часто. Например, настройки профиля. В таких сценариях нужно не меньше времени уделить проектированию и проверкам, но можно более хладнокровно относиться к ошибкам. Тут учитывать хоткеи уже нет смысла и если какой-то сценарий приведет к ошибке — это не так страшно, как в первом случае. Говорят, что именно поэтому в автомобиле салон сделан максимально комфортным, по сравнению с моторным отсеком. Таких сценариев обычно намного больше, чем первых.
Сценарии исключения
А вот эти сценарии самые популярные обычно у программистов. Есть четкое ощущение, что ими можно пренебречь в проектировании. Это не значит, что про них можно просто забыть и все. Их нужно обрабатывать, но делать это — максимально грубо. Например, представьте, вы открываете одну страницу в двух вкладках браузера и в одной из них делаете какое-то действие, которое меняет статус чего-то. А потом идёте в другую и делаете это же действие, как должна повести себя система? От способности обрабатывать исключения зависит лишь качество кода, а вот успех продукта обусловливается способностью справиться с ситуациями, описанными в магистральных и промежуточных сценариях.
Как определить сценарии, если это неочевидно
Тут мы придумали простую систему. Берем три метрики: количество пользователей, частота встречи сценария, серьезность. И оцениваем каждую либо 0, либо 1. Как правило, магистральные сценарии получают оценку 3, промежуточные 2, а исключения 1 или 0.
Что делать, если и на первые два уровня уже нет ресурсов
Первое о чем стоит подумать — это делать ли эти сценарии вообще. Ну а если уже решили всё же делать, то делайте низкую проработку модульно. Определите часть системы, которую позже комплексно можно будет переделать.
Вывод
Никому не нужен магазин с идеально продуманным сценарием добавления товара в «Избранное» в двух вкладках браузера, когда поиск товаров работает плохо и непонятно.