Юзкейсы что это

Путь героя: почему юзкейсы отлично продают и как их правильно писать

Когда рекламные статьи в формате причин или мифов надоели, можно протестировать другой приём — юзкейс. Так называют истории, основанные на пользовательском опыте. Такие тексты дают отличные показатели по просмотрам и конверсии, но подходят не для всех продуктов и требуют от авторов учесть несколько тонких моментов. Как составить такой текст, в колонке для Sostav рассказали эксперты «ПромоСтраниц» Яндекс — Надя Дмитриева, Элина Крючкова и Олег Копылов.

Почему юзкейсы эффективны

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

Почему это работает

• Во-первых, в ленте соцсетей и блог-платформ эти тексты выглядят, как в естественной среде обитания. Пользователь даже может и не отличить заголовок и обложку рекламного юзкейса от превью поста блогера из своих подписок.
• Во-вторых, с помощью юзкейсов можно интересно рассказать даже про самый сложный продукт. Вы не излагаете сухую теорию, а сразу показываете его действие на практике. А это нагляднее и понятнее пользователям.
• В-третьих, такие тексты показывают не только сам продукт или услугу, а то, какую пользу получает читатель. Например, мама рассказывает про игрушку и как она увлекает ребёнка надолго, что позволяет взрослым в это время заняться своими делами. То есть в центре не товар и его характеристики, а история, в которой читатель узнаёт себя и свои проблемы.
• Наконец, юзкейсы предполагают эмоции. Это провоцирует людей кликнуть на заголовок и прочитать историю, которая обещает сильные чувства.

Где не нужен юзкейс

Однако есть ряд ситуаций, когда от юзкейса лучше отказаться. Например, когда:

• нет реального подходящего отзыва. В такой ситуации возникает соблазн выдумать историю, но не рекомендуем так делать: обман всегда виден. Выходом может стать комбинированная история (например, собрать в одну историю опыт разных людей);
• в отзыве нет интересной фактуры. Мало просто описать, как человек купил товар, попробовал его и получил какой-то результат. Чтобы текст получился интересным, в нём должна быть драматургия, в идеале — конфликт;
• выгода от продукта неочевидна или чтобы её получить, нужно совершить массу действий. Например, когда описывается сложная схема взаимодействия: пригласить друзей, чтобы они совершили какие-то действия — и только после этого и соблюдении массы нюансов можно получить условные 100 рублей;
• в основе лежит какой-то сценарий, который на самом деле сложно воспроизвести в реальной жизни. Например, у нас как-то была идея написать про эпиляторы от лица мужчины — как он воспользовался им и какие у него остались впечатления. Такой текст вызвал бы интерес у читателей. Но описанный в нём опыт едва ли кому-то пригодится.

Во всех этих случаях лучше поискать другие форматы.

Как написать классный юзкейс

1. Нужен сюжет. Исследователь Джозеф Кэмпбелл на основе анализа мифов Древней Греции, народных сказок, «Красной шапочки» Шарля Перро и других известных произведений выявил общие элементы, по которым движется повествование. Их он перечислил в книге «Путь героя».

Если адаптировать эту схему для юзкейсов, то она может выглядеть так:

Почему заходить стоит именно через героя? Читатель ассоциирует его с собой и примеряет происходящее с персонажем на себя, на свою жизнь. И тогда больше шансов, что он захочет узнать, чем закончится предложенный нами сюжет.

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

Есть простая и эффективная формула сценариста Аарона Соркина (известен по сериалу «Ньюсрум», фильму «Социальная сеть» и другим). Он говорил: хороший сценарий построен на трёх актах: сначала мы загоняем человека на дерево, потом поджигаем это дерево, а затем спасаем человека. Эта формула работает и для юзеркейсов.

Например, есть семья Ивановых с трехкомнатной квартирой в хорошем сталинском доме. Дети уже выросли, и Ивановым нужно поменять свою трёшку в центре на три однокомнатных квартиры. Задача нетривиальная, как вы понимаете. В том числе потому, что нужно всё подгадать так, чтобы всем переехать разом — ведь жить больше негде. Это проблема (или человек на дереве).

Семья уже год не может организовать эту сделку — рассказываем, почему (здесь дерево уже горит). Потом кто-то из родственников рассказывает, что есть девелопер, у которого есть услуга трейд-ин. Но Ивановы не уверены, что им это подходит. Например, стоимость услуги показалась высокой. Это этап сомнений. На выходе из него мы ещё и отрабатываем возражения: да, придётся потратиться, но зато Ивановы сэкономят на услугах риелтора, а размен пройдёт быстрее. Вот оно, решение и путь в новую жизнь.

