Краткий ответ
Дополнительные пять секунд на каждый ввод, умноженные на тридцать вводов в день, умноженные на сто пользователей – это полноценный рабочий день, который ежедневно теряется из-за перегруженного интерфейса. Упрощение UX, как правило, является наиболее высокодоходным действием, которое можно предпринять в существующей системе, и почти всегда основывается на удалении, а не на создании элементов.
Достаточно трех инструментов: аудит использования полей, трехкликовый тест для каждой ключевой задачи и адаптация макета в соответствии с ролью и этапом процесса.
Почему экраны разрастаются
Никто не проектирует экран с 80 полями. Он формируется в течение семи лет благодаря точечным запросам, каждый из которых по отдельности был обоснован. Повторяются три механизма:
- Запрос "только одно поле" — кажущаяся нулевой предельная стоимость оборачивается огромной совокупной стоимостью.
- Поле, которое осталось после изменения процесса — никто не несет ответственности за его удаление.
- "Запасное" поле — "возможно, оно понадобится для отчета в будущем".
Поэтому упрощение — это не разовый проект, а постоянная практика: каждый запрос на новое поле требует указания поля, которое будет удалено, или четкого обоснования.
Шаг 1 — Аудит использования полей
Для каждого основного объекта создается таблица с четырьмя столбцами: процент заполнения за последние 12 месяцев, использование в отчетах, использование в автоматизациях и интеграциях, а также заявленный владелец процесса.
| Вывод | Интерпретация | Решение |
|---|---|---|
| Заполнение менее 10%, не используется в отчетах | Заброшенное поле | Удаление из макета |
| Высокое заполнение, не используется в отчетах | Работа, не востребованная никем | Уточнение у владельца процесса |
| Низкое заполнение, обязательное поле | Пользователи вводят произвольное значение | Отмена обязательности или изменение на Picklist |
| Высокое заполнение и использование в отчетах | Активное поле | Оставить, возможно, переместить вперед |
Третья строка наиболее опасна: обязательное поле, заполненное фиктивным значением, загрязняет данные и подрывает доверие.
Шаг 2 — Трехкликовый тест
Для каждой ключевой задачи — обновление этапа, документирование звонка, закрытие обращения — подсчитывается количество кликов и экранов от начала намерения до завершения. Более трех кликов для ежедневной задачи оправдывает исправление.
Доступные инструменты: Quick Actions вместо открытия полной записи, редактирование из списка, Path с направляющими полями для каждого этапа и компоненты, которые появляются только в релевантном контексте. Руководящий вопрос всегда один: что пользователь пришел сюда делать и что ему мешает.
Шаг 3 — Макет по роли, а не по объекту
Единый экран для всех ролей — это объединение всех потребностей, то есть плохо для всех. Торговому представителю нужно восемь полей; операционному менеджеру — пять других; бэк-офису — поля для подтверждения, которым нет места у первых двух.
Разделение по типу записи (Record Type) и профилю в сочетании с динамическими формами (Dynamic Forms) для условного отображения в зависимости от этапа сокращает экран из 60 полей до экрана из 12 релевантных полей. Важно: условное отображение не заменяет бизнес-решение о том, что вообще требуется.
Шаг 4 — Домашняя страница как рабочий список
Первый экран, который видит пользователь, должен отвечать на вопрос "Что мне нужно делать сейчас?", а не показывать общие графики. Список задач, отсортированный по приоритету, "зависшие" элементы и аномалии, требующие внимания. Это ежедневная отдача, которая оправдывает ввод данных, и это ключевой фактор восстановления использования — см. Повышение приживаемости Salesforce.
Измерение: до и после
Перед корректировкой измеряется среднее время выполнения трех основных задач пятью реальными пользователями с секундомером. После корректировки измерения повторяются тем же методом. Снижение времени выполнения задачи на 30% и более является приемлемым результатом для первой волны упрощения.
Помимо этого, отслеживаются качество данных и процент выполнения ключевого действия в соответствии с метриками использования Salesforce. Истинное упрощение улучшает оба показателя; если время сократилось, но качество пострадало, значит, было удалено необходимое поле.
Возражения и как на них отвечать
"Но поле нужно для отчета" — кто использовал этот отчет в прошлом году? "Менеджер X его запросил" — существует ли процесс, который его оправдывал? "Возможно, понадобится в будущем" — его можно вернуть в течение часа, а исторические данные сохраняются даже после удаления из макета.
Эти возражения решаются в рамках процесса организационных изменений, а не как техническая дискуссия — см. Управление изменениями Salesforce.
Заключение
Проведите аудит использования полей, удалите заброшенные, сократите обязательные поля до двух на каждом этапе, создайте макет в соответствии с ролью и превратите домашнюю страницу в рабочий список. Измерьте время выполнения задач до и после — это доказательство, которое оправдает следующую волну улучшений.
