Отсутствие жалоб не показатель. Как понять, удобен ли бизнес-пользователям интерфейс?

Привет, Хабр! Меня зовут Дмитрий Смагин, я руководитель продукта информационного моделирования в команде девелопера ПИК. В этой статье хочу рассказать про наш опыт работы над интерфейсами B2B-продукта, про ожидания и обратную связь от внутренних корпоративных пользователей и о том, почему важно далеко не всегда опираться только на метрики.

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

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

Пользователь не обязан страдать

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

Но, когда речь заходит о САПР-системах, особенно о внутренних B2B-инструментах, планка ожиданий резко падает.

Странные интерфейсы, перегруженные окна, огромные инструкции и фразы уровня «ну тут просто нужно привыкнуть» воспринимаются как что-то нормальное. Более того, пользователи зачастую даже не жалуются — потому что годами работают в таких условиях и уже не верят, что что-то можно изменить.

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

·         почему мы вообще увидели проблему;

·         как пытались построить UI/UX-процессы без дизайнеров;

·         зачем аналитики внезапно начали изучать Figma;

·         как UX-тесты изменили наше представление о пользователях;

·    и почему в какой-то момент мы поняли, что проблема была не только в интерфейсах.

Провально-успешное демо

Что считается успехом? Команда показывает демо, отвечает на все вопросы заказчика, заказчик принимает функционал, команда счастлива.

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

На одной из первых демо-встреч внутри команды ПИК с презентацией нового продукта я столкнулся с непривычным явлением для человека, который ранее работал с B2C-сервисами. Команда презентовала заказчикам, сотрудникам одного из инженерных подразделений, продукт с далеко не самым удобным интерфейсом… а заказчик не давал никакой обратной связи.

«Постмит» с командой по «горячим следам» презентации показал, что проблема связана не с «неудачным интерфейсом», а с внутренними процессами:

• ранее заказчики не оставляли требований к интерфейсам, макетов приложения или сервиса не было;

• дизайнеры также не участвовали в процессах;

• процесса проектирования интерфейсов не существовало, разработчик делал UI так, как считал нужным;

• также не существовало UI-kit (набора стандартов или правил для разработки интерфейсов) или UX-паттернов;

• «приемка» новых функций проходила просто на созвонах;

• фраза «пользователи просто не читают инструкции» была универсальным объяснением для всех проблем;

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

50 оттенков интерфейса

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

Проблема была в том, что никто раньше системно не работал с UI/UX. И это не претензия к команде — просто такого процесса никогда не существовало. Не было ни дизайнеров, ни внутренних стандартов, ни человека, который бы отвечал за пользовательский опыт. Главными всегда оставались алгоритм и результат работы инструмента. Интерфейс воспринимался, скорее, как что-то вторичное: «работает — уже хорошо».

Поэтому мы начали с очень простого формата — встреч по разбору интерфейсов. Брали существующий плагин, открывали его и пытались ответить на вопрос: «Что здесь неудобно?»

Первые встречи были в основном про UI. Команда постепенно начинала замечать вещи, на которые раньше просто не обращала внимания:

·         хаотичные отступы;

·         разные размеры элементов;

·         противоречивые иконки;

·         перегруженные окна;

·         отсутствие структуры;

·         разные стили модальных окон в соседних инструментах.

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

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

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

• мог никогда раньше не работать с этим инструментом;

• мог не понимать, какие объекты вообще нужно выбирать;

• мог не знать, что выбор выполняется встроенным функционалом Revit;

• иногда даже не замечал, что после запуска инструмента вообще что-то произошло.

В результате сценарий выглядел примерно так:

• пользователь запускает плагин;

• получает ошибку;

•  не понимает, что от него хотят;

• идет в инструкцию или просто закрывает инструмент.

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

Это можно сформулировать в мысль №1: «Если пользователь не смог начать работать с инструментом — проблема не всегда в пользователе».

В дальнейшем мы постоянно убеждались в этом на UX-тестировании.

От мануала к сценариям

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

Мысль №2: «Возможно, проблема не в том, что пользователь “не читает”, а в том, что читать нужно слишком много».

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

Постепенно формировались первые решения:

•  интерфейсами действительно нужно заниматься;

• нужен единый UI-kit;

• аналитикам придется изучать инструмент для прототипирования;

• процессы разработки нужно менять;

• макеты должны стать обязательной частью подготовки задач.

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

Где разрабатывать прототипы

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

Но очень быстро стало понятно, что это тупиковая ветка:

• бесплатные версии были сильно ограничены;

• часть сервисов не отвечала требованиям информационной безопасности для использования внутри компании;

• не хватало гибкости;

• сами макеты, скорее, напоминали схемы, чем реальные интерфейсы.

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

Никакого обучения, курсов или UX-менторов у нас не было. Аналитики просто начали смотреть видео, разбираться, пробовать, ошибаться и собирать первые макеты буквально на ходу.

Первый редизайн

Первым инструментом, который мы решили переработать, был плагин для армирования по площади.

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

Изначально его интерфейс выглядел достаточно хаотично:

• элементы были разбросаны;

• блоки не читались;

• структура отсутствовала;

• окно пыталось одновременно решить все задачи сразу.