2. Герой не должен быть схематичным. «Привет, я Игорь, мне 39 лет и я хочу купить квартиру в Москве» — визуализируется такой герой? Вряд ли. Другое дело, если наделить его эмоциями и подробностями жизни. «Привет, я Гарик. Два месяца назад я развёлся с женой, оставил жене и дочери квартиру в Дорогомилово. Сейчас ищу себе холостяцкие апартаменты на западе Москвы». Такие детали сразу делают героя объёмным и напоминающим кого-нибудь из знакомых.

3. Речь человека должна была живой. Даже если это не вписывается в tone of voice бренда. Бывает, что заказчик не готов нарушать свой стандарт. Тогда можно предложить ему сделать приписку типа: «Наш клиент поделился отзывом, публикуем его без купюр».

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

4. Детали тоже оживят историю. Допустим, человек рассказывает, что хорошо знает район, в котором расположен ЖК. Этим не стоит ограничиваться, лучше уточнить, что он имеет в виду. Например, здесь он занимался гандболом, а рядом до сих пор живёт его бабушка. Идеально, если он даже расскажет какую-то историю из детства. Это повышает доверие к герою и его словам.

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

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

Бывает, что такие тезисы сложно передать живой речью. В таком случае можно использовать вставки, которые разбивают рассказ и сообщают важные факты о продукте.

6. Важно смотреть на продукт глазами пользователя. Иногда бренду кажется, что важны одни характеристики продукта, а читателям могут оказаться полезнее другие. Представьте, о чём человек думает, когда заказывает продукт или услугу? В идеале стоит найти такого человека и попросить его рассказать свой пользовательский опыт, пройти этот путь вместе с ним.

7. Фото — только любительские. Даже если они не лучшего качества. Они покажут, что история не вымышленная, что герой действительно пользовался продуктом — и не где-то в студии, а в реальных условиях. Идеальными будут снимки, где человек или его родные показывают, как им помог товар или услуга. Это — ещё один кирпичик для выстраивания доверия читателя к нашей истории и продукту.

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

Героя для юзкейса нет, но написать статью в таком формате хочется. Что делать

На этот вопрос есть сразу несколько ответов. Вот они:

• присмотритесь к другим форматам. Юзкейс — это не универсальная таблетка и раскрыть преимущества вашего продукта можно не только через реальные истории людей. С высокой вероятностью статья в формате юзкейса от лица вымышленного героя сработает хуже, чем чек-лист с жизненными примерами и сценариями.
• сделайте собирательный образ героя. Это может сработать, если на продукт есть несколько отзывов от разных людей. На их основе можно написать хороший юзкейс, превратив опыт 3−4 пользователей в историю одного человека.
• написать юзкейс в формате «‎Как я выбирал…». В классическом юзкейсе герой делится своими эмоциями уже после того, как он попробовал продукт. Другой вариант предполагает рассказ о том, как человек столкнулся с проблемой, нашел для неё решение в виде вашего продукта и объясняет, почему выбрал именно его.

Как проверить, что ваш юзкейс убедителен. Чек-лист

По этим пунктам мы проверяем себя, чтобы убедиться, что история не выглядит надуманной.

• Избегайте круглых цифр. Например, в рассказе про кешбэк по банковской карте не стоит писать «я получил за месяц 3 000 рублей». Гораздо реальнее смотрится 2247 рублей.
• Убедитесь что выбрали хорошее имя. Может показаться, что если у нас в тексте будет Агриппина, то мы выделяемся и наш юзкейс запомнится. Но вряд ли читатель встречал людей с этим именем в жизни. Поэтому больше доверия вызовут «стандартные» Михаилы, Никиты, Маши и Юли.
• Убирайте рекламные фразы. Вряд ли доверие вызовет человек, который говорит столь неестественно.
• Проверяйте все расчёты. Герой или рекламодатель мог допустить ошибку. Если читатель заметит, что математика не сходится, он потеряет доверие к тексту.
• Это же касается и характеристик продукта. Если после прочитанной истории пользователь заинтересуется им, перейдёт на лендинг и увидит несоответствие, то останется с обманутыми ожиданиями. И тогда вместо готового тёпленького клиента бренд получит разочаровавшегося и уже остывшего.

Примеры классных юзкейсов, которыми можно вдохновиться

