Всем привет! Я – аналитик 1С, и, благодаря своей работе, часто сталкиваюсь с разработкой пользовательского интерфейса. За годы практики у меня сформировалось собственное видение идеального интерфейса, которым хочется поделиться. Предупреждаю: статья начнётся издалека, но потом мы перейдём непосредственно к когнитивной нагрузке.
Особенности интерфейсов 1С и роль UX/UI дизайна
Особенность интерфейсов 1С заключается в том, что многие функции и возможности определяются платформой и антологией продуктов 1С. Редко в команде разработки есть UX/UI дизайнер, и, честно говоря, часто разработчики довольно пренебрежительно относятся к этой специализации. Между тем, профессия UX/UI дизайнера существует не зря. Понятный, не противоречивый интерфейс, когда выполнение операции воспринимается как органичный шаг, а не досадная помеха, – это то, что отличает продукт, который пользователь воспринимает как инструмент, от "костыля", который лишь добавляет работы.
1 часть. Причины неудобства и громоздкости интерфейса
На мой взгляд, неудобство и громоздкость интерфейса можно объяснить несколькими причинами:
Насыщенность событиям в рамках одной операции.
Отсутствие чётко проработанного бизнес-процесса.
На первом пункте пока не буду останавливаться, раскрою его позже. Предлагаю поговорить о втором пункте.
Если бизнесу сказать, что у него отсутствует процесс, вам возразит, что задачи как-то выполняются. Если принять это за аксиому, всё пойдёт плохо. Никогда не говорите бизнесу, что у него нет процессов!
Как правило, ИТ специалисты работают с заказчиками из конкретных бизнес-подразделений (например, продажи или закупки). Для бизнес-подразделения его внутренний процесс выглядит конечным и самодостаточным, существуют в вакууме, представляя собой россыпь атомарных процессов. Например, в закупках можно выделить:
Процесс обработки заявки на закупку: от отправки запроса до одобрения руководством.
Процесс запроса предложений (RFQ/RFP): сбор информации, анализ, выбор.
Процесс размещения заказа: отправка, подтверждение.
Процесс получения и приемки товара/услуги: доставка, проверка, оформление.
Процесс оплаты счетов: проверка, согласование, оплата.
Процесс управления поставщиками: оценка эффективности, ведение базы данных, развитие отношений.
Процесс управления контрактами: создание, согласование, контроль исполнения.
Это ещё относительно зрелый взгляд на процессы. Зачастую, никто не знает всех цепочек бизнес-процесса из всех операций. В моей практике был случай, когда в компании вообще никто не знал этапы общего процесса материального обеспечения. Бизнесу это не мешало жить, хотя, возможно, было бы меньше суеты и переписок. Все решалось личными контактами, но работало. Хаос – первичен и органичен, но становится болезненным, когда людей, влияющих на процессы, становится больше, чем помещается за одним столом.
Отсюда второй тезис: для бизнеса жёсткое определение ролей внутри процесса – ограничение. Редко кто думает, что изолированные процессы практически не существуют. Роли перераспределяются по принципу – кто свободен, тот и делает. Чёткое разграничение обязанностей воспринимается как бюрократия. Был случай, когда бухгалтерия сознательно предоставила продажнику слишком много прав (изменение записей задним числом). Я обратила внимание главного бухгалтера на риски нарушения кассовой дисциплины. Главбух хитро улыбнулась, но через пару лет продажник выносил из компании выручку, используя расширенные права.
Таким образом, для бизнеса процесс – это фактические шаги, а не технология. Прозрачность процесса часто воспринимается как атака на конфиденциальность и безопасность.
Что понимают ИТ специалисты под "бизнес-процессом"?
Бизнес-процесс глазами ИТ-архитектора
ИТ-архитектор рассматривает бизнес-процесс как контекст, в котором работают информационные системы. Его задача – спроектировать архитектуру, поддерживающую и оптимизирующую этот процесс. Это стратегический взгляд "сверху вниз".
Фокус: Как ИТ может реализовать и улучшить бизнес-процесс. Определение необходимых систем и данных, их взаимодействие и требуемые интеграции.
Интересующие аспекты: Требования к данным, интеграции, масштабируемость, гибкость, безопасность и соответствие нормативным требованиям.
Результат работы: Проект архитектуры ИТ-систем, описывающий, как ИТ поддерживает и оптимизирует процесс.
Бизнес-процесс глазами ИТ-инженера
ИТ-инженер смотрит на бизнес-процесс как на набор задач, реализуемых с помощью кода и инфраструктуры. Это тактический, практический взгляд "снизу вверх".
Фокус: Как реализовать отдельные шаги бизнес-процесса в коде и инфраструктуре.
Интересующие аспекты: Технические требования, производительность, надёжность, интеграция и тестирование.
Результат работы: Рабочий код, настроенная инфраструктура и развёрнутое приложение, реализующее шаги бизнес-процесса.
Когнитивная нагрузка и принципы снижения
Дизайн интерфейсов – один из способов существенно снизить когнитивную нагрузку пользователя и повысить продуктивность его работы. Убеждён, этому способствует наличие бизнес-процессов, автоматизируемых ИТ-специалистами.
Что такое когнитивная нагрузка?
Когнитивная нагрузка (Cognitive Load) – это объем умственных усилий, требуемый дл�� выполнения задачи. Чем сложнее задача, тем выше нагрузка.
Почему это важно?
Высокая когнитивная нагрузка приводит к ошибкам, снижению производительности, стрессу, трудностям в обучении и снижению креативности.
Типы когнитивной нагрузки:
Внутренняя когнитивная нагрузка: Сложность самой задачи.
Внешняя когнитивная нагрузка: Нагрузка, вызванная плохим дизайном. Это то, что нужно минимизировать!
Релевантная когнитивная нагрузка: Нагрузка, связанная с обучением.
Принципы снижения когнитивной нагрузки:
Простота и минимализм: Избавьтесь от лишнего.
Четкость и ясность: Используйте понятный язык и иконки.
Визуальная иерархия: Выделите важное.
Согласованность: Используйте одни и те же элементы и шаблоны.
Обратная связь: Предоставляйте пользователю информацию о его действиях.
Контекстная помощь: Предоставляйте помощь, когда это необходимо.
Принципы юзабилити и дизайна, ориентированного на пользователя (User-Centered Design).
Приемы, которые я использую:
Вся информация, влияющая на процесс, должна быть вынесена в пользовательские настройки (оптимизация затрат на разработку и справочная информация).
Чёткое разделение ролей: даже при пересечении функционала роль не должна предоставлять избыточный функционал.
Принцип DRY (don’t repeat yourself): повторение функционала должно быть исключено.
Помощь пользователю в прохождении функционала, обеспечение одинакового результата при разных сценариях.
Практические советы как улучшить интерфейс и облегчить работу с ним:
Справочники.
Редко вижу, чтобы над справочниками вообще парились. Обычно дело в том, что большинство используемых справочников типовые. Что хочется выделить - информация в карточках справочника, которая влияет на работу функционала должна быть доступна для чтения явно.
Пример: добавленный признак в справочник «Физические лица» не был добавлен на форму, но существенно влиял на логику работы документа. Я получила задачу, комментарием к которой было емкое: «Просто магия какая‑то». Пожалуйста, не нужно магии. Программа не должна ставить пользователя в тупик и заставлять задумываться о сверхъестественном быстрее чем о логике бизнес‑ процесса.
Документы
Покажите связь документа с другими документами, которые являются его основанием или последователем. Покажите какие регистры затрагивает документ, покажите состояние документа, если он взаимодействует с внешней информационной системой. Не заставляйте пользователя гадать о последствиях и о том, возникли ли они вообще
Пример 1: при создании документа с тарификацией услуг отсутствовала прямая связь со спецификацией — источником данных, при попытке разобраться пользователь просто лез на стену, вдобавок документы были разбросаны по разным подсистемам без всякой логики.
Пример 2. Заявка на тендер, создаваемая в 1С, улетала на сайт торговой площадки без всякого уведомления успешно это произошло или нет. Нервы у закупщиков сдавали регулярно. Потому что то что выглядело как операция, которая предполагала 3 шага, растягивалась на час, закупщик был вынужден открывать сайт площадки и проверять поступила ли его заявка.
3. Обработки
Неочевидные последствия включение/ выключение флажков, неочевидная связь флажков и значения полей — все это зло. Если поля зависят от флажков, не нужно их выводить до установки флажка или показывать лишние поля после снятия влияющего флажка.
Пример: в обработке есть и флажок и поле. И работают они вместе, но при условии что флажок установлен и поле заполнено.
В заключение, хочу пожелать вам сохранять теплое отношение к пользователю и серьёзно относиться к его комфорту в работе, так как это напрямую влияет на эффективность компании. Программа должна быть для пользователя, а не наоборот. Интерфейс должен вести пользователя, а не пользователь — пробираться сквозь него.
Благодарю за внимание!
