Как я буду разбирать первые экраны сайтов глазами клиента

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

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

Мне нужна практика, но не ценой выдуманных выводов.

Когда я пытаюсь сформулировать оффер для “Дожми Продажи”, я постоянно упираюсь в одни и те же вопросы:

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

Читать про позиционирование и AJTBD полезно.

Но в какой-то момент теория начинает создавать ложное ощущение, что я уже умею это делать.

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

Открывать первый экран как потенциальный клиент.
Фиксировать, что именно я понял.
Замечать, что пришлось додумать самому.
Пытаться восстановить работу, которую продаёт компания.
И только после этого предлагать свою версию.

Эта статья - карта всей серии.

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

Главный вопрос серии

В каждом материале я буду отвечать на один вопрос:

Что я как потенциальный клиент понял о компании до того, как начал подробно изучать её продукт?

Не что компания хотела сказать.

Не что она, возможно, обсуждала на стратегических сессиях.

Не что её команда знает о продукте изнутри.

А какую модель продукта создала страница в моей голове.

Это важное различие.

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

Но потенциальный клиент не видит внутренние документы.

Он видит заголовок, подзаголовок, визуал, кнопку и несколько ближайших аргументов.

Из них он за несколько секунд пытается собрать ответ:

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

Именно эту сборку я хочу исследовать.

Почему я смотрю именно на первый экран

Первый экран не обязан объяснить весь продукт.

Более того, попытка поместить туда всё обычно делает его слабее.

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

Для меня первый экран - это не набор обязательных элементов.

Это первый контракт понимания между компанией и посетителем.

Компания как будто говорит:

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

Если этот контракт не складывается, посетитель начинает строить собственную версию продукта.

Иногда она совпадает с намерением компании.

Иногда оказывается уже реального продукта.

Иногда шире того, что компания способна контролировать.

А иногда я вообще не понимаю, с чего начать.

Все эти исходы для меня являются нормальным материалом исследования.

Что именно я буду разбирать

Основной объект каждой статьи - первый экран главной или продуктовой страницы.

Я буду фиксировать:

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

Иногда я посмотрю следующие несколько блоков.

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

Например:

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

Но серия не будет полноценным обзором сайта.

Я не оцениваю всю информационную архитектуру, SEO, дизайн-систему, скорость загрузки, продуктовую экономику или работу отдела маркетинга.

Я исследую только один объект:

какое понимание продукта рождается у потенциального клиента на входе.

Четыре слоя, которые нельзя смешивать

Самый большой риск такого формата - незаметно превратить собственное восприятие в доказанный факт.

Чтобы этого не происходило, каждый разбор будет разделён на четыре слоя.

1. Факт страницы

Это то, что действительно можно увидеть и проверить:

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

Здесь я не должен интерпретировать.

Если на странице написано “увеличивайте продажи”, факт состоит только в том, что компания использует эту формулировку.

Из этого ещё не следует, что продукт увеличивает продажи, что аудитория верит обещанию или что заголовок не работает.

2. Моё считывание

Это модель, которая возникла у меня как у посетителя:

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

Это реальный результат коммуникации страницы со мной.

Но это не доказательство того, что все клиенты понимают её так же.

Корректная формулировка:

Я считал этот экран так.

Некорректная:

Клиенты не понимают, что продаёт компания.

3. AJTBD-гипотеза

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

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

Это уже не наблюдение за страницей.

Это моя исследовательская гипотеза.

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

4. Неизвестное

Иногда данных недостаточно.

Я не знаю:

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

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

Неизвестное - не дефект статьи.

Иногда это самый честный и полезный результат разбора.

Как я буду восстанавливать работу клиента

AJTBD нужен мне не как словарь правильных терминов.

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

Можно заменить одно слово.
Можно сократить подзаголовок.
Можно сделать кнопку активнее.

Но если я не понял, какую работу выполняет человек, новый текст останется ещё одной версией копирайтинга.