В этой статье есть все главные элементы хорошего юзкейса: история героя, живой язык повествования, любительские фотографии продукта. Читаешь и веришь Сергею, которому удалось найти вяленую воблу как из детства. Цифры у статьи тоже впечатляющие: прочитали ее 595 тысяч человек, среднее время чтения — 2 минуты.

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

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

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

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

Как и зачем писать Use Cases

Image via Shutterstock.

Создание эффективных Use Cases (далее используется термины «варианты использования», «сценарии», «юзкейсы») — must have навык любого аналитика. Ведь в некоторых случаях без описанных сценариев не обойтись намного сложнее, чем с ними.

Следующие заметки будут полезны начинающим бизнес аналитикам, системным аналитикам, а также студентам.

Что такое Use Case

На собеседовании порой можно услышать следующее определение «Это такая UML-диаграмма с человечками и овалами». Давайте разберемся, что это такое, и рассмотрим несколько простых примеров.

Use Case описывает сценарий взаимодействия участников (как правило — пользователя и системы). Участников может быть 2 и больше. Пользователем может выступать как человек, так и другая система.

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

В жизни встречала такие названия: варианты использования, юзкейс, сценарий, прецедент, сценарий использования.

Текст vs диаграмма/схема

Какое описание лучше: текстовое или диаграмма? Выбор за вами и вашей командой. В первые годы работы я использовала диаграммы либо диаграммы + текстовое описание к ним. Сейчас я предпочитаю текстовое описание сценариев, и объясню почему:

• Такой формат более понятен заказчикам (а они тоже предпочитают читать и согласовывать варианты использования).
• Текст проще и быстрее отредактировать, чем диаграммы и текст.

Конечно, если в вашем проекте очевидны дополнительные преимущества от использования диаграмм — надо их использовать.

Кому и в каких случаях нужны сценарии

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

— Заказчикам. Описано человеческим языком, заказчик своевременно может подтвердить, что это именно то, чего он ждет, или поправить.

— Тестировщику. Почти готовый тест-кейс 🙂

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

А также другим участникам процесса.

В каких случаях они нужны:

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

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

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

Как их описывать

Давайте рассмотрим пару примеров, они говорят сами за себя.

Пример 1. Разблокировать учетную запись пользователя (простой короткий пример, без альтернативного потока событий):

Успешный сценарий:

1. Администратор выбирает пользователя и активирует «Разблокировать».
2. Система переключает учетную запись пользователя в статус «активный», и посылает сообщение (тут можно сослаться на текст сообщения из списка сообщений, см. примечание ниже) пользователю на email (если «User Account → email» не пусто).

Пример 2. Авторизация пользователя:

Успешный сценарий:

1. Пользователь запускает систему. Система открывает сессию пользователя, предлагает ввести логин и пароль.
2. Пользователь вводит логин и пароль.
3. Система проверяет логин и пароль.
4. Система создает запись в истории авторизаций (IP адрес пользователя, логин, дата, рабочая станция).
5. Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).

Важные моменты

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

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

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

— Список сообщений, которые система выдает пользователю, стандартные тексты электронных писем и т.п. удобно расположить в едином месте в документе, и ссылаться на нужный пункт из разных юзкейсов, т.к. сообщения в сценариях часто дублируются.

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

— Кстати, про «копипасты». Незаполненную табличку для описания юзкейса есть смысл «копипастить».

— Как видно из примеров выше, расширение к шагу номер 1 указывается в разделе «Расширение» как 1а, 1б, и т.д. Расширение *а — это общее расширение к сценарию, не к конкретному.

Правильных и полезных вам сценариев! Вопросы, примеры, предложения, комментарии приветствуются. Спасибо за внимание.

При написании статьи я использовала материалы из книги Алистера Коберна «Современные методы описания функциональных требований к системам».

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

�� Подобається Сподобалось 10

До обраного В обраному 10

Что такое Юзкейс (Use Case) или «Сценарий Использования» в Тестировании ПО?

Юзкейс (Use Case) — это перечень действий, сценарий по которому пользователь взаимодействует с приложением, программой для выполнения какого-либо действия для достижения конкретной цели. Тестирование по юзкейсам проводится для того чтобы обнаружить дополнительные логические дыры и баги в приложении, которые сложно найти в тестировании индивидуальных модулей, частей приложения отдельно друг от друга. Юзкейс тестирование может проводится как часть Приемочного тестирования. Для удобства визуального восприятия Use Case часто рисуют в виде диаграмм с переходами.

Пример Юзкейсов (Use Cases)

для разных типов пользователей онлайновой системы:

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

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

• IevgeniiKucherenko
• 27 августа 2016, 23:39
• 0