Все статьи

Как повысить эффективность внутренней системы

Унифицируем элементы интерфейса: UI-kit

Повышаем удобство: библиотека типовых решений

Унифицируем процессы: библиотека паттернов

Проверяем решения: юзабилити-тестирование и оценка по модели GOMS

В городе Сан-Хосе в штате Калифорния (США) стоит здание, известное как дом Винчестеров. Его хозяйка, спасаясь от родового проклятия, всю жизнь достраивала и расширяла его. Когда после ее смерти строительство прекратилось, оказалось, что в доме есть около 160 комнат, 13 ванных, 6 кухонь, 40 лестниц и более 10000 окон, причем часть лестниц упираются в потолок, а некоторые окна вделаны в пол. Жить в таком доме невозможно, хотя снаружи он выглядит нарядно.

Дом Винчестеров (источник фото: flickr, автор: Gregg O'Connel, распространяется по лицензии CC BY 2.0)

Внутренние системы крупных компаний похожи на этот дом, с той разницей, что дом создавался настолько хаотичным специально, а внутренние системы становятся такими в ходе естественного развития. На протяжении многих лет с момента их появления в компании в них добавляют новые бизнес-процессы и новые роли пользователей, меняются команды разработчиков и технологии. В результате оказывается, что логика их работы не соответствует реальному рабочему процессу, некоторые функции дублируют друг друга, а однотипные элементы на разных экранах оформлены по-разному. Работать с такими системами сложно, сотрудники даже после специального обучения постоянно делают ошибки, а самое главное — даже руководители компании не знают, как вся система устроена.

Рано или поздно руководство компании решает, что пора навести порядок в системе, чтобы сделать ее эффективнее. В этой статье мы расскажем, как с этой задачей справляются UX-аналитики. В зависимости от масштаба изменений, на которые готова пойти компания, аналитик может составить UI-kit, библиотеку типовых решений или библиотеку паттернов.

Унифицируем элементы интерфейса: UI-kit

Когда в компании отсутствуют единые стандарты разработки интерфейса, разработчики создают новые экраны, руководствуясь только техническим заданием и здравым смыслом. Они могут не помнить или не знать, как выглядят некоторые элементы интерфейса на других экранах системы, и вынуждены каждый раз заново придумывать их оформление. Это увеличивает время разработки, а элементы интерфейса с одинаковыми функциями в разных частях системы оказываются оформлены по-разному.

Кажется, что это не страшно: пользователь все равно найдет нужную кнопку, независимо от того, как она выглядит. Но на самом деле из-за подобных различий в оформлении пользователи тратят лишние секунды на то, чтобы на каждом экране найти нужный элемент интерфейса и разобраться с его функцией. Другие проблемы могут быть более серьезными. Например, изучая систему одного из наших клиентов, наши аналитики выяснили, что поля различных типов визуально ничем не отличались друг от друга. Из-за этого даже опытные сотрудники тратили лишние секунды на то, чтобы понять, какое действие от них сейчас требуется. Кажется, что секунда — это совсем немного, но в течение рабочего дня секунды, потраченные на работу с интерфейсом, складываются в минуты и часы, которые можно было бы потратить на что-нибудь более полезное для компании. UI-kit позволяет исправить подобные проблемы.

Пример проблемы, связанной с отсутствием единого стандарта оформления интерфейсов. Три поля, обведенные в красную рамку, выглядят одинаково, хотя на самом деле это три разных элемента интерфейса: текстовое поле, поле с предиктивным поиском по списку и поле с выпадающим иерархическим списком.

Для создания UI-кита требуется совместная работа дизайнера и аналитика. Аналитик изучает систему и составляет список всех элементов интерфейса, которые в ней использованы. Элементы интерфейса — это всё, с чем взаимодействует пользователь:

  • тексты и надписи (заголовки, названия полей, плейсхолдеров и вкладок, надписи на кнопках, сообщения об ошибках и т.п.);
  • кнопки;
  • вкладки;
  • тултипы;
  • поля;
  • чекбоксы и радиобаттоны;
  • выпадающие списки;
  • и т.п.

Даже на этой стадии работы аналитик общается с пользователями, разбирает некоторые процессы и консультируется с разработчиками. В результате он определяет, какие элементы в системе лишние, каких не хватает, какие неправильно оформлены, а какие можно оставить без изменений. После этого дизайнер под его руководством сводит в единый документ требования к оформлению, размерам и поведению всех элементов интерфейса, так, чтобы пользователю было удобно отличать их друг от друга и удобно взаимодействовать с ними. Такой документ и называется «UI-kit».

UI-kit начинается с описания шрифтов и цветов, которые будут использоваться в системе. Шрифты и цвета важны, поскольку позволяют расставить визуальные приоритеты на странице и закодировать информацию о типе элемента и его состоянии. Благодаря правильному кодированию пользователь, даже бросив беглый взгляд на экран, может понять, где на нем основное и вспомогательное меню, какие кнопки и поля активны, а какие заблокированы, есть ли на экране сообщения об ошибке и т.д.

Страница из UI-kitа, на которой перечислены все цвета, использованные в системе

После цветов и типографики показаны все остальные элементы интерфейса во всех возможных состояниях.

Часть UI-kit, посвященная кнопкам и ссылкам. Показаны размеры кнопок, оформление основных, вспомогательных и заблокированных кнопок, а также изменения цвета при наведении курсора и нажатии.

Благодаря UI-kit интерфейс становится более единообразным, аккуратным и удобным. Это хорошо, потому что, усвоив, как выглядит иконка поиска или обязательное для заполнения поле на одном экране, пользователи с легкостью найдут их на всех остальных, и благодаря этому им станет легче работать с системой. Кроме того, UI-kit несколько удешевляет разработку, потому что позволяет ставить разработчикам задачу на интерфейсном уровне, и им больше не приходится заново придумывать внешний вид кнопок и полей. Однако UI-kit не показывает, как правильно располагать кнопки и поля, чтобы пользователям было удобно работать с системой и не содержит требований к реализации в интерфейсе однотипных процессов. Эту задачу выполняют библиотеки типовых решений и библиотеки паттернов, но для их создания нужна аналитическая работа более высокого уровня.

Повышаем удобство: библиотека типовых решений

Гораздо более серьезную проблему, чем неконсистентные интерфейсы, представляют собой интерфейсы, не соответствующие реальному рабочему процессу пользователей. Они вынуждают пользователей делать ненужные шаги при вводе данных, провоцируют на ошибки и вызывают негативные эмоции.

В нашей практике был случай, когда CRM была настолько плохо спроектирована, что не облегчала сотрудникам работу, а затрудняла ее. Для того, чтобы корректно ввести данные в систему, сотрудникам приходилось задерживаться после работы на два-три часа. При этом на некоторых экранах от сотрудников требовалось ввести данные, которыми они на данном этапе работы с клиентом не располагали, и они были вынуждены вводить в систему ложные данные. Надо ли говорить, что они ненавидели ее, а CRM с ложными данными была бесполезна для бизнеса. В другой компании ненависть к внутренней системе была настолько сильна, что важным негласным требованием к новому интерфейсу стало полное отсутствие сходства со старым. В противном случае сотрудники даже не стали бы пробовать им воспользоваться.

Отрывок из отчета об экспертной оценке CRM-системы. Несоответствие порядка разделов, вкладок и полей потребностям пользователей — характерная для системы проблема.

Чтобы устранить подобные проблемы, аналитику понадобится доступ к сотрудникам компании и их рабочим местам, чтобы он мог понаблюдать, как они на самом деле работают с системой. Ему необходимо выяснить:

  • на каких этапах рабочего процесса они обращаются к системе;
  • с какими полями, формами, вкладками, экранами работают;
  • какие вспомогательные средства используют (другие системы, справочники, записи и т.п.);
  • с какими сложностями при работе с системой сталкиваются и как с ними справляются.

Изучив пользователей, аналитик понимает, как сделать систему удобнее: удалить избыточные сущности, добавить недостающие, изменить порядок полей и вкладок или даже поменять логику некоторых процессов. Требования к изменению системы он передает проектировщику, который создает макеты новых экранов. Таким образом удается сократить количество действий, необходимых для совершения одной операции в системе, и, следовательно, повысить эффективность работы сотрудников.

Пример из отчета по оценке системы. Аналитик обнаружил проблему: расположение и ширина столбцов в таблице не соответствуют потребностям пользователей. Рекомендации по устранению этой и других проблем лягут в основу библиотеки типовых решений.

Макеты всех экранов и более мелких элементов (форм, фильтров, наборов вкладок, всплывающих окон и т.п.), с которыми пользователи работают в рамках уже существующих бизнес-процессов, аналитик сводит в единый документ — библиотеку типовых решений. Этот документ руководство может передать разработчикам, чтобы на его основе они изменили существующий интерфейс системы или создали новый.

Библиотека типовых решений содержит макеты как целых экранов, так и их отдельных элементов, как, например, этого фильтра на иллюстрации

Библиотека типовых решений позволяет существенно улучшить систему и увеличить скорость работы сотрудников (о том, как измерить эффект от изменений, мы напишем дальше). Однако, если в систему необходимо будет добавить новые роли или функции, разработчикам придется заново придумывать, как должны выглядеть соответствующие экраны, и нет гарантий, что их решение будет оптимальным. Эту проблему решает библиотека паттернов.

Унифицируем процессы: библиотека паттернов

Паттерн — набор действий в системе, не зависящий от информации, с которой работает пользователь. Паттерны могут быть низкоуровневыми и касаться частных действий в системе («перемещение между полями», «поиск») или высокоуровневыми и касаться целых смысловых блоков в бизнес-процессах («идентификация потребности клиента» или даже «выход из тела процесса»).

Библиотека паттернов представляет собой набор шаблонов, которые позволяют создавать новые страницы для новых ролей и процессов, не нарушая консистентность интерфейса. Если интерфейс системы одинаково структурирован для всех бизнес-процессов, то сотрудники быстро к нему привыкают, не тратят время на поиск нужных элементов управления, делают меньше ошибок и легче осваивают новые задачи при получении новой роли.

Пример низкоуровневого паттерна: переключение между элементами управления при помощи клавиатуры

Для создания библиотеки паттернов UX-аналитик исследует, как сотрудники компании, представляющие различные бизнес-роли, работают с системой, и выявляет в их деятельности общие смысловые блоки. Затем вместе с проектировщиком он унифицирует эти блоки, чтобы в интерфейсе они отображались одинаково независимо от того, какой информацией они наполнены. Проектировщик создает макеты, демонстрирующие реализацию найденного паттерна в интерфейсе, аналитик описывает, в каком случае их стоит использовать.

Пример паттерна проектирования «определить вероятный запрос пользователя»

В идеальном случае унификация смысловых блоков должна затрагивать не только интерфейс, но и бизнес-процессы в компании. Например, в концепции Единой фронтальной системы Сбербанка первичной является потребность клиента, с которой он обратился к оператору, независимо от содержания этой потребности и от того, физическое это лицо или юридическое. Однако в зависимости от роли сотрудника или принятой в отделении тактики работы набор смысловых блоков, из которых состоит интерфейс, может меняться.

Адаптация интерфейса операциониста в зависимости от тактики работы отделения банка

Как правило, библиотека паттернов создается одновременно с библиотекой типовых решений и UI-kitом. Все три библиотеки объединяются в единую дизайн-систему. Польза дизайн-системы для оптимизации интерфейсов и процессов в компании максимальна. Благодаря ей интерфейс будет всегда консистентным и масштабируемым, а пользователю при смене роли не придется переучиваться.

Проверяем решения: юзабилити-тестирование и оценка по модели GOMS

Все решения, принятые в ходе создания UI-kitа, библиотеки типовых решений или библиотеки паттернов, нужно проверить на пользователях системы. Необходимо удостовериться, что пользователи понимают, как взаимодействовать с интерфейсом и что новый интерфейс действительно облегчит им работу.

Для тестирования создается кликабельный прототип системы, соответствующий новым требованиям. Аналитик просит пользователей выполнить в нем типовые для системы задачи. Это позволяет выявить и скорректировать недостатки новых решений до того, как они пойдут в разработку.

Отрывок из отчета о тестировании макета банковского call-центра. Оказалось, что специалистам не хватает в макете определенной информации.

Юзабилити-тестирование позволяет понять, насколько новый интерфейс будет удобен и понятен для пользователей. Удобный интерфейс позволяет повысить бизнес-эффективность системы. Чем меньше времени пользователь тратит на то, чтобы выполнить в системе свою задачу, чем меньше действий ему для этого требуется, тем система эффективнее.

Оценить эффективность любой системы можно при помощи группы методов GOMS (от английского Goals, Operators, Methods, and Selection rules). Для этого задачу, которую пользователь выполняет в системе (например, «корректировка информации об участнике сделки»), раскладывают на элементарные действия: перемещение курсора мыши, нажатие на клавишу клавиатуры и т.п. Существуют таблицы с экспериментально вычисленными значениями времени для каждого такого действия. Используя эти таблицы, аналитик вычисляет чистое время, которое пользователь тратит на работу с интерфейсом системы.

Операция, время Название Смысл
M = 1,2 c Ментальная подготовка Время, необходимое для умственной подготовки к следующему шагу, т.е. принятие решения о действии на следующем шаге
P = 1,1 c Указание мышкой Время, необходимое для указания на какую-то позицию на экране монитора. Фактически перемещение курсора мыши
H = 0,4 c Перемещение руки с клавиатуры на мышь или обратно Время, необходимое для перемещения руки с клавиатуры на ГУВ или с ГУВ на клавиатуру. Фактически взятие или бросание мыши
Операция, время Название Смысл
M = 1,2 c Ментальная подготовка Время, необходимое для умственной подготовки к следующему шагу, т.е. принятие решения о действии на следующем шаге
P = 1,1 c Указание мышкой Время, необходимое для указания на какую-то позицию на экране монитора. Фактически перемещение курсора мыши
H = 0,4 c Перемещение руки с клавиатуры на мышь или обратно Время, необходимое для перемещения руки с клавиатуры на ГУВ или с ГУВ на клавиатуру. Фактически взятие или бросание мыши

Пример кодирования операций для оценки интерфейса

Таким образом, GOMS позволяет оценить эффективность старого и нового интерфейса системы, причем для оценки нового интерфейса достаточно его кликабельного прототипа. Например, при экспертной оценке внутренней системы одного банка мы выделили ряд сквозных изменений, которые позволили повысить эффективность ряда операций на 20-60%.

Отрывок из отчета об оценке макетов нового интерфейса банковской CRM по модели NGOMSL. Для первой задачи выигрыш по времени составил 35%, для второй — 63%.

Заключение

Одним из показателей уровня зрелости системы является скорость, с которой ее можно изменить. Документы, которым посвящена эта статья (UI-kit, библиотека готовых решений и библиотека паттернов), позволяют сделать систему более зрелой, более гибкой и более легко изменяемой.

Если ресурсы позволяют, изменение существующего продукта или разработку нового лучше всего сразу начать с создания дизайн-системы, потому что взятые вне дизайн-системы UI-kitы или библиотеки решений не могут обеспечить единообразие интерфейсов и процессов, с которыми работают сотрудники. Использование дизайн-систем позволяет:

  • повысить эффективность работы сотрудников компании: пользователи смогут выполнять больше задач с меньшими усилиями;
  • сократить время обучения сотрудников, так как однородный интерфейс помогает новичку понять, что надо делать на каждом экране;
  • уменьшить затраты на разработку интерфейсов для новых бизнес-процессов, так как разработчики смогут использовать готовые компоненты, шаблоны и паттерны интерфейсов, и им не придется больше заново придумывать, как должны быть оформлены экраны системы;
  • сохранить консистентность системы даже при работе нескольких десятков распределённых команд, благодаря чему система никогда больше не превратится в неуправляемого монстра;
  • унифицировать не только внешний вид системы, но и процессы в компании.

Если же компания не готова к настолько глобальным изменениям, стоит начать с малого и перепроектировать несколько ключевых процессов. Вы увидите, насколько повысится эффективность системы и удовлетворенность ее пользователей, и это станет мотивацией для дальнейшей работы.

Чтобы подробнее узнать, как наша компания может помочь вам повысить эффективность вашей внутренней системы, напишите Дмитрию Силаеву: d.silaev@usabilitylab.net. Он ответит на все ваши вопросы.

Тэги

Поделиться статьёй

Поделитесь своим мнением
Стоила ли статья потраченного времени?