Почта Mail.ru — наш самый известный продукт и ценнейший актив — к 2020 году сильно вырос. Сегодня это больше, чем просто почтовый сервис: в Почте можно отправлять и получать письма, организовывать свои планы на день, отслеживать штрафы и даже платить за ЖКХ.
У Почты появились не только новые функции, но и новые форматы. Важнейший из них — B2B-сервис, который входит в платформу Mail.ru для бизнеса. Это Корпоративная Почта Mail.ru, которая экономит место на ваших серверах, интегрируется с популярными антивирусами и поддерживает совместный доступ к почтовому ящику и задачам.
Чтобы получались актуальные и удобные продукты, важно создавать их в контакте с пользователями, изучая их потребности, привычки и паттерны поведения. Поэтому процесс развития большинства направлений Mail.ru Group сопровождают usability-исследования.
Зачем нам usability-тестирование?
Пользу любых исследований можно обозначить так: на любом шаге развития продукта они помогают понять, насколько текущее направление работы соотносится с ожиданиями пользователей. Будь то этап идеи или развитие продукта после релиза. В процессе usability-исследований мы общаемся с реальными пользователями — чтобы узнать, насколько понятно то, что мы уже сделали или собираемся сделать.
Получить подробные данные о привычках пользователей, их путях взаимодействия с продуктами и трудностях, с которыми они могут столкнуться, — работа, которая требует больших ресурсов. Основные задачи — наблюдать за тем, как пользователи справляются с интерфейсами продуктов или выяснять их потребности с помощью интервью или других методов. В Mail.ru Group этим занимается целая usability-лаборатория — UXLab. Она растет так быстро, что даже за время работы над этой статьей может пополниться новыми сотрудниками. Это здорово, потому что желание развивать продукты, ориентируясь на потребности и привычки пользователей, говорит о стратегическом мышлении менеджмента и всей команды в целом.
Есть два основных пути, по которым usability-аналитик может работать с командами внутри компании. В первом варианте взаимодействие строится в формате внутреннего агентства: исследователь принимает запросы от разных проектов и попеременно работает с ними. Второй случай — проект располагает собственным специалистом. Мы в UXLab Mail.ru Group перешли ко второму формату: сейчас каждый исследователь работает внутри определенной продуктовой команды.
Все продукты уникальны, поэтому для каждого отдельного случая подходит свой метод. Мы работаем преимущественно с качественными методами (интервью, фокус-группы, юзабилити-тестирования), но заходим и со стороны количественных данных. В особых случаях приходится применять особые методы. Сегодня — речь именно о таком кейсе.
Особенности продуктов для бизнеса
У интерфейса продуктов Mail.ru для бизнеса есть два «лица». Одно видит основная масса пользователей, которая использует продукты для бизнеса — Почту, Мессенджер и Файловое хранилище — в работе. Обычно это сотрудники компаний-партнеров, купившие наше коробочное решение. Второе видят те, кто настраивает и устанавливает пакет продуктов — системные администраторы и технические специалисты. Они работают с GUI административной панели, где можно настраивать доступы, формировать группы пользователей и совершать другие действия, необходимые для нормального функционирования продуктов.
С интерфейсом самих продуктов сталкивается гораздо большее количество пользователей, чем с панелью администратора. Поэтому может появиться соблазн посвятить основные ресурсы улучшению той части, которую видят чаще. В случае с Mail.ru для бизнеса всё не так однозначно. Если системный администратор будет совершать ошибки из-за того, что мы плохо организовали административную панель, в конечном счете пострадают все сотрудники компании.
Для того чтобы избежать такого развития событий, в течение последнего полугода мы провели серию крупных исследований, посвященных технической части продукта. Исследовать административную часть продуктов Mail.ru для бизнеса сложнее, чем тестировать обычные пользовательские интерфейсы. Ниже я расскажу об особенностях тестирования технической части B2B-продуктов и о том, как мы справились вызовами этой области.
Почему непросто тестировать сложный B2B-продукт
- Особый рекрутинг, непростые респонденты. Для исследований корпоративных продуктов Mail.ru мы ищем сотрудников потенциальных компаний-партнеров: как для тестирований технической стороны, так и для изучения самих продуктов. Таких респондентов — системных администраторов, ассистентов руководителей — находить сложнее: их время стоит дорого, поэтому и рекрутинг становится более затратным. Иначе нельзя: чтобы сделать вывод об удобстве продукта, нужно взаимодействовать именно с потенциальными пользователями.
- Нестандартный интерфейс. В тестированиях инсталлятора и административной панели продуктов Mail.ru для бизнеса основная часть изучаемого интерфейса — поля для заполнения, системы фильтрации и навигация внутри настроек. Помимо того, что это не самое часто встречаемое исследователями графическое наполнение, такие тестирования требуют особой техники проведения.
Из-за особенностей программ для создания макетов интерфейса мы не можем позволить респонденту вводить любые данные в поля параметров при работе с прототипом. Выход из этой ситуации — автоматическое заполнение данных по клику рандомными данными, которое мы заранее прописываем в инструменте для создания прототипа. Респондент видит пустые поля для заполнения, сначала рассказывает, что собирается внести в них, а потом кликает на строку и сравнивает свои ожидания с появившимся вариантом.
Во время теста исследователь должен быть максимально сконцентрирован — ему нужно внимательно отслеживать каждый шаг респондента, чтобы тот озвучил свои предположения до того, как случайно кликнет по одному из полей и увидит подсказку. - Специфический контекст происходящего. Обилие полей и настроек может запутать, но в их значениях разобраться еще сложнее. Системными параметрами продуктов не зря занимаются конкретные специалисты: чтобы хорошо понимать суть происходящего, нужно получить соответствующее образование. Исследователь, как правило, не имеющий специальных знаний, сталкивается с запутанной и неизвестной ему терминологией. Сокращения вроде AD, SSL и ВКС (видеоконференцсвязь), часто встречающиеся в параметрах инсталлятора, поначалу могут казаться иностранным языком.
В нашем случае решением оказалась глубокая вовлеченность в процесс исследования дизайнера, продакт-менеджера и руководителя отдела разработки. Последний помогал как в проектировании прототипа, так и в процессе исследований, что позволяло сориентироваться в происходящем и оперативно задавать вопросы о непонятных частях интерфейса. - Тестирования помогают определиться с направлением дальнейшей работы над интерфейсом. В основном, когда заказчики приходят к команде usability-исследователей с запросом, в предполагаемом интерфейсе уже продуманы сценарии использования, которые кажутся команде подходящими. Когда мы имеем дело с распространенными функциями, нам легко предположить, что может быть понятно и привычно пользователю. Например, на большинстве сайтов вход в личный кабинет находится в правом верхнем углу, поэтому мы можем рассчитывать, что если последовать этому паттерну или незначительно от него отступить, то у юзера не возникнет проблем с пониманием того, где мы спрятали его профиль.
В случае Mail.ru для бизнеса мы имеем дело с набором функций, которые не мелькают ежедневно перед глазами миллионов пользователей. Мы работаем с интерфейсом, который видит узкая аудитория — системные администраторы и технические специалисты компаний. Более того, в основном внутри административных панелей и инсталляторов содержится конфиденциальная информация, из-за чего нельзя просто взять и подсмотреть, как сисадмины привыкли работать с такими интерфейсами.
Это приводит к тому, что к началу тестирования настроек продуктов для бизнеса мы часто подходим с двумя или тремя вариантами структуры прототипа без каких-либо предпочтений между ними. Основным вопросом становится не то, какой из продуманных нами сценариев удобнее, а то, попали ли мы в логику поведения респондентов или нужно все переделывать. - Кстати, про переделывание. По причине того, что мы нередко начинаем «нащупывать» нужные нам реализации прямо в процессе первых тестирований, для корпоративных продуктов Mail.ru подошел формат RITE — Rapid Iterative Test and Evaluation. По стандартному плану проекта с usability-тестированием принято провести общение со всеми респондентами и уже после вносить правки по агрегированным результатам. В случае RITE этот процесс делится на несколько этапов: мы проводим несколько тестов, потом берем перерыв на быстрые правки по уже полученным сведениям, и следующие респонденты выполняют задания на обновленном прототипе. В зависимости от каждой конкретной ситуации можно установить подходящее количество этапов.
Какие результаты получили и как их интерпретировали?
Что может дать сочетание непростой предметной области с методом исследования RITE? Расскажу на примере тестирования инсталлятора корпоративных продуктов Mail.ru для бизнеса. Это было первое исследование интерфейсов подобного рода в нашей команде, и эффективный подход мы сформировали прямо в процессе него.
План тестирования состоял из трех этапов:
- Сначала, чтобы исправить самые крупные и заметные ошибки, мы собрали обратную связь от наших коллег. Так мы смогли исправить самые явные интерфейсные проблемы, не тратя ресурсы на поиск внешних респондентов.
- На втором этапе мы провели тестирования с респондентами из компаний-партнеров, чтобы получить максимально широкий и независимый от привычек конкретной команды взгляд на наш инсталлятор.
- На финальном, третьем этапе, мы показывали прототип конкретным специалистам — системным администраторам, которые имеют опыт интеграции похожих коробочных решений для корпоративного использования. Они помогли нам разобраться с самыми тонкими нюансами.
Мы хотели сделать инсталлятор таким, чтобы с помощью инструкции с ним мог разобраться любой сотрудник компании-заказчика. Для этого на первом и втором этапе мы пообщались не только с техническими специалистами, но и «казуальными» пользователями — сотрудниками, которые не имеют опыта работы с корпоративным ПО и вообще далеки от технических вопросов (менеджеры, HR, бухгалтеры). Эти респонденты помогали нам разобраться с вопросами сугубо интерфейсного характера и понять, насколько прототип в текущей реализации понятен людям, далеким от системного администрирования.
После трех итераций тестирования мы модернизировали интерфейс согласно данным, которые получали после каждой из групп респондентов. Мы смогли проверить, насколько логично и удобно организованы переходы по шагам инсталляции, понятна ли суть полей и настроек. В итоге мы переименовали часть полей, чтобы технические специалисты однозначно понимали, что от них требуется. Кое-где добавили подсказки, а какие-то настройки и вовсе спрятали или убрали.
Со стороны сугубо интерфейсных вопросов мы поняли, например, что нужно переделать строку прогресса, чтобы она перестала казаться кликабельной вопреки нашей задумке, и поработали над отображением шага с проверкой введенных данных.
Помимо наглядного результата usability-тестирования инсталлятора — значительного улучшения интерфейса, мы убедились в правильности выбранной нами логики установки продуктов. Респонденты понимали последовательность шагов в инсталляторе и соглашались с ней, а их впечатления от работы с прототипом были приятными.
Однако в исследованиях так бывает не всегда. В процессе следующего тестирования, изучая настройки групп в административной панели, мы уже на первом этапе выяснили, что логика, которая казалась нам естественной, не оказалась таковой для системных администраторов. Но это тоже важный результат, ведь главное — понять, что делать дальше и проверить гипотезу, а не обязательно подтвердить ее.
Выводы
Мы всегда стремимся рассказывать о своей работе и показывать, как здорово выпускать продукт в мир с уверенностью, что он будет понятен и удобен пользователям. Этой статьей хочется показать, что даже сложные интерфейсы, исследование которых связано с определенными преградами и трудностями, можно успешно изучать.
Под любой проект можно подобрать подходящий метод, который даст ответы на актуальные вопросы и поможет проверить ваши гипотезы, даже если поначалу непонятно, как это сделать. И неважно, работаете вы с B2B- или B2C-продуктом, важно сделать его качественным. В этом как раз помогают регулярные исследования. Удобный и понятный интерфейс — залог счастья клиента, что в долгосрочной перспективе превращается в счастливых пользователей и вашу прибыль.
