Почему пользователи учатся

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

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

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

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

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

Средства обучения

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

· Общая «понятность» системы

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

Понятность системы

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

· Ментальная модель

· Метафора

· Идеома

· Аффорданс

· Cтандарт

Ментальная модель

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

Разберем это на примере файловой системы. Каждый, кто обучал кого-нибудь пользоваться компьютером, знает, как трудно объяснить пользу от записи файла после его редактирования. Дело в том, что без понимания сущности происходящих в компьютере процессов понять сущность записи невозможно. Допустим, пользователь создал новый документ, что-то в нем сделал, после чего попытался выйти из программы. Программа спрашивает его «Сохранить документ или нет?»; тут и начинается самое интересное. Во-первых, в этом вопросе главное значимое слово непонятно. Что такое сохранить? Где сохранить? Куда сохранить? Если же вопрос ставится техническим языком, а именно «Записать документ на диск?», то и здесь непонятно: на какой такой диск? Во-вторых, что важнее, даже если пользователь понял вопрос, он все равно не может понять, зачем документ сохранять? Как-никак документ уже имеется, сохранять его не надо.

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

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

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

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

Изначально пользователь не имеет ментальной модели памяти компьютера. Проблема же состоит в том, что компьютер не дает ему возможности самому построить модель, так что единственным её источником может являться обучение. Это один из самых больших недостатков дизайна современных компьютеров, во всяком случае, первый компьютер без разделения памяти на постоянную и временную (Palm Pilot) разошелся тиражом в миллионы экземпляров.

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

Метафора

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

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

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

К сожалению, у метафор есть несколько существенных недостатков.

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

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

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

Пример неудачной метафоры. Главный экран ОС Magic Cap. Будучи вся построена на метафорах, ОС приобрела широчайшую известность среди журналистов компьютерных изданий (они сразу всё понимали). С другой стороны, она не смогла добиться такой же любви у пользователей: они её понимали, но отказывались с ней работать из-за её неэффективности.

4. Совершенно необязательно, что сам по себе копируемый образец работает идеально. Если его копировать, окажется, что система не сможет быть эффективней своего прародителя. Например, Adobe PageMaker во многом копирует традиционные верстальные гранки, наследуя их известность пользователям вместе с их ограничениями. Благодаря этому он стал чрезвычайно популярен. Однако через некоторое время появился не копирующий гранки QuarkXpress, и отвоевал большую часть пользователей лишь потому, что работал более эффективно, не таская на себе груз старой идеи. Пользователи предпочитали потратить больше времени на обучение, зато выиграть в скорости работы. Анекдотичность ситуации заключается в том, что к настоящему времени гранки не используются вовсе, появилось поколение пользователей, которое никогда их в глаза не видело. Результат: обучаясь PageMaker, они должны дополнительно обучаться идее гранок, которая им вовсе не нужна.

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

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

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

Таким образом, метафора, будучи лучшим средством для избавления пользователя от обучения, не является средством хорошим. С другой стороны, метафоры иногда всё-таки работают (взять те же музыкальные программы), так что определенную пользу от них получить можно.

Анализируя опыт успешных случаев их применения, можно вывести следующие правила:

· опасно полностью копировать метафору, достаточно взять из неё самое лучшее;

· не обязательно брать метафору из реального мира, её смело можно придумать самому;

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

· если метафора хоть как-то ограничивает систему, от неё необходимо немедленно отказаться.

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

Идеома

Метафорический подход основан на интуитивном понимании. Идиоматический подход основан на знании о том, как решать ту или иную задачу - естественный для человека процесс.

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

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

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

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

Аффорданс

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

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

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

1. маппинг, или повторение конфигурации объектов конфигурацией элементов управления (этот способ работает хорошо в реальном мире, но не очень хорошо на экране, поскольку предпочтительней непосредственное манипулирование);

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

3. визуальное совпадение аффордансов экранных объектов с такими же аффордансами объектов реального мира (кнопка в реальном мире предлагает пользователю нажать на неё, псевдотрехмерная кнопка предлагает нажать на неё по аналогии);

4. изменение свойств объекта при подведении к нему курсора (бледный аналог тактильного исследования).

Стандарт

Если что-либо нельзя сделать «самопроизвольно» понятным, всегда можно сделать это везде одинаково, чтобы пользователи обучались только один раз. Например, кран с горячей водой всегда маркируют красным цветом, а кран с холодной – синим. Частично это соответствует свойствам человеческого восприятия (недаром красный цвет мы называем тёплым, а синий – холодным), но в основном здесь работает привычка.

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

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

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

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

· Типы обучающих материалов

· Среды передачи обучающих материалов

· Спиральность

Поиск по сайту: