Как написать кейс, вызывающий доверие

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

 

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

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

Важно понимать, зачем вообще пишутся кейсы:

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

Помните об этом, и вам будет проще подобрать название, написать тезисы и создать структуру текста.

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

Как за 6 шагов написать убедительный кейс

Шаг №1: Выбираем показательный проект

Как понять, что у вас “созрела” тема для кейса? Задайте себе или коллегам несколько вопросов:

1. Есть ли у вас довольный клиент и высокие результаты сотрудничества с ним?
2. Не будет ли он против публикации кейса?
3. Насколько актуальна проблема, которую мы решили? Будет ли читателям интересно узнать о способах ее решения?
4. Возможно, в процессе работы вы нашли новое применение своему продукту?
5. Действительно ли результаты работы впечатляют? Покажут ли они ваш продукт с выгодной стороны?

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

Шаг №2: Собираем данные

Тут могут возникнуть некоторые трудности:

• заказчик может не идти на контакт;
• может не хотеть обнародовать цифры, отчеты и т. д.
• не знает, какие данные нужно предоставить.

Как мы обычно решаем эти проблемы:

1. Мы хорошо понимаем, что в 99% случаев кейс нужен не клиенту, а нам. Поэтому для начала налаживаем коммуникацию. Наш Customer Success менеджер или Support проводит регулярный аудит проекта, советует, как настроить сервис так, чтобы клиент получил максимум результата. Важно все время поддерживать коммуникацию, чтобы пользователь привык к общению. Только убедившись, что клиент всем доволен и легко идет на контакт, мы предлагаем написать кейс.
2. Главное, не поддаться искушению “нарисовать” все самому — так вы получите действительно “фантазийный” кейс. Большинство компаний соглашается на публикацию их отчетов, если вы в них скроете конфиденциальную информацию. Или замените абсолютные цифры на относительные, показав динамику роста показателей. Если клиент ни в какую не согласен обнародовать цифры, можно пойти на компромисс — не упоминать название компании в тексте.
3. По нашему опыту, иногда клиент просто не понимает что сказанные им слова можно проиллюстрировать цифрами или динамикой графика. В этом случае мы просим у него доступы, например, к Google Analytics или получаем разрешение на публикацию скриншотов из отчетов. И собираем эти данные самостоятельно.

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

Шаг №3: Пишем текст

Как говорится: “Глаза боятся, а руки делают”. Вы собрали информацию, и теперь ее надо упорядочить. Легче всего это делать, когда у вас уже есть структура будущего текста.

 

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

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

Кроме того, учитывайте, где будет опубликован текст, на вашем блоге или внешнем ресурсе. От этого будет отличаться подача. В первом случае пользователь уже знает о вашем продукте и заранее более лоялен. Во втором, вам нужно написать материал максимально беспристрастный, но “цепляющий” аудиторию, которая, возможно, никогда о вас не слышала или пользуется услугами ваших конкурентов. Вот пример подобного кейса на портале Vc.ru, который был написан совместно с партнерами.

Шаг №4: Проверяем и дополняем

Итак, ваш текст готов. Теперь нужно проверить:

