Кейс на сайте помогает потенциальному заказчику понять, решала ли компания похожую задачу и как она работает. Для этого нужны контекст, конкретный вклад и подтверждённый результат. Галерея фотографий показывает внешний вид, но не объясняет, что было сделано и почему это важно для клиента.
Подготовку стоит начать до дизайна страницы. Соберите факты об одном проекте, установите границы допустимой публикации и выберите изображения, которые поддерживают рассказ. Ниже — порядок работы и бланк, который можно передать ответственному за материалы.
Выберите проект под вопрос будущего клиента
Начните с услуги, которую хотите объяснить. Если компания продаёт проектирование, важен процесс принятия решений. Если внедрение — условия, состав работ и переданный результат. Крупное название заказчика не заменяет релевантной истории.
Запишите вопрос посетителя: «Справится ли компания с нашим ограничением?», «Что входит в работу?», «Как проходит передача?». Затем проверьте, есть ли у выбранного проекта факты для ответа. Не обязательно брать самый масштабный проект, если по нему невозможно показать ни задачу, ни вклад, ни результат.
Место кейса в навигации определите по структуре корпоративного сайта: от соответствующей услуги к примеру работы и далее к обсуждению похожей задачи.
Зафиксируйте исходную задачу и границы вклада
Описывайте ситуацию до начала работы: кому требовался результат, что мешало и какие условия нельзя было изменить. Источником могут быть бриф, согласованная задача или проверенное объяснение ответственного. Не добавляйте задним числом цель, о которой проектная команда не договаривалась.
Разделите результат всего проекта и работу вашей компании. Укажите, что вы получили на входе, что создали, что настроили и что не входило в объём. Это особенно полезно, когда использовались готовые сервисы, материалы заказчика или существующая инфраструктура.
Например, ссылка с сайта на внешний сервис записи не доказывает разработку самой системы записи. Фотография готового объекта не показывает, кто проектировал, производил или монтировал его. Формулировка вклада должна соответствовать подтверждённой работе.
Бланк сбора фактов для кейса
Скопируйте таблицу в рабочий документ. Для каждого ответа укажите источник и состояние проверки. Неизвестное оставляйте вопросом с ответственным, а не заполняйте правдоподобным текстом.
| Поле | Что записать | Чем подтвердить |
|---|---|---|
| Проект и версия | Название, объект работы, дата или этап | Документ проекта, версия результата |
| Задача клиента | Кто нуждался в результате и зачем | Бриф, согласованное описание |
| Ограничения | Материалы, процессы, технические условия | Зафиксированные исходные условия |
| Вклад компании | Конкретные выполненные работы и границы | Состав работ, задачи, передача |
| Решение | Что выбрали и почему | Макет, схема, согласованное решение |
| Результат | Что передано и принято | Реестр результата, проверка, приёмка |
| Измеренный эффект | Показатель и период, если они известны | Отчёт с источником и условиями измерения |
| Иллюстрации | Что объясняет каждый кадр | Исходник, дата, связь с версией |
| Согласование | Что разрешено показать и кто проверяет | Подтверждение для конкретной редакции |
Внутренние документы не обязательно публиковать. Их задача — помочь редактору проверить утверждение. В открытой версии достаточно понятного описания результата и допустимых иллюстраций; закрытые условия и данные не должны попадать на страницу случайно.
Объясните решение через конкретный пример
Читателю трудно оценить слова «комплексный подход» или «удобный интерфейс». Выберите одно решение и покажите его связь с задачей. Что было нужно человеку? Какие варианты рассматривались? Что выбрали и какое ограничение учли?
Учебный пример: компания готовила каталог оборудования, характеристики которого обновлялись в учётной системе. Вместо повторного ручного ввода на сайте предусмотрели согласованный обмен выбранными полями. В кейсе можно объяснить источник данных, границы обмена и проверку карточки после обновления — если всё это действительно входило в работу и подтверждено.
Этот пример вымышленный. Он показывает способ построения рассказа, а не опыт или результат CoreWeb. Название интеграции и обещание автоматизации нельзя переносить в реальный кейс без проверки.
Различайте переданный результат и эффект для бизнеса
«Запущен раздел с согласованными карточками» и «увеличились продажи» — разные утверждения. Первое можно подтвердить составом результата и приёмкой. Второму нужны данные: какой показатель, за какие периоды, из какого источника и при каких условиях.
Если используете сравнение, сохраните исходные значения, способ расчёта и границы выборки. Проверьте, не менялись ли одновременно реклама, ассортимент, условия продаж или учёт обращений. Наблюдаемое изменение не всегда можно объяснить только проектом.
Когда измерений нет, опишите проверяемый продуктовый результат: доступные функции, завершённый этап, переданные материалы, выполненные условия. Кейс не обязан содержать процент роста. Нельзя заменять отсутствующую аналитику оценкой «стало в несколько раз эффективнее».
Подберите иллюстрации, которые объясняют работу
Для каждого кадра сформулируйте, какой тезис он подтверждает. Общий вид помогает понять контекст; подробность — увидеть решение; последовательность — разобраться в процессе. Подпись должна связывать изображение с рассказом, а не повторять название проекта.
Проверьте дату и версию. Текущий сайт, интерьер или продукт могли измениться после передачи; такой кадр нельзя автоматически подписать как ваш результат. Если используется схема или демонстрационный пример, обозначьте это прямо.
Подготовьте исходник достаточного качества, подпись, источник и сведения о допустимом использовании. Отдельно проверьте, что в кадр не попали закрытые документы, контакты или данные пользователей. Для информативного изображения текстовая альтернатива должна передавать его смысл в контексте страницы — этот подход описан в руководстве W3C WAI. Не превращайте alt в перечень поисковых запросов.
Согласуйте содержание и ограничения
Назначьте проверяющего факты и человека, который подтверждает допустимый объём публикации. Это роли в процессе: для рассказа о проекте не обязательно раскрывать персональный состав команды.
По отдельности проверьте название клиента, логотип, изображения, технические подробности, цифры и цитаты. Разрешение на один материал не следует автоматически распространять на все остальные. Фиксируйте решение относительно конкретной редакции; после существенных изменений отправляйте её на повторную проверку внутри согласованного процесса.
Если часть сведений закрыта, определите, можно ли сделать полезное обезличенное описание. Замена названия сама по себе не исключает узнаваемость по экрану или деталям проекта. Если допустимых фактов недостаточно, отложите кейс и покажите на странице услуги свой процесс или явно обозначенный учебный пример.
Как передать материалы веб-студии
Соберите текст фактов, реестр подтверждений, разрешённые изображения и список открытых вопросов. Укажите, кто уточняет сведения и кто принимает финальную редакцию. Так студия сможет проектировать страницу вокруг содержания, а не подгонять историю под случайный набор блоков.
Перед запуском прочитайте кейс как потенциальный заказчик: понятны ли задача, вклад и результат; помогают ли подписи; доступны ли изображения на телефоне; есть ли переход к нужной услуге и способ обсудить проект. Проверьте, что опубликована согласованная версия и в ней не осталось внутренних пометок.
Включите кейсы в общий реестр материалов для сайта. При подготовке корпоративного сайта заранее согласуйте, кто собирает факты, пишет и проверяет тексты: это часть объёма проекта, которая влияет на готовность страниц к запуску.