Что такое пользовательский сценарий
Пользовательские сценарии + объекты взаимодействия: создаем единый источник информации для команды проекта
Как юзабилити-специалистам, дизайнерам и разработчикам получить быстрый доступ к нужным данным
В этой статье мы описываем способ систематизации информации о пользовательских сценариях и объектах взаимодействия в программном продукте или на сайте. Используя такой подход, мы решаем сразу две задачи: юзабилити-специалисты получают информацию о действиях пользователей в продукте, а дизайнеры и разработчики — срез по объектам, с которыми взаимодействуют пользователи.
Мы в юзабилити-агентстве Юзетикс спроектировали и протестировали интерфейсы сотен цифровых продуктов. Каждый продукт создается для решения определенных задач, в том числе чтобы помочь пользователям достичь целей, например: купить подарок, купить продукты, оплатить услуги ЖКХ, проверить баланс, пополнить счет и т. д. В рамках одного продукта реализуются несколько пользовательских сценариев, выполнение которых приведет пользователя к цели. Например, для достижения цели «приготовить ужин» пользователь интернет-магазина может пройти следующие сценарии: найти подходящие продукты, оформить заказ, отследить заказ, оставить отзыв и т. д.
Над продуктом обычно работают юзабилити-специалисты, дизайнеры и разработчики. У них есть общая задача — сделать так, чтобы продукт помогал пользователям достичь целей. Но для решения этой задачи им нужна разная информация:
В этой статье мы расскажем, как систематизировать полученные в ходе юзабилити-тестирования данные и создать единый источник информации о пользовательских сценариях и объектах взаимодействия. Благодаря быстрому доступу к такой информации юзабилити-специалисты, дизайнеры и разработчики смогут сосредоточиться на том, что важно для выполнения их задач при создании продукта.
Шаг 1. Фиксируем цели и пользовательские сценарии, выполнение которых должно привести пользователя к достижению целей
Зачем: не упустить из виду основное предназначение продукта с точки зрения пользователя.
Попросите 10 человек купить что-нибудь в одном интернет-магазине. Каждый из 10 пользователей будет делать покупку по-своему. Вы получите 10 способов прохождения процесса выбора товара и оформления заказа в интернет-магазине от разных пользователей, даже если все они будут выполнять одну задачу — купить товар. Более того, один пользователь интернет-магазина в разное время будет использовать разные сценарии.
Купить товар — основная цель пользователя интернет-магазина, но не единственная.
Шаг 2. Для каждого сценария фиксируем объекты взаимодействия
Зачем: составить список объектов проектирования для дизайнеров и разработчиков.
При прохождении одного сценария пользователь обращается к разным объектам.
Объекты, с которыми взаимодействует пользователь при прохождении сценария, могут быть функциональными блоками или интерфейсными формами разного масштаба — от несложного рекламного баннера до поисковой системы на сайте.
Шаг 3. Собираем информацию о пользовательских сценариях и объектах взаимодействия
Зачем: создать единый источник информации о целях пользователей, пользовательских сценариях и объектах взаимодействия.
Итак, мы зафиксировали:
Теперь мы можем рассмотреть ситуацию взаимодействия пользователя с продуктом в двух плоскостях: с одной стороны, мы увидим все сценарии использования продукта, а с другой — объекты, с которыми взаимодействует пользователь, проходя по каждому сценарию.
Шаг 4. Для каждого объекта рассматриваем 5 стадий взаимодействия пользователя с ним
Зачем: сфокусироваться на главных действиях, применимых к объектам, которые нельзя пропустить при проектировании продукта и UX-тестировании.
Каждый раз, когда пользователь встречает очередной объект, взаимодействие с ним складывается по принципу, который сформулировал П. Я. Гальперин на основе теории концепции поэтапного формирования умственных действий.
Каждое взаимодействие пользователя с объектом проходит через 5 стадий действия по Гальперину:
5 стадий действия по Гальперину в случае с Винни-Пухом:
1) воспринимает информацию о том, где находится мед, и осознает ситуацию;
2) принимает решение забраться в гнездо к диким пчелам;
3) забирается на пчелиное дерево;
4) получает и воспринимает «обратную связь»;
5) корректирует свои действия: снова поднимается к гнезду пчел, но уже на воздушном шарике
В зависимости от сложности объекта применение такой схемы может происходить несколько раз — по мере детализации объекта. Пример для интернет-магазина: мы можем сказать, что все 5 стадий действия применимы и для объекта Фильтры в целом, и для каждого отдельного фильтра внутри объекта Фильтры: для фильтров по цвету, форме, цене, материалу и т. д.
Шаг 5. Для каждого объекта фиксируем контекст взаимодействия
Зачем: составить список требований к свойствам и состояниям объектов взаимодействия, которые необходимы, чтобы продукт помогал пользователям достичь цели.
Существует также контекст взаимодействия — ряд факторов, которые могут повлиять на то, какой реализованный в продукте сценарий пользователь выберет для достижения своей цели, а также на то, какие свойства объектов взаимодействия будут востребованы у него при выполнении сценария.
Для интернет-магазина есть множество факторов, которые влияют на то, какой сценарий выберет пользователь для взаимодействия с продуктом по пути к цели и какие свойства объектов взаимодействия будут важны для пользователя при выполнении сценария. Примеры таких факторов:
О том, как учитывать контекст взаимодействия при разработке продукта, мы рассказали в нашей статье «Персонажи + Jobs-to-Be-Done: опыт применения объединенного подхода».
Что в результате
В результате юзабилити-специалисты, дизайнеры и разработчики получают быстрый доступ к единому источнику важной для выполнения своих задач информации, включая:
Этот подход удобен и для анализа разных цифровых продуктов. Например, можно:
Анализ полученной информации позволяет:
Иллюстрации к статье созданы Анной Крюковой на основе иллюстраций Эрнеста Шепарда к первому изданию книги А. Милна Winnie-the-Pooh (1926).
Пользовательские сценарии в SEO
Комплексный подход к наполнению сайта контентом подразумевает проработку так называемых пользовательских сценариев. Это понятие является ключевым не только для создания интерфейсов программ или сайтов, но и для подготовки текстов.
Создание пользовательских сценариев в классической методологии начинается с анализа задач. Здесь необходимо понять, какие задачи пытается решить посетитель сайта, а затем — как именно он это делает, в порядке очерёдности. Фактически на этом этапе необходимо выявить и описать ментальную модель пользователя, т.е. есть как в его представлении должен работать сайт, что необходимо для сопоставления желаемого с действительным.
Эту часть работы крайне желательно выполнять, опираясь на работу непосредственно с пользователями. Во-первых, это позволит создать на следующем этапе более правдоподобные персоны. Во-вторых, интервью важны для понимания реалий, поскольку зачастую пользователи ищут информацию совсем не так, как вы ожидаете.
К примеру, существует расхожее представление, что пользователи преимущественно отсеивают нерелевантные страницы посредством инкрементального уточнения запросов. Однако на практике вы можете не раз столкнуться с тем, что пользователи сначала пытаются вспомнить сайт, который ссылался на нужную им информацию, затем ищут этот сайт в поисковике, после чего пользуются внутренним поиском сайта для нахождения нужной страницы и уже с этой страницы переходят на целевой сайт.
Поисковые запросы часто делят на информационные, навигационные и транзакционные. Но их также можно рассматривать с ракурса детализации искомой информации, как это предлагает делать Стоуни Дегейтер, который выделяет три группы пользователей поисковиков, условно описывая их в контексте онлайнового магазина:
1. Исследователи. Эти пользователи ещё не вполне уверены, что именно им надо. При поиске в этом случае используются широкие понятия с не более чем двумя-тремя ключевыми словами, по причине чего в выдаче оказываются самые разные, зачастую далеко не всегда связанные друг с другом страницы. Многие пользователи на стадии исследования используют эту первую выдачу как основу для дальнейшего уточнения критериев поиска. Просмотрев её, они получают представление о том, какую информацию ищут.
2. Потенциальные покупатели. У этой группы пользователей уже есть достаточно чёткое представление о том, что они ищут. Например, если им нужен телевизор, они скорее всего знают производителя, поэтому ключевых слов здесь в среднем немного больше, и они точнее описывают цель поиска.
3. Заинтересованные покупатели. Представители этой последней группы ищут совершенно определённую информацию. Если мы говорим о покупателях, то они уже знают не только производителя, но и основные характеристики товара, которые тоже попадают в поисковой запрос. Эта группа использует поисковые фразы длиной от 4 до 6 слов, которые максимально точно описывают искомое, чтобы заведомо отсеять нерелевантные страницы.
Понимание этого пригодится вам в дальнейшем при написании пользовательского сценария, поскольку каждая из придуманных персон может не просто оказаться в любой из этих трёх групп, но и последовательно пройти все стадии от начала до конца.
Чёткое понимание того, кто ваши посетители, обуславливает правильность составленных сценариев, которые, в свою очередь, помогают понять, как нужно писать тексты. Для этого необходимо создать несколько персон — собирательных образов разных групп внутри целевой аудитории. Двух-четырёх персон обычно достаточно для того, чтобы охватить максимальный процент ЦА.
При описании персоны необходимо учесть следующие характеристики:
И, конечно, не забудьте дать персоне имя. По возможности постарайтесь избежать анкетного стиля изложения.
Приведённые выше основные характеристики напрямую влияют на поисковое поведение пользователя и на поведение этого пользователя на сайте. Они влияют на то, какова тематика запроса, сколько слов в поисковой фразе, какие это слова, как много времени есть у пользователя на ознакомление со страницей из выдачи, на что в первую очередь падает внимание и т.д.
Иными словами, чем чётче портрет вымышленного посетителя сайта, тем лучше вы можете понять и предугадать действия настоящих посетителей. А уже это помогает удержать их на сайте и увеличить конверсию. Поэтому памятуя о вымышленности персоны, не стесняйтесь брать за основу реальных людей. Более того, персон часто рекомендуется придумывать по результатам работы с пользователями.
На основе всей полученной информации пишется сценарий: краткая история о том, как описанная ранее персона решает (условно) свойственную ей задачу. Вам необходимо провести пользователя от возникновения поискового мотива через работу с поисковиком до перехода на целевую страницу и далее.
В идеале сценарий пишется не только на основании анализа задачи и описания персон, но и на основании непосредственного наблюдения пользователей в естественной среде. В этом случае критически важно не вмешиваться в действия тестировщика. В противном случае вы рискуете внести в сценарий нехарактерные для пользователей действия и мотивы и принять неправильные решения.
Каждый сценарий должен описывать действия пользователя вплоть до точки конверсии. Ваша задача — на основе описания персоны и проработанного сценария построить модель идеального текста, которая будет учитывать специфическую для персоны лексику и востребованную детализацию изложения, а также содержать указания к построению макета страницы. Это позволит вам максимально точно подобрать ключевые слова для продвижения. В частности, из детализации станет ясно, как продвигать целевую страницу: по высокочастотным запросам или по «длинному хвосту».
Остаётся добавить, что пользовательские сценарии — не одноразовая работа. Их необходимо периодически обновлять и отшлифовывать. Самая очевидная тому причина — постоянные изменения в SERP популярных поисковиков, которые оказывают заметное влияние на поисковое поведение пользователей.
Что строить в первую очередь: User Journey Map или User Flow?
(Мы продолжаем переводить цикл статей по UX/UI. Полную подборку можно найти в коллекции « Инструменты проектировщика»)
UX дизайн — комплексный процесс. Чтобы создавать по-настоящему удобные и полезные продукты, проектировщики используют разные инструменты на разных этапах. В этой статье мы разберем два типа материалов, которые помогают визуализировать опыт пользователя в продукте: карта пути пользователя (user journey map) и пользовательские сценарии (user flows).
Попробуем ответить на такие вопросы:
Для начала я объясню некоторые базовые термины, которые встретятся нам в этой статье.
Интересуетесь свежими статьями по дизайну? Вступайте в группу на Facebook.
Ищите системное погружение в тему? Загляните в блог для дизайнеров.
Что такое карты пути пользователя (User Journey Map)?
User Journey Map помогает зафиксировать пользовательский опыт во время взаимодействия с продуктом. Это некое визуализированное путешествие пользователя по продукту. User Journey Map — как журнал, в котором пользователь записывает свои чувства, неудачи и успехи.
В User Journey Map может быть несколько слоев, она не привязана к конкретному элементу в продукте, который отвечает за то или иное действие. User Journey Map даже может описывать, что делает система “за кулисами”, чтобы предоставить пользователю необходимую информацию. С другой стороны, User Journey Map — это больше про пользователя: она описывает его чувства, мысли, действия при взаимодействии с продуктом.
User Journey Map обычно линейны, так как описывают различные аспекты достижения конкретных задач.
Что такое пользовательские сценарии (User Flows)?
User flows (также известные как пользовательские сценарии, UX-сценарии, Wire, UI или IX сценарии) — это наглядные материалы, которые иллюстрируют весь путь пользователя в продукте целиком.
Изначально это были блок-схемы, но со временем они обросли разными визуальными элементами — вайрфреймами, скетчами и визуализацией жестов.
Сейчас user flow — это гибрид классической блок-схемы и элементов визуального интерфейса. В основе user flow лежат задачи, которые выполняет пользователь, а также возможные альтернативные исходы.
Можете прочесть пару моих статей об UX-сценариях (user flow):
User Flows in Sketch — Step by Step Guide to Create Them Quickly
Sketch is a powerful tool to create digital products. You may be surprised but it is also ideal to prepare some other…
If one picture is worth thousand words, then UI flows are worth a thousand pictures. Even if you created outstanding…
Отличия
User flows (также известные как пользовательские сценарии, UX-сценарии, Wire, UI или IX сценарии) — это наглядные материалы, которые иллюстрируют весь путь пользователя в продукте целиком.
Изначально это были блок-схемы, но со временем они обросли разными визуальными элементами — вайрфреймами, скетчами и визуализацией жестов.
Сейчас user flow — это гибрид классической блок-схемы и элементов визуального интерфейса. В основе user flow лежат задачи, которые выполняет пользователь, а также возможные альтернативные исходы.
Можете прочесть пару моих статей об UX-сценариях (user flow):
Отличия
В основе сценария — User Flow — как правило, лежит порядок действий, которые должен выполнить пользователь. User Flow помогает понять, все ли процессы в продукте имеют логическое завершение. Глядя на user flow, команда может сразу понять, в чем суть решения, которое предлагает продукт.
User flow могут быть нелинейными — в них есть точки принятия решений, пути, режимы и петли, при помощи которых мы иллюстрируем все возможные взаимодействия с продуктом.
Обычно в User Flow мы не делаем акцент ни на ощущения пользователя, ни на множество возможных уровней решения. Основная задача сценариев — показать процесс работы с продуктом.
User Journey Map больше ориентированы на пользовательский опыт клиента. Они выявляют проблемные точки и моменты радости. User Journey Map может описывать разные аспекты решения: например, не только мобильное приложение, но и работу системы на сервере.
Есть определенные правила построения User Flow (наверное потому, что сценарии эволюционировали из блок-схем). А вот что касается User Journey Map, единого рецепта тут нет. Можно найти в интернете кучу примеров карт и все они будут очень разные.
Как использовать User Flow в процессе дизайна
Меня очень часто спрашивают: с чего начать? С User Journey Map или с User Flow? Не буду оригинальным: все зависит от ситуации 🙂
Если у вас уже есть готовое решение, тогда, мне кажется, сначала стоит создать User Flow. На основании этих сценариев вы сможете построить хорошую User Journey Map, которая в свою очередь поможет выявить проблемные места и устранить их. Не менее важно выявить приятные моменты на пути пользователя, чтобы сохранить их и при возможности усилить.
Когда вы создаете решение с нуля, собирайте требования, узнавайте потребности пользователей и пишите пользовательские истории. В первую очередь думайте о том, что должен сделать пользователь, чтобы выполнить стоящую перед ним задачу. На базе этой информации вы создадите карту User Journey Map. В эту версию карты не обязательно включать вайрфреймы: рассматривайте ее как начальный план, который вы детализируете на последующих этапах. Уже потом, когда вы создадите вайрфреймы и макеты, можно будет обратиться к UX Flows: они помогут понять, правильный ли путь вы предлагаете пользователям и как его можно улучшить.
Короче говоря:
Я рекомендую начинать с User Flow, если у вас на руках готовое решение. Если вы запускаете новый проект, начните с построения User Journey Map и уже потом усиливайте ее при помощи User Flow.
Еще я обнаружил, что User Flow очень эффективны, когда дело касается общения с клиентом. Людям, не связанным с дизайном, проще понять формат блок-схемы. А вот User Journey Map они читают с трудом — поэтому бывает рискованно показывать ее клиентам на ранних этапах и без объяснений.
Как создавать User Journey Map и User Flow
При создании этих материалов я люблю пользоваться разными полезными инструментами.
Когда нужно накидать User Journey Map прямо во время встречи или мозгового штурма, я предпочитаю стикеры. Их можно легко менять местами, выбрасывать ненужные и заменять новыми.
Цифровую карту User Journey Map проще всего создавать в электронной таблице.
Что касается User Flows, то в режиме реального времени их проще всего создавать на белой доске. Но после встречи/мозгового штурма определенно стоит красиво оформить наработки в каком-нибудь цифровом инструменте. Я использую для этого Sketch — он на удивление хорошо подходит для создания различных UX материалов. Чтобы сделать процесс еще эффективнее, я создал инструмент для создания UX-сценариев — SQUID. Благодаря библиотеке, я могу за считанные минуты создавать стилизованные пользовательские сценарии.
Сценарий использования
Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой. Методика сценариев использования применяется для выявления требований к поведению системы, известных также как функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне чем в при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.
Содержание
История
В 1986 году Ивар Якобсон, позже соавтор Унифицированного Языка Моделирования (UML) и Рационального Унифицированного Процесса (RUP), впервые сформулировал методику визуального моделирования для описания сценариев использования. Первоначально он использовал несколько иные термины — англ. usage scenarios и usage case, но ни один из них не был естественным для английского языка. И в конечном счете он остановился на термине use case — сценарий использования. После создания Якобсоном методики моделирования сценариев использования многие люди поспособствовали улучшению этой методики, включая Курта Биттнера, Алистера Кокберна, Ганнэра Овергарда, и Джери Шнайдера.
В течение 1990-ых сценарии использования стали одной из самых распространенных методик документирования функциональных требований, особенно в объектно-ориентированной среде, откуда они и произошли. Но их применение не ограничивается объектно-ориентированными системами, поскольку сценарии использования не объектно-ориентированы по природе.
Цели сценариев использования
«Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства программных проектов это означает, что потребуется множество сценариев использования чтобы определить необходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования.»
Сценарии использования не должны путаться с понятием свойств системы (англ. Feature ). Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования.
Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актер (англ. Actor ) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Тот же самый человек, использующий систему, может быть представлен как различные актеры, потому что они играют различные роли. Например, «Джек» может играть роль Клиента использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.
Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Это — преднамеренная политика, потому что это вынуждает автора сосредоточиться на том, что система должна сделать, а не, как это должно быть сделано, и позволяет избегать создания предположений о том, как функциональные возможности будут реализованы.
Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.
Сценарий использования должен:
Уровень детализации
Алистер Кокберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:
Подходящая детализация
Некоторым процессам разработки программного обеспечения достаточно простого сценария использования для определения требований системы. Другим необходимо много детализированных сценариев использования. В общем случае чем больше и сложнее проект, тем более вероятно, что будет необходимо использовать много детализированных сценариев.
Уровень деталей в сценарии использования часто зависит от стадии проекта. Начальные сценарии могут быть краткими, но в процессе развития проекта они становятся более детальными. Это отражает различные требования к сценариям использования. Первоначально они должны только быть краткими, так как они применяются для получения общих деловых требований с точки зрения пользователей. Однако, позже в процессе создания системы разработчики нуждаются в намного более определенном и детальном руководстве.
Рациональный Унифицированный Процесс (RUP) стимулирует разработчиков использовать краткое описание сценариев использования в диаграмме сценариев использования с обычным уровнем детализации в виде комментария и детальным описанием в текстовом анализе. Сценарии могут быть задокументированы с помощью специальных инструментов (например, UML Tool, SysML Tool), или написаны в обычном текстовом редакторе.
Нотация сценариев использования
В Унифицированном языке моделирования отношениях между всеми или частью сценариев использования и актерами представлены в виде диаграммы сценария использования или диаграммах, первоначально основанных на объектной записи Ивара Якобсона. SysML использует то же самое представление на системном уровне.
На диаграммах сценариев использования в UML сценариев отображается в виде эллипса. Внутри эллипса или под ним указывается имя элемента.
К сценариям использования в UML применимы следующие виды отношений:
В том числе между прецедентами:
Сценарии использования и процесс разработки
Варианты применения сценариев в процессе разработки зависят от используемой методологии разработки. В одних методологиях разработки все, что требуется это краткий обзор сценария. В других сценарии использования усложняются и изменяются в ходе разработки. В некоторых методологиях они могут начать как краткие деловые сценарии, развиться в детальные системные сценарии использования, и затем перерасти в чрезвычайно детальные и исчерпывающие тесты.
Шаблоны сценариев использования
Нет никакого стандартного шаблона для документации детальных сценариев использования. Существуют много конкурирующих схем, но лучше всего использовать те шаблоны, которые лучше подходят для проекта. Есть, однако смысл упомянуть об основных моментах на которые стоит обратить внимание.
Имя сценария Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше чем Регистрирующийся Пользователь), и должно объяснять о чем сценарий использования.
Неплохо использовать как имя сценария цель актера, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.
Цель Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком актере, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием. Актеры Актер это кто-то или что-то вне системы и влияющий на систему или находящийся под ее влиянием. Актер может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими актерами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия. Заинтересованные лица Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования. Предварительное условия Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте так же, что предварительные условия это не «активаторы» (см. ниже). Так как верные предварительные условия НЕ инициируют выполнение сценария. Активаторы Активатор это событие инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), но ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.
Есть несколько вариантов как описать ситуацию, когда активация происходит, но предварительные условия не удовлетворены.