Обучение работе с системой

Начиная с определенного объема функциональности системы, количество пользователей, знающих всю функциональность, неуклонно снижается. Т.е. чем объемней система, тем больше шансов на то, что среднестатистический пользователь знает о ней очень немного (относительно общего объема функциональности). На свете нет ни единого человека, который бы полностью знал MS Word, предполагаю, что средний пользователь умеет пользоваться не более чем пятью процентами его возможностей. Плохо это по многим причинам: во-первых, пользователи работают с системой не слишком эффективно, поскольку вместо методов адекватных они используют методы знакомые. Во-вторых, достаточно часто случается, что пользователи, не зная, что имеющийся продукт делает то, что им нужно, ищут (и находят) продукт конкурента. В-третьих, при таком положении вещей затруднительно продавать новые версии продукта: если пользователь не умеет пользоваться и тем, что есть, убеждать его совершить покупку ради новой функциональности придется на довольно шатком фундаменте.

В случаях компьютерных систем стимул есть вещь почти исключительно добровольная. Это значит, что пользователь обучится пользоваться программой или сайтом только в том случае, если он будет уверен, что это сделает его жизнь легче и приятней. На профессиональном жаргоне это называется возвращением инвестиций (return of investments, ROI): ни один инвестор не вложит деньги (действие) без уверенности, что эти деньги принесут ему доход.

А также пользователь будет учиться какой-либо функции, только если он знает о её существовании. Рассчитывайте на средних пользователей, а не новичков или на профессионалов: поскольку средних пользователей абсолютное большинство.

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

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

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

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

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

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

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

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

Но, к сожалению, не для любой функциональности можно подобрать подходящую метафору. Даже подходящая метафора может оказаться бесполезной, если её не знает существенная часть аудитории или её тяжело однозначно передать интерфейсом.

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

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

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

Другой составляющей понятности является нечто, по-английски называемое affordance. Аффордансом называется ситуация, при котором объект показывает субъекту способ своего использования своими неотъемлемыми свойствами. Например, надпись «На себя» на двери не является аффордансом, а облик двери, который подсказывает человеку, что она открывается на себя, несет в себе аффорданс.

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

Визуальное ограничение в передачи аффорданса приводит к тому, что доступными оказываются всего несколько способов:

· маппинг, или повторение конфигурации объектов конфигурацией элементов управления;

· видимая принадлежность управляющих элементов объекту

· визуальное совпадение аффордансов экранных объектов с такими же аффордансами объектов реального мира;

· изменение свойств объекта при подведении к нему курсора.

Самый мощный, но зато и самый ненадежный способ обучения – это стандарт. Дело в том, что если что-либо нельзя сделать «самопроизвольно» понятным, всегда можно сделать это везде одинаково, чтобы пользователи обучались только один раз. Он очень хорошо работает, когда популярен, в противном случае не работает вовсе.

Популярен же он может быть двумя способами: во-первых, он может быть во всех системах, во-вторых, он может быть популярен внутри отдельной системы.

Обучающие материалы:

Базовая справка объясняет пользователю сущность и назначение системы. Обычно должна сработать только один раз, объясняя пользователю, зачем система нужна. Как правило, не требуется для ПО, зато почти всегда требуется для сайтов.

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

Справка предметной области отвечает на вопрос «Как сделать хорошо?». Поскольку от пользователей зачастую нельзя рассчитывать знания предметной области, необходимо снабжать их этим знанием на ходу.

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

Процедурная справка отвечает на вопрос «Как это сделать?». В идеале она должна быть максимально более доступна, поскольку если пользователь не найдет нужную информацию быстро, он перестанет искать и так и не научится пользоваться функцией (возможно, никогда). Разработчики чаще всего не привязывают темы справки к интерфейсу: когда пользователям непонятно, как выполнить нужное им действие, им приходится искать в справочной системе нужную тему.

Контекстная справка отвечает на вопросы «Что это делает?» и «Зачем это нужно?». Как правило, наибольший интерес в ПО представляет первый вопрос, поскольку уже по названию элемента должно быть понятно его назначение (в противном случае его лучше вообще выкинуть), а в интернете – второй (из-за невозможности предугадать, что именно будет на следующей странице). Поскольку пользователи обращаются к контекстной справке во время выполнения какого-либо действия, она ни в коем случае не должна прерывать это действие, её облик должен быть максимально сдержанным, а объем информации в ней – минимальным.

Для контекстной справки используют всплывающие подсказки (ToolTip). Существует также эффективный метод спиральные тексты. При возникновении вопроса пользователь получает только чрезвычайно сжатый, но ограниченный ответ (1-3 предложения). Если ответ не удовлетворяет пользователя, пользователь может запросить более полный, но и более объемный ответ. Если и этот ответ недостаточен, пользователь может обратиться к ещё более подробному ответу. Таким образом, при использовании этого метода, пользователи получают именно тот объем справочной системы, который им нужен.

Справка состояния отвечает на вопрос «Что происходит в настоящий момент?». Поскольку она требуется именно что в настоящий момент, она не может быть вынесена из интерфейса.

Сообщения об ошибках. Идеальное сообщение об ошибке должно отвечать всего на три вопроса: В чем заключается проблема?

Как исправить эту проблему сейчас? Как сделать так, чтобы проблема не повторилась?

Среды передачи материалов:

Бумажная книга. На одном листе может быть сконденсировано очень много материала, легко позволяет читателю получить большой объем материала за один сеанс, наилучшим образом работает при последовательном чтении. Сравнительно плохой поиск нужных сведений. Объем практически всегда лимитирован.

Справочная карта. Отдельная краткая бумажная документация, демонстрирующая основные способы взаимодействия с системой (quick reference card). Будучи реализована на едином листе бумаги, позволяет пользователю повесить её перед собой. Хороша как средство обучения продвинутым способам взаимодействия с системой и устройству навигации в системе.

Структурированная электронная документация. Плохо предназначена для чтения больших объемов материала, зато обеспечивает легкий поиск и не имеет лимита объема. Занимает большой объем пространства экрана. Плохо подходит для показа крупных изображений, зато в неё могут быть легко интегрированы видео и звук.

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

Всплывающие подсказки. Хорошо справляются с ответом на вопросы «Что это такое» и «Зачем это нужно», при условии, что объем ответов сравнительно невелик. Поскольку вызываются пользователями вручную, в обычном режиме не занимают пространства экрана и не отвлекают внимания пользователей. С другой стороны, очень легко вызывают отвыкание – после первого же случая неудовлетворения пользователя подсказкой, пользователь перестает вызывать и все остальные подсказки.

Дата добавления: 2014-01-06