1. Обоснованы ли основные тезисы фактами. Например, какая формулировка вызывает у вас больше доверия? “Клиент стал пропускать меньше звонков” или “Онлайн-магазин LETS снизил количество пропущенных звонков чуть больше чем в 3 раза с 24,6% до 6,9%”.
2. Правильно ли вы преподносите цифры. В примере, приведенном выше, мы могли бы их округлить, но не стали этого делать. Если вы пишете кейс, то лучше указывать четкие цифры. Проверено, что в качестве доказательства человек посчитает цифру 24,6% более убедительной, чем 30%. Но в то же время не переусердствуйте, цифры в формате 87,56% или 47 561 осложняют восприятие информации. Кроме того, если изменение какого-то показателя происходит больше, чем на 100%, вместо слова  «проценты» лучше использовать слово «разы». Например, увеличение не на 150%, а в 2,5 раза.
3. Хватает ли в кейсе скриншотов, графиков, инфографик для подтверждения ваших слов и цифр.
4. Разбит ли текст на подпункты и смысловые блоки — это облегчает восприятие информации.
5. Объективны ли вы при подаче информации или ваш кейс скорее похож на явный пиар. Описывайте не только успехи, но и сложности, которые возникали в процессе работы. Пишите не только о себе, но и об инструментах или партнерах, которые помогли вам добиться поставленных целей.
6. Есть ли в нем ссылки на авторитетные источники или хотя бы на сайт самого клиента. Так читатель сможет перейти по ссылке и увидеть своими глазами, над каким проектом вы работали.
7. Соответствуют ли результаты кейса поставленным задачам. Если во вступлении и среди целей указано “повышение продаж на 50%”, читателю захочется прочесть именно об этом.
8. Не похож ли ваш текст на сухой отчет, от которого хочется зевать. Помните, что сторителлинг, как известно, увеличивает лояльность. Ваша цель — рассказать потенциальному клиенту историю успеха, которая его захватит, а не усыпить с первых фраз потоком скучных фактов.
9. Есть ли в тексте цитаты или отзывы клиента. Их не всегда удается получить, но если есть такая возможность, лучше ее использовать. Мы всегда стараемся включать в кейсы “живую” речь наших клиентов. Она вызывает больше доверия и читается проще, чем обезличенная констатация фактов.

 

Не забывайте, что публикуя кейс, вы позиционируете себя как эксперта, и оценивать вас будут соответственно.

Шаг №5. Привлекаем коллективный разум

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

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

Шаг №6. Согласовываем с клиентом или агентством

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

Выводы

Давайте подытожим, что нужно, чтобы получился кейс, по-настоящему вызывающий доверие.

 

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

Источник

Зачем и как писать кейсы? Как кейсы могут повысить лояльность к вашей компании?

Здесь вы узнаете:

Что такое кейс?
Зачем нужны кейсы?
Где можно применить бизнес кейсы и их решения?
Какие бывают кейсы?
Как писать кейсы?
Структура и содержание кейса.
Что полезного можно сделать с написанным кейсом?
Кейсы по заработку в Интернете.
Вывод.

Маркетинговый кейс, а часто его называют просто «кейс» – это история успеха, которую используют для улучшения спроса на предлагаемые компанией товары и услуги. Название образовано от английского «case study» – изучение случая, а сам кейс позволяет увидеть продукты в действии и показать, какие проблемы он может решить.

Что такое кейс?

Основная цель кейсов – подтолкнуть потенциального покупателя к совершению аналогичного действия при имеющихся у него подобных проблемах.

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

Зачем нужны кейсы?

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

Создатель кейса для себя получает следующие плюсы:

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

Компания-клиент, в свою очередь, получает такие преимущества от использования кейсов:

• Создание имиджа фирмы, активно внедряющей новые разработки для решения бизнес-задач.
• Реклама бренда на сайте разработчиков кейса и в СМИ, которые освещают данную историю успеха.

Где можно применить бизнес кейсы и их решения?

• «Историю успеха» актуально использовать для создания пресс-релиза и последующего распространения через СМИ.
• Кейс можно разместить на своем сайте в разделе «Пресс-кит» или «Истории успеха».
• Кейс можно использовать в качестве иллюстрации для презентаций.

Какие бывают кейсы?

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

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

Примером кейса с решением может служить внедрение компанией Wargaming решения от Oracle Big Data Appliance. Wargaming создала популярную игру World of Tanks, в которую играют более 100 млн человек. При этом игроки оставляют множество данных, важных для бизнес-аналитики. Раньше эти данные хранились в таблицах Excel и не могли быть использованы для маркетинговых задач, а после внедрения Oracle Big Data Appliance было проанализировано поведение игроков. Это помогло найти подход почти к каждому пользователю, что привело к росту выручки, – в одном из регионов прибыль увеличилась на 65%.

Подача в виде истории позволяет раскрыть все стороны работы и рассказать и о трудностях, и о победах. Сторителлинг можно использовать, если вы будете работать с клиентами долгосрочно, тогда со временем историю можно расширить. Примером такого кейса может служить MST Agency и их слоган «Мы создаём цифровые истории».

В зависимости от типа исполнения можно выделить такие типы кейсов:

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

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

Несколько примеров различных типов кейсов компаний из разных областей.

Как писать кейсы?

Обычно при написании кейса используется такая схема:

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

У вас может получиться короткий кейс на 1500 знаков, который можно легко вписать в структуру продающей страницы или рекламной листовки. Также вы можете написать лонгрид, длина которого составит 10000 знаков, что позволит отобразить всю нужную информацию. При определении объема учитывайте главную задачу кейса – дать описание процесса в общем, либо же расписать каждую из частностей. И, естественно, учитывайте свои трудозатраты на написание материала, особенно, если вы планируете заниматься его прямыми продажами.

Как вариант, можно сделать и то, и другое (в плане объема). То есть, написать объемную публикацию в свой блог, после чего краткое изложение данного материала разместить в качестве портфолио или использовать на странице с описанием продукта.

Во время работы над кейсом необходимо помнить о 7 ключевых правилах:

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

• Заголовок, содержащий проблему. Пользователи смогут ассоциировать себя с ситуацией, которую вы описываете в кейсе. Примерами заголовков могут быть такие: «Как продвинуть сайт без бюджета». Кейс сразу же заинтересует начинающих предпринимателей, которые обычно стеснены в средствах.
• Заголовки, отражающие полученный результат. «Квартира мечты за 60 дней» – кейс о ремонте.

4. Перед тем как написать историю успеха, подумайте об оформлении публикации. Чтобы подача материала выглядела профессионально, используйте несколько рекомендаций:

• Используйте понятные, читаемые шрифты.
• Добавляйте иллюстрации, которые показывают ситуацию ДО применения кейса и ПОСЛЕ.
• Визуально выделите результаты, чтобы зафиксировать внимание пользователя.
• Если у вас есть отзыв, то правильно оформите цитату.

5. Используйте отзывы клиентов. Такие материалы делают вашу «историю успеха» реальной. Просто хвалебный отзыв принесет мало пользы, но если вы будете задавать клиенту наводящие вопросы, то отзыв будет полезен и для вас, и для других пользователей. Старайтесь подтвердить «реальность» клиента, например, дайте ссылку на его профиль в соцсетях.
6. Кейс должен содержать историю, а также быть живым и интересным. Помните, что каждый клиент – это личность. И у каждого, кто к вам обратился, есть своя история и проблема, которую вы должны решить. Чтобы добиться максимального вовлечения читателей, напишите кейс живым, образным языком. При этом важно показать, что только ваша компания может спасти положение.
7. В финале вашей истории разместите приглашение к сотрудничеству. Главная цель кейса – это повышение количества продаж, поэтому в конце должна быть реализована опция, которая поможет пользователю отправить заявку или заказать ваш продукт.

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

Структура и содержание кейса

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

• Предлагаемый вами уникальный продукт.
• Успешное применение подобных технологий в прошлых проектах.
• Награды на рынке.

Проблема. Здесь подробно опишите проблему, с которой столкнулся заказчик. Например, проблемой может быть низкая производительность труда в компании.

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

Оценка. Итоговая часть кейса, в которой описываются полученные достижения после применения продукта.

Перед тем, как написать историю успеха, изучите финансовую сторону процесса. Например, упомяните, что ваш продукт помог увеличить доход фирмы-заказчика на 50%. Также, если внедрение вашего решения помогло снизить затраты, обязательно напишите и об этом.

Если вас интересует, как написать кейс, примером может быть история внедрения нового ПО в отечественной компании ОАО «Региональная Сетевая компания», которая обеспечивает электроэнергией населенные пункты Свердловской области. Ей потребовалось несколько горячих линий для обслуживания клиентов. Представители компании «Альфа-Информ» провели презентацию работающего решении, которое уже было использовано для компании «НОВАТЭК-Челябинск».

Как результат, в ОАО «Региональная Сетевая компания» был внедрен программный продукт oktell, который позволил организовать контакт-центр. Результатами стали: оперативная работа с потребителями и повышено качество работы с клиентами. Упростилась работа при аварийных ситуациях, что позволило предотвратить возможные убытки компании и клиентов.

Что полезного можно сделать с написанным кейсом?

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

