разработка симуляторов и тренажёров по работе с программным обеспечением (ПО), методология дистанционного обучения/образования, интерфейс электронного курса, управление вниманием пользователя, юзабилити электронного курса, проверка знаний пользователя, автозаполнение данных, сторителлинг и персонажи для симуляторов ПО
Этот пост объединяет почти все ранее опубликованные в этом блоге записи по теме разработки симуляторов и тренажёров по работе с ПО.
Здесь представлено краткое описание улучшений симуляторов ПО, которые я разрабатывал. Почти все они представлены в том порядке, в котором они появились. Мне кажется, так будет понятнее, откуда "растут ноги" у того или иного улучшения и для чего все эти улучшения были сделаны. Отмечу, что далее будет сказано, в том числе, про не самые удачные изменения.
Итак, далее наглядный пример "кайдзенщины" (постепенные улучшения приводят к более весомым результатам). Ниже пойдет речь о том, как можно управлять вниманием пользователя в симуляторе, как сделать удобный интерфейс, как помочь пользователю осознать ценность навыка, который он получит после прохождения симулятора и т.д. Всё, что написано ниже, предлагаю воспринимать как сборник советов и рекомендаций.
Улучшение №1. Реалистичность интерфейса в симуляторе ПО.
Кнопки и др.элементы интерфейса реагируют на наведение на них указателя мыши, на щелчки по ним, как и должны реагировать (интерактивный элемент при обращении к нему должен тем или иным образом показывать, что с ним можно взаимодействовать). Кроме кнопок правильным будет сохранить и другие характеристики ПО; например, диалоговые окна имеет смысл делать не "алертовые", а оригинальные.
Другое дело, что это правило касается только тех кнопок и элементов, которые нужны для продолжения выполнения операции в рамках задания. Все прочие элементы "мертвы" (ни на какие действия пользователя реагировать не будут).
Почему "мёртвые" кнопки лучше сделать именно "мёртвыми". Дело в том, что если пользователь случайно обнаружит, что все кнопки нажимаются, но при этом ничего не происходит, то он может подумать, что:
- косяк симулятора (одно не работает, другое не работает = доверие к симулятору снижается);
- в симулируемом ПО будет тоже самое;
- действия пользователи ошибочны, но не ясно, в чём именно ошибка.
Вдобавок пользователь будет фрустрирован из-за того, что пользователь не получил ожидаемого эффекта от совершенного действия.
Улучшение №2. "Служба одного окна". Чтобы не загромождать интерфейс лишним инфомусором, пошаговая инструкция и комментарии к операции размещаются в рамках одного единственного окна-сообщения. Чтобы выделять сообщение на фоне интерфейса, рамка текстбокса сообщения сделана красной, а каждое новое сообщение появляется с небольшой задержкой и всегда в новом месте.
Красный цвет рамки окна сообщения позволяет моментально привлечь внимание пользователя. Тем более, именно красный цвет не будет вызывать нежелательные ассоциации с интерфейсом симулируемого ПО (ведь интерфейсы, как правило, не содержат элементов красного цвета). Задержка появления и появление сообщение в новом месте позволяет обращать на себя внимание пользователя каждый раз заново, как только содержание сообщения меняется.
Таким образом, оставляем только интерфейс симулируемого ПО + окно с пошаговой инструкцией. Во многих сторонних симуляторах я часто наблюдаю такую картину: на каждом кадре все время появляются какие-то новые окна - то по два, то по три. Все они разные (по цвету и стилистке). Но почему их именно столько и чем они друг от друга отличаются - не понятно, и понимать этого не хочется. Нет желания каждый раз о чём-то догадываться, пытаться понять "логику" происходящего на кадре.
Нет никакого смысла плодить лишние сущности (принцип "бритвы Оккама"). Внимание пользователя нужно сосредоточить на интерфейсе симулируемого ПО и на сообщении с пошаговой инструкцией. Источник сообщения должен быть один. В итоге пользователь, увидев один раз это сообщение, и не встретив по ходу прохождения симулятора других аналогов, будет двигаться в привычном для него темпе, не отвлекаясь постоянно на новые информаторы-раздражители.
Кстати, окно с сообщением легко скрывается, если навести указатель мыши на значок скрытия, который интегрирован в это же окно. В результате пользователь всегда имеет возможность посмотреть, что за этим окном находится (ведь бывает так, что объем текста в таком окне оказывается довольно-таки большим). Пользователь должен иметь возможность полного обзора содержимого интерфейса симулируемого ПО.
Улучшение №3. Выделение пошаговой инструкции (текста, в котором содержится указание к действию, которое пользователь должен произвести прямо сейчас).
Пошаговая инструкция внутри сообщения выделена значком "поинтер-курсора" (ручка с поднятым вверх пальцем), который указывает на то, что конкретная часть сообщения относится к тем действиям, которые пользователю нужно выполнить в данный момент.
"Мухи отдельно, котлеты отдельно": пользователь видит внутри сообщения отдельно информацию о том, какое действие нужно выполнить прямо сейчас, отдельно - комментарии, к примеру, о том, к чему приведёт это действие. Тем самым, мы выделяем внутри сообщения разные смысловые блоки.
Улучшение №4. Показать то, о чём сообщается в пошаговой инструкции.
В сообщении с пошаговой инструкцией названия кнопок или элементов, с которыми производится то или иное действие, выделено жирным + ссылкой, при наведении указателя на которую на целевом элементе появится прямоугольник выделения.
Таким образом, облегчаем жизнь пользователя. Совершенно ни к чему заставлять его искать по всему интерфейсу нужный в данный момент элемент. Особенно, когда их много. Особенно, когда часть кнопок не подписаны и обозначены только пиктограммой. И совершенно ни к чему в сообщении заменять название кнопки ее пиктограммой (например "кнопку сохранить" заменять на пиктограмму дискеты). Ведь таких кнопок в пределах кадра может оказаться несколько. И если не точно таких же, то очень на нее похожих.
Нужно понять, что симулятор - это не квест, в котором нужно что-то все время выискивать и догадываться непонятно о чем и зачем.
Дефект: разные типы ссылок в пошаговых инструкциях выглядят одинаково. В тексте пошаговой инструкции ссылки выделения подчеркнуты сплошной линией, то есть выглядят они как ссылки перехода. Некоторые пользователи опасаются "трогать" эти ссылки, так как не хотят появления новых окон, неожиданных переходов с текущего кадра куда-то еще. На самом деле при щелчке по большинству таких ссылок никаких переходов не будет, всплывающие окна не появятся. Зато при наведении указателя мыши на такую ссылку в интерфейсе симулируемого ПО появится выделенный фрагмент.
Однако в этих инструкциях могут быть и стандартные ссылки, при щелчке по которым появится всплывающее окно с дополнительной информацией. Но выглядеть оба типа ссылок будут абсолютно одинаково. В результате пользователь никогда наверняка не будет знать, к чему приведет его взаимодействие с той или иной ссылкой.
Дефект: почти все пространство на кадре занято интерфейсом симулируемого ПО. В первых курсах интерфейс симулируемого ПО пристыкован к границам кадра. Нет возможности посмотреть название раздела (темы).
Дефект (вообще-то громко сказано): появление источников данных в виде сканов документов. Текст инструкции и пояснения визуально разорваны с объектом, на который они ссылаются.
Улучшение №5. Появление описания задания на этапе его выполнения.
Я предоставил пользователю возможность на любом этапе выполнения задания посмотреть его описание, при этом не используя никаких дополнительных кнопок на панели навигации, не перегружая кадр лишними ссылками и "плавающими" объектами, предназначенных для показа этого описания.
Вызов всплывающего окна с описанием появляется по щелчку кнопку, интегрированную в пошаговую инструкцию. В тех курсах единственным незначительным минусом было то, что я использовал для размещения описания задания объект CL "Глоссарий" (он невероятно глючный).
В дальнейшем использовал объект "Окно-Помощь", а в последних версиях вместо встроенных навигационных объектов CL использую всплывающее окно, которое появляется в модальном режиме.
В одном из курсов-тренажёре показ описания задания выглядит следующим образом:
Такая "колбаса" нужна в тех случаях, когда пользователю необходимо иметь перед глазами множество данных, которые будут использованы при заполнении форм. Сообщение с описанием легко скрывается одним щелчком мыши.
Улучшение №6. Предупреждение пользователя о переходе.
Если пользователь на каком-то этапе выполнения задания щелкает по кнопке перехода, то появится сообщение с предупреждением о переходе и кнопками для подтверждения перехода / отмены перехода. Это необходимо, чтобы избежать непреднамеренного прекращения выполнения задания из-за ошибочного щелчка по кнопке перехода. Понятное дело, что, случись такое, пользователь расстроится и будет (если будет) проходить задание уже с совсем другим настроем.
Дефект: практическое задание (тренажёр) представляло собой копию инструктажа, но уже без показа пошаговых инструкций. Разнообразие заключалось только в том, что данные для ввода (данные по клиенту, к примеру) отличались. Пользователям было неинтересно проходить одни и те же операции друг за другом. Даже, если тренажёры выделены в отдельный курс.
Улучшение №7. Привязка заданий к реальным рабочим ситуациям.
Перед заданием описывалась реальная ситуация, в рамках которой необходимо выполнение тех или иных операций в программе. Таким образом, пользователи понимали значимость конкретных операций, понимали, в каком контексте они выполняются, для чего именно выполняются и т.д. Для того, чтобы донести до пользователя ценность данной операции, следует описать ситуацию как проблемную. Таким образом, выполняя задание в симуляторе, пользователь получает решение описанной проблемы.
Здесь покажу образец 2014-го года (используется принцип сторителлинга - на протяжении 5-7 кадров демонстрируется рабочая ситуация, в которой один из сотрудников сталкивается проблемой, разрешить которую можно, выполнив определенную операцию в ПО):
Улучшение №8. Автозаполнение данных.
Принцип следующий: в режиме "инструктаж" демонстрируем правильную последовательность выполнения операции и не отвлекаем пользователя на отслеживание им правильности ввода данных при заполнении различных форм. А вот в режиме "тренажёре" все данные он уже будет заполнять вручную. Подробно об этом написано здесь. Однако, если всё задание заключается в заполнении какой-то одной несложной формы, то от автозаполнения лучше отказаться.
Итак, автозаполнение данных нужно для того, чтобы сконцентрировать внимание пользователя в большей степени на правильной последовательности выполнения операции. Лишь только после того, как пользователь поймёт, как правильно выполнять всю операцию от и до, имеет смысл обращать его внимание на корректность введенных им данных.
Кстати, рекомендую облегчить жизнь пользователя: имена и названия для ввода сделать максимально короткими. К примеру, вместо ФИО "Радонежского Константина Прокофьевича" пусть будет "Митин Лев Олегович". Это сократит вероятность совершения ошибки пользователем при вводе данных.
Улучшение №9. Выделение интерфейса симулируемого ПО от интерфейса курса.
Теперь окно симулятора показывается на затемнённом полупрозрачном фоне. Сразу отмечу, что это не модальный режим, когда всё то, что находится на слоях ниже (например, кнопки навигации по курсу), оказывается недоступным.
Рассмотрим плюсы этого улучшения.
- Визуально отсекается то, что не относится к симулируемой программе, за исключением окна с пошаговой инструкцией (однако, как мы помним, оно тоже скрывается по желанию пользователя).
- При всём при этом кнопки перехода и другие функциональные кнопки курса остаются доступными. При наведении указателя мыши на область за границами интерфейса симулируемой программы затемнение исчезает (в этот момент пользователь получает доступ ко всем кнопкам курса).
- Пользователь может видеть заголовок раздела, которое содержит название операции, которую он выполняет (ну, а вдруг, его отвлекли, и он забыл, какую он выполняет операцию).
- Интерфейс заключён в оболочку окна проводника. Оно, в свою очередь, содержит значок симулируемой программы (favicon). Вроде мелочь, но так достигается еще большая узнаваемость интерфейса симулируемой программы.
Есть и минусы. Оболочка окна выглядит по-разному в зависимости от того, какая ОС установлена на ПК пользователя и какие настройки используются для оболочки. Поэтому визуально оболочка симулируемой программы в курсе и оболочка программы, которую видит пользователь в реальности, чаще всего будет отличаться. Это также относится и к стилю кнопок, элементов выделения в программе и т.д. Но я не думаю, что это очень критично. Ведь, в конце концов, и разрешение мониторов может отличаться. В свою очередь, пользователь может развернуть окно программы во весь экран, а может и не разворачивать. В зависимости от размера окна его содержимое будет выглядеть по-разному - это относится к размеру элементов и их расположению относительно друг друга. Это значит, что добиться вешней идентичности с интерфейсом симулируемой программы на 100% всё равно не получится.
Дефект: оболочка окна симулируемой программы содержит текстовый мусор. Он элементарно затирается, если окно "заскринено" в винде в стиле "классика", XP или 8-ки, но не аэро, который стоит по умолчанию в 7-ке. Это, конечно, мелочь. Но всё-таки все лишнее должно быть стёрто.
Дефект: в заданиях, где требовалось введение данных с клавиатуры, в соответствующих полях "мигал" курсор (как если бы его туда поставили вручную). Для этого в начале кадра прописывался JS. Впоследствии от этого "улучшения" отказался, так как в большинстве программ курсор сам по себе никуда не ставится. То есть, это нарушение логики поведения программы.
Улучшение №10: и все-таки в некоторых окнах этот курсор ставился автоматом, и если этот момент не учитывался в симуляторе, пользователи приходили в лёгкое раздражение. Таким образом, улучшение заключается в том, что курсор появляется в поле автоматически только, если так же он появляется в реальной программе.
Улучшение №11: чтобы указать пользователю на то, что он неправильно ввёл значение в поле ввода, данное поле меняет свой цвет на красный. Фишка прописывается в JS. Стоит отметить, что, как правило, программы так себя не ведут. В реальности пользователь либо увидит сообщение программы о неправильно введённом значении, либо вообще ничего не увидит.
Поэтому я использую этот инструмент в заданиях, где пользователю требуется заполнить сразу множество полей на одном кадре. Если он не заполнит какое-то обязательное поле или введёт значение, которое не соответствует заданной маске, появится сообщение с перечнем полей, которые нужно заполнить правильно (появление сообщения соответствует реальному поведению программы, изменения цвета поля - нет).
Если же пользователь допускает орфографическую ошибку, вводит лишний символ и пр. (например, когда требуется, чтобы он правильно ввел паспортные данные конкретного человека), то поле с ошибочными данными подсвечивается красным цветом, иначе пользователь свою ошибку обнаружит с большим трудом или не обнаружит вовсе.
Улучшение №12: проверка правильности заполнения формы по итогам выполнения задания.
Обратную связь можно предоставить сразу же после совершения пользователем ошибки. И в этом случае ошибку он сразу же исправит. А можно предоставить её после того, как пользователь выполнит задание целиком. Такой вариант актуален в большей степени для тренажёров.
Итак, пользователь выполняет задание в тренажёре, где нет никаких подсказок. Даже после прохождения инструктажа, он допускает ошибки. Почему? У каждого из нас уровень внимательности различается. Для кого-то не проблема заполнить все поля правильно, чтобы все названия были указаны с заглавной буквы, чтобы не было лишних пробелов и т.д. Для других же подобные ошибки являются систематическими. Поэтому важно пропустить пользователя через тренажёр несколько раз, пока он не научиться замечать и исправлять те виды ошибок, которые характерны именно для него. Именно с этой целью обратная связь предоставляется по итогам выполнения задания, а не сразу же после совершения ошибки.
Когда пользователь видит перечень ошибок в конце, то он сразу представляет себе масштаб бедствия и какие могут быть последствия, если он таким же образом будет "косячить" в реальности. Кроме того, задание будет считаться невыполненным. Поэтому у пользователя не должно возникать вопросов о том, почему ему необходимо выполнить задание повторно.
Особенности реализации:
- разделяем типы ошибок (ошибка написания с заглавной/строчной буквы, пропущенные поля, заполнены лишние поля, орфографические ошибки и пр.),
- показываем пользователю допущенную ошибку,
- показываем пользователю и те поля, где ошибок допущено не было (полная детализация),
- показываем, что должно было быть введено в поле.
Улучшение №13: компактное размещение сканов документов в пределах окна с пошаговой инструкцией.
Любой скан размещаем внутри окна с пошаговой инструкцией.
Если скан очень большой, то превращаем в его "превьюшку" → целевой фрагмент размещаем так, чтобы информация с него легко "считывалась":
Подробности смотрите в отдельном посте.
Улучшение №14: схема обучения "инструктаж - тест - тренажёр".
Представим, что пользователь прошёл симулятор в режиме "инструктаж". И сейчас готов выполнить задание в тренажёре, в котором подсказок не будет. Если операция сложная, то имеет смысл дать пользователю возможность подготовиться к тренажёру. В качестве такой подготовки выступает тестирование.
Как это выглядит: ряд вопросов и кейсов на знание того, как выполняется тот или иной этап, которые сопровождаются скриншотами программы. Пример:
В результате мы прорабатываем наиболее сложные зоны - те этапы операции, при выполнении которых пользователь с высокой вероятностью допустит ошибку. Когда он пройдёт такое тестирование, ему будет гораздо проще пройти тренажёр, и с меньшей вероятностью будет совершать действия наугад. Получается, что тестируя пользователя, мы его обучаем.
Также следует добавить в тест вопросы, отвечая на которые пользователь сможет лучше усвоить, почему тот или иной этап важно выполнять именно так, как это описано, и к чему может привести неправильное выполнение операции.
Улучшение №15: предоставление пользователю возможности выбора режима прохождения симулятора - инструктаж или тренажёр. Это значит, что пользователь может не проходить инструктаж, а сразу приступить к тренажёру.
Это целесообразно в тех случаях, когда целевая группа курса включает опытных сотрудников, для которых работа с программой не вызывает вопросов. При этом большинство этих сотрудников выполняют операции с ошибками, а часть обязательных операций по каким-то причинам не выполняют. И, кончено, они не знают, что допускают ошибки. В этом случае даже опытный сотрудник не сможет пройти тренажёр, так как у него сформирована неправильная модель поведения. И вот здесь у него возникает потребность пройти инструктаж. Во время прохождения инструктажа, пользователь будет большое внимание уделять именно тем этапам, при выполнении которых в тренажёре у него возникали ошибки.
Другой плюс этого улучшения (в большей степени для разработчиков курса): если задание в инструктаже и тренажёре идентичны, то разместить оба можно на одном слайде. Пошаговые инструкции будут демонстрироваться только в том случае, если пользователь выбрал режим "инструктаж". Особенно это удобно, когда в симулятор приходится периодически вносить изменения - убрать или удалить какую-то операцию, заменить последовательность и пр. В этом случае работа по корректировкам сокращается вдвое.
Улучшение №16: интеграция со справочными материалами.
В конце симулятора пользователю сообщается о том, что в случае необходимости он может обратиться к веб-справке. Такая веб-справка содержит краткую пошаговую инструкцию, которая сопровождается скриншотами из программы. Веб-справка размещается на информационно-справочном портале. Если во время работы у пользователя возникает необходимость выполнить определенную операцию, и он по каким-то причинам забыл, как выполнить один из этапов, то он очень легко сможет найти и открыть нужную веб-справку и далее выполнить операцию без ошибок (подробно про реализацию читайте здесь).
Улучшение №17: использование реалистичных сканов паспорта в заданиях, где необходимо использовать паспортные данные. Это позволяет хоть как-то приблизить условия выполнения задания к реалистичным.
В примере ниже использовано лицо рисованного персонажа, а не фото реального человека. Связано это с тем, что перед заданием проблемная ситуация проиллюстрирована с помощью именно рисованных персонажей.
Заключение
Минимизация визуального шума. Контролируемое появление объектов. Унификация формы сообщений для пользователя. Для чего все это нужно? Для того, чтобы управлять вниманием пользователя. Чтобы это внимание было сконцентрировано только на том, что важно для обучения. Чтобы сделать обучение максимально комфортным и эффективным. В этом и заключается пед.дизайн, то есть, в том, чтобы спроектировать такую обучающую среду, в которой каждый элемент будет использован с целью повышения положительного эффекта от обучения.
