Зачем бизнес-аналитики лезут в дизайн или как мы вырубили «лес» и избавились от «слона»

Меня зовут Ирина Козлова, я — старший бизнес-аналитик в ИТ-компании STM Labs. Помимо моих ключевых обязанностей: бизнес- и системный анализ, сбор и управление требованиями, я принимаю непосредственное участие в приемке макетов от дизайнеров. Разрабатывая продукт с нуля, можно столкнуться с множеством проблем и трудностей. Одна из них – как нарисовать хороший дизайн. В своей статье расскажу, как бизнес-аналитик может помочь при проектировании дизайна интерфейса и может ли у дизайна быть KPI. Материал позволит вам узнать несколько ключевых аспектов для создания дизайна продукта, которым удобно, а главное хочется пользоваться.

Для начала я бы хотела обратить ваше внимание на простые примеры различного дизайна в нашей жизни.

Сколько раз вам удалось достать нужное количество кетчупа из стеклянной банки с первого раза? Лично мне - ни разу. Но зато как сексуально она смотрится.

Пластиковая перевернутая не так шикарна, но зато с ней легко контролировать количество кетчупа на своей тарелке.

То, что выглядит великолепно, но трудно использовать, является примером отличного UI и плохого UX. В то время как что-то очень удобное и ужасное является примером отличного UX и плохого UI.

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

В Университете Огайо (рисунок №2) прежде, чем застилать дорожки брусчаткой, рабочие дали студентам и посетителям студенческого городка потоптать газон… и это было не просто так!
Таким образом, люди сами прожили оптимальный путь от одного корпуса к другому. И уже эти тропинки выложили брусчаткой и по ним стало удобней передвигаться, но все так же эффективно — это и есть прекрасная комбинация UI и UX.

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

UI — дизайн кнопок, полей ввода, форм приложений - всех точек взаимодействия пользователя с продуктом.

Главное отличие, которое следует иметь в виду, заключается в следующем: дизайн UX — это общее впечатление от опыта, а дизайн UI — это то, как интерфейсы продукта выглядят и функционируют.

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

Прежде я работала в продуктовой кампании и процесс взаимодействия бизнес-аналитика (БА) и дизайнерами был построен следующим образом. БА был тем человеком, кто приносит «топливо» для работы дизайнера, а именно:

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

Мы разрабатывали продукт по автоматизации маркетинговых активностей в телеком сфере. Нашим основным заказчиком был второй по величине британский телеком оператор - O2.
Зачем же нужен был наш продукт? Представьте, вы жуткий фанат кофе (любите ванильный латте на миндальном молоке) и по пути на вашу работу открылась новая кофейня.
И вот в четверг утром, когда вы проходите мимо этой кофейни, вам волшебным образом приходит смска с примерным содержанием: «Только для тебя и только сегодня! Скидка на твой любимый ванильный латте на миндальном молоке в новой кофейне рядом с тобой!».
Или вам могло приходить смс с предложением подключения пакета Мегабайт интернета, когда вы исчерпали лимит интерната на вашем тарифном плане. Вот такие СМСки и не только делали мы.

У нас было 4 дизайнера, 12 аналитиков, более 80 разработчиков, 3 архитектора, более 15 QA инженеров и конечно же несколько менеджеров что бы все и всех контролировать.

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

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

И дизайнер предложил такой вариант.

В нашей команде мы называли это слоны :)

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

Задача была проста - нужно было дать пользователю возможность настраивать эти самые правила для маркетинговых кампаний по следующим критериям:

Можно было установить лимиты на участие:

Первым решением предложенным дизайнером было дерево принятий решения.

Две этих задачи и предложенные макеты натолкнули меня на следующее

Да! Пожалуй, можно выделить следующие показатели:

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

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

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

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

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

1. количество символов, которые можно вводить;

2. формат;

3. числовые, буквенные, буквенно-цифровые, любые виды символов;

4. зависимости между полями и т. д.

Но когда ошибки возникают, важно их правильно отобразить.

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

Мой пример из жизни - пытались ли вы когда-нибудь получить справку ЕГРН? Один из государственных сайтов призван помочь вам это сделать в электронном виде.

На картинке представлена форма заполнения электронного заявления на получение такой справки.

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

Выбираем нужный тип объекта и тут можно выбрать в параметре «Площадь» значение «Значение отсутствует», но система все равно будет требовать от вас ввести численное значение площади объекта. Далее адрес или кадастровый номер. Предположим, второе вы не помните, зато знаете адрес и тут достаточно (согласно форме) заполнить только регион и район.

Итак, пользователь заполнил обязательные поля, но вот незадача - сайт не пускает его дальше. Если дополнительно заполнить поля, которые необязательны, система позволяет пройти дальше - крайне неочевидное поведение с точки зрения пользователя. Дизайн должен подсказывать, какие действия возможны в данный момент: помогать решать ваши бизнес-проблемы (в примере это получение справки).

Эта часть, пожалуй, самая субъективная составляющая дизайна. Чтобы все разложить «по полочкам» ее можно разбить на подчасти:

Один из наилучших способов упростить сложные формы – начать группировать связанные поля. Группировка множества неструктурированных полей в несколько простых и понятных наборов значительно повысит удобство работы с формой.

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

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

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

Интерфейс, представленный в разных стилях (цвета, шрифты и т. д.) вызовет отторжение у пользователя. Стоит придерживаться единообразия.

Визуальный «шум» – это одно из основных препятствий, мешающих восприятию интерфейсов. Для того чтобы снизить визуальный «шум» в интерфейсе необходимо использовать больше свободного, не заполненного ничем пространства.

Пример - конфигурация маркетинговых кампаний.

Левый макет - разработчики сами нарисовали (в команде на тот момент не было ни аналитиков, ни дизайнеров).
Что они сделали верно? Тут есть группировка. А что сделали плохо - все слишком сжато и плотно.
Так, например, подсказка, которая призвана помочь пользователю заполнить столь сложную форму, перекрывает значимый контент. Итог: подсказка не помогает, а наоборот пугает и путает т. к. пользователь не видит часть формы.

Что изменилось, когда пришел дизайнер? Добавился «воздух»! Основная цель каждой формы – завершение. Первый вариант с трудом позволяет пользователю достичь этой цели. В новом варианте мы создали для пользователя четкий путь заполнения формы, снизили визуальную нагрузку, и форма стала выглядеть намного проще.

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

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

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

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

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

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

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

Как же два этих подхода могут помочь выполнить KPI?

Вернемся к примерам со слонами. Что с ними не так?

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

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

Так же это представление не масштабируемо. Новые причины отказа и детализация существующих уже невозможна в представленном виде.

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

Новый вариант макетов. На их согласование ушла не одна неделя.

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

Вернемся к«дереву»

На первом этапе реализации проблем нет. Дерево легко читается и понятна логика его выполнения.

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

Это теперь не просто одинокое деревце в поле, теперь это целый «лес», где каждое дерево работает по-своему. Но нюанс в том, что то, как работает весь этот «лес», система никак не подсказывает.

А логика, тут следующая: верхнее дерево работает по логическому И, нижние деревья - логическое ИЛИ и между - логическое И.

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

В итоге первое решение, которое было предложено, было уже плохо применимо. С «лесом» оказалось сложно работать.

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

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

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

Конечно же, аналитик никогда не будет обладать той же компетенцией, что дизайнер.

Но какой подход в работе выбрать решать только вам.

Если вы хотите развиваться в этой теме, то вот список литературы и полезных ссылок from my heart: