Если вы работаете UX-исследователем в B2B-направлении и ваши респонденты — разработчики, то скорее всего вам знакомо это ощущение: приходите поговорить про пользовательский опыт, а в итоге погружаетесь в дебри технической документации. Манифесты, подписи, Bundle, API, ключи, PEPK… Страшно? Немного. Но выжить — реально.

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

Для разработчиков мы развиваем RuStore Консоль и инструменты, которые упрощают публикацию, продвижение и аналитику приложений. Это не просто интерфейс, а целая экосистема с собственными задачами, процессами и логикой, которую нужно понимать, даже если у тебя нет CS-диплома.

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

Этот текст будет полезен как UX-исследователям без CS-бэкграунда, так и тем, кто работает с разработчиками бок о бок и помогает им строить качественные B2B-продукты.

Подготовка: вникнуть и не сломаться

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

Что помогает разгрести инфопоток и не сдаться:

• Читать техническую документацию и туториалы: внутренние гайды, Confluence, мануалы для пользователей, сторонние источники. Начинаю с разделов вроде «How it works» — там чаще всего логика, сценарии, схемы, а не синтаксис и переменные.

• Спрашивать у ИИ как школьник: «Объясни, что такое SDK простыми словами» — всегда сработает.

• Гуглить термины с припиской «for designers»: так чаще попадаешь на статьи с метафорами и визуализациями вместо формул и стека вызовов.

• Не зацикливаться на каждом непонятном слове: иногда всё становится ясно в контексте сценария.

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

• Задавать вопросы команде: продакт объяснит архитектуру, дизайнер — сценарий, тестировщик — где все ломается.

• Просить показать флоу: 15 минут демо часто эффективнее часа изучения документации.

• Изучать баг-репорты и фидбек: кладезь реальных проблем и терминов, которыми их описывают.

• Создавать тестовый аккаунт и нажимать всё подряд: так удается пройти большинство пользовательских сценариев и разобраться в последовательности действий.

• Готовить чек-лист простых вопросов (помогает даже без знания терминов):
  
  – «Как бы вы объяснили это джуну в первый рабочий день?»
  – «Что бы сделали иначе, если бы реализовывали фичу второй раз?»

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

Интервью: не притворяться экспертом

Вот где начинается настоящая проверка. Можно выучить, что такое SDK, но в моменте разговор всё равно уходит куда-то в wrapper, bundle или Gradle. Если просто кивать и молчать, надеясь «допонять потом», — инсайты проходят мимо.

Что помогает не потеряться:

• Вести bingo-лист терминов. Записывай все незнакомые слова, и уже после 3–5 интервью словарь станет шире, а новые термины начнут встречаться всё реже.

• Звать напарника. Позови на встречу тестировщика или продакта — если разговор уйдет в глубокую технику, они помогут подхватить.

• Признавать, что не инженер. Честность работает: «Я не разработчик, но хочу разобраться. Объясни попроще».

• Уточнять всё, что кажется важным. «А где вы это обычно проверяете?», «А когда это возникает?». Даже простые вопросы дают много контекста.

• Фокусироваться на действиях, а не терминах. Даже если не понял, что за bundle, из контекста всё равно понятно, что разработчик не смог загрузить приложение. А это уже UX-проблема.

• Задавать волшебный вопрос. «Вы делаете это по памяти или по документации?» — помогает оценить прозрачность сценария.

• Перефразировать и уточнять. «То есть у вас отдельный билд для Android TV, и он не проходит валидацию — правильно поняла?». Это и эмпатия, и проверка на понимание.

• Ссылаться на опыт других. «А прошлый респондент делал так. У вас по-другому?». Иногда это один и тот же процесс, но описанный другими словами.

Главное — не играть в эксперта, когда в чём-то не разбираешься. Непонимание — не слабость, а точка роста. UX-исследователь — это не тот, кто знает всё заранее, а тот, кто умеет слушать, задавать вопросы и вытаскивать суть. Даже из Gradle-сценариев.

Например, один из респондентов рассказывал, как подключал SDK для авторизации через сторонний сервис. Половину терминов я не поняла, но суть уловила: документация написана «для своих», примеров мало, часто приходилось гуглить, чтобы просто понять, с какой стороны подступиться. В итоге он потратил два дня, чтобы SDK заработал в приложении. Это и есть UX-проблема — когда интеграция превращается в квест, а не в понятную инструкцию с результатом.

Анализ: перевод с «разработческого» на UX-язык

Интервью прошло — теперь выжить бы на этапе расшифровки. В голове на повторе крутится цитата респондента:

«Круто было бы создать кастомный endpoint с логикой на Node.js – типа мини-бэкенда с embedded SQLite, поддержкой Webhook'ов, JWT-авторизацией и каким-нибудь rate limiting из коробки»

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

Вот как я подхожу к анализу:

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

• Обсуждаю проблемы с продактом и дизайнером. Где именно застрял пользователь? Где интерфейс не помог? Что можно изменить?

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

• Рисую флоу. Хотя бы на бумаге. Так видно, где у пользователя возникает фрустрация.

• Перевожу с тех-языка на UX-язык:
  
  – Слетает подпись → непонятно, что нужно использовать старый ключ.
  – SDK конфликтует → неясно, какую версию использовать, а документация не обновлена.

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

Как донести до команды и не потерять суть

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

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

Что помогает:

• Показать последствия, а не просто боль.
  Не «непонятно, как пройти валидацию», а «разработчик уже три дня не может обновить сборку».

• Показать сценарий глазами пользователя.
  Схема, скринкаст, комикс, таймлайн – всё, что помогает прожить этот путь вместе с пользователем.

• Давать цитаты, которые невозможно забыть.
  «Забыл ключ — всё, до свидания релиз».

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

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

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

Чтобы быть сильным UX-исследователем, не обязательно писать на Kotlin или сходу читать Gradle-файлы. Куда важнее — слышать, замечать, задавать правильные вопросы и подсвечивать то, что обычно теряется в техническом хаосе. Ты не просто наблюдаешь за процессом — ты строишь мост между UX и разработкой. Мост из внимания, ясности и искреннего желания разобраться.