К счастью, сегодня многие ИТ-компании знают, насколько важно развивать направление исследований. UX-исследования помогают понять ожидания пользователей, а значит, позволяют создавать продукты, максимально удовлетворяющие их потребности. Благодаря UX-исследованиям можно выявить проблемы пользовательского опыта на ранних этапах разработки и внести необходимые изменения до запуска. Поэтому необходимость этого процесса вопросов ни у кого не вызывает.

Однако в процессе развития этого направления компании сталкиваются с множеством сложностей: начиная от того, где искать респондентов, заканчивая вопросами эффективного хранения результатов исследований. Все это сложные вызовы, которые зависят в том числе и от типа продуктов. Случается, что без должной поддержки UX-исследования не получают своего развития и решения принимаются экспертно, как это часто бывает в заказной разработке.

Чтобы развивать исследования как метакомпетенцию всех дизайнеров, в МойОфис выстроили многоуровневую систему обучения, начиная с момента онбординга. Были спроектированы процессы и инструменты, которые помогают дизайнерам регулярно учиться друг у друга, и определены критерии, по которым оценивается успешность каждого исследования. Подробнее, как в МойОфис сейчас организовано это направление, читайте под катом.


Привет, Хабр! Меня зовут Кирилл Улитин, я лид направления UX и исследований в МойОфис. Уже некоторое время экспертиза UX-исследований в нашей компании полностью сосредоточена в департаменте дизайна продуктов. Сейчас в нём 50 человек, это 10 дизайн-команд.

У МойОфис сложная экосистема продуктов, и изначально дизайн-департамент образовывался как точка их синхронизации. Около 10 лет назад наши дизайнеры «делились» на UX и UI. От людей, которые приходили работать в UX, мы ожидали, что они будут проектировать интерфейсы, проводить исследования и отдавать эти результаты в UI на финальные макеты. Постепенно процессы изменились: мы научились собирать макеты быстрее, появились дизайн-системы — и три года назад мы решили объединить UX и UI.

Роль лида в развитии команды

Исследования — метакомпетенция в дизайн-департаменте. При этом исследования — сложный процесс, полный различных нюансов и содержащий высокий компонент операционной деятельности. Например, для поиска респондентов нужно либо выстраивать внутренний процесс, либо аутсорсить этот этап подрядчику, а, скажем, для количественных исследований нужны сервисы. Все это нужно анализировать, бюджетировать и внедрять. Чтобы развивать это направление, я взял на себя роль лида направления UX и исследований. Сейчас у меня несколько зон ответственности.

Общая структура дизайн-департамента
Общая структура дизайн-департамента

На моменте онбординга я погружаю новых сотрудников команды в наши процессы: рассказываю, какими инструментами мы пользуемся, показываю, как в них залогиниться, где искать гайды. То есть первую неделю работы новичок знакомится с нашим дизайн-процессом, имеющимися материалами. Из последних изменений — я стал добавлять в онбординг мини-задания, чтобы ребята сразу применяли новую информацию на практике.


Примеры подобных мини-заданий

  • Зайди в базу всех исследований и найди с помощью фильтра все исследования твоей команды

  • Зайди в любое исследование, где проводился опрос или немод. тест, и посмотри, как был устроен его план и результаты

  • Найди форму этого опроса и посмотри, как он был устроен

  • Зайди в любое исследование, где проводилось интервью или мод. тест, и посмотри, как был устроен его гайд и результаты

  • Посмотри видео о том, как исследования презентуются на компанию


Также я отвечаю за процесс ревью всех наших исследований. Раньше ревью занимался только я, но при масштабировании департамента стало понятно, что одного человека на эту задачу не хватит. Поэтому мы стали развивать коллег в дизайн-командах. Теперь ревью занимаются еще несколько человек, у которых есть опыт в исследованиях — за счёт бэкграунда или потому что они прошли обучение. Кроме этого, недавно мы наняли исследователя — она помогает мне с развитием направления, с разработкой и внедрением новых методов, а также со сквозными исследованиями по всем продуктам.

Ещё я создаю гайды, по которым работают дизайнеры. Это такая информационная поддержка относительно того, что нужно делать на каждом этапе дизайна — исследования сюда тоже включены. Я владею той частью, которая касается UX в целом и исследований, слежу за актуальностью и полнотой этих гайдов, периодически дополняю их на основе обратной связи.

Гайды по исследованиям в базе знаний

