Многие эксперты сходятся в том, что дизайн пользовательского опыта (User Experience Design) в ИТ-решениях, создаваемых для бизнес-пользователей, во-первых, специфичен, и, во-вторых, к сожалению, часто просто ужасен. Попробуем разобраться, почему так происходит – и как можно изменить эту ситуацию.
Зачем нужен UX Design в B2B и почему он - особенный?
UX Design в целом – отрасль знаний хоть и сравнительно новая, однако вполне насыщенная информацией. Есть и учебники, и образовательные программы, и изобилие вакансий и резюме на рынке труда, с разной степенью детализации и системности описывающих задачи и необходимые компетенции. Но основной акцент делается, как правило, на B2C-сферу, создание продукта для определенной (более или менее широкой) аудитории со вполне конкретными целями повышения метрик вовлеченности, конверсии и т.д. B2C UX-дизайн, соответственно, фокусируется на потребителях, эмпатии, эмоциональных триггерах; очень значимой становится визуальная эстетика конечного решения, применение паттернов, схожих с маркетинговыми, рекламными, фиксация и управление настроением.
В свою очередь, B2B-решения, особенно реализуемые в проектах, крайне редко разрабатываются с привлечением UX-дизайнера. UI-дизайнер, то есть грубо говоря, «художник по интерфейсам», встречается в проектах несопоставимо чаще, хотя тоже далеко не во всех; наименование роли как «UX/UI дизайнер» в данном случае не должно вводить в заблуждение. Кажется, что дополнительные ресурсные затраты в данном случае совершенно избыточны: ведь пользователи так или иначе будут работать во вновь созданном программном обеспечении, если это диктуется их должностными обязанностями. Функциональные требования, информационная безопасность, совместимость с другими системами ИТ-ландшафта куда более важны как для заказчика, так и для исполнителя работ. А раз такие кейсы являются невостребованными, нет и практики, наработанного опыта и его обобщения: публикаций в RU-сегменте Интернета на эту тему немного, впрочем, можно найти вполне интересные статьи англоязычных авторов (ссылки на некоторые из них приведены в конце этого текста).
Обобщив публикации, можно сформулировать следующие тезисы:
Качество пользовательского опыта очень многих B2B-систем крайне низкое, в статьях используются описания вроде «hopelessly convoluted» (безнадежно запутанные). Складывается это, в том числе, за счёт накопленных особенностей решений, которые развивают заложенные много лет назад (когда современных UX-методик толком и не было) основы.
Комплексность B2B-решений дополнительно усложняет задачу: система может решать множество бизнес-задач очень разных групп бизнес-пользователей, функционируя во взаимосвязи со смежными ИТ-системами организации. Корректная работа функций системы становится сама по себе вызовом для команды, ресурса на «украшения» не остаётся.
Заказчик (покупатель) решения не является его будущим пользователем. ИТ-подразделение, например, не очень хорошо представляет (да и не обязано представлять) нюансы работы какого-то функционального отдела. Об особенностях нефункциональных требований к системе со стороны топ-менеджмента крупной организации и вовсе сложно узнать, кто бы ни занимался сбором требований. Кроме того, пользователи систем привыкают к их особенностям и не готовы к изменениям, даже в ущерб эффективности.
Недостаток методик также является значимым: встраивание UX-дизайна в процессы, матрицу ответственности и пр., мало того, что не очень мотивировано для стейкхолдеров (по причинам, изложенным выше), так еще и является нетривиальной задачей, которую приходится решать «с чистого листа», не имея подходящих компетенций в команде и уж тем более отдельных специалистов с соответствующим опытом. Сами же методы и инструменты UX-дизайна зачастую не очень хорошо подходят для B2B-решений – об этом мы поговорим ниже.
Все эти факторы делают крайне маловероятным возможное революционное изменение в виде переработки для качественного улучшения пользовательского опыта системы в ходе её развития (редизайн); то же относится и к созданию нового решения, пусть и с несколько меньшей вероятностью. Всё-таки развитие идёт, и некоторые вещи потихоньку приживаются в качестве общих паттернов проектирования и реализации.
А кто этим занимается?
Начнём с того, что зачастую, к сожалению, никто. Точнее, процесс-то идёт, ведь какой-то пользовательский опыт в конечном итоге в любом случае рождается (системой ведь пользуются в большинстве случаев), однако - хаотично, без ответственного компетентного специалиста, без применения нужных методик и инструментов.
В этом случае будущий пользовательский опыт складывается из отдельных решений, контекстно принятых бизнес-аналитиком, консультантом или разработчиком на основе требований, транслируемых от заказчика (а мы помним, что заказчик во многих случаях не будет являться пользователем). Если же отдельная роль (должность) в команде всё-таки есть, то и это зачастую вызывает некоторые вопросы.
Отметим, что в идеальном случае для проектирования качественного решения с учетом аспекта пользовательского опыта роли составляют следующий набор (и каждой роли соответствует минимум один человек в команде, может быть и больше – в зависимости от масштаба проекта):
Конечно, компетенции могут пересекаться. Сфера UX, например, для не слишком больших проектов может реализовываться через набор дополнительных компетенций бизнес-аналитика или UI-дизайнера, и в этом нет ничего плохого при соблюдении некоторых условий. Сфера UI-дизайна может разделиться между бизнес-аналитиком, UX-дизайнером и разработчиком, в самых разных пропорциях. Всё это возможно, но требует от руководства проекта и лиц, принимающих решения, понимания и анализа как задач, так и знаний и навыков членов команды.
Проанализировав некоторые публикации на тему компетенций UX-дизайнеров, мы можем заметить, что эта профессия зачастую примыкает к профессии UI-дизайнера, сливаясь в единое целое. Возможно, вы встречали эти аббревиатуры, написанные через «/», мы уже упомянули это чуть выше. В принципе, в этом нет ничего плохого, однако получается, что и квалификационные особенности тяготеют именно к визуальной части работы. Вот некоторые примеры: «Чаще всего UX-дизайнерами становятся люди, получившие дизайнерское образование по профилям «Промышленный дизайн» или «Графический дизайн» (специальность «Дизайн» с кодом 54.03.01, или, например, «Графика» с кодом 54.05.03)» (https://www.profguide.io/professions/ux-designer.html); «Из-за универсальности профессии, попробовать свои силы может любой желающий. Важными качествами для работы являются: чувство стиля; умение рисовать; усидчивость и терпеливость; навыки работы с данными (https://apokdpo.ru/stati/ux-i-ui-dizajner-opisanie-obyazannostej-i-osobennostej-professii/)» (спасибо уже за упоминание данных, однако, здесь скорее всего имеется в виду обобщение результатов исследований, а не проектирование дашбордов или процессов администрирования системы); и даже «UX – это пользовательский опыт. До сих пор не понимаю, как можно быть «дизайнером опыта», поэтому буду говорить о дизайнере интерфейсов» (http://choose-it.ru/article/?id=1284).
А что должен делать UX-дизайнер на самом деле?
Попробуем определить области задач именно для UX-дизайнера, предполагая, что работу по конечному визуальному решению выполнит UI-дизайнер, получив необходимые для этого исходные данные. Не будем стараться разделить деятельность по конкретным людям, сориентируемся именно на роли (выше мы показали, что деление компетенций между членами проектной команды может быть самым разным).
Начнём с того, что проектирование пользовательского опыта вообще означает, что до начала разработки и даже отрисовки макетов, кто-то детально представляет – как именно пользователь будет взаимодействовать с системой (т.е. как управлять ею, что получать, в какой последовательности и т.д.). Такое представление должно рождаться с учетом анализа функциональных и нефункциональных требований к системе – а также с использованием максимально возможного количества информации об объекте автоматизации (мы говорим всё-таки о B2B-решениях).
Наиболее сложной задачей области UX для любой системы, где существует более пары-тройки экранных форм, является проектирование информационной архитектуры.
Информационная архитектура – это все иерархии, связи и атрибуты для всех объектов и функций, что должны быть представлены в интерфейсе будущей системы (включая и навигацию) для верного восприятия информации и управления ею.
Вообще, это задача и область ответственности UX-дизайнера. Однако, сложно себе представить, чтобы человек, компетенции которого соответствуют описанному выше в некоторых цитатах, справился с такой задачей на основе, например, регламента страниц на 100 с приложениями, описывающими пару-тройку дюжин итераций бизнес-процесса, соответствующее количество показателей деятельности и т.п.
Здесь и далее UX-дизайнер должен выбрать и использовать необходимый инструментарий для работы. И если его опыт находится в области продуктовых команд и B2C решений, то скорее всего выбор будет не вполне эффективным для сферы, которую мы рассматриваем. Многие инструменты проектирования пользовательского опыта построены на эмоциональной составляющей (например, Customer Journey Map, представленная ниже на иллюстрации). Более того, основополагающие методики, используемые в том числе Google, буквально начинаются с раздела «Эмпатия». Шаги пользователя в рамках сценария его работы с системой имеют эмоциональную характеристику – и это базис для проектирования опыта.
Какие изменения представляются логичными для B2B UX? Кажется, что куда более верным будет следование бизнес-смыслу сценария, то есть ведение пользователя от одной конкретной бизнес-задачи к следующей в рамках общей бизнес-цели, определяющей смысл существования этого сценария. Да, эмоции пользователя – это в каких-то случаях важная вещь, но далеко не такая важная, как эффективность, простота, последовательность, приоритетность в его бизнес-процессах, если речь идёт о B2B-решении. Подробнее об этом можно прочитать тут: https://habr.com/ru/articles/816945/.
В этом же ключе должны решаться и остальные задачи, что, вероятно, может предоставить некоторые не вполне очевидные, но существенные преимущества проектной команде. Так, разделение на этапы процесса проектирования дизайна может сэкономить ресурсы на итеративные изменения по итогам согласования. Гораздо проще внести изменения в документ с задачами и сценариями, чем в десятки реалистичных макетов (кроме того, понимание сути работы будущей системы легче, если вас не отвлекают эстетика и подробные детализации). Что уж говорить про готовые экранные формы.
Спроектированный (и согласованный в каком-либо очевидном для обеих сторон виде) пользовательский опыт делает крайне маловероятной ситуацию, когда разработанное решение не вполне понятно или не очень-то нужно конечным бизнес-пользователям (целиком либо в какой-то его части). Формальная сдача, кстати может пройти благополучно безотносительно этого, т.к. соответствие функциональным требованиям у хорошего исполнителя в любом случае будет стопроцентным. Успешное завершение проекта, трудные доработки – или потеря деловой репутации и перспектив работы с этим заказчиком – что выбрать? И окупается ли этот выбор экономией на некоторых компетенциях проектной команды?
Модель компетенций в команде, планирование и реализация работ
Самая простая модель представлена выше: полный набор ролей и соответствующих профильных специалистов. Однако далеко не всегда такая модель достижима и целесообразна – причины могут быть и организационными, и лежать в конкретике проекта, и т.д.
В зависимости от конкретных условий можно предположить следующий выбор для организации, реализующей B2B ИТ-проекты:
развитие UX-компетенций (возможно, определенной части) бизнес-аналитиков;
включение в команды UX-дизайнеров с, крайне вероятно, переподготовкой их для работы с B2B-спецификой и построением непривычной для них тесной связки с бизнес-аналитиками.
Единое верное для всех случаев решение представляется невозможным в силу разницы контекстов и ситуаций.
В части развития компетенций бизнес-аналитиков важны методология анализа и проектирования «от пользователя» (человекоориентированный подход), практические приемы описания бизнес-целей, задач и сценариев; в значительно меньшей степени следует уделить внимание навыкам владения специализированным прикладным ПО для макетирования (с низкой степенью детализации визуального решения) и прототипирования (Figma, Sketch и подобные – если, конечно, есть другие члены команды, которые могут взять на себя эту работу или её наиболее сложные аспекты).
В свою очередь, UX-дизайнеры, работающие в B2B-командах, очевидно, должны стать «немного бизнес-аналитиками»: уметь анализировать бизнес-процессы, нормативную и методическую документацию (опять же, с учетом возможной помощи от коллег – не обязательно приобретать вторую профессию полностью). Кроме того, им следует провести ревизию своего инструментария. Некоторые методы UX-исследований для сбора данных и приемы проектирования окажутся недоступны по причинам, изложенным в начале этой публикации – а практики проектирования, завязанные на обработке результатов исследований в этом случае тоже «просядут».
С учетом вышеизложенного, формулируем рекомендации для организаций:
Управление компетенциями сотрудников таким образом, чтобы в любой проектной команде обеспечивался необходимый набор с учетом сложности и объема решения (особенно значимы небольшие имплементации в знаниях руководителей проектов, а также отдельные или совмещаемые компетенции бизнес-аналитика и UX-дизайнера).
Включение работ по проектированию пользовательского опыта в шаблоны и инструменты управления проектами, а также обеспечение этих работ (методики, форматы артефактов, связи задач и т.д.).
Англоязычные публикации на тему:
Luca Reale «Everything You Need To Know About B2B UX Design»
https://drewl.com/blog/b2b-ux-design-2023/
Duncan Trevithick «UX for B2B Companies: How is it Different?»
https://www.resonio.com/blog/b2b-ux-design/
Mathias Ellegiers «Designing Better B2B E-Commerce Experiences: Information Architecture and UX»
Samuel J. Horodezky «B2B UX – Common Obstacles and Attainable Solutions»