BILLmanager — биллинговая система от ISPsystem. Её клиенты — компании, которые продают хостинг, лицензии на ПО, VPS, VDS, SSL-сертификаты. Через BILLmanager они ведут учёт транзакций и клиентов, подключают платёжные шлюзы, настраивают каталог услуг и тарифов, запускают промо-коды.
Предприниматели, которые в прошлом сами администрировали серверы. Они знают, что такое виртуальная машина и зачем нужен SSL — но уже давно смотрят в сторону бизнеса, а не в командную строку. А также клиенты предпринимателей. Мужская аудитория — примерно две трети, женская — треть.

Директор разозлился, проходя путь потенциального клиента — от знакомства с продуктом до запуска. После этого решили разобраться, что не так, и запустили исследование.
Путь клиента в BILLmanager длинный. От первого знакомства с продуктом до момента, когда он наконец работает — десять шагов:
Проблемы, как показало исследование, были не в одном месте. Они были везде.
Я спланировала исследование: описала этапы CJM, сформулировала вопросы для интервью, проинструктировала команду, как собирать информацию. Дальше — в поле. Каждое интервью длилось 1,5–2 часа.
Нас интересовал опыт человека, который только знакомится с продуктом. Поэтому искали предпринимателей-технарей: разбираются и в бизнесе, и в технике, но с BILLmanager раньше не работали. Исключили специалистов техподдержки, программистов и пресейл-инженеров ISPsystem — их опыт с продуктом был слишком плотным для этой задачи.
Для чистоты эксперимента добавили несколько человек без технического бэкграунда — интересно было посмотреть, насколько интерфейс и документация окажутся понятны и им. Спойлер: эта группа людей больше всех опиралась на документацию.

Проблемы нашли во всех четырёх точках касания: лендинг, документация, интерфейс, командная строка. Всего их было 53. Отчёты о найденных проблемах на лендинге, документации и CLI передали ответственным за эти точки подразделениям для дальнейшего разбора и устранения.
По итогам исследования я приоритизировала проблемные места и договорилась с менеджером продукта о включении редизайнов в роадмап. В роадмап на 2023 год попали: первоначальная настройка, форма регистрации, настройка услуг, настройка тарифов, дашборд.
Логика была простая: первоначальная настройка — один из первых шагов до попадания в рабочий интерфейс. Человек ещё не видел продукт, ещё не понял, зачем он нужен — а уже получил семь шагов путаницы и угрозу про истекающую лицензию. Починить именно это место значило убрать барьер на входе в продукт.
Что нашлось в исследовании:
И весь этот путь растягивался на семь шагов, прежде чем человек попадал в рабочий интерфейс.
Я сформулировала концепцию будущего интерфейса: переосмыслить набор полей в визарде и тексты к ним. Понятные шаги, минимальный набор полей. К каждому полю — объяснение, зачем оно нужно и на что влияет. Кнопки «Далее» и «Назад». Прогресс заполнения виден. В конце — переход в интерфейс.
Команда сделала макеты. Я сделала ревью финальных решений.
Потом мы вернулись к тем же респондентам. Попросили прокликать прототип, сравнить с тем, что было, и сказать честно.
Реакция была однозначной: намного лучше. Визард понятнее, шаги понятнее, подписи понятнее. Про справку сказали — не нужна вообще. Дело оказалось не в оформлении справки. Она просто лишняя, когда сам визард объясняет, что и зачем.
Пока шло повторное тестирование, выяснилось, что часть полей тоже можно убрать. Сократили ещё раз. В итоге интерфейс вышел в продакшн.
Первоначальная настройка — один из первых шагов на пути потенциального клиента, где решается, останется ли он с продуктом дальше. Убрать путаницу здесь — значит защитить один из решающих моментов на пути клиента, ещё до того как он успел разочароваться. Форма регистрации, настройка услуг, тарифов и дашборд — тот же путь: за ними последовали свои редизайны.