Пример из практики: Разработка дизайна (UI-UX) для ERP системы с нуля, на базе PRD.
Автор: Кристина Шаноян
Со-автор: Вольф Алексанян
Дисклеймер: Эта статья основана на реальном продукте оцениваемым 8-значным числом (USD). Проект был разработан с нуля. Для этой статьи мы полностью переделали дизайн той части системы, которую собираемся показать.
Ввиду высоких рисков связанных с безопасностью оригинальной системы, некоторые части описываемого кейса не будут выглядеть типично. Большая часть системы и функционала видимого на изображениях описана не будет.
Оригинал статьи был написан на английском, поэтому все изображения на английском.
Ссылка на PRD
Ссылка на прототип в Figma
Ссылка на Персону с указанием склонностей к когнитивным искажениям
Ссылка на Персону в инструменте UX Core Persona
Со-автор: Вольф Алексанян
Дисклеймер: Эта статья основана на реальном продукте оцениваемым 8-значным числом (USD). Проект был разработан с нуля. Для этой статьи мы полностью переделали дизайн той части системы, которую собираемся показать.
Ввиду высоких рисков связанных с безопасностью оригинальной системы, некоторые части описываемого кейса не будут выглядеть типично. Большая часть системы и функционала видимого на изображениях описана не будет.
Оригинал статьи был написан на английском, поэтому все изображения на английском.
Ссылка на PRD
Ссылка на прототип в Figma
Ссылка на Персону с указанием склонностей к когнитивным искажениям
Ссылка на Персону в инструменте UX Core Persona
#1. Описание проекта
Мы собираемся разработать ERP (Enterprise Resource Planning) систему. На русском подобное ПО называется системой планирования корпоративных ресурсов. Примеры популярных систем: MS Dynamics 365, SAP ERP, Oracle Cloud, Odoo и другие.
Разрабатываемая система будет использоваться в существующей организации. Стартовое число пользователей около трех тысяч.
В рамках этого проекта наш клиент является многолетней, стабильной организацией со множеством правил и критически важных процессов. Каждый процесс начинается с заполнения какой-либо формы, с последующим утверждением, либо отклонением запроса. Процесс рассмотрения запросов привязан к разным ролям в системе.
Природа запросов тоже разная. Это могут быть как постоянные запросы на выходной день или пересмотр зарплаты, так и более сложные, типа заявки на рабочий перелет в другую страну, либо организацию частного тренинга и так далее.
В системе есть несколько пользовательских уровней, определяющие базовые настройки доступа. Самый низкий уровень - регулярный сотрудник - 95% пользователей системы. Этот тип пользователей может как являться инициатором каких-либо запросов, так и участвовать в рассмотрении некоторых запросов своих коллег.
Затем идет среднее звено - команда HR - 4% пользователей системы. Они занимаются конфигурированием рабочих процессов, изменением полей необходимых для заполнения форм и многим другим.
Самый старший пользовательский уровень - админы - <1% пользователей системы. Они занимаются обслуживанием глубоких настроек ERP системы. По сути, они определяют то, как будет выглядеть рабочее пространство для разных пользовательских групп. Они же назначают менеджеров среднего звена (напр. HR специалистов).
Рабочая среда нашего клиента крайне динамична. Рабочие процессы, люди, ответственные за принятие решений, а также контент форм и кнопки в системе постоянно меняются. Именно из-за этого появляется необходимость создания адаптируемой и очень гибкой ERP системы, позволяющей модифицировать рабочее пространство множеством разных способов.
#2. Исследование PRD проекта
В процессе дизайна, PRD (Product Requirements Document) служит основным нормативным документом. Множество ключевых моментов, описанных в документе дают нам базу для фундамента наших дизайн решений. Вот несколько из них:
1. "The system will be web-based, with the support of all modern browsers (MS Edge, Chrome, Firefox, Safari). The mobile support of the system is not considered in the MVP. This means we consider the system users to log in from desktop workstations only. The system will be used internally in an air-gapped network, meaning that there won’t be any Internet connection, and the system will have to work autonomously."
Это требование из PRD подсказывает. что нам следует адаптировать дизайн под экраны рабочих станций (десктоп). UX должен быть одинаковым на всех поддерживаемых браузерах, включая Apple Safari.
Ввиду высокой бюрократизированности организации клиента, мы делаем допущение, что некоторые (или большинство) пользователей будут использовать браузеры Internet Explorer и/или MS Edge.
Из-за отсутствия подключения к Интернету в сети нашего клиента, мы не можем быть уверены, что пользователи ERP системы будут использовать последние версии браузеров. Следственно, нам следует избегать слишком современные UI решения. Вместо этого, нам следует придерживаться более консервативных, простых UI элементов, которые не сильно зависят от последних версий Javascript.
Это требование из PRD подсказывает. что нам следует адаптировать дизайн под экраны рабочих станций (десктоп). UX должен быть одинаковым на всех поддерживаемых браузерах, включая Apple Safari.
Ввиду высокой бюрократизированности организации клиента, мы делаем допущение, что некоторые (или большинство) пользователей будут использовать браузеры Internet Explorer и/или MS Edge.
Из-за отсутствия подключения к Интернету в сети нашего клиента, мы не можем быть уверены, что пользователи ERP системы будут использовать последние версии браузеров. Следственно, нам следует избегать слишком современные UI решения. Вместо этого, нам следует придерживаться более консервативных, простых UI элементов, которые не сильно зависят от последних версий Javascript.
2. “The smallest screen size the system supports is Full HD (1920x1080).” So there will be no need for any design considerations for smaller screens.
Работа с этим разрешением экрана дает нам огромную свободу. Так как в ERP системах есть масса функционала, Full HD упростит размещение этого функционала.
3. “The system will be available in Arabic (default) and English”
Это требование подчеркивает необходимость учета многоязычности в дизайне. Каркас, расположение элементов и типография должны быть адаптированы чтобы поддерживать RTL (Right-To-Left). Цветовая палитра должна быть оптимизирована как для Англоговорящих, так и Арабоговорящих пользователей.
4. "There are three system user types: admins, HR team members, and regular employees. Each user type has its set of privileges and accesses.”
Это требование указывает на наличие нескольких групп пользователей. Отдельно подчеркивается, что некоторые группы будут заниматься обслуживанием системы, тогда как другие будут заниматься процессингом основных операций организации.
Из этого мы делаем вывод, что UI (интерфейс) будет выглядеть по-разному для разных пользователей, полностью завися от степени данных им привилегий. Следственно, мы должны удостовериться, что наши UI-UX решения будут одинаково комфорты для всех пользователей, вне зависимости от кол-ва кнопок и страниц к которым у них есть доступ.
Из этого мы делаем вывод, что UI (интерфейс) будет выглядеть по-разному для разных пользователей, полностью завися от степени данных им привилегий. Следственно, мы должны удостовериться, что наши UI-UX решения будут одинаково комфорты для всех пользователей, вне зависимости от кол-ва кнопок и страниц к которым у них есть доступ.
#3. Исследование Пользователей
Чтобы определить Персону нашего продукта мы провели разные онлайн и оффлайн мероприятия. В их числе интервью, опросы, и анализ сотен протоколов встреч (meeting minutes) наших продакт менеджеров с клиентами и конечными пользователями разрабатываемой системы.
Затем мы вывели гипотезы и факты о пользователях системы и адресовали наиболее вероятные когнитивные искажения, к которым пользователи склонны в силу разных факторов. Это дало нам четкое понимание того, что именно учитывать в работе с дизайном (и не только дизайном).
Основная идея этого исследования заключалась в том, что понимание когнитивных искажений к которым склонны наши пользователи даст нам четкую картину того, как именно они воспринимают информацию и какие у них ожидания при использовании системы.
Подобный подход при грамотном использовании значительно улучшает как качество продукта в целом, так и пользовательский опыт в частности.
Большая часть нашего исследования Персоны продукта может быть найдено в изображении, и по ссылке ниже:
#4. Главные сложности
Не смотря на наличие готовых ERP-продуктов на рынке, наш клиент не смог найти такое решение, которое бы соответствовало их критериям гибкости и машстабируемости.
Клиенту нужна была возможность полного контроля каждого аспекта работы каждого модуля. При этом Клиент хотел иметь возможность развивать каждый модуль системы независимо от остальной части. Скорость имплементации модификаций тоже была критична. Существующие рыночные решения (Например MS Dynamics 365) запрашивали от 6 до 12 месяцев на модификации, не считая крупных инвойсов за изменения.
Клиенту нужна была возможность полного контроля каждого аспекта работы каждого модуля. При этом Клиент хотел иметь возможность развивать каждый модуль системы независимо от остальной части. Скорость имплементации модификаций тоже была критична. Существующие рыночные решения (Например MS Dynamics 365) запрашивали от 6 до 12 месяцев на модификации, не считая крупных инвойсов за изменения.
Другой сложностью было разработать крайне простую навигацию в системе, которая будет доступной для понимания для пользователей не сильно посвященных в нюансы работы комплексного софта.
#5. Информационная архитектура
Первым шагом для нас стала разработка информационной архитектуры проекта. Это позволило нам представить все модульные страницы проекта, связи между ними, а также пользовательские интеракции с системой (навигация).
Sitemap
#6. Дизайн эскизов (Wireframing)
Следующий шаг - эскизы. Мы исследовали приложения которые дольше всего использовали наши пользователи, чтобы реплицировать хороший опыт оттуда в наш проект. Так мы придерживаемся Закона Якоба, названного в честь исследователя UX Якоба Нильсена. Закон гласит, что пользователи проводят большую часть своего времени на других сайтах и в результате предпочитают сайты, которые работают так же, как уже знакомые им.
MAINFRAME - Каркас проекта
Наша ERP система состоит из двух секций: панель навигации и область отображения контента. Держа четкое визуальное разделение между инструментами навигации и контентом страницы мы избегаем рисков, где пользователь может "потеряться", либо не понять что произошло.
Разные исследования показали, что пользователи исследуют веб страницы в F-образном паттерне. F-паттерн — это самая распространенная траектория сканирования контента, организованного в форме блоков.
Сначала пользователи сканируют (читают) верхнюю часть страницы по горизонтали; это верхняя планка буквы “F”.
Затем, они сканируют вниз по левому краю экрана в поисках интересной информации. Наткнувшись на такую информацию, они начинают ее читать — то есть снова идут по горизонтали и формируют среднюю планку буквы “F”.
Затем, оставшийся контент сканируется по вертикали вниз.
Сначала пользователи сканируют (читают) верхнюю часть страницы по горизонтали; это верхняя планка буквы “F”.
Затем, они сканируют вниз по левому краю экрана в поисках интересной информации. Наткнувшись на такую информацию, они начинают ее читать — то есть снова идут по горизонтали и формируют среднюю планку буквы “F”.
Затем, оставшийся контент сканируется по вертикали вниз.
Конечно, в Арабской версии проекта F-паттерн будет обратным (справа-на-лево). Следственно, навигация и область контента также будут отображены зеркально.
FIELD BUILDER - Конструктор полей
Конструктор полей (Field Builder в PRD) состоит из страницы отображающей список существующих полей, а также рабочей области, позволяющей создавать новые поля. Было решено отобразить существующие поля в форме таблицы с данными.
Вообще, использование таблиц является одним из лучших способов отображения сложной-для-понимания информации в корпоративном ПО. Хорошо продуманная таблица может значительно улучшить как читабельность данных, так и простоту взаимодействия с ними.
При разработке таблицы необходимо задаться следующими вопросами:
При разработке таблицы необходимо задаться следующими вопросами:
- Какой цели служит таблица с данными для конкретного пользователя? Как эти данные используются?
- Какие устройства будут использовать пользователи для просмотра таблицы?
- Как именно пользователи должны взаимодействовать с таблицей?
Обычно, все это детально описывается продакт менеджерами в PRD.
В нашем случае, в этом документе мы видим, что страница Конструктора Полей - это контейнер отображающий все существующие поля в системе. Помимо этого, система также показывает метаданные по каждому полю. Метаданные в свою очередь напрямую связаны с бизнес интересами пользователей, у которых есть доступ к этой странице.
В нашем случае, в этом документе мы видим, что страница Конструктора Полей - это контейнер отображающий все существующие поля в системе. Помимо этого, система также показывает метаданные по каждому полю. Метаданные в свою очередь напрямую связаны с бизнес интересами пользователей, у которых есть доступ к этой странице.
Через некоторое время проведенное за исследованием документа и других данных, наш скетч страницы выглядит так:
СОЗДАНИЕ НОВЫХ ПОЛЕЙ
Теперь мы должны приготовить страницы, где пользователи будут создавать новые поля. Вкратце, основные моменты по этому пункту в нашем PRD выглядят так:
- Пользователь должен иметь возможность создавать индивидуальные, либо системные поля. В сумме выбор делается из девяти типов полей;
- Пользователь должен иметь возможность конфигурировать любое поле;
- Пользователь должен иметь возможность обзора создаваемого поля, до его сохранения. Так, отображение создаваемого поля должно быть как при создании, так и при редактировании.
Один из первых вопросов который у нас возник звучал так: "А стоит ли нам, запуская процесс создания поля, открывать его как новую страницу в системе? Или нам достаточно использовать всплывающее окно?"
Главным аргументом в пользу отдельной страницы являлась масштабируемость такого решения. Конечно, всплывающее окно выглядело более компактным, "легким" решением.
В поисках истины мы провели ряд встреч с клиентом, поняли степень масштабируемости, нужной для их бизнеса, и решили использовать всплывающее окно.
Основным аргументом стало то, что в ближайшие пару лет никакого серъезного изменения функционала в workflow-е создания новых полей не ожидалось.
Основным аргументом стало то, что в ближайшие пару лет никакого серъезного изменения функционала в workflow-е создания новых полей не ожидалось.
Другие аргументы в пользу всплывающего окна:
- Всплывающее окно предоставляет более "легкий на глаз", комфортный опыт, т.к. пользователям не приходится переходить на другую страницу. Этот подход в целом снижает когнитивную нагрузку на пользователя;
- Отдельная страница с тем объемом функционала, который требовался, могла казаться пользователям чрезмерностью;
- Для MVP (Minimum Viable Product, минимальное решение, достаточное для запуска продукта), всплывающего окна было достаточно.
#7. UI дизайн и прототипирование
Теперь, когда у нас было скетчи и первые варианты прототипов с низкой детализацией, мы хотели провести несколько итераций и завершить дизайн и прототипирование.
При выборе цветовой гаммы, мы выбирали из наиболее нейтральных. Причина в том, что наши пользователи собирались использовать продукт на протяжении многих часов каждый день. Мы же хотели избежать любого потенциально возможного раздражения от интерфейса.
При выборе цветовой гаммы, мы выбирали из наиболее нейтральных. Причина в том, что наши пользователи собирались использовать продукт на протяжении многих часов каждый день. Мы же хотели избежать любого потенциально возможного раздражения от интерфейса.
В результате мы взяли наиболее тихие, чистые, простые цвета, не требующие чрезмерного внимания от пользователя.
В стилистике компонентов мы использовали закругленные углы (без чрезмерностей).
Основным шрифтом был выбран Proxima Nova - хороший шрифт предоставляющий компромиссное решение отвечающее критериям баланса, эстетики и чистоты.
В стилистике компонентов мы использовали закругленные углы (без чрезмерностей).
Основным шрифтом был выбран Proxima Nova - хороший шрифт предоставляющий компромиссное решение отвечающее критериям баланса, эстетики и чистоты.
#8. Итерации дизайна
Процесс дизайна постоянен и цикличен. Разработка любого цифрового опыта представляет собой живой проект, который нужно постоянно улучшать и "настраивать". Для этого мы используем такие инструменты как прототипирование, тестирование с пользователями и частные ДЕМО с нашими коллегами.
Все эти шаги повторяются постоянно, до достижения наилучшего результата.
Все эти шаги повторяются постоянно, до достижения наилучшего результата.
Не смотря на то, что мы провели несколько месяцев на этой стадии работы на проекте и повторяли все эти шаги десятки раз, в какой-то момент мы решили взять паузу. Это было буквально перед передачей проекта команде инженеров.
Идея была в том, чтобы взяв паузу, взглянуть на проект "свысока", оценить всю картину и понять, не пропустили ли мы что-либо. Так как практически весь проект мы только и делали что "углублялись" в детали, мы легко могли упустить какие-то детали в процессе.
Как результат этой технической паузы, мы вывели множество улучшений в разных категориях. Наиболее релевантные улучшения для этой стати приведены далее:
УЛУЧШЕНИЕ ТАБЛИЦЫ ДАННЫХ
- Выравнивание контента
В зависимости от того, отображается ли текстовая или числовая информация в таблице, подходы к их визуализации разные.
Числовые данные в наших таблицах были выравнены по левому краю, что сказывалось негативно на читабельность. Мы выровняли их по правому краю.
Разные исследования показали, что подход, при которым числовые данные выравниваются по правому краю значительно улучшает как их читабельность, так и возможность сравнивать числа в одной колонке.
Следует добавить, что в этом правиле бывают и исключения. Так, при работе с телефоными номерами, календарными датами и почтовыми индексами, выравнивание по левому краю может быть хорошей опцией. - Избегание дубликатов в наименованиях
Мы нашли ряд дубликатов в названиях колонок. Упростив названия колонок мы значительно снизили шум в таблицах.
УЛУЧШЕНИЕ КОНСТРУКТУРА ПОЛЕЙ
После очередного раунда валидации нашего продукта (прототипированная версия в Figma) с пользователями, они пришли к выводу, что им необходимо иметь возможность создавать группы полей, а также иерархию полей. Так, например, они хотели иметь возможность создавать поле "Национальность", и привязывать результаты этого поля к отображению других полей, появляющихся после выбора какого-то значения здесь.
Единственным решением для достижения этой цели была реструктуризация того, как пользователь создает поля.
Всплывающее окно создания полей мы убрали сразу - теперь оно точно не подходило под нужды бизнеса. На замену ему пришла полноценная страница.
Всплывающее окно создания полей мы убрали сразу - теперь оно точно не подходило под нужды бизнеса. На замену ему пришла полноценная страница.
Мы также использовали концепт описанный в книге "About Face. The Essentials of Interaction Design" автора Алана Купера, которую Кристина в это время читала. Концепт о котором говорится звучит так:
«Программы, которые монополизируют внимание пользователей в течение длительного периода времени, являются приложениями суверенной позиции. Суверенные приложения предлагают большой набор связанных функций и пользователи, как правило, поддерживают их в рабочем состоянии и работают непрерывно, занимая весь экран».
«Программы, которые монополизируют внимание пользователей в течение длительного периода времени, являются приложениями суверенной позиции. Суверенные приложения предлагают большой набор связанных функций и пользователи, как правило, поддерживают их в рабочем состоянии и работают непрерывно, занимая весь экран».
В случае с нашей ERP системой, нам с первого дня было известно, что пользователи будут посвящать бОльшую часть своего рабочего времени на работу с системой. Следственно, Конструктор Полей подходит под описание концепции "суверенной позиции". Это значит, что нам не следует как-либо ограничивать рабочее пространство.
Как результат, мы обновили страницу конструктора, с учетом концепции Алана Купера, а также требований клиента (возможность создавать группы полей, а также создавать отношения между ними).
Для настройки отношений (Parent field - child-field) между полями, мы задействовали внешнюю индикацию. Для создания отношения мы использовали drag and drop. Наша гипотеза состояла в том, что это наиболее удобное решение, так как ему очень легко научиться из-за близости этой аналогии с тем, как наши клиенты работают с физическими папками и файлами на их рабочих столах.
Помимо этого, функционал drag and drop дает возможность с легкостью изменять отношения между полями.
#9. ПОЛЬЗОВАТЕЛЬСКОЕ ТЕСТИРОВАНИЕ
Последний шаг перед завершением стадии дизайна и прототипирования, это тестирование юзабилити решения с пользователями. Для этого мы предоставили доступ к системе нескольким пользователям из разных департаментов в организации клиента, передали им основные инструкции и стали ждать фидбэк.
Не смотря на то, что мы постоянно показывали клиенту каждое наше решение и валидировали каждый шаг с будущими пользователями системы, мы подготовили полноценный прототип проекта в Figma, в виде более четырех сотен страниц.
В процессе финального демо нашего ремастеринга "Конструктора Полей", нам стало очевидно, что связи parent-child между полями не достаточно очевидны. Их отображение слишком неявное. Поэтому последним штрихом стало добавление небольшого индикатора четко показывающее принадлежность и связь каждого поля.
Эта модификация стала последней в этой части системы, а позже и весь проект был успешно подведен к стадии разработки.
Спасибо за внимание.