Анастасия Баженова: Процесс проектирования цифровых продуктов похож на сборку кубика Рубика
Автор: Анастасия Баженова · 2023
<p>Интервью для корпоративного издания ООО «Газпромнефть-Цифровые решения».</p><p><strong>Продолжаем публиковать кейсы про исследования и проектирование пользовательского опыта. В этот раз, кроме проектирования, расскажем про направление UX-редактирования. Коллегам будет интересно узнать, как интерфейсные тексты влияют на удобство и восприятие продукта для пользователей.</strong></p><p><strong>В проекте по реинжинирингу ERP-системы SAP «Сапфир», в рамках импортозамещения бизнес решений ОЭДК и ПКО, Анастасия Баженова, UX-аналитик отдела исследования и проектирования продуктов, работала ещё и как UX-писатель. Что из этого получилось, читайте в нашем интервью.</strong></p><p><strong><strong>– Анастасия, сначала расскажите о продукте </strong>SAP ERP «Сапфир» – что с ним было не так и почему потребовался реинжиниринг?</strong></p><p>SAP ERP – это решение для управления бизнес-процессами и ресурсами предприятия, а «Сапфир» ‒ это система управления ключевыми финансовыми процессами, созданная на базе технической платформы SAP. В 2022 году разработчик решения объявил об уходе с российского рынка и прекращении поддержки локальных версий своих продуктов. В связи с этим появилась необходимость импортозамещения сервиса.</p><p>Система, с которой нам предстояло работать, функционирует на основе бизнес-процесса «Управление эффективностью деятельности контрагентов» и его подпроцессах. В каждой её версии насчитывается от 70 до 100 пользовательских ролей с разным набором доступной функциональности. Интерфейсы системы в дочерних обществах (а их 18) и корпоративном центре отличаются. К тому же версии модулей менялись и дорабатывались на стороне разработчиков системы, но накатывались эти обновления неравномерно и не повсеместно.</p><p>Для понимания специфики SAP, стоит отдельно упомянуть про транзакции. Что это значит: для работы с различными страницами и разделами, пользователю нужно заполнить форму и запустить соответствующую транзакцию. При этом, чтобы найти форму той или иной транзакции, нужно знать и помнить ее буквенно-числовой код. Представляете, сотруднику нужно «держать в уме» с десяток номеров, отпирающих таблицы и формы с другими номерами и шифрами, которые тоже нужны. Но уже для других операций…</p><p><strong>– Что вам предстояло сделать?</strong></p><p>Во-первых, сделать так, чтобы интерфейсы импортозамещенной системы были консистентными как в корпоративном центре, так и в дочерних обществах. Спроектировать продукт с учетом его дальнейшего масштабирования и изменения отдельных шагов бизнес-процесса. Для выявления потребностей пользователей – провести UX-исследование. Затем, на основе имеющихся данных и документации – восстановить схему процесса AS IS, выявить критичные проблемы и барьеры в работе бизнес-процесса и исходной системы.</p><p>На основе функциональных требований, результатов исследования и аналитики – спроектировать пользовательский путь TO BE, на котором будет построена работа новой импортозамещенной системы.</p><p>Параллельно с аналитикой и исследованиями предстояла работа по локализации и доработке существующих текстов и коммуникаций для интерфейсов новой системы.</p><p><strong><strong>– Вы провели </strong>юзабилити-исследование, проанализировали действующую схему бизнес-процесса и системы.<strong>Что показал анализ продукта?</strong></strong></p><p>В ходе исследований и анализа мы выделили ряд ключевых проблем. Принятые в бизнес-процессе и его основных артефактах терминология и сокращения практически не были унифицированы с интерфейсом системы и имели расхождения в разных его версиях. Например, «параметры» и «показатели» оказались дублирующими друг друга сущностями. Не понимая какие из этих данных нужны системе для расчета ключевых показателей, пользователи каждый раз тратили время на заполнение одних и тех же таблиц сначала в Excel, а затем и в системе.</p><p>Практически отсутствовала пользовательская документация. Сотрудники передавали как говорится «из уст в уста» инструкции по работе с системой, доподлинно не зная о ее возможностях. Многие артефакты продолжали делать в таблицах Excel, так как модули SAP обеспечивали лишь частичную автоматизацию процесса в ДО.</p><p>Другая проблема была связана с «наслоением» информации. Систему не чистили от лишних и неактуальных данных на протяжении нескольких лет. На интервью пользователи объясняли это страхом что-то сломать…</p><p><strong>– И с таким багажом вы подошли к проектированию новой системы. Расскажи подробнее о процессе?</strong></p><p>– Я сравниваю процесс проектирования со сборкой кубика Рубика: в процессе отсекаются худшие варианты, а из оставшихся ты находишь оптимальное решение. Конечно, мы сразу отказались от самого трудоемкого пути – досконального анализа экранов всех версий и наборов доступных функций для каждой роли во всех дочерних обществах. Даже при отсутствии расхождений в интерфейсах модулей для некоторых ролей у нас в работе оказалось порядка 1500 вариаций системы.</p><p>Мы выделили группу ключевых ролей бизнес-процесса и системы. Их оказалось без малого 10. Дальше все по классическим шагам UX-исследования: описали методику исследования, нашли подходящих респондентов, провели ряд глубинных интервью и отрисовали CJM. Простая, на первый взгляд, схема, если не учитывать погружения в специфику каждого подразделения и количество обработанной в сжатые сроки информации.</p><p>– <strong>Сложности были?</strong></p><p>Одним из главных барьеров исследования, да и аналитики по сути, стала доступность интерфейсов SAP. Это связано с утвержденной функционально-ролевой моделью, согласно которой доступ к тем или иным возможностям системы могут получить только сотрудники, наделенные правами конкретных ролей бизнес-процесса.</p><p>Что мы сделали? Чтобы увидеть, как работает система и как она может выглядеть в разных дочерних обществах, мы делали видеозаписи каждого интервью, где респонденты демонстрировали экран и выполняли набор своих обычных функций в SAP. Видеотека хронометражем в 15 часов позволила нам не только зафиксировать пользовательские сценарии базовых ролей со всеми их нюансами, отследить паттерны и барьеры, но и актуализировать функциональные требования.</p><p>На экваторе проекта стало очевидно, что для завершения процесса отрисовки дизайн-макетов в срок, результатов аналитики и исследования будет не достаточно. Для ускорения дальнейшей работы дизайнеров из подрядных организаций и в дополнение к уже разработанному пользовательскому пути подпроцессов, были спроектированы варфреймы с верхнеуровневой навигацией и структурой.</p><p>Детализация экранов стала примером хорошей практики, которая позволила нам наглядно продемонстрировать общий вид новой системы и скорректировать, по результатам обратной связи от экспертов и заказчиков, взаимодействие элементов интерфейса и логику переходов между страницами.</p><p>Благодаря заранее проработанной информационной структуре и навигации, отрисовка таких макетов заняла у дизайнера в два раза меньше времени.</p><p><strong><strong>– В начале беседы мы сказали, что расскажем коллегам, почему роль </strong>UX-писателя важна в процессе проектирования продукта.<strong>Если пропустить этот шаг, как это может аукнуться на дальнейшем развитии продукта?</strong></strong></p><p>– Если UX-аналитика позволяет сделать процесс проектирования гораздо быстрее и эффективнее, то UX-писательство – формирует простые и понятные коммуникации между продуктом и его конечными пользователями.</p><p>Но на финальном этапе проектирования схемы TO BE, зачастую, шаг по созданию контента для интерфейсов, обходят вниманием и сразу спешат передать артефакты дизайнерам для верстки макетов.</p><p>Основных причин здесь несколько. Во-первых, это отсутствие в процессе проектирования продуктов шагов по проработке интерфейсных текстов и роли UX-писателя как таковой. Эта часть работы над проектом строится на тесном взаимодействии аналитика, UX-писателя и UX/UI дизайнеров. Если из этой цепочки, по-разным причинам, выпадает звено в виде писателя, то магическая трансфигурация состоится не до конца и вы повторите ошибку Рона Уизли, превратившего грызуна в кубок с длинным хвостом. Во-вторых, не стоит забывать про hard skills участников проекта. Умение писать слова и складывать их в предложения, совсем не тоже самое, что умение создавать и продумывать юзабилити-контент, куда входят самые разные форматы микротекстов, коммуникаций с пользователями и документации.</p><p>В итоге перед выходом на prod, а иногда и на стадии развития и тиража, такой продукт гарантированно потребуется дорабатывать или даже делать его редизайн.</p><p><strong>– Вы прошли весь цикл проектирования. <strong>Расскажи о создании ux-текстов и локализации контента.</strong></strong></p><p>Результаты UX-исследования и аналитики подтвердили гипотезу о том, что низкий уровень локализации SAP негативным образом сказался на скорости и качестве выполнения пользователями задач. Что особенно важно, когда дедлайны процессов и их отдельных шагов ограничены сроком от нескольких дней до двух недель.</p><p>В первую очередь, мы ориентировались на паттерны системы – это таблицы, формы и редакторы, которые используются для их создания, соответственно. На основе актуальных артефактов и при поддержке экспертов направлений, мы локализовали и отредактировали контент этих сущностей, приведя его к некой единообразной и понятной системе. Потенциально это позволит решить проблему качества и достоверности информации, сократит время сотрудников на обработку данных – особенно при обмене информацией между разными ДО и подразделениями.</p><p>Отдельного внимания удостоилась локализация и проработка навигации и сервисных коммуникаций, которые в прежней версии SAP сильно усложняли пользователям жизнь. В этом нам пригодился опыт и практики других ERP-систем, референсы которых также использовались в аналитике.</p><p>Следующие шаги UX-писателя по работе над данным проектом должны заключаться в создании пользовательских инструкций, гайдов, а также разработки чат-бота для поддержки пользователей. Но это уже совсем другая «тиражная» история…</p>
