Muse Group, компания за MuseScore и Ultimate Guitar, всерьёз рассматривала полноценный облачный нотный редактор: рынок, казалось, просил именно его. От большой и дорогой разработки удержали интервью с музыкантами. На этом примере хорошо видно, как устроен метод, который в компании называют «живым контактом», и почему дашборд такую ошибку не поймал бы.
Дашборд не видит причины отказа
Продуктовая аналитика отвечает на вопрос «где»: на каком экране человек закрыл приложение, после какого шага не оформил подписку, сколько длилась операция. Но цифра не объясняет, почему действие имело такой смысл для пользователя. Он мог бросить сценарий из-за ошибки интерфейса, срочного отвлечения на репетицию или неверно сформулированной задачи. В музыкальном софте один и тот же клик для школьника, концертного аранжировщика и издателя нот означает совершенно разные намерения, и по логам их не отличить.
В интервью с основателем Muse Group Евгением Найдёновым UX-подход компании описан как методология «живого контакта». В её основе лежит разбор недавнего рабочего эпизода (мнение о макете или рейтинг фичи здесь почти ничего не дают): что человек пытался сделать, в какой обстановке, с какими материалами, где потерял время и чем заменил продукт. Такой разговор возвращает контекст, который исчезает в событиях аналитической системы.
Метрики при этом никто не отменяет. Логи показывают масштаб паттерна, частотность поведения и эффект релиза; разговор помогает правильно назвать проблему до того, как она превратится в дорожную карту. Такой порядок защищает Muse Group от дорогой ловушки: строить большую фичу под громкий рыночный запрос, когда пользователю на деле требовалось короткое действие в конкретный момент работы.
Живой контакт начинается там, где кончается воронка
Аналитика фиксирует следы решений, а UX-исследователь восстанавливает сами решения. Недостаточно спросить музыканта, нравится ли ему редактор или нужен ли облачный сервис: ответ станет рационализацией, хотя в работе человек действовал по привычке, в спешке или под влиянием ограничений, о которых сам не задумывался.
Разговор о последнем конкретном случае устроен иначе. Исследователь просит показать партитуру, письмо коллеги, фото с телефона, экспортированный PDF или заметки и проходит последовательность действий вместе с человеком. Где возникла правка? Почему её нельзя было сделать позже? Кто ждал файл? Можно ли было открыть ноутбук? Чем пришлось пожертвовать: точностью, скоростью, качеством вёрстки или спокойствием перед выступлением? Наблюдаемые детали ценнее любых деклараций о желаемой фиче.
Три вопроса, которые звучат разумно, но портят интервью
Одни и те же формулировки раз за разом уводят разговор в комплименты. Ниже показано, чем их заменить, чтобы получить эпизод поведения, а не прогноз.
- «Нравится ли вам редактор / нужна ли такая фича?»: человек оценивает вашу идею, а не свою работу, и из вежливости достраивает удобный ответ. Спросите вместо этого: «Покажите последний файл, который правили в спешке: что и почему пришлось менять?»
- «Пользовались бы вы облачной версией?»: это прогноз о будущем в идеальных условиях, а не факт поведения. Спросите вместо этого: «Когда вы в последний раз открывали чужой компьютер или телефон ради правки: что тогда мешало?»
- «Какая фича вам важнее?»: ответ смешивает роли (ученик, аранжировщик, издатель) и уводит в список фич. Спросите вместо этого: «Где в последний раз задача и инструмент столкнулись: на каком шаге и с какими материалами?»
Руководитель UX-направления Muse Group Гоша строит исследования вокруг такой беседы, а не анкеты с заданными ответами. Это требует дисциплины: рекрутинга по роли и сценарию, единого интервью-гайда, фиксации артефактов, командного разбора записей и проверки гипотез следующими сессиями. Без такой рамки свободный разговор превращается в коллекцию ярких историй, в которых интервьюер слышит подтверждение собственной идеи.
Пользователь редко формулирует проблему языком продуктовой команды. Композитор не попросит «режим локального редактирования с низкой когнитивной нагрузкой», а скажет: «Мне прислали замечание перед посадкой в поезд, я хотел быстро поменять четыре такта и отправить файл». Первая формулировка ведёт прямо к проектированию фичи, вторая описывает обстоятельство, по которому и стоит оценивать уместность решения.
Запрос на облако может скрывать потребность в правке
В истории с браузерным нотным редактором такой сдвиг оптики сэкономил компании целую разработку. Рыночный сигнал выглядел очевидно: профессионалам нужен полноценный облачный аналог настольного приложения, с коллаборацией, доступом отовсюду, единым хранением и работой прямо в браузере. Но такой редактор потребовал бы большой команды, долгой разработки и болезненных компромиссов по скорости, точности нотации и совместимости.
Интервью изменили саму постановку задачи. Профессионалы не стремились переносить в браузер весь производственный цикл: для глубокой работы у них уже были привычные инструменты, шаблоны, библиотеки и техника, которой они доверяют. Проблема возникала на стыке: срочно просмотреть присланный материал, внести малую правку, оставить комментарий, отреагировать с телефона или чужого компьютера. Им нужен был лёгкий инструмент для короткого эпизода, а не ещё одна тяжёлая облачная рабочая станция.
Этот разворот важнее интерфейса. Рыночный запрос часто описывает форму, увиденную у других сервисов; интервью отделяет её от работы, ради которой она якобы нужна. Услышав «сделайте облачный редактор», команда сравнивает себя с конкурентами по списку функций. Услышав историю о правке между репетицией и дорогой, она смотрит уже на скорость входа, сохранность документа, понятную версию файла и отсутствие лишних шагов.
По словам Найдёнова, отказ от ненужной большой разработки сберёг компании значительные средства. В отчёте о выпущенных фичах эта экономия почти незаметна: нет релиза и, возможно, красивого графика новой метрики. Зато остаётся ресурс для задач, где продукт становится частью реального процесса. Так исследование перестаёт быть декоративным этапом перед дизайном: оно позволяет не строить то, что логично лишь на слайде.
Музыкант, ученик и издатель говорят разными словами
Пользователи у Muse Group к тому же очень разные. MuseScore, Ultimate Guitar и сервисы вокруг музыкальной практики связывают обучение, любительское исполнение, профессиональную нотацию, права на контент и распространение материалов. В такой среде нельзя считать ориентиром «среднего пользователя». Массовый пользователь может создавать будущую привычку рынка, но его день не похож на день человека, готовящего партитуру для ансамбля или очищающего запись перед студийной сессией.
MuseScore хорошо иллюстрирует эту разницу. Найдёнов говорил, что в США девять из десяти школьников, работающих с нотным редактором, знакомы с MuseScore. Привычка действует снизу вверх: ученик приносит знакомый инструмент в колледж, студию, ансамбль и позднее в профессию. Это не значит, что профессиональные требования нужно подчинить школьному сценарию; факт показывает лишь, где формируется будущий стандарт ожиданий и почему низкий порог входа меняет баланс рынка.
С преподавателем разбирают урок: раздачу материала, проверку заданий, исправление ошибок и объяснение нотации. С аранжировщиком обсуждают согласование версий, экспорт для исполнителей и дедлайны перед концертом. С владельцем прав выясняют происхождение табулатуры, территорию лицензии, атрибуцию автора и условия публикации. Вопрос «какая фича вам нужна?» для всех трёх ролей слишком груб; точнее выяснять, где возник последний конфликт между задачей и инструментом.
В свободном ПО исследование затрагивает ещё и отношения с сообществом. MuseScore вырос из FOSS-культуры, где участники вкладывают в код не только рабочие часы, но и профессиональную идентичность. Найдёнов вспоминал конфликт двух разработчиков вокруг пул-реквеста на GitHub, который в Германии дошёл до ножевого ранения. Это крайний и трагический эпизод, но он показывает, что изменения продукта и процесса нельзя сводить к абстрактной «реакции аудитории»: для части участников код был личным делом, а не нейтральной дискуссией.
Доверие проверяют не количеством интервью
При таком разбросе ролей число созвонов почти ничего не говорит о качестве исследования. Десять однотипных разговоров с одной ролью могут дать ложную уверенность, а три интервью в разных условиях работы способны обнаружить критическое различие. Сильный результат проверяют по тому, изменил ли он решение команды и может ли она объяснить причину наблюдаемым сценарием, а не вырванной из контекста цитатой.
Для команды полезны четыре контрольных вопроса:
- описан ли недавний эпизод поведения, а не общее мнение о продукте;
- видела ли команда рабочие артефакты: файл, устройство, переписку, версию документа или обходной путь;
- отделена ли проблема пользователя от предложенного им рецепта;
- можно ли проверить гипотезу прототипом, журналом событий или повторным интервью с той же ролью.
Такая проверка защищает и от харизматичного собеседника. Опытный профессионал может убедительно формулировать позицию, но его процесс бывает уникальным. Исследователь не обязан превращать каждую историю в фичу: он сопоставляет её с другими эпизодами, определяет границы применимости и ищет повторяющееся: обстоятельство, боль, обходной манёвр или язык описания трудности.
Телеметрия в MuseScore показывает другую грань доверия. Её внедрение вызвало резкую реакцию части разработчиков: сбор данных называли слежкой. Напряжение сняли не аргументом «метрики нужны бизнесу», а прозрачностью и готовностью обсуждать правила. Урок для исследований отсюда прямой: нельзя скрытно собирать поведение и ожидать честного участия. Пользователь и сообщество должны понимать, что собирают, зачем, кто имеет доступ и как данные влияют на продуктовые решения.
Рост экосистемы меняет цену ошибки
На ранней стадии команда может поговорить с несколькими знакомыми пользователями. Когда группа растёт, а сервисы связаны учётной записью, контентом и подпиской, импровизация перестаёт работать. Интервью начинают противоречить друг другу, выводы теряют автора, соседние команды повторяют одну и ту же проверку. Нужна инфраструктура знаний, в которой контекст решения не исчезает сразу после встречи.
В Muse Group она связана с единым источником истины в Confluence и асинхронной коммуникацией вместо статусных совещаний. Для UX это значит, что запись интервью, краткая карта сценария, гипотеза, решение и результат проверки должны храниться рядом. Иначе уже через два месяца непонятно, почему команда отказалась от фичи или выбрала именно такой компромисс.
Масштаб повышает и цену неверной интерпретации данных. OMR-система Muse Group обрабатывает от 3 до 25 тысяч оцифровок нот в день и формирует закрытый датасет. Недостаточно спросить, нравится ли распознавание: качество нужно разбирать на конкретных рукописях, сканах, издательских макетах и ошибках разметки. Порядок в правах и метаданных, который компания выстраивала для Ultimate Guitar через десятки тысяч лицензионных соглашений, часть той же среды: без чистого происхождения контента нельзя надёжно обучать модели и честно объяснять, откуда взялся результат.
Рост меняет и роль исследователя. Он не может быть единственным, кто «знает пользователя»: его задача в том, чтобы научить дизайнеров, менеджеров и инженеров слышать контекст, хранить доказательства и формулировать проверяемые вопросы. Иначе организация будет ждать очереди к UX-отделу вместо того, чтобы принимать решения быстрее.
Эмпатия не заменяет продуктовую дисциплину
«Живой контакт» не означает, что продукт исполняет просьбу каждого собеседника. Пользователь видит локальную проблему и обычно предлагает локальный способ её снять. Команда же отвечает за архитектуру, экономику, безопасность, права на контент и последствия для других ролей. Уважение к собеседнику выражается в понимании его ситуации и честном объяснении границ, и безусловное согласие для этого не требуется.
Это видно в позиции Muse Group по генеративной музыке. Найдёнов говорил, что 75-80% музыкантов из аудитории компании считают генерацию музыки лишённой авторства и смысла. Компания не строит стратегию вокруг замены творца алгоритмом, хотя развивает ИИ-инструменты для другой работы: разделения стемов, шумоподавления, подбора аппликатуры и переложения в заданный стиль. Исследование помогает провести границу между автоматизацией рутины и захватом авторского решения.
Зрелая позиция такова: интервью формируют проблему, аналитика проверяет её распространённость и эффект решения, а стратегия определяет, стоит ли решать её именно этой компании. Дашборд без контакта с людьми даёт точные ответы на неверный вопрос; эмпатия без проверки ведёт к дорогой разработке ради единичного случая.
Как соединить интервью с проверкой поведения
Самое ценное в методологии Muse Group связано с отказами: команда расстаётся с дорогой идеей, если реальная работа пользователя не подтверждает гипотезу. Такой отказ нередко полезнее очередной фичи, потому что сохраняет внимание, деньги и доверие аудитории.
Для музыкальных продуктов эта дисциплина особенно важна: здесь пересекаются образование, творческая идентичность, профессиональный труд, авторское право и машинная обработка контента. Технология может снять рутину, но не должна стирать автора из процесса. Живой разговор возвращает в продукт человека с задачей, сроком, привычками и ответственностью за результат.
История с облачным нотным редактором, с которой начинается этот разбор, хорошо показывает, чего стоит такой разговор. Рынок, казалось, просил именно его, и большая разработка выглядела очевидным шагом, пока интервью с музыкантами её не остановили. Для фич поменьше механизм тот же, только масштаб скромнее: несколько недавних рабочих эпизодов у разных ролей, где фича сняла бы реальную трудность, и сверка по логам, насколько такие эпизоды часты. Когда их не находится, эффектная идея ждёт, пока контекст и данные не сойдутся.