Гайды мы создавали на основе частых вопросов, чтобы не объяснять каждый раз одно и тоже. У нас собраны рекомендации по проведению качественных и количественных исследований, разбор основных ошибок при применении, руководства по специфическим методам, например, по работе с айтрекером GazePoint, которым мы пользуемся; собрана информация о различных каналах поиска респондентов и в целом о процессе исследования в виде чеклиста по шагам. В создание гайдов я стараюсь вовлекать всех членов команды, чтобы эти материалы были общим знанием, а не мнением одного человека.

Для ускорения подготовки у нас есть два шаблона: качественное исследование и количественное. В них зафиксирована структура плана, чтобы коллеги, у которых не так много опыта, не терялись, а могли подготовиться на основе структуры и подсказок в шаблоне.

Кроме этого, есть база самих исследований, где мы фиксируем каждое проведенное исследование с 2018 года. Их можно фильтровать по разным параметрам: продуктам, типу исследования, фиче. База используется при подготовке новых исследований, а также для ситуаций, когда на исследование нет времени, но можно проанализировать результаты предыдущих, например, на соседней платформе или сквозной фиче. В базе есть ссылки на план каждого исследования, отчеты и записи.

Всё это — живой и динамичный процесс. Сейчас я думаю о том, как сделать наш гайд по исследованиям более наглядным или более заточенным под конкретный метод, чтобы их было легче проводить.

Гайд «Типовой сценарий теста»
Гайд «Типовой сценарий теста»

Как устроен обязательный этап ревью исследований

Этап ревью у нас обязателен, он зафиксирован в системе управления проектами наряду с остальными задачами. Ревью всегда проходит в два этапа: когда составляется план исследования и во время интерпретации результатов.

Сейчас мы проводим по 3-5 исследований разной сложности в неделю. Все немодерируемые тесты мы закидываем в специальный канал: «Планирую запускать такой тест, можете посмотреть, как он выглядит?» С одной стороны, это нужно, чтобы все видели, что идет какая-то движуха и другие дизайнеры понимали, что тоже могут так сделать в следующий раз. С другой стороны, в чатике есть UX-писатели, они могут подсказать, как переписать вопрос, если формулировка не очень понятная.

Такая система — это ускорение. Иногда, если тест простой, человек может не делать страницу с планом исследования, а сразу собрать тест на основе опыта или взять шаблон типового теста из базы знаний. Или похожий на уже когда-то проведенный тест, чтобы не делать лишнюю работу. Коллеги смотрят, учатся замечать ошибки, оставляют комментарии.

При этом мы стараемся выстраивать горизонтальное взаимодействие. В случаях с дизайн-задачами ревью делает коллега того же грейда. В случае с исследованиями — важно подключать человека, который владеет методологией, чтобы избежать типовых ошибок, про которые люди с небольшим опытом могут просто не знать. Например, выбрать тест side-by-side для интерфейсных решений вместо того, чтобы собрать задание в прототипе и оценивать его успешность или скорость выполнения.

Ещё на внутреннем сервере (чтобы всё было конфиденциально) у нас есть внутренняя база записей интервью — так дизайнеры могут смотреть, как другой человек проводит интервью. Это позволяет поддерживать и развивать навык ведения интервью, учиться работать с разными респондентами.

В конце каждого года мы подводим итоги, как эти исследования повлияли на продукт. Оцениваем по двум критериям:

  • тип влияния исследования

    Здесь смотрим, каким оно было в принципе. Например, мы выпустили новую фичу — или наоборот не выпустили. Или изучаем, как исследование повысило наш статус в глазах других участников — может быть, его как-то переиспользовали, или, например, мы решили опубликовать результаты вовне.

Тип влияния

Описание, примеры

Изменило продукт (реализовано или прямо сейчас в разработке)

Влияние на продукт (выпуск функции, НЕ выпуск функции) повлияло на то, как мы сделали решение

Изменило роадмап продукта (есть задачи в RM)

Влияние на стратегию развития продукта, что-то запланировали и самое главное — это куда-то попало

Стейкхолдеры посмотрели на продукт глазами пользователей

Участие стейкхолдеров в наблюдении за пользователем
- если они были наблюдателем на сессии.
- если стейкхолдер глубоко погрузился в результаты, смотрел видео взаимодействия и т.п.

Использовано для публикации или выступления

Использование в коммуникации другими стейкхолдерами или нами, например в презентации или переписке

Вызвало новое исследование

На основе результатов поняли, что нужно продолжить исследование

Установлено сотрудничество с кем-либо

Новая совместная работа с другими департаментами

Поднят статус UX

Заинтересованность ключевого стейкхолдера в исследованиях

Разработана инфраструктура UX-исследований (новый метод, инструмент и т.п.)

Новые методы, процессы, инструменты