• Готовые кейсы с решениями демонстрируют успех вашей компании и показывают все возможности продуктов.
• Истории успеха обучают аудиторию. Чтобы создать кейс, вы должны провести расследование и оценить результаты, а написанный кейс даст пользователям новые знания.
• Case study привлечет дополнительное внимание к вашему бизнесу или деятельности ваших партнеров.
• Кейсы – один из компонентов сторителлинга, который помогает удерживать внимание пользователей и формирует лояльность к вашей компании и продуктам.

Кейсы по заработку в Интернете

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

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

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

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

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

Вывод

Бизнес-кейсы – это публикации, которые просматривают в два раза чаще, чем обычные текстовые материалы. Увидев успешный Case study, пользователи дольше остаются на сайте и внимательнее изучают публикации.

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

 

Кейсы что это такое и как его писать пример

Как написать кейс и никого не усыпить: алгоритм и способы улучшить самый сухой рассказ

Рассылка по интернет-маркетингу: Нажимая на кнопку, вы даете согласие на обработку своих персональных данных

• Главная
• /
• Блог
• /
• Как написать кейс и никого не усыпить: алгоритм и способы улучшить самый сухой рассказ

Время чтения: 10 минут Нет времени читать? Нет времени? Алексей Рожков Редакция «Текстерры»

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

Зачем писать кейс, даже если вообще не хочется

Логика подсказывает, а Content Marketing Institute доказывает, что кейсы работают. В глобальном исследовании за 2016 год 65% маркетологов назвали их эффективными, а 82% опрошенных специалистов посчитали публикацию кейсов основной тактикой в маркетинге для рынка B2B. Такие ожидания не кажутся завышенными, потому что опубликованные кейсы дают реальные преимущества:

1. Убеждают потенциального клиента в экспертности. Это лучшее социальное доказательство того, что вы решаете обозначенные в кейсе проблемы.
2. Помогают показать ценность услуги, которую нельзя потрогать. Например, разработка слоганов, привлечение лидов, маркетинговый анализ или аудит сайта – все это работы, которые в глазах неподготовленного заказчика выглядят невесомо. Но если описать подробно этапы и количество занятого персонала, обосновать цену будет проще.
3. Люди хотят делиться кейсами. Их хорошо распространяют группы в условиях недостатка нормального авторского контента. Активно лайкают на будущее пользователи. На иллюстрации ниже – общее соотношение по шерам одного из кейсов в группе «Интернет-маркетинг». 24 из 41 поделившихся – сторонние группы со своей аудиторией. Это проще, чем создавать собственный контент.

Когда можно и нужно писать кейс

Кажется, что ничего достойного публикации не происходит. Работаем потихоньку, запускаем какие-то обновления, находим клиентов и заключаем договора, учимся и улучшаем результаты труда, потихоньку растим сумму чистой прибыли и уменьшаем стоимость лидов. А кейсы – это же надо горы перевернуть. Вон у Румянцева опубликовали, как ворваться в конкурентную нишу и всех там разметать. Мы же не такие.

Но вам и не надо! Это обман и завышенные ожидания. Кейсы уровня конференций «Найди свой трафик» и RCM – это квинтэссенция знаний, но и ваш запас опыта для кого-то покажется недостижимым. Им тоже можно и нужно делиться.

Кейсы можно и нужно писать, если:

1. Получили дорогостоящий контракт. Он же не просто так на вас свалился. Реклама, продвижение услуги, работа на переговорах, правильные аргументы и поиск болевых точек клиента – все это интересно вашему читателю, который тоже так хочет.
2. Сделали выручку больше обычного. Проанализировали, почему так случилось. Какие действия предпринимали. Если сыграла роль сезонность или случайный фактор, подумали, как в следующий раз использовать этот рычаг, чтобы удвоить эффект.
3. Дешево привели клиентов заказчику или решили повседневную задачу нетривиальным способом.
4. Сильно облажались. Истории о провалах нравятся даже больше, чем счастливые хэппи энды. Вот, например, кейс о том, как Царские ковры не стали покупать в Рязани. Или почему надо сначала думать и зреть в корень проблемы. Кому лень читать, коротко суть – на рынке уже был товар лучше и дешевле, от чего провал. На эту тему следующий скрин.

