Фреймворк STAR (Situation, Task, Action, Result) лет 20 применяют в найме: кандидаты с его помощью структурируют кейсы, чтобы наглядно показать свой опыт. Мы в Mindbox применили его в дизайне: научились анализировать пользовательские сценарии и проектировать интерфейсы.

Меня зовут Антон Черный, я лид продуктовой дизайн-драйвер команды. В этой статье я расскажу, как и для чего применять STAR в дизайне интерфейсов. А еще на реальных фейлах Mindbox покажу, что бывает, если игнорировать части этого подхода.

Что для нас «удобный интерфейс»

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

Чтобы исправлять ситуацию, мы сформулировали три принципа:

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

Беречь время. Иногда компании специально удерживают пользователя: например, засыпают уведомлениями или вовлекают в игры. Это не наш путь: Mindbox — сервисный продукт, поэтому нам нужно максимально быстро привести пользователя к результату. Для этого дизайн должен быть простым, лаконичным, минималистичным.

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

Теперь мы стараемся смотреть на интерфейс глазами человека, который устал к концу дня и хочет одного — завершить уже задачу и пойти домой. В такой парадигме одна кнопка, расположенная на видном месте, ценнее целого набора «крутых» фич и мудреного дизайна.

Как STAR помогает посмотреть на задачу глазами пользователя

STAR — это акроним, который включает основные части фреймворка: situation, task, action, result. Обычно соискатели описывают по этому плану кейсы в портфолио. Мы переняли этот опыт и стали описывать задачи дизайна с точки зрения пользователя. Только начинаем мы это делать еще до того, как будет нарисовано хоть что-то — сразу, как получаем задачу в работу. 

Прежде всего проходимся по первым трем «буквам» и отвечаем на вопросы. Попробуем пройти по этому процессу вместе. 

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

Situation (ситуация) — это описание контекста, в котором находится пользователь. Чтобы сформулировать ситуацию, отвечаем на вопросы:

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

• Какие есть ограничения? В нашем случае маркетолог работает с десятками рассылок, у него нет доступа к SQL или BI, и у него мало времени на глубокую аналитику — нужна простая, визуальная и быстрая система сравнения.

• Из какого источника мы знаем о существовании этой проблемы? Мы в Mindbox провели 4 интервью с маркетологами. Они жаловались, что не могут быстро понять, какие рассылки работают лучше остальных, не могут найти точки роста.

Ответив на вопросы, мы получаем следующую формулировку:

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

Task (задача) — идеальный результат, которого пользователь стремится достичь. Чтобы сформулировать, отвечаем на вопросы:

• Какую именно цель ставит пользователь в этой ситуации? Например, в нашем случае маркетолог хочет сравнить результаты разных рассылок и понять, какие механики стоит усиливать, а какие выключать.

• Что должно измениться для пользователя, чтобы он сказал: «Я достиг результата»? Например, пользователь должен увидеть, как для определенного сегмента лучше работают email-рассылки, а не SMS.

• Как можно измерить успех этого сценария? В нашем случае можно оценивать:

  – время на анализ (раньше тратил час, теперь 5 минут);

  – количество обращений к BI-аналитику или продакту за объяснением;

  – количество решений, которые пользователь принял, исходя из дашборда.

• Что может помешать пользователю достичь результата? Слишком сложные фильтры, отсутствие подсказок о том, как интерпретировать метрики, перегруженный интерфейс с десятками графиков.

Из этого мы получаем формулировку T:

Маркетологу нужно быстро и понятно сравнить эффективность разных рассылок, чтобы принять решение, куда вкладывать усилия. Успех — это когда он уверен в выводе и может объяснить его команде без BI или поддержки.

Action (действие) — какие действия мы можем предпринять, чтобы реально закрыть task пользователя:

• Какие шаги мы предпринимаем, чтобы задача пользователя решалась проще и быстрее? Мы сделали так, чтобы маркетолог мог сравнить любую рассылку и любую метрику. Для этого достаточно выбрать первую и вторую метрику, и система автоматически отрисует их на графике. Такой подход позволяет искать зависимости, видеть причинно-следственные связи и находить точки роста.

