Привет! Эта статья про ценность исследований клиентского / пользовательского* опыта в таких «сложных» продуктах, как API, модули для 1С и других интеграционных решениях.
По опыту исследователей Контура, команды таких продуктов могут столкнуться с сомнениями в необходимости исследований, с вопросами и даже страхами при их организации и планировании. Это нормально. Исследования в таких специфических средах могут пугать трудоёмкостью, дороговизной или барьерами при внедрении изменений.
Мы собрали 9 барьеров, препятствующих организации и проведению исследований, на каждый барьер предложили решение, а также привели примеры из практики**.
Если ты занимаешься развитием или разработкой интеграционного продукта (например, модуль для 1С) — эта статья для тебя. Надеемся, что приведённые кейсы и способы их решений помогут в твоей работе. Мы понимаем, что наш опыт — не исчерпывающий. Если в твоём продукте по-другому, расскажи в комментариях, мы готовы к дискуссии.
*В статье термины «клиентский» и «пользовательский» опыт используются в качестве синонимов для упрощения рассказа.
**Приведённые примеры реальны, поэтому обезличены :)
Барьер 1. Продукт покупают — значит, проблем нет
Кейс |
Решение |
Команда, видя высокие показатели продаж, делает вывод, что проблем нет. Поэтому решает НЕ изучать пользовательский опыт и, как следствие, НЕ работать над его улучшением. |
Подсветить команде нарушенную причинно-следственную связь. Нельзя однозначно сказать, что есть связь между высоким уровнем продаж и отсутствием проблем в пользовательском опыте. Кроме того, продажа ещё не гарантирует продление использования сервиса. Покупка продукта — лишь начало сложного клиентского пути. Интеграционные решения требуют внедрения, настройки, тестирования и регулярных обновлений. Клиенты могут купить продукт, но при этом: - не внедрить решение из-за отсутствия готового бизнес-процесса; - столкнуться с техническими сложностями при настройке; - не увидеть ценности из-за ошибок на этапе внедрения; - столкнуться со значимыми проблемами в процессе использования продукта. Для того, чтобы оперативно узнавать о проблемах, важно исследовать клиентский путь. Это поможет ДО наступления срока продления эксплуатации (когда может быть уже поздно), выявить скрытые проблемы/барьеры в использовании продукта. Рекомендации по итогам исследования могут включать изменения в процессах внедрения, а не только в коде, это нормально и так же значимо, как и интерфейсные изменения. |
Пример из практики
Десктопный продукт. Запрос на исследование — собрать пожелания пользователей, выявить возможности дальнейшего развития функциональности продукта. Ожидание — список новых фичей.
Реальность — при рекрутинге выяснили, что большинство пользователей НЕ пользуется продуктом вообще, хотя показатели продаж были в норме.
Причины неиспользования:
не выделены средства на внедрение;
есть свои «костыли» для выполнения задачи, поэтому самостоятельное освоение откладывают.
Даже те, кто выделил средства на внедрение, не превратились в пользователей:
нет времени на встречи и обучение;
обучение прошли, но этого недостаточно, чтобы начать работу.
Результат: варианты развития функциональности исследования не появились, но выявили значимую для продукта проблему и пошли дорабатывать процесс внедрения.
Барьер 2. Это 1С! Пользователи приняли ограничения, мы НЕ можем влиять на их опыт
Кейс |
Решение |
Команда разработки модуля для 1С считает, что НЕ может в полной мере влиять на внешние инструменты типа 1С, поэтому нет смысла их исследовать. |
Подсветить команде, что мы можем улучшать пользовательский опыт другими инструментами: текстами в интерфейсе, обучающими материалами, новыми процессами. Пользовательский опыт сущ��ствует даже без визуального интерфейса. Устоявшиеся паттерны работы в учётных системах — не приговор. Исследования показывают, как их корректировать. Нужно заходить в исследование через изучение задач и процессов, не общаться с пользователем на языке проблем, а ставить целью исследования изучение процессов. Пользователи могут в силу привычки не осознавать проблемы, однако при анализе сценариев и бизнес-процессов мы можем самостоятельно найти «слабые места» и далее понимать, как их можно улучшать или автоматизировать. При этом улучшения НЕ всегда интерфейсные. Команда может влиять на UX (user experience) через: - улучшение документации, текстов в интерфейсе и подсказок; - оптимизацию бизнес-процессов клиента / предложение чёткого плана внедрения, активную помощь в адаптации к новому способу работы; - упрощение логики интеграции / работы в нашем решении. |
Пример из практики
В модуле для 1С сервиса X сделали рабочий стол. Таким образом со-настроили свои потребности с потребностями пользователя:
профит для команды — появляется пространство для коммуникации с пользователем, инструмент упорядочивания его пути и информирования об изменениях;
профит для пользователя — удовлетворена потребность в актуальной и нужной информации в одном месте («под рукой»).
Барьер 3. Пользователи могут сами дорабатывать сервис под свои потребности, зачем тогда нам что-то изучать и дорабатывать?
Кейс |
Решение |
При работе в модуле / использовании API пользователь на стороне клиента может запустить самостоятельную разработку/доработку и удовлетворить свои потребности. Команда считает, что в этой ситуации ей незачем изучать пользовательский опыт. |
Подсветить команде, что «может доработать» не равно «должен и будет дорабатывать» самостоятельно. Не все потребности индивидуальны и должны решаться кастомными доработками. Частотные сценарии или потенциально частотные подразумевают решение «из коробки». Упрощение сценария силами команды разработки позволит обеспечить доступность сервиса бОльшему числу клиентов и пользователей, повысить лояльность к компании и удовлетворённость продуктом. И, как следствие, позволит стать/остаться продукту лидером на рынке. Знание о пользовательских сценариях и потребностях позволит своевременно дорабатывать решение, а в случаях, когда доработка программы невозможна — создать подробные справочные материалы. Также важно понимать, что пользователь может испытывать сложности при работе с программой, но не осознавать, в чём именно проблема и как упростить сценарий. Мы владеем большей экспертизой и можем предложить более эффективные решения. |
Пример из практики
Модуль для 1С сервиса Х. Из-за непонятного интерфейса пользователи осуществляли поиск только с помощью определённых функций, о которых они знали, а другие (тоже нужные) — не использовали, так как интерфейс не подсказывал и не помогал пользователям решить их задачу.
Исследование помогло выявить пользовательские сценарии поиска и улучшить процесс навигации, что повысило скорость выполнения задач. Поиск — это основной сценарий пользователей. Он должен быть оптимальным «из коробки», несмотря на возможность дорабатывать сервис самостоятельно.
Барьер 4. С сервисом работают программисты, они НЕ пользователи
Кейс |
Решение |
Команда знает, что с решением работают технические специалисты, поэтому нет смысла исследовать их пользовательский опыт, у них достаточно компетенций, чтобы разобраться с любой программой самостоятельно. |
Да, пользователи с техническим бэкграундом могут быть более продвинутыми и во многом самостоятельно разбираться с особенностями программы. Но это не значит, что можно не учитывать эту аудиторию при разработке. У них тоже есть пользовательский опыт, с которым можно и нужно работать, и, по возможности, стремиться улучшать его. Как правило, у специалистов с техническим бэкграундом есть сформированные чёткие требования или ценные идеи по работе системы в части интеграции и безопасности, учитывающие технические ограничения. Мы можем изучать опыт таких пользователей для того, чтобы выяснить эти требования и ожидания, и поработать с ними. Речь идёт как о специалистах компаний клиентов, так и о внутренних пользователях компании разработчика (внедрение, техническая поддержка). Также технические специалисты компаний клиентов, как правило, знают, с какими проблемами/сложностями сталкиваются конечные пользователи продукта, так как они могут приходить к ним с вопросами. В некоторых случаях технические специалисты могут рассказать о проблемах конечных пользователей. Но это происходит не всегда. Мы встречали ситуации, когда технические специалисты считали пользователей некомпетентными и глупыми, поэтому не сообщали об их проблемах. В этом случае важно продолжить исследование и услышать информацию из первых уст. |
Пример из практики
Модуль для 1С сервиса Х. Добавили новый сценарий. С одной стороны, сценарий будут выполнять конечные пользователи — бухгалтеры — и необходимо учесть их опыт при реализации сценария в программе. С другой — настройкой сценария на стороне клиента будет заниматься не конечный пользователь, а технический специалист. Но важен опыт каждой роли. Для того, чтобы его учесть, в исследовании участвовали как бухгалтеры, так и технические специалисты.
В результате получили информацию и узнали пожелания как непосредственно к интерфейсу, так и по техническим доработкам.
Барьер 5. Если нет интерфейса, то и исследовать НЕ нужно
Кейс |
Решение |
У пользователей куплено API, то есть интерфейс относится к учётной системе клиента, а не к нашему продукту. Исследовать НЕ нужно. |
Интерфейс — это основной способ взаимодействия пользователя с системой. Но даже если команда разработки не отвечает за интерфейс, пользовательский опыт есть. Мы можем фокусироваться в исследовании в первую очередь на пользовательских сценариях (какие рабочие задачи выполняют, с какими сложностями сталкиваются при их выполнении). Такой фокус поможет понять рабочий контекст пользователя, тот путь, который пользователь проходит каждый день, в том числе, в программном решении, с которым настроена интеграция. Зная это, мы можем помочь ему на этом пути, лучше встроиться в его сценарий. Кроме того, пользовательский опыт начинается раньше, чем работа в интерфейсе, и на это мы тоже можем влиять. Процессы внедрения и настройки очень важны, без этих этапов пользовательский опыт может и не случиться (то есть, пользователь может и не дойти до основной задачи, на которую «нанимает продукт»). Мы можем определить, какие задачи пользователь решает до того, как начинает работать в сервисе, чтобы помочь ему легче и проще дойти до сервиса и начать работу в нём. |
Пример из практики
Коннекторы сервиса Х. Внедрение настраивает коннектор согласно бизнес-процессу компании. Для того, чтобы настроить коннектор, необходимо писать код в консольном окне, интерфейса нет. В ходе исследования выяснили, что новичкам-внедренцам было сложно вникать в процесс настройки и неудобно пользоваться существующим способом настройки (написание кода). В своём сценарии они копировали код у более опытных внедренцев и адаптировали его под конкретный кейс. Из-за неудобства представления информации иногда настройки получались некорректными, приходилось переписывать код. Эту проблему удалось решить визуализацией настроек. Сделали интерфейс, благодаря которому новичкам-внедренцам стало легче вникать в процесс и ориентироваться в нём.
Барьер 6. Не понятно, кто пользователь, к кому с какими вопросами идти
Кейс |
Решение |
Исследовать слишком сложно. Большое количество сотрудников работает в организации, не понятно кто пользователь и к кому с какими вопросами идти. |
Действительно, на старте может быть непонятно, к кому с какими вопросами идти и как это делать (смотри следующий барьер). Мы предлагаем отталкиваться от такой структуры функциональных ролей: Роль 1. Держатель бизнес-процесса. В компании точно есть сотрудник, который владеет знанием о бизнес-процессе в компании, знает, кто с каким решением работает, и даже может рассказать, какие задачи выполняют коллеги. Идём к нему для того, чтобы понять процесс: кто работает в продукте, какие задачи выполняет. Роль 2. Разработчик. Сотрудник, который занимается настройкой решения. Обычно это IT, технический специалист (может быть на аутсорсе). Идём к нему, если важно узнать про техническую составляющую. Роль 3. Конечный пользователь. Сотрудник, который непосредственно выполняет ключевые задачи в решении. Идём к нему, если важно оценить удобство работы в системе, понять, какие задачи выполняет пользователь и как это делает. Также можно выяснить ��убъективную оценку скорости работы модуля и бесшовность рабочего сценария. |
Пример из практики
Модуль для 1С сервиса X. Пользователей модуля для исследования искали через держателя бизнес-процесса. Он рассказывал о том, кто, в каких решениях и (частично) как работает и соединял команду с конечным пользователем. Для того, чтобы выйти на держателя бизнес-процесса, организовали рекрутинг через персональных менеджеров.
Барьер 7. Не понятно, как выстроить коммуникацию с пользователем из-за сложного контекста
Кейс |
Решение |
Исследовать слишком сложно. Большое количество сотрудников работает в организации, каждый говорит на своём языке. Не понятно, как выстроить эффективную коммуникацию. |
Действительно, для успешной коммуникации необходимо говорить на языке пользователя. Для того, чтобы коммуникация состоялась, предлагаем по-разному готовиться ко встречам с выделенными в предыдущем барьере ролями. Роль 1. Держатель бизнес-процесса: - задаём вопросы о процессе, организационной составляющей работы; - для того, чтобы говорить с держателем БП, мы должны хорошо понимать задачи, которые выполняет интеграционное решение (знать продукт); Роль 2. Разработчик: - задаём вопросы о технической составляющей; - задаём вопросы о тех сложностях, с которыми к нему обращаются конечные пользователи организации; - важно понимать технические термины для того, чтобы у информанта возникло доверие и диалог состоялся. Лучше брать на встречу кого-то из команды с бОльшим техническим контекстом; Роль 3. Конечный пользователь: - отталкиваемся от задач, которые выполняет пользователь. Просим рассказать/показать, как он это делает; - вопросы об изменении бизнес-процесса не задаём, так как пользователь на них не влияет. Также нужно продумать, как модерировать саму встречу. Важно не уйти в помощь пользователям, чтобы не решать локальные проблемы. Обозначить на старте, что все вопросы мы выслушаем, но после интервью. Или создадим отдельную встречу, где поможем разобраться с существующими проблемами. Это может делать не разработка, а поддержка или внедрение. |
Пример из практики
Модуль для 1С сервиса X. На интервью с пользователями ходили вместе с методологом команды, которая хорошо знала продукт, его техническую составляющую. Исследователь задавал вопросы по гайду, методолог давала технические комментарии и задавала уточняющие вопросы.
Барьер 8. Не понятно, как выстроить коммуникацию с пользователем, так как есть инфраструктурные ограничения
Кейс |
Решение |
Пользователи есть, но как до них «дотянуться» с вопросами — не понятно. |
Да, у нас действительно ограничены возможности по взаимодействию в интерфейсе. Например, в модуле низкая конверсия на опросы и нужно обновление для их доставки. А в API-решения интерфейса для вывода опросов и вовсе нет. Да, мы работаем с неоднородным полем, то есть в один и тот же момент времени разные пользователи могут взаимодействовать с разным интерфейсом (версии, конфигурации). Но мы не бессильны: - мы можем найти персонализированный подход к пользователю, зная, какие роли работают в решении и по каким каналам получают информацию — звонки, почта, мессенджеры, уведомления на устройства типа ТСД; - мы должны иметь на руках все карты: знать хронологию развития версий, иметь под рукой визуал их интерфейсов и, наконец, просто смелость напроситься на экран пользователя и увидеть своими глазами. Во многих исследованиях без наблюдения никак; - мы знаем о пользователях больше, чем кажется. Всё, что знаем (версия, метрики активности, ошибок и тому подобное) можем не спрашивать. |
Пример из практики
ПО для специального устройства, сканирующего коды маркировки. Когда нам нужно мнение сотрудников склада, мы не звоним сисадмину и не пишем на почту бухгалтеру. Мы шлём свои вопросы или уведомления прямо в интерфейс специального устройства. Во всех непонятных ситуациях мы просто звоним пользователям, оказывается, они нередко совсем не против поболтать. Чтобы найти пользователя, которому «больше всего надо», берём контакты из обращений в поддержку.
Барьер 9. Слишком много ресурсов требуется для того, чтобы организовать такое исследование
Кейс |
Решение |
Интеграционные решения отличаются от веба, они сложнее. Как следствие, для того, чтобы провести исследование, необходима длительная и сложная подготовка. Проще не исследовать. |
Действительно, на старте может потребоваться больше ресурсов для погружения исследователя в контекст работы системы, изучение версий, локальную установку решения и так далее. Но мы рекомендуем не скупиться на стартовых инвестициях. Вложения бОльших ресурсов в сравнении с исследованиями веба могут потребоваться: - на старте исследования. Здесь необходимо подключать к подготовке владеющих экспертизой роли (аналитика или разработчика). Чаще всего это нужно только в начале работы и дальнейшие исследования потребуют меньшее включение; - при приглашении пользователей участвовать в исследовании. Пользователи могут быть не очень мотивированы участвовать, а значит, потребуется ресурс на дополнительную мотивацию в виде умелого рекрута или вознаграждений. Это нормальная практика. В некоторых исследованиях веба рекрутинг иногда может быть даже сложнее. Само исследование (за рамками подготовки), как правило, занимает столько же времени, как в вебе, и конкретные цифры зависят от задачи и методов. Обычно такие инвестиции окупаются так как цена ошибки в разработке выше, чем на этапе исследования. |
Пример из практики
Модуль для 1С сервиса X. Исследователь — часть команды, но н�� сфокусирован на модуле. В первый раз исследователю показали, как работает модуль, дали справочные материалы и установили систему. Далее такое тотальное погружение не требуется, исследователь берет задачи и изучает ту часть системы, по которой проводит исследование.
Резюме
Спасибо, что дочитал до конца! Это 9 барьеров для проведения пользовательских исследований в интеграционных решениях, которые мы выделили на основе нашего опыта, и предложили способы их преодоления:
Продукт покупают, значит проблем нет → не факт, важно убедиться, что проблем действительно нет. В практике есть контрпримеры, когда продукт был куплен, но из-за сложностей интеграции им не пользовались;
Это 1С! Пользователи приняли ограничения, мы не можем влиять на их опыт → даже если интерфейсно мы не можем облегчить пользовательский сценарий, мы можем влиять на процесс работы с помощью инструкций, подсказок, обучения и других материалов;
Пользователи могут сами дорабатывать сервис под свои потребности, зачем тогда нам что-то изучать и дорабатывать → мы должны предоставить оптимальное решение «из коробки». Закрытие частотных сценариев и потребностей позволит оставаться лидерами на рынке в условиях конкуренции;
С программой работают программисты, они не пользователи → технические специалисты — пользователи со своими рабочими задачами, сценариями. Учёт потребностей любой роли, которая работает с продуктом — это проявление клиентоцентричного подхода к разработке, которого придерживается Контур;
Если нет интерфейса, то и исследовать не нужно → мы можем влиять на процессы внедрения и настройки решения. Для этого нам важны знания о том, как пользователь проходит эти этапы, что ему важно в этих процессах. Кроме того, представление о пользовательском контексте и рабочих задачах поможет разрабатывать решение, которое будет бесшовно встраиваться в его работу;
Не понятно, кто пользователь, к кому с какими вопросами идти → мы можем опираться на схему разделения ролей (владелец бизнес-процесса, технический специалист, конечный пользователь), в зависимости от задачи идти к нужной роли;
Не понятно, как выстроить коммуникацию с пользователем, так как сложный контекст → использовать персонализированный подход, опираться на особенности каждой из ролей при выстраивании коммуникации;
Не понятно, как выстроить коммуникацию с пользователем, так как есть инфраструктурные ограничения → узнать, какими каналами коммуникации пользуются пользователи, и персонализировать коммуникацию;
Слишком много ресурсов требуется для того, чтобы организовать такое исследование → быть готовым вложиться на старте, в будущем это окупится.
Поделитесь, с какими барьерами сталкивались вы? Какие решения находили, чтобы их решить? Мы понимаем, что тема не исчерпана, нам интересно узнать о вашем опыте и продолжить диалог в комментариях к этой статье.
Больше про UX-исследования — в телеграм-канале Сдоба.