1. Открыли новый способ работы – уменьшили издержки, запустили новую технологию, заметили ошибки в старых бизнес-процессах и исправили их. Первые результаты, прогнозы на будущее.
2. Вышло обновление сервиса, услуги или продукта – описываем, зачем сделали, на что надеемся, и как теперь будет работать. Если нет результатов, то выворачиваем кейс наизнанку и пишем о том, какие результаты были, чем не устраивали и почему обновление должно все изменить.
3. Когда удалось перевернуть представление о чем-то. Например, если вам удалось запустить крутую социалку средствами диджитал или раскрутить группу ВКонтакте одного из Краснодарских ЖЭКов. Или разработать приложение-гид по беременности.

Когда лучше ничего не делать:

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

Как писать кейс? С чего начинать?

Кейс – это ваша реклама, так что писать его лучше по принципам рекламы. Заголовок продающий. Универсальная формула – выгода через сложность. Прочитают ли ваш труд, зависит от первого абзаца – вступительного интро. Его задача – объяснить, о чем речь, что сделали, какие сложности решили и сколько денег потратили. Все надо уместить в пару предложений.

Обратите внимание на заявление в следующем анонсе «это не тест, а реальная кампания, которая работает 8 месяцев». Оно качественно выделяет руководство на фоне остальных.

Исходные данные. Обидно прочитать несколько страниц текста, чтобы убедиться, что кейс нельзя применить к твоему собственному бизнесу. Бюджет на работу, отправная точка, обстоятельства, компетентность и численность команды, дедлайн – все это важно, если вы пишете/снимаете/рисуете с целью принести пользу, а не ради виртуальных аплодисментов.

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

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

Читайте также: Что лучше: лонгриды или короткие статьи? Кейс «Текстерры»

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

Структура редко отличается. Чтобы было проще, задайте себе вопросы перед тем, как приступать к работе. Мой список, когда-то стянутый с geektimes и доработанный, выглядит так:

1. Кто заказчик? Что за компания?
2. Какая миссия проекта – кому он нужен?
3. Как все работало раньше?
4. Что не устраивало?
5. Есть ли что-то необычное в задаче?
6. Есть ли ограничения по проекту – деньги, время, персонал, законы?
7. Делали все стандартно или разрабатывали индивидуальное решение?
8. Команда, которая работала над проектом?
9. Какие трудности ожидали? Какие случились?
10. Насколько втянули заказчика в проект?
11. Какие инструменты привлекали? Что из них собственные наработки, что позаимствовали?
12. Что вообще сложного было или, может, каждый второй справится?
13. Как выглядит результат?
14. Это хорошо или плохо?
15. Что говорит заказчик?
16. Уже работает или только придумали, как сделать?
17. Что именно изменилось?
18. А что было бы, если не делать ничего?
19. А если бы не получилось? Откуда знали, что получится?
20. Сколько стоит работа?
21. Быстро справились?
22. Что надо было сделать иначе?
23. Кому и как можно использовать результаты работы?

Отвечайте на вопросы, следуйте простой логике и ничего выдумывать не стоит. Хотя можно придумать, как улучшить последовательность, которой пользуются все подряд.

Читайте также: 200+ лучших кейсов по интернет-маркетингу в рунете

Как можно улучшить кейс?

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

Тест кейс (test case). Примеры написания и атрибуты тест кейсов

ТЕСТ КЕЙС (TEST CASE) – это комплекс исходных данных, условий и ожидаемых результатов, разработанный с целью проверки требуемого свойства продукта. Test cases, собранные в последовательность для достижения некоторой цели образуют test suite (набор тестов).

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

Примечание: test case перевод из wikipedia

Содержание

Чтобы больше прояснить ситуацию с терминами и определениями, давайте сопоставим некоторые термины касательно этой темы:

