Важное примечание: Все исследования проведены на публичных данных. Я отправляю эти разборы командам, потому что верю: лучший способ проверить гипотезы — столкнуть их с реальностью. Моя задача — подсветить разрывы в пользовательском опыте, которые могут стоить денег, и предложить варианты их устранения. Буду рада обратной связи и готовa скорректировать выводы, если увижу контекст, который ускользнул от моего внимания как внешнего исследователя.
Если читать некогда — вот суть за 40 секунд
Я составила таблицу из семи компаний, документацию которых хотела изучить. Быстро прошлась по каждой, оставила заметки и выбрала трёх фаворитов. Вот что из этого вышло.
Bpium — отечественный продукт, к которому переезажают российские бизнесы с зарубежных аналогов.
Документация построена вокруг функций, а не задач. Готовый ш��блон CRM спрятан так, что 90% пользователей его не найдут (моя оценка). Предложила задаче-центричную архитектуру и 5 конкретных тикетов в Jira на первый месяц работ.
DirectAdmin — гайд по миграции с cPanel заставляет администратора импровизировать в 80% шагов.
Для почты и DNS инструкций нет — коэффициент импровизации 80–100% (не математический). Спроектировала структуру Plan→Do→Check и скрипты-помощники.
AmoCRM — разработчик тратит 48 минут вместо 5 на типовую интеграцию. 860% лишнего времени.
Гипотетические потери для обеих сторон — от 275 тысяч до 3+ миллионов рублей в год. Это оценочные (не бухгалтерские) расчеты, все подробности и методология - в детальном разборе. По итогу, предложила три прототипа: раздел со сценариями, визуальные маркеры, перекрёстные ссылки.
Главное: я не собирала портфолио под конкретные вакансии. Я просто искала ответ на вопрос «нравится ли мне эта работа?». А кейсы получились сами.
Внизу — чек-лист, если вдруг хотите повторить.
Я не умею учиться на курсах.
Серьёзно.
Не умею ради галочки. Как только меня начинают вести за ручку по линейному пути «вот так правильно» — мне становится скучно до тошноты.
Я умею учиться на практике. На живых данных, на реальных ошибках, на том, что болит прямо сейчас.
Знакомый в университете рассказал шутку:
— На работе сказали: забудьте всё, чему учили в институте.
— А ты?
— А мне то же самое сказали в институте, когда я пришёл после школы.
Поэтому, когда передо мной встала задача собрать портфолио, я не придумала ничего лучше, чем… просто делать работу.
Результатом стали три готовых кейса, десятки часов исследований, интересные находки, гипотетические подсчеты потерь и готовая методика, которой я делюсь в этой статье.
Моя специализация — информационная архитектура и пользовательские сценарии. Я анализирую, как знания о продукте доходят до пользователя, где возникают разрывы и сколько это стоит.
Если бы я работала внутри команды, я бы, конечно, учла технический долг, ограничения по ресурсам и историю решений. Но здесь я играю роль внешнего исследователя, который смотрит на продукт глазами пользователя. Моя задача — не навязать «единственно правильное» решение, а подсветить проблему и дать прототип, который команда сможет адаптировать под свой контекст.
Моя методика: 7 шагов полевого исследования (тот самый чек-лист)
Шаг 1. Найти продукт, который реально интересен
Не «где есть вакансия», а что вас цепляет. Сложные системы не пугают, а интригуют? Отлично. Если интересно — вы пойдёте вглубь и не заметите, как пролетело 10 часов.
В моем примере: я выбрала Bpium, потому что я ранее никогда не работала с low-code платформами и было интересно, как это выглядит изнутри, особенно документация.
Шаг 2. Выбрать сценарий, который цепляет
Не читайте «просто» документацию. Берите конкретного пользователя с конкретной задачей и проходите его путь. CEO, который выбирает CRM? Разработчик, который её внедряет? Администратор, который переносит 500 сайтов? У каждого своя боль.
В моем примере: В DirectAdmin выбор был очевиден — инженер, которому придется мигрировать сайты с одного вендора на другого, и при этом, в одиночку.
Шаг 3. Пройти путь (можно с таймером, как нравится)
Фиксируйте всё, что заставляет остановиться, задуматься, пойти гуглить. Каждая точка неопределённости — это данные.
В моем примере: предлагаю записывать все, особенно там, где возникают сомнения "а прав ли я?". К этому обязательно нужно будет вернуться. Записывайте даже то, что кажется очевидным.
Шаг 4. Искать паттерны, а не опечатки
Одна ошибка — опечатка. Три одинаковых сбоя в разных местах — системная проблема. Ищите не «где криво», а «почему оно так устроено, что неизбежно становится криво».
В моем примере: В документации DirectAdmin несколько раз встречается ситуация: команда проведена, но не сказано, как должен выглядеть успешный вывод и что делать, если что-то пошло не так. Это паттерн «я знаю, ты знаешь» — автор исходит из того, что читатель уже в контексте, и пропускает важные пояснения.
Шаг 5. Посчитать цену текущего решения
Сколько времени теряет пользователь? Сколько денег теряет бизнес? 48 минут вместо 5 — это 860% лишнего времени. Цифры убеждают лучше любых слов.
В моем примере: В кейсе с AmoCRM разработчик тратит 48 минут вместо 5 — 860% лишнего времени. Оценочные потери — от 275к до 3+ млн рублей. ВАЖНО: Цифры выше — это оценочный метод, иллюстрация подхода. Для расчета точных данных конкретной компании нужны: зарплаты сотрудников, реальное количество интеграций и средний чек. Но даже гипотетическая оценка помогает увидеть масштаб проблемы и начать разговор.
Шаг 6. Спроектировать улучшение
Ничего не стоит сказать «тут плохо». Инженерная культура — когда вы не только нашли проблему, но и предложили, как её чинить. Скриншоты, схемы, примеры кода, план работ на следующий месяц — всё, что показывает: вы умеете не только копать, но и строить.
В моем примере: примеры макетов, текстов, тикеты, скрипты, любая конкретика, которая может быть оценена для воплощения в жизнь. Если не можете написать код — предложите концепцию, это тоже ценно.
Шаг 7. Упаковать в историю
Кейс — это не отчёт. Это рассказ: был пользователь, была проблема, я нашёл корень, посчитал цену, предложил решение. Истории запоминаются, а вот отчёты — нет.
В моем примере: предпочитаю упаковывать в 2 формата: подробности в документе и краткая выжимка с ключевыми идеями в слайдах.
Три истории, где эта методика сработала
Кейс №1. Bpium: Как переучить документацию думать как пользователь
Цифра-якорь: Рискну предположить, что 9 из 10 пользователей не найдут готовое решение.
Bpium — отечественная low-code платформа для переезда с Airtable и n8n. Мне было интересно: следуют ли создатели low-code продуктов своим же принципам? Ведь их документация — не приложение, а часть продукта. Она должна быть максимально понятной. Иначе какой смысл в low-code?
Выбираем сценарий: бизнес-пользователь хочет развернуть CRM за один день, используя только официальную документацию.
Проблема:
Документация Bpium построена вокруг функций: каталоги, поля, автоматизации. Но пользователь с задачей «внедрить CRM» приходит не за функциями, а за решением. Он вынужден сам собирать пазл из разрозненных разделов.
Сценарий, который по логике должен занимать 5–10 минут, растянулся из-за того, что путь к готовому решению оказался неочевидным.
Находка:
Спустя 40 минут активного поиска по сайту в разных разделах, нашелся полностью работающий шаблон CRM. Он лежал в подвале сайта, в разделе «Демо». Не было никакой связки с документацией. Вероятно, продукт быстро рос: сначала «Демо» было на виду, а потом переехало вниз, уступив место формам сбора лидов. В любом случае, для человека, который решает задачу сам, а не через отдел продаж — это неочевидная, но важная находка.
Пользователь, который ищет «как внедрить CRM», должен был:
-
Догадаться, что шаблон существует.
-
Найти его в неочевидном месте.
-
Только потом начать разбираться с каталогами и полями.
Это может быть очень сложно. Ценность low-code платформы — в скорости. Если пользователь тратит 40 минут на поиск готового шаблона, а не на его настройку, это убивает основной смысл продукта. Шансы, что он дойдет до решения, падают драматически
Решение:
Проектируем другую архитектуру — задаче-центричную:
-
Главная точка входа — «Решения» (Solutions): CRM, база знаний, портал клиента.
-
Внутри решения: сначала готовый шаблон, потом кастомизация, потом углублённые руководства.
-
Разрозненные технические статьи переупакованы в «рецепты» и привязаны к конкретным задачам.
На схеме не останавливаемся. Раскладываем это в технический план: структура папок в репозитории /docs/, примеры переработки контента «было/стало», 5 тикетов в Jira на первый месяц рефакторинга.
Пример одного тикета:
Заголовок: Перенести готовый шаблон CRM из раздела «Демо» в раздел «Быстрый старт»
Описание: Сейчас пользователь, который хочет внедрить CRM, тратит 40+ минут на поиски готового решения. При этом шаблон уже существует, но лежит в подвале сайта, в разделе «Демо», без единой ссылки из документации.
Что сделать:
Добавить раздел «Быстрый старт» или «Готовые решения» в навигацию документации.
Перенести туда шаблон CRM.
Поставить перекрёстные ссылки из основного руководства.
Ожидаемый эффект: снижение времени первого онбординга с 40+ минут до 5–10 минут.
Почему именно на первый месяц? Потому что я знаю, что ресурсы всегда ограничены, и есть свои сложности и причины, почему нельзя сделать "идеально" прямо сейчас. Так как я не могу знать всех ограничений, с которыми сейчас сталкивается продукт, предлагаю план исходя из того, что мне кажется наименее сложным и затратным на данный момент. Будет здорово, если команда мне ответит, тогда сможем спланировать ресурсы вместе.
Чему научил этот кейс:
Хорошая информационная архитектура — это не про красоту. Это про скорость онбординга и конверсию. В идеале, лучше говорить с командой на их языке: структура, тикеты, примеры кода или шаблоны, на основании которых сразу можно внедрить решение для себя и кастомизировать позже.
Bpium - полная методология и детали
• Слайды с выжимкой
• Полный аудит с тикетами и архитектурой
Кейс №2. DirectAdmin: Пять системных проблем в одной инструкции
Цифра-якорь: 80% шагов — чистая импровизация.
За год работы в хостинговой компании я наслушалась страшилок про миграцию. Клиенты жалуются на дороговизну cPanel, но продолжают на ней сидеть. Почему? Потому что переезд страшнее переплаты.
Я решила проверить, как основной конкурент — DirectAdmin — помогает своим пользователям мигрировать с cPanel.
Сценарий: Администратору нужно перенести аккаунт (файлы, БД, почту, DNS, .htaccess) с cPanel на DirectAdmin. У него есть только официальное руководство «Migration from cPanel».
Проблема:
Идем этот путь шаг за шагом и обнаруживаем не разрозненные ошибки, а пять системных проблем, которые делают миграцию стресс-тестом.
Для решения четвертой проблемы, можно сделать яркое примечание в тексте, к��торое сразу бросается в глаза. Ниже визуальный макет, который я предлагаю:
Цена:
Для этого кейса ввожу такое понятие как коэффициент импровизации — долю шагов, где администратор вынужден догадываться или искать информацию самостоятельно. Это не математический показатель, а скорее, метафора ощущения.
-
Планирование: 80% импровизации
-
Файлы: 50%
-
Базы данных: 90%
-
Почта: 100% (инструкций просто нет)
-
DNS: 100% (аналогично почте)
Общий коэффициент: 80%.
Получается, что большую часть времени администратор, следующий официальному руководству, действует вслепую.
Решение:
Проектируем архитектуру, которая закрывает все пять проблем:
-
Структура Plan → Do → Check: чек-листы подготовки, пошаговое выполнение, валидация результата — закрывает проблему №1 (нет фазы планирования) и добавляет контроль вместо импровизации.
-
Визуальный мост CLI → GUI: для каждой ключевой команды — скриншот и точный путь в панели, где виден результат. Это ответ на проблему №2 (разрыв между CLI и GUI) — администратор видит, что происходит.
-
Глоссарий в начале гайда: «аккаунт», «пользователь», «домен» — решает проблему №3 (путаница в терминах).
-
Блоки Risk Mitigation вместо пассивных предупреждений: вот риск, вот как проверить, вот что делать. Это превращает «чёрные ящики» (проблема №4) в прозрачные и контролируемые шаги.
-
Скрипты-помощники: Account Auditor (оценка объёма работ) и Post-Migration Validator (проверка целостности) — связывают разрозненные инструкции (проблема №5) в единый понятный процесс. Скрипты не заменяют документацию, а дополняют ее, давая элементы контроля и валидации.
Чему научил этот кейс:
Документация — это система, которая либо даёт пользователю контроль, либо отнимает его. И сложные сценарии требуют не только текста, но и инструментов. Скрипты, чек-листы, валидаторы — это тоже документация.
DirectAdmin - полная методология и детали
• Слайды с выжимкой
• Полный аудит с 5 проблемами
Кейс №3. AmoCRM: 860% лишнего времени и миллионные потери
Цифра-якорь: от 275 тысяч до 3+ миллионов рублей в год.
(цифры основаны на расчете средней ставки в час разработчика по внедрению. Исследование проводилось на публично доступной документации, без использования демо-доступа, методика расчета и детали - в подробном аудите.)
CRM — моя любовь. Я пережила внедрение HubSpot и знаю, как хорошая CRM может вытащить бизнес, — и как больно, когда она внедряется через пень-колоду.
Мне стало интересно, как с этим у отечественных игроков. Я взяла AmoCRM и сценарий, который должен быть типовым: форма обратной связи на сайте + квалификация лидов.
Сценарий с двумя ролями:
-
У нас есть CEO — выбирает CRM и хочет убедиться, что она решит его задачу.
-
И есть Разработчик — получает задачу «сделай, чтобы лиды из формы попадали в CRM и квалифицировались».
Проблема:
Проходим путь обоих персонажей и замеряем время.
CEO должен найти подтверждение, что сценарий работает. На сайте нет ни одного релевантного кейса. Только общие слова. Результат: CEO не может принять решение и скидывает задачу разработчику «разберись сам».
Ниже визуализация решения, которая снимает первый разрыв и делает ту самую связку между бизнесом и разработчиком через наличие кейса, калькулятора затрат и блока "Для разработчиков", откуда можно отправить информацию на почту:
Однако, без этого решения разработчик идёт в документацию. И там начинаются сложности. В примере предлагается создать две сделки. Та, которая нужна — это вторая, в категории неразобранного. Но разработчик пока еще об этом не знает.
Вместо 5 минут он тратит 48, потому что:
-
Документация ведёт в неправильный эндпоинт (в «сделки» вместо «неразобранного»).
-
Правильное решение спрятано на три уровня вложенности.
-
Примеры кода смешивают два разных сценария без пояснений.
Цена:
Считаем процент трудозатрат:
48 минут / 5 минут × 100% = 860% лишнего времени
Дальше — простая арифметика.
-
Час разработчика по средней ставке (условно): 2 500–3 000 рублей.
-
Типовая интеграция занимает 48 минут вместо 5. Разница — 43 минуты.
-
Предположим, что в компании делают 5 таких интеграций в неделю, это 110 часов переработок в год.
110 часов × 2 500 ₽ = 275 000 ₽ в год — только на переработках команды, без учёта простоев и демотивации.
А теперь представим, гипотетически, что из-за этого барьера мы теряем всего 5% потенциальных клиентов, которые передумали внедрять интеграцию или выбрали другую CRM.
-
Одна интеграция приносит вендору в среднем 200 000 рублей LTV.
-
Если таких клиентов хотя бы 15 в год — это ещё 3 млн рублей упущенной выручки.
Итого: от 275 тысяч до 3+ миллионов рублей в год — цена плохой документации на одном сценарии. Это консервативная оценка.
Решение:
Внедряем три прототипа:
-
Раздел со сценариями на стартовой странице документации. Чтобы CEO и разработчик сразу видели: «да, вот именно наша задача, идём сюда».
-
Визуальные маркеры «для публичных / для частных интеграций» в примерах кода.
-
Перекрёстные ссылки между связанными эндпоинтами и предупреждения в местах, где легко ошибиться.
Чему научил этот кейс:
Документацию можно и нужно измерять в часах и деньгах. 860% лишнего времени и до 3+ миллионов потерь в год — хорошее напоминание, что документация — это не просто "текстики для пользователей", а прямой фактор выручки.
AmoCRM - полная методология и детали
• Слайды с выжимкой
• Полный аудит с расчётами и схемами
Почему это работает
Это не целенаправленный подбор портфолио под вакансию. Я просто делала то, что мне интересно: исследовала, как знания о продукте доходят до пользователя.
А потом оказалось, что это и есть портфолио. Только живое и с цифрами. Это работает лучше любых тестовых.
Сталкивались с похожими разрывами? Может, есть любимая боль или, наоборот, удачное решение? Делитесь в комментариях — соберём коллекцию живых кейсов.
Автор: Flannery_Gold