• Как мы проверяем, что эти шаги действительно помогают пользователю? Сначала мы прописали текстовый user flow от первого клика до финального ответа на вопрос: «Что я могу улучшить в маретинговых механиках?». Это позволило убедиться, что шаги следуют в логичном порядке, и нигде не приходится догадываться, искать действия под иконкой или возвращаться назад.
  Затем мы провели UX-тесты: маркетологам дали задачу сравнить эффективность email и SMS-рассылок, замеряли время, количество ошибок и наблюдали, где люди останавливались или сомневались. На основе этих наблюдений мы упростили интерфейс и сделали его прозрачнее.

• Какие альтернативы или ошибки мы исключаем, чтобы не построить «космолёт»? Мы сознательно отказались от перегрузки дашборда множеством графиков и лишних опций, оставив только возможность сравнивать интересующие маркетолога метрики и сегменты.

Формулировка A: 

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

Дальше по намеченному плану проектируем интерфейс, внедряем и проводим тесты. Вот на этом этапе возвращаемся к STAR и формулируем последнюю «букву».

Result (результат) — это не факт релиза, а цикл проверки и доработок. Проверка метрик и сборо обратной связи от клиента должны стать обязательной и постоянной частью процесса обновления. Чтобы понять, достигли ли мы результата, отвечаем на вопросы:

• Как мы понимаем, что достигли результата? Факт релиза дашборда не означает, что задача закрыта. Результатом становится ситуация, когда маркетолог может сам, без BI и поддержки, быстро сравнить нужные рассылки и метрики, сделать вывод и принять решение. Успех — это когда он тратит на анализ минуты вместо часов и чувствует уверенность в выводах.

• Какие метрики и сигналы мы отслеживаем? Мы смотрим на поведение пользователей: сколько времени уходит на построение отчета, как часто используются фильтры, снижается ли количество обращений в поддержку. Смотрим и на субъективные сигналы: перестали ли маркетологи жаловаться, стали ли чаще принимать решения на основе данных, а не «на глазок». Если цифры говорят, что люди всё еще тратят много времени или избегают инструмента, значит, мы не достигли результата.

• Как выстроить правильный цикл? Мы настраиваем быстрый цикл обратной связи: собираем метрики, проводим короткие UX-тесты уже на продакшне, регулярно общаемся с клиентами. Любое наблюдение становится поводом для итерации. Мы понимаем, что «идеального» дашборда не существует — всегда есть куда улучшать. Поэтому результат — это не статичное состояние «готово», а постоянный процесс: проверил → узнал → доработал.

Что будет, если «пропустить букву» в STAR

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

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

Если же пропустить одну из «букв», полнота обзора теряется. Появляется больше рисков допустить ошибку: сделать то, что не нужно клиенту или сделать неудобно. Дальше покажу на реальных примерах из опыта Mindbox. 

Одна из задач, которые решают маркетологи с помощью Mindbox, — запускать рассылки. Для этого они верстают письмо, выбирают получателей, настраивают отправку: выбирают время, тему, тип рассылки. Когда Mindbox только развивался, у нас было не так много клиентов, за каждым был закреплен персональный менеджер, который всем этим занимался. Поэтому интерфейс был неважен. Но с ростом компании ресурса менеджеров стало не хватать, клиенты начали работать сами и жаловаться, что платформа неудобная. Продавать такой продукт было стыдно, поэтому мы взялись за обновление. Но по пути допустили несколько ошибок. 

Situation (Ситуация)

На первый взгляд, редизайн старого — дело очевидное. Интерфейс устарел, неудобный, с виду страшный. Кажется, достаточно «осовременить» его, навести визуальный порядок — и всё станет лучше. Но если не разобраться в том, почему и как пользователи им пользуются, можно сделать только хуже.

Мы в своем кейсе решили «все сломать и построить заново». Сделали карточки, структурировали блоки, добавили иконки и современные компоненты. Стало красиво и удобно. Но как оказалось, лишь на первый взгляд. 

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

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