• Тест-кейс и тест = синоним
• Не путаем чек-лист и тест. Отличие тест кейса от чек-листа заключается в том, что чек-лист это всего лишь идея будущего теста,  а тест кейс, как мы говорили выше, набор данных и ожидаемых результатов. Часто чек лист становится хорошим началом атрибута Test description в тест-кейсе.
• Не путаем тест план и тест кейс. Что касается мы уже определились, а вот тест план это фундаментальный документ, который описывает разные аспекты процесса тестирования. Подробно о тест плане мы поговорим в отдельной статье.
• Тест сценарий и тест кейс, также неравны. Тестовый сценарий (test scenario) – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Хороший тестовые сценарии и тест кейсы в нем всегда следуют некоторой логике, например: типичному использованию приложения, удобству тестирования, распределению функций по модулям и т.д.

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

В чем сложность написания тест кейсов?

Признаться честно, разработка тест кейсов не совсем приятное для многих тестировщиков занятие. И эта неприязнь легко поддается объяснению, ведь их создание требует от Software Testing Engineer следующего:

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

Примечание: Существует мнение, что мозг поглощает около 20% питательных веществ, при том, что занимает около 2% от всего организма. Возможно, поэтому наше «серое вещество», желая сэкономить энергию, предлагает посмотреть любимый сериал, а не обдумать какую-либо проблему.

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

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

back to menu ↑

Зачем нужно написание тест кейсов?

Как мы отмечали выше создание тестов не простое занятие для большинства нестировщиков. Тем не менее, позитивные свойства качественных тест кейсов заключаются в том, что они позволяют:

• Найти проблемные места в требованиях. Если требование не понятно и не тестируемо в принципе, то написание тест кейса это проявит. Вместе с тем, здесь нужно быть предельно ответственным, нельзя копипастить требования в ТК.
• Структурировать всю информацию. Логика и структура дадут нам больше шансов тратить меньше времени на вникание в сам тест кейс (одно будет вытекать из другого). Кейсы, максимально замапленные на требования, позволяют потом не искать, откуда же эта информация взята.
• Ускорить регрессию. Чтобы провести качественный регресс, надо выбрать правильные тест кейсы smoke test, высокоуровневый тест кейсы и тд. Помимо этого, тест кейсы, содержащие максимум вспомогательной информации: логины, пароли – тем самым экономим время.
• Хранить и собирать информацию. Все сложные настройки должны быть описаны в тест кейсах (логины, пароли, валидация полей, сертификаты, данные карт и тд.). Всегда можно приатачить к кейсам дополнительные файлы с нужной инфой или даже какое-то важное письмо.
• Отслеживать процесс тестирования. Тут важно отметить следующие особенности, что одна ячейка таблицы=один тест, так четко и без проблем ставим статус. Можно создаем статистику (пройдено /не пройдено, не протестировано)

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

back to menu ↑

Как писать тест кейсы?

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

• Подробный или общий?
• Позитивный или негативный?
• Простой или сложный?
• Независимый или объединенный?

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

Подробный или общий тест кейс?

Пример оформления 1

Тест кейс 1		Тест кейс 2
1.In the field A, type 2 2.In the field B, type 3 3.Click Add button. 4.Check value of the field C	4. The value is 5.	1. Verify that the program sums A and B correctly	1. It is so.

Плюсы и минусы

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

Пример оформления 2

Тест кейс
Summing A and B 1.In the field A, enter valid integer 2.In the field B, enter valid integer 3.Click Add button. 4.Check value of the field C 5. Repeat  steps 1-4 for 0, 99999 ( max allowed value), -99999, 1.5, aaa ( invalid values)	4. The value of C field equals A+B

Плюсы и минусы

• Мы не привязаны к точным значениям
• Время на поддержку теста сокращается
• Мы перечисляем конкретные цифры, которые должны быть проверены в тесте

Позитивные или негативные тест кейсы?

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

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

Помня эти принципы, тестировщику проще не совершить крен в ту или иную сторону будь-то при написании тест кейсов игры или use case testing.

Простые или сложные тест кейсы?

Начиная разработку ТК сотруднику необходимо помнить, следующую последовательность разработки, а потом и выполнения тестов:

• Простые позитивные
• Простые негативные
• Сложные позитивные
• Сложные негативные

Такая очередность позволяет оптимизировать процесс написания и в дальнейшем легче определять приоритет тест кейса.

Независимые или объединенные тест кейсы?

В данной ситуации нет однозначного ответа да этот вопрос, все зависит от конкретного проекта. Поэтому просто перечислим типичные характеристики данных тест кейсов