Первое, что мы начали делать, — структурировать интерфейс.

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

Так начали появляться первые элементы UI-kit:

• размеры окон;

• отступы;

• состояния кнопок;

• стили элементов;

• паттерны поведения интерфейса.

Очень много внимания мы уделяли кнопкам и логике действий.

Раньше интерфейсы часто выглядели так:

• «Создать армирование»;

• «Сгенерировать элементы»;

• «Построить схему»;

• «Выполнить расчет».

При этом пользователь каждый раз заново пытался понять: что именно сейчас произойдет? 

Мы начали упрощать логику интерфейса и строить ее вокруг контекста. Например, если пользователь уже находится внутри инструмента армирования, то кнопка «Создать» уже достаточно однозначна.

Параллельно начали появляться:

• всплывающие подсказки;

• состояния кнопок;

• disable-логика;

• встроенная справка;

• pop-up комментарии к элементам интерфейса.

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

Например, кнопка «Свернуть» в старых инструментах долгое время отсутствовала. Пользователи настолько привыкли к этому, что на UX-тестах продолжали закрывать плагин целиком и запускать его заново — просто потому что годами работали так и привыкли.

UX-тесты

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

Да, аналитики давно знали инструменты. Да, команда хорошо понимала бизнес-логику. Но между этим и реальным пользовательским сценарием могла оказаться пропасть. Решили попробовать UX-тестирование.

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

У нас был внутренний Telegram-канал с проектировщиками, где мы публиковали новости и обновления по инструментам. Туда и написали первый пост о том,  что такое UX-тестирование, зачем оно нужно и почему нам важны пользователи. Мы старались писать максимально простым языком, чтобы правильно транслировать ценность. 

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

• созванивались;

• выдавали тестовую сборку плагина;

• подключали пользователя к встрече;

• просили выполнить определенный сценарий.

На встрече обычно были продакт, аналитик  и сам пользователь. Роли быстро распределились естественным образом. Аналитик больше следил за BIM-частью и мог помочь, если проблема была связана именно с моделью или особенностями Revit. Продакт наблюдал за общей логикой взаимодействия и за тем, как пользователь воспринимает интерфейс.

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

На тестах мы просили пользователей:

• запускать инструменты;

• выполнять реальные сценарии;

• проговаривать свои мысли;

• делиться эмоциями;

• не бояться говорить, если что-то непонятно.

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

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

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

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

Пользователи старых версий были по-настоящему поражены. Ключевое, что они говорили: «Мы не знали, что так вообще может быть, мы всегда работали в таком и не думали, что интерфейс может быть другим». 

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

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

Первые неудачи

Разработка интерфейса стала delivery-частью продукта. Это, скорее всего, и расслабило, так как оказалось, мы до конца все еще не решили проблему пользовательских сценариев, то есть проектировали с допущениями. Это и привело к первому факапу. У пользователей была одна кнопка, которая выполняла одну функцию, но проверки лежали на самих пользователях, поэтому решили это переработать и сделать более «современный» сценарий — пошаговый интерфейс.

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

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

• какие-то функции мы разместили не на тех шагах;

• какие-то сценарии сделали слишком длинными;

• часть возможностей вообще оказалась нужна только конкретной роли.

В результате инструмент получил много крутых фич, но они были незаметны из-за корявости маршрута. Со следующей версией мы это учли, а для того чтобы не допускать подобных ошибок, стали строить CJM (Customer Journey Map).

Суть факапа в том, что интерфейс мы спроектировали, основываясь своем опыте и своем мнении, а сценарий работы пользователей понимали не до конца — отсюда и лишний, усложненный функционал. Вывод, который мы из этого сделали: сначала изучать AS-IS (как пользователь работает сейчас и какая у него реальная потребность) и только потом проектировать TO-BE.

Как понять, что у вас проблемы с интерфейсом

Если хотя бы на три вопроса вы ответили «да», возможно, проблема не в пользователях, а в интерфейсах вашего продукта:

• Пользователи часто просят инструкции или обучение.

• На демо приходится объяснять каждую кнопку.

• Поддержка отвечает на одни и те же вопросы.

• Новые сотрудники долго осваивают инструмент.

• Пользователи говорят: «Нужно просто привыкнуть».

• У похожих функций разные сценарии работы.

• Интерфейсы в соседних инструментах сильно отличаются.

• Пользователи редко дают обратную связь.

• Есть функционал, которым почти никто не пользуется.

• Кто-то в команде произносил фразу: «Пользователи просто не читают инструкции».

И еще одна мысль, ради которой во многом все затевалось. В B2B и во внутренней разработке пользователи часто даже не знают, что могут стать счастливее — они просто не видели продукта другого качества. Если их все устраивает и жалоб нет, это еще не значит, что проблем нет. В продуктовых командах привыкли опираться на метрики, но когда метрик нет, проблему легко не заметить — и тогда задача руководителя продукта в том, чтобы за счет опыта и насмотренности проактивно предложить изменение и дать пользователям эту возможность.

Если бы нам пришлось проходить этот путь заново, мы бы начали не с интерфейсов. Мы бы начали с вопроса:

– А мы вообще знаем, как наши пользователи работают с продуктом?