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

Привет, Хабр! Меня зовут Илона, я продуктовый дизайнер в команде Project Ruler. В Naumen я работаю больше года, и за это время мы успели сделать многое, чтобы улучшить продукт и подготовить его к редизайну.

Илона

продуктовый дизайнер Project Ruler

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

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

Что такое Project Ruler и почему ему понадобился редизайн

Project Ruler — система управления проектами, которая поддерживает как классические, так и гибкие подходы. У продукта амбициозная цель — стать одним из стандартов управления проектами на российском рынке.

При этом у нас была проблема: интерфейс начал выглядеть устаревшим. Мы поняли это не только по внутренним ощущениям. Несколько потенциальных клиентов отказались от продукта именно из‑за интерфейса. Функциональность им нравилась: они отмечали возможности и мощность системы, но визуальная часть и пользовательский опыт проигрывали более современным решениям конкурентов.

Мы собрали обратную связь и поняли, что просто обновить внешний вид недостаточно. Нужно разобраться, какие сценарии действительно важны пользователям, что мешает им сейчас и какие изменения стоит включить в первую версию.

Поэтому редизайн решили начать с исследований.

Старт исследования: ограничили масштаб задачи

Полный редизайн системы управления проектами — большая задача. Одновременно переработать все роли, разделы и сценарии невозможно, поэтому сначала мы определили границы MVP.

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

Из пяти запланированных исследовательских методов мы успели провести четыре. Юзабилити‑тестирование подготовили, но пока поставили на паузу.

Конкурентный анализ: сформировали первые гипотезы

Начали мы с конкурентного анализа. Это базовый метод, но нам было важно заранее определить, на какие вопросы мы хотим получить ответ.

Нам нужно было не просто посмотреть на интерфейсы других систем, а изучить, как конкуренты решают конкретные пользовательские задачи:

• как человек находит свои задачи;

• как открывает проект;

• как меняет статус;

• как ищет нужную функцию;

• как отслеживает текущую работу;

• как возвращается к недавно открытым объектам.

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

Наблюдения по каждому сценарию фиксировали в Figma. Но довольно быстро поняли, что набора разрозненных заметок недостаточно. Чтобы анализ можно было использовать дальше, мы сформировали систему критериев.

Часть из них относилась к UX и UI, часть — к конкретным пользовательским сценариям. В результате получилась большая таблица, в которой мы отмечали:

• распространенные паттерны;

• спорные или неудобные решения;

• интересные функции;

• различия между продуктами;

• возможные направления для Project Ruler.

Главный принцип был такой: решение конкурента — это не готовый ответ, а гипотеза.

Например, если в нескольких продуктах есть раздел «Недавние», это еще не означает, что такой раздел автоматически нужен нам. Сначала стоит проверить, решает ли он реальную задачу наших пользователей.

С такими гипотезами мы и пошли на глубинные интервью.

Глубинные интервью: проверили гипотезы и изучили рабочий контекст

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

Сначала определили цель и темы разговора, затем собрали структуру интервью и перешли к рекрутингу.

Пригласили около 20 человек, но примерно половина отказалась: не каждый готов выделить от получаса до часа на исследование. В итоге провели девять интервью.

После каждого разговора делали транскрибацию и переносили информацию в таблицу: вопрос, ответ, связанную гипотезу, подтверждение или опровержение, дополнительные наблюдения и инсайты.

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

Модель помогала искать повторяющиеся темы и связи между ответами. Иногда подсвечивала мысли, которые мы могли пропустить, хотя сами проводили и переслушивали интервью. При этом GPT оставался вспомогательным инструментом: выводы мы проверяли по транскриптам и собственным наблюдениям.

В результате часть гипотез подтвердилась, часть — нет, а некоторые ответы дали новые вопросы для следующего этапа.

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

Древовидное тестирование: проверили структуру до дизайна

Для проверки информационной архитектуры мы выбрали древовидное тестирование.

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

Так можно проверить:

• понятна ли структура;

• что человек ожидает от названий разделов;

• куда идет по интуиции;

• на каких этапах начинает сомневаться;

• какие функции находятся не там, где пользователь ожидает их увидеть.

Для нас это было особенно важно на раннем этапе. Изменить структуру или название раздела сейчас гораздо проще, чем переделывать готовые макеты и разработанный интерфейс.

Как мы готовили и проводили исследование

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

Затем подготовили задания и вопросы для респондентов. Здесь мы допустили одну ошибку. Среди вопросов были слишком общие: понравилось ли исследование, было ли сложно, комфортно ли было участвовать. Если задавать их сразу после встречи, человек чаще всего отвечает, что все прошло хорошо, и полезной информации получается немного.

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

Для тестирования нашли 20 респондентов. Здесь с рекрутингом было проще: исследование занимало 15–30 минут, поэтому все приглашенные согласились участвовать.

Сессии проводили с модератором. Респонденты демонстрировали экран и проходили задания, а мы просили их рассуждать вслух.

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

Как анализировали результаты

Мы объединили результаты двух исследований и собрали таблицу по основным критериям:

• прямой успех — пользователь сразу выбрал ожидаемый путь;

• косвенный успех — сначала ошибся или пошел другим путем, но в итоге нашел нужный раздел;

• неуспешное выполнение;

• комментарии респондентов;

• возможные причины выбора того или иного пути.

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

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

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

В результате мы зафиксировали проблемные места информационной архитектуры, рекомендации по ее изменению и вопросы, которые требовали дополнительной проверки.

Опросы: разрешили спор внутри команды

После древовидного тестирования мы скорректировали информационную архитектуру и перешли к серым прототипам.

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

Тогда мы подготовили несколько вариантов и отправили пользователям короткий опрос. 

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

Юзабилити-тестирование: этап, который пока остался на паузе

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

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

Что мы узнали о пользователях и как это повлияло на продукт

Теперь к самой интересной части — результатам.

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

Если собрать основные результаты в одном месте

Что бы мы сделали иначе

Не все в процессе оказалось удачным и это, пожалуй, не менее полезная часть опыта.

Во‑первых, в древовидном тестировании мы задавали слишком общие вопросы о впечатлениях. В следующий раз будем спрашивать о конкретных точках сомнения и причинах выбора маршрута.

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

В‑третьих, полезно заранее определить не только критерии успеха исследования, но и план действий для разных результатов. Что будем делать, если структура пройдет тест? Если проблема окажется только в одном разделе? Если придется пересобирать ее почти полностью?

Тогда исследование заканчивается не просто выводом, а понятным следующим шагом.

Как выбрать метод для своей задачи

Наш кейс связан с большим редизайном, но для каждой продуктовой задачи не нужен полный набор исследований. Часто достаточно одного метода — главное понять, какой вопрос вы хотите проверить.

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

Важно только заранее понимать, какой вопрос вы задаете и какое решение сможете принять после получения ответа.

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

Исследования показывают, что это не всегда так.

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

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

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

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