Независимые:

• Независимые тесты быстро и легко проходим
• Можно продолжать тестирование, если один тест упал
• Проходить тесты можно в любом порядке

Объединенные:

• Сценарии повторяют поведения пользователя
• Эффективны, когда в 1 шаге у нас по 10 подшагов
• Мы не создаем каждый раз новые данные, а используем созданное на предыдущем шаге
• Характерны для интеграционного и системного тестирования

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

Best practices тест кейсы:

• Используйте простой разговорный язык
• Всегда используйте полное описание и наименование элементов
• Не объясняйте Windows basics
• [button], (?), “field name”, ‘label’
• “Open”, а не “go”

Теперь пришло время поговорить про поля тест кейса и характерные атрибуты.

back to menu ↑

Что может являться атрибутом тест кейса?

Мы написали про основные принципы того, как составлять тест кейсы, теперь давайте разберемся, какая же должна быть структура тест кейса.

Названия атрибутов тест кейса
ID	Priority	Req. ID	Module	Sub-Module	Test description	Expected result	Result	Comment

Следует отметить, что атрибуты тест кейса могут отличаться в зависимости от компании и инструмента, с помощью которого данные тесты создаются, поэтому мы перечислим наиболее распространенные атрибуты тест кейса:

1. ID — уникальный идентификатор. Если проставляется руками, то желательно делать его осмысленным. Часто генерируется автоматически.
2. Priority (приоритет тест кейса) – атрибут, который указывает приоритетность ТК, и принимает значение, согласно принятой в компании классификации (A-B-C-D-E, High-Medium-Lowи тд.)
3. Req. ID – атрибут, указывающий на связанный с тестом пункт требования
4. Module – здесь указывается связанный с тест кейсом модуль.
5. Sub-Module – аналогично предыдущему пункту, только вписывается более мелкая структурная единица.
6. Test description (описание тест кейсов) – важный атрибут, в котором указывается заголовок (суть теста), условия для его выполнения, шаги и действия после прохождения теста. Test description, соответственно, может и должен содержать:

• Precondition
• Steps
• Postcondition

7. Expected result (ожидаемый результат тест кейса) – данный атрибут отражает ожидаемый результат по каждому шагу.
8. Result – сюда заносятся данные о результате пройденного теста (passed/failed и др.)
9. Comment – сюда можно вносить свои примечания к тесту (вопросы заказчику, какие-либо наблюдения или детали)

back to menu ↑

Написание тест кейсов: примеры

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

 

Скачать тест кейс пример оформления в формате xlsx

Этот контент заблокирован

Поделиться этой страницей, чтобы разблокировать контент!

Еще больше примеров в этой статье

Что такое тест-кейс и как его писать

Школа для начинающих тестировщиков

Начало: 19 марта 2020

Азбука IT

Начало: 19 марта 2020

Программирование на Python для тестировщиков

Начало: 20 марта 2020

Логи как инструмент тестировщика

Начало: 23 марта 2020

Погружение в тестирование. Jedi point

Начало: 23 марта 2020

Тестирование REST API

Начало: 23 марта 2020

Техники локализации плавающих дефектов

Начало: 23 марта 2020

Python для начинающих

Начало: 25 марта 2020

Chrome DevTools: Инструменты тестировщика

Начало: 26 марта 2020

SQL: Инструменты тестировщика

Начало: 26 марта 2020

Git: инструменты тестировщика

Начало: 26 марта 2020

Консольные утилиты Android: инструменты тестировщика

Начало: 26 марта 2020

Командная строка: инструменты тестировщика

Начало: 26 марта 2020

Selenium IDE 3: стартовый уровень

Начало: 27 марта 2020

Практикум по тест-дизайну 2.0

Начало: 27 марта 2020

Школа тест-менеджеров v. 2.0

Начало: 1 апреля 2020

Тестирование юзабилити (usability)

Начало: 1 апреля 2020

Тестирование производительности: JMeter 5

Начало: 3 апреля 2020

Программирование на C# для тестировщиков

Начало: 3 апреля 2020

Автоматизация функционального тестирования

Начало: 10 апреля 2020

Тестирование веб-приложений 2.0

Начало: 10 апреля 2020

