Как мы решили UX-проблему BPF в Dynamics 365
Стандартные инструменты Dynamics 365 часто позволяют решить задачу без дополнительной разработки. Но что делать, если технически всё работает, а пользователю при этом неудобно?
В этой статье мы разберём реальный кейс работы со сложной формой в Dynamics 365, где стандартный Business Process Flow не дал нужного пользовательского опыта. Покажем, с какими ограничениями мы столкнулись, какие подходы попробовали и почему в итоге выбрали гибридное решение вместо полной кастомизации.
А узнать больше можно в нашем видео:
Проблема со стандартным BPF
Форма содержала большое количество информации:
поля с разными типами данных;
подгриды;
PCF-компоненты;
дополнительные скрипты и бизнес-логику;
несколько связанных этапов процесса.
Опытные пользователи хорошо ориентировались в системе. Но для новых пользователей возникали вопросы:
с чего начинать;
какие данные заполнять в первую очередь;
когда сохранять запись;
когда можно переходить дальше;
что именно нужно сделать на каждом этапе.
Поэтому мы решили использовать Business Process Flow (BPF) как навигатор по процессу.
Но стандартный BPF быстро показал свои ограничения.
С какими ограничениями мы столкнулись?
При большом количестве этапов весь процесс сложно увидеть целиком.
Длинные названия стадий плохо помещаются в интерфейсе.
Некоторые PCF-компоненты нельзя использовать так же, как на стандартной форме.
Сложно добавить дополнительные описания и подсказки для пользователя.
Ограниченное пространство ухудшает восприятие сложного процесса.
В результате BPF технически выполнял свою задачу, но не давал того UX, который нам был нужен.
Попытка адаптировать стандартный подход
Сначала мы попробовали оставить BPF и добавить дополнительную логику.
Например, при переходе на определённый этап пользователь автоматически попадал на соответствующую вкладку формы.
Это работало технически, но создавало новые UX-проблемы:
интерфейс мог неожиданно переключаться;
пользователь мог терять контекст;
некоторые этапы всё равно оставались слишком общими.
Стало понятно, что нам нужен другой подход.
Почему мы не сделали всё кастомным
Очевидным решением было полностью заменить стандартную форму собственным интерфейсом.
Но тогда пришлось бы заново реализовывать уже существующую функциональность:
валидацию полей;
lookup-поля;
PCF-компоненты;
JavaScript;
существующие web resources;
обязательные поля;
бизнес-логику.
Это означало бы значительно больше разработки и, что особенно важно, больше поддержки в будущем.
Поэтому мы решили не переписывать то, что уже работает.
Гибридное решение
Вместо стандартного BPF мы создали собственный Guide внутри формы.
Идея простая:
слева — процесс, справа — стандартная форма.
Пользователь видит:
все этапы процесса;
краткое описание каждого этапа;
текущий этап;
уже пройденные этапы;
необходимую информацию для текущего шага.
При этом сама форма Dynamics 365 продолжает работать стандартным образом.
Это позволило сохранить:
существующие поля;
PCF-компоненты;
скрипты;
валидацию;
бизнес-логику;
привычное поведение формы.
Что изменилось для пользователя
Новый подход сделал процесс более понятным:
пользователь видит весь процесс целиком;
понимает, на каком этапе находится;
знает, что нужно сделать дальше;
может вернуться к предыдущему этапу;
не теряет привычную форму Dynamics 365.
Дополнительно мы решили проблему с сохранением записи.
При переходе на следующий этап форма сохраняется, поэтому к моменту работы с подгридами запись уже существует.
Итог
Этот кейс показал, что стандартное решение не всегда является лучшим решением с точки зрения UX.
Но это не означает, что нужно сразу создавать полностью кастомный интерфейс.
В нашем случае оптимальным оказался гибридный подход:
стандартную функциональность Dynamics 365 мы сохранили;
стандартный BPF заменили более удобной навигацией;
существующую бизнес-логику не переписывали;
кастомизировали только ту часть, которая действительно создавала проблему.
В итоге мы получили более понятный процесс для пользователей без необходимости полностью переделывать существующую форму.
Comments