[Usability, Интерфейсы, Управление проектами] Исследования в сложных B2B-продуктах: как это работает в Mail.ru для бизнеса

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
07-Сен-2020 20:37

Цитировать

Почта 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-продуктом, важно сделать его качественным. В этом как раз помогают регулярные исследования. Удобный и понятный интерфейс — залог счастья клиента, что в долгосрочной перспективе превращается в счастливых пользователей и вашу прибыль.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_usability, #_interfejsy (Интерфейсы), #_upravlenie_proektami (Управление проектами), #_issledovanija (исследования), #_b2b, #_mail.ru_dlja_biznesa (mail.ru для бизнеса), #_blog_kompanii_mail.ru_group (
Блог компании Mail.ru Group
), #_usability, #_interfejsy (
Интерфейсы
), #_upravlenie_proektami (
Управление проектами
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 13:34
Часовой пояс: UTC + 5