Не повлияло

  • степень влияния исследования

    Этот показатель отражает, на какую часть продукта мы смогли повлиять, насколько широким было воздействие: это был один маленький компонент, несколько или отразилось на всей компании.

Степень влияния

Описание, примеры

Отдельный стейкхолдер

Отдельный проект или команда

Несколько проектов или команд

Компания

Использование в общем демо

За пределами компании

Выступление, пресс-релиз, статья

Не повлияло

Этой моделью оценки влияния поделилась в своем выступлении Victoria Sosik на конференции UXRConf. Мы адаптировали способ для своих потребностей и используем уже второй год.

Мини-презентации Fun With Research

Чтобы поддерживать развитие коллег, раз в две недели я провожу Fun With Research — серию встреч по нашему обучению. Это своего рода мини-тренинги для команды. Иногда с практической частью, иногда — без, иногда на них мы обсуждаем новости, иногда вместе разбираем какие-то темы.

Выступать на такой встрече-презентации может кто угодно. Например, дизайнер провёл интересное исследование и хочет поделиться методологией. Или у команды была какая-то сложная задача, и ребята хотят рассказать, как они её решали. Эту встречу мы отделяем от демо, потому что на демо презентуются результаты, а Fun With Research — именно про улучшение дизайн-процессов, новые фишки, обмен опытом и знаниями.

Процесс с Fun With Research зародился примерно в конце 2021 года. Сначала для меня это был челлендж, потому что мне приходилось заниматься всем: придумывать, что рассказывать, планировать контент-план на эти встречи... Сейчас такие встречи все больше ситуативны и не требуют особой подготовки. Всегда находится что-то, про что можно рассказать, или есть сложность в процессах, которую стоит ещё раз подсветить и проговорить дальнейший план действий.

Примеры тем, которые ребята разбирают во время Fun With Research
Примеры тем, которые ребята разбирают во время Fun With Research

Эти мини-тренинги мы проводим в основном по недостающим компетенциям. Например, мы делали тренинг по ведению интервью, потому что поняли, что не всем хватает знаний/опыта по этой теме. Ещё делали тренинг по Jobs to be done, чтобы наши дизайнеры умели проводить предварительную аналитическую работу: собрать имеющиеся материалы, посмотреть, что есть от других ролей, от бизнес-аналитиков, от поддержки, написать в итоге job stories и уже по ним прорабатывать интерфейсы.

Очень здорово, когда внутренние выступления на Fun With Research перерастают потом во внешние. Уже не раз было так, что коллеги что-то рассказывают, мы понимаем, что это довольно интересный материал, и решаем сделать из него статью или податься с ним на тематическую конференцию. Некоторые из таких статей можно прочитать в этом блоге на Хабре, четыре наших статьи вошли в шорт-лист «Технотекст 2023»:

Вместо итогов

Я часто слышу от коллег — и от исследователей, и от дизайнеров, — что там, где есть юзабилити-лаборатория, чаще всего образуются очереди. Поскольку мы держим эту зону ответственности у себя, у нас есть возможность закладывать время на исследования при планировании задач. В других компаниях получается, что дизайнер должен проявить некую инициативу — обычно это что-то сверх его рабочих обязанностей. А у нас проведение исследований вписано в должностные обязанности. Конечно, сложности тоже бывают: нет времени, непонятно, зачем тестировать ту или иную идею, но тут, опять же, мы общаемся и договариваемся.

Бывает в компаниях и другая проблема: когда исследователь внешний, он как бы оторван от команды, и это приводит к тому, что результаты воспринимают с трудом. В МойОфис исследователь находится «внутри». Так мы контролируем качество работы дизайнера на всех этапах: своевременно даем ему обратную связь, и он ни в коем случае не подгоняет результаты под то, что уже выбрал, а проверяет гипотезы, отвечает на вопросы исследования. Результаты он приносит в свою команду разработки, с которой работает каждый день и которая ему доверяет. В итоге изменения в продукте происходят быстрее.

Всё это про большую ответственность дизайнера. Он сам отвечает за проведённое исследование. И если, например, складывается ситуация, что оно было проведено зря, дизайнер сможет сам это отрефлексировать и в будущем сделать свою работу лучше.

P.S. Хочу выразить благодарность коллегам из Pathway за идею этой публикации, которая появилась из интервью для их блога.

Комментарии (2)


  1. Zelebublik
    04.07.2024 10:42

    О, подскажите название плагина, которым на скрине "Типовой сценарий теста" вы сделали горизонтальный переключатель вкладок "First Click", "Figma" и "Восприятие"?


    1. ulitin Автор
      04.07.2024 10:42

      Это плагин AUI Tabs, очень кстати помогает при формировании гайдов