Поэтому я буду собирать конструкцию:

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

Ситуация объясняет, почему человек начал искать решение сейчас.

Работа показывает, какой прогресс он пытается совершить.

Роль уточняет, какое решение человек должен принять и за что отвечает.

Механизм объясняет, что именно делает продукт.

Следующий шаг снижает неопределённость и помогает продолжить путь.

Если один из этих элементов отсутствует, я не буду автоматически считать это ошибкой компании.

Возможно, нужный контекст уже известен входящему трафику.

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

Возможно, продукт намеренно оставляет широкую рамку.

Но я должен явно показать, где смысл находился на странице, а где я достроил его сам.

Верхняя работа, нижние работы и функции

В этой серии я особенно хочу натренироваться не путать три уровня.

Функция

То, что делает продукт.

Например:

• записывает звонки;
• объединяет сообщения;
• строит отчёт;
• создаёт документы;
• проверяет данные;
• автоматизирует действие.

Нижняя работа

Конкретный прогресс внутри более крупной задачи.

Например:

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

Верхняя работа

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

Например:

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

Функция не обязана находиться в заголовке.

Верхняя работа тоже не всегда должна становиться главным оффером.

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

Как я буду работать с ролями

Фраза “для собственника” ещё не объясняет ценность продукта.

Два собственника могут находиться в совершенно разных ситуациях и пытаться выполнить разные работы.

Поэтому я буду идти не от должности к набору функций, а в другом порядке:

ситуация -> работа -> решение -> роль -> продуктовый ответ.

Мне важно понять:

• что человек пытается решить;
• почему не может сделать это сейчас;
• какое решение примет после использования продукта;
• какая информация или возможность ему для этого нужна.

Только после этого можно объяснять продукт для роли.

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

Для каждой роли нужно раскрыть собственное решение.

Собственнику может быть важен тренд и момент вмешательства.

Руководителю - причина изменения и конкретные сотрудники.

Менеджеру - следующая работа по сделке.

Маркетингу - повторяющиеся сигналы спроса и качества лидов.

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

Как будет устроен каждый разбор

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

Сначала - сцена входа

Почему я открыл сайт и что ожидал понять.

Затем - факты первого экрана

Что буквально написано и показано.

Потом - моё первое считывание

Какой продукт возник у меня в голове.

После - главный разрыв

Одной статье нужен один основной исследовательский конфликт.

Например:

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

Дальше - AJTBD-гипотеза

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

Затем - вопросы для проверки

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

Только после этого - моя версия

Она может включать:

• новый заголовок;
• подзаголовок;
• CTA;
• визуальный принцип;
• зонтичный оффер;
• ролевые раскрытия;
• более узкую границу обещания.

В финале - возврат к собственной практике

Что этот разбор изменил в моём понимании “Дожми Продажи”.

Не как рекламная вставка.

А как честный ответ:

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

Объём не является целью

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

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

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

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

Не каждый сайт обязан дать:

• сильный конфликт;
• полноценную AJTBD-модель;
• альтернативный оффер;
• ролевую архитектуру;
• метафору;
• большой вывод для “Дожми Продажи”.

Иногда честный результат будет состоять из нескольких абзацев:

Первый экран понятен. Я вижу, что продаётся, кому и зачем. Существенной альтернативной гипотезы у меня сейчас нет.

Или:

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

Такой материал не нужно искусственно расширять.

Главный критерий публикации - не объём, а наличие честного наблюдения, которое меняет или уточняет понимание продукта.

Что делать, если я ничего не понял

Я заранее фиксирую это правило, потому что соблазн придумать красивый ответ будет большим.

Если после изучения первого экрана я не могу уверенно сказать:

• что продаётся;
• кому;
• в какой ситуации;
• какую работу решает;
• чем продукт отличается от категории;

я не буду искусственно собирать “правильный оффер”.

Я напишу:

Я не смог уверенно восстановить продуктовую логику с первого экрана.

После этого покажу:

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

Фраза “я пока не знаю” для этой серии полезнее, чем уверенный текст, построенный на выдуманном понимании бизнеса.

Почему это не будет критикой компаний

Я анализирую только публичный фасад продукта на конкретную дату.

У компании могут быть:

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

Поэтому я не буду утверждать:

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

Моя позиция проще:

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

Это позволяет быть точным, не занимая верхнюю позицию.

Как серия связана с “Дожми Продажи”

Эта практика нужна мне не отдельно от продукта.

Она напрямую связана с тем, что мы пытаемся делать в “Дожми Продажи”.

Компания часто не знает заранее:

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

Ответы на эти вопросы нельзя получить только переписыванием заголовков.

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

Поэтому каждый внешний разбор будет для меня ещё и способом сформулировать внутреннюю проверяемую гипотезу:

Что нужно посмотреть в коммуникациях компании, чтобы понять, соответствует ли моя версия реальному спросу?

Так связь с “Дожми Продажи” остаётся содержательной.

Не “наш продукт всё исправит”, а “вот какую гипотезу можно было бы проверить на фактах”.

Контрольный чек-лист серии

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

Факты

• Я точно зафиксировал дату и версию страницы?
• Я отделил точный текст компании от своего пересказа?
• Я не приписал компании то, чего она не заявляла?
• Я не сделал вывод о продукте без его использования?

Считывание

• Я ясно написал, что именно понял как клиент?
• Я обозначил это как своё восприятие, а не мнение всех клиентов?
• Я показал, какие элементы страницы создали это понимание?
• Я отметил, что пришлось достроить самому?

AJTBD

• Я начал с ситуации и прогресса, а не с должности?
• Я не назвал функцию верхней работой без объяснения?
• Я разделил верхнюю и нижние работы?
• Я показал текущие альтернативы и барьеры?
• Я обозначил гипотезу как гипотезу?

Роли

• Для каждой роли есть конкретное решение, а не просто список функций?
• Понятно, почему роли нужен продукт именно в этой ситуации?
• Я не спутал пользователя, инициатора, покупателя и принимающего решение?

Обещание

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

Альтернативный экран

• Заголовок связан с работой или ближайшим прогрессом?
• Подзаголовок объясняет механизм?
• CTA соответствует зрелости посетителя?
• Визуал помогает понять продукт, а не украшает страницу?
• Я объяснил, почему предлагаю именно эту конструкцию?

Тон

• Материал помогает понять, а не унижает?
• Я не изображаю знание чужого бизнеса лучше его команды?
• В статье нет злорадства и публичной порки?
• Я допускаю, что у компании есть неизвестные мне основания?
• Я прямо написал, что моя версия требует проверки?

Связь с собственной практикой

• Разбор действительно изменил или уточнил моё понимание “Дожми Продажи”?
• Я сформулировал конкретную гипотезу для проверки?
• Связь с продуктом не выглядит рекламной вставкой?
• Чужая компания не используется как отрицательный фон для моего продукта?

Если на несколько вопросов ответ “нет”, статья ещё не готова.

Почему эта карта может измениться

Я не хочу превращать эту статью в окончательную методологию.

Её смысл противоположный.

Я фиксирую текущую систему координат, чтобы по мере новых разборов видеть, как изменяется моё мышление.

Возможно, часть вопросов окажется бесполезной.

Возможно, появятся новые типы работ.

Возможно, я обнаружу, что слишком много внимания уделял заголовкам и слишком мало - контексту входящего трафика.

Возможно, некоторые мои первые альтернативные офферы позже покажутся слишком уверенными.

Это нормальный результат практики.

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

Главный принцип

Я не ищу, как сделать компанию “правильной”.

Я пытаюсь понять, какую модель продукта её сайт создаёт у меня в голове, где эта модель собирается, где распадается и можно ли объяснить тот же продукт яснее через реальную работу клиента.

Каждая следующая статья будет проверкой этого принципа.

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