Английский для тестировщиков

Начало: 13 апреля 2020

Комплексная система подготовки к сертификации ISTQB FL (КСП ISTQB)

Начало: 13 апреля 2020

Тестирование безопасности

Начало: 15 апреля 2020

Автоматизатор мобильных приложений

Начало: 15 апреля 2020

Тестирование мобильных приложений

Начало: 15 апреля 2020

Программирование на Java для тестировщиков

Начало: 17 апреля 2020

Selenium WebDriver: полное руководство

Начало: 17 апреля 2020

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

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

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

Что такое Use Case

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действующие лица	Администратор, Система
Цель	Изменить статус учетной записи пользователя на «активный».
Предусловие	Учетная запись пользователя не активна.
Успешный сценарий: Администратор выбирает пользователя и активирует «Разблокировать». Система переключает учетную запись пользователя в статус «активный», и посылает сообщение (тут можно сослаться на текст сообщения из списка сообщений, см. примечание ниже) пользователю на email (если «User Account → email» не пусто).
Результат	Учетная запись пользователя была переведена в статус «активный».

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

Действующие лица	Пользователь, Система
Цели	Пользователь: авторизоваться в системе и начать работать; Система: идентифицировать пользователя и его права.
Успешный сценарий: Пользователь запускает систему. Система открывает сессию пользователя, предлагает ввести логин и пароль. Пользователь вводит логин и пароль. Система проверяет логин и пароль. Система создает запись в истории авторизаций (IP адрес пользователя, логин, дата, рабочая станция). Система выдает пользователю сообщение по поводу успешной авторизации (ссылка на сообщение).
Результат	Пользователь успешно авторизирован и может работать с системой.
Расширения:
*а	Нет доступа к БД. Система выдает сообщение (ссылка на сообщение). Результат: пользователь не может войти.
1а	В настройках безопасности для данного IP адреса существует запрет на вход в систему. Результат: форма логина не предоставляется, система выдает сообщение пользователю (ссылка на сообщение).
2а	Пользователь выбирает: «Напомнить пароль». Вызывается сценарий «Напомнить пароль».
3а	Пользователь с введенными логином и паролем не найден. Результат: отказ в авторизации. Система выдает сообщение (ссылка на сообщение). Переход на шаг 2.
3б	Количество неудачных попыток авторизоваться достигло максимального, установленного в настройках. Результат: пользователь не может войти. Выдается сообщение: (ссылка на сообщение). Вход с IP адреса Пользователя заблокирован на время, установленное в настройках.

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

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

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

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

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

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

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

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

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

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

Как написать идеальный кейс 🚩 Литература

 

В идеальном кейсе, как и в сказке, 4 основных элемента:

• Герой, которому хочется сопереживать,
• События, которые меняют героя,
• Цель, на пути к которой герой преодолевает препятствия,
• Секретный ингредиент.

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

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

 

Идеальный кейс рассказывает историю, в которой герой проходит 5 основных шагов.

1. Кризис. Отправная точка героя. Ситуация, когда старые способы и решения не работают, и необходимо что-то изменить, чтобы выйти из кризиса.
2. Проблема. Герой формулирует проблему, с которой столкнулся, ставит задачи и определяет цель.
3. Инструменты. Что было сделано,чтобы решить проблему и достичь цели? Шаги, решения, приёмы.
4. Результат. К какому итогу пришел герой? Итог может быть положительным, а может быть отрицательным. Важно, чтобы отрицательный результат не описывался в идеальном кейсе как провал. Отрицательный результат — это как ценный опыт, который чему-то научил героя.
5. Опыт. Что герой кейса понял и чему научился, пока выходил из кризиса и шел к своему результату.

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

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

• Читается ли в кейсе ваша идея, ваш нарратив? Захотят ли люди поделиться вашей историей? Почувствовали ли они сопричастность?
• Приятно ли читать ваш кейс? Удобен ли формат? Интересен ли стиль? Скучно написанные кейсы не зацепят аудиторию, даже если в них формально соблюдена структура.
• Можно ли представить вашу историю? Важно визуализировать то, что вы пишете. Это помогает читателю сильнее погрузиться в вашу историю и лучше ее понять