Что дало понимание S. Когда мы провели исследование ситуации, оказалось, что существуют разные паттерны: кто-то делает рассылку с нуля, кто-то — из шаблона, а кто-то — копирует прошлую.

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

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

Эта информация помогла сделать новое обновление, теперь более продуманное: 

• Вернули узнаваемые названия и последовательность шагов, чтобы не разрушать мышечную память.

• Добавили кнопку «Создать на основе прошлой рассылки».

• Оставили интерфейс компактным, без лишних шагов, но с явными точками контроля. На странице осталось только то, с чем маркетолог реально может взаимодействовать. Остальное спрятали под капот.

Task (Задача)

Когда мы работали над новым интерфейсом, предположили, что задача пользователя — просто «запустить рассылку». В итоге сделали первый редизайн: стало современнее и визуально чище, но… маркетологам стало только сложнее.

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

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

Что дало понимание T. Как только мы переосмыслили задачу, стало очевидно, что нужно не «рисовать заново», а сделать путь пользователя логичным и последовательным:

• сохранить последовательность действий сверху вниз;

• сгруппировать настройки по шагам, чтобы не прыгать по экрану;

• встроить интерфейс в привычные сценарии работы, а не изобретать новые.

Аction (Действия)

Даже если идеально понять ситуацию (S) и точно сформулировать задачу пользователя (T), это не гарантирует, что правильные действия будут верными (A). Потому что действия — это не идеи в голове, а конкретные продуктовые решения, которые попадают в руки пользователей. Если действовать вслепую — легко испортить даже хорошую задумку.

Чтобы правильно спланировать действия, нужно проделать две операции. 

1. Прописать user flow — от первого клика до последнего. Прямо в текстовом виде, без UI. И проверить, понятно ли, что, когда и зачем происходит? Нет ли шагов, где пользователь должен «догадаться», искать нужное под иконкой, возвращаться назад из-за плохой последовательности?

Например, мы спрятали кнопку «Протестировать рассылку» в бургер-меню в правом верхнем углу, потому что визуально так было чище. 

Но пользователи не находили функцию, отправляли рассылку без теста и получали ошибки. В итоге из-за красоты страдал пользовательский опыт. Если бы мы проследили путь пользователя, мы бы заметили, что запуск теста — финальный и очень важный шаг настройки рассылки. 

2. Провести UX-тесты — пусть люди попробуют решить задачу. Нужно не просто просить посмотреть макет, важно попросить сесть и проделать задачу, пусть и самую простую. А после — спросить:

• Какой шаг вызывал сомнения?

• Что вызвало тревогу?

• Был ли момент, когда хотелось вернуться назад или спросить, уточнить?

Снова пример из нашего опыта. Мы сделали так, что настройка рассылки завершалась финальным экраном «Запланировать время отправки». Здесь пользователь мог отправить рассылку сразу или запланировать ее — для нас всё было вполне логично. 

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

Result (Результат)

Когда задача выполнена, легко расслабиться и пропустить последний шаг. Но если не задать себе вопрос «А стало ли лучше для пользователя?», можно остановиться слишком рано. Тогда возможен один (или сразу все) из следующих сценариев: 

• Пользователи продолжат путаться, просто перестанут жаловаться.

• Новички будут тихо ненавидеть продукт.

• Поддержка будет разгребать участившиеся обращения.

Решение задачи не завершается с релизом. Оно заканчивается только, когда:

• Замерили эффект (поведение, ошибки, время, обращения).

• Получили обратную связь от клиентов (интервью, юзабилити-сессии, кастдевы).

• Сформулировали, что нужно улучшить и запланировали это улучшение.

Если в вашем продукте тоже случаются решения, оторванные от ситуации или задачи пользователя, попробуйте разобрать ближайшую задачу по STAR. Возможно, вы найдёте неочевидные ошибки — как было в нашем случае. И делитесь своими результатами, порадуемся вместе :-)