Программистам о разработке пользовательских интерфейсов.
Глава 2: Выясняем, чего ожидают пользователи

Joel Spolsky

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

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

Вот один из примеров. В Microsoft Word (как и в большинстве других текстовых редакторах) когда вы вставляете картинку в документ, она встраивается в файл документа. Вы можете создать картинку, перетащить ее в документ, затем удалить первоначальный файл с картинкой, но она все равно останется в документе.

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

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

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

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

Итак, если гора не идет к Магомету, то придется изменить программную модель. Например, при вставке изображения в документ можно помещать его копию в папку с документом, так что это будет по крайней мере соответствовать копированию (а оригинал можно спокойно удалить).

Как выяснить, какова пользовательская модель программы?

Оказывается это довольно легко сделать. Просто спросите у самих пользователей! Выберите пять разных сотрудников вашей фирмы или друзей и расскажите им в общих чертах, что делает ваша программа ("это программа для создания веб-страниц"). Затем опишите ситуацию: "Вы работаете над веб-страницей, и вы вставляете в нее Picture.JPG". Затем задайте им несколько вопросов: "Где окажется изображение? Если вы удалите Picture.JPG, будет ли она по прежнему отображаться в документе?" 

Один мой друг работал над программой для фото-альбома. После того, как пользователь вставлял в него фотографии, программа выводила на экран набор их уменьшенных копий (thumbnails). Для создания этих копий требуется много времени, особенно если фотографий много, поэтому мой друг решил хранить сгенерированные копии где-то на диске. Он мог сделать это разными способами. Копии можно хранить в одном большом файле, названном Thumbnails, можно хранить их в разных файлах, но в одной директории, названной Thumbnails. Мой друг выбрал следующий способ: уменьшенную копию каждого изображения picture.jpg он сохранял в новом файле с названием picture_t.jpg в той же папке. Так что если вы создали альбом из 30 фотографий, то на диске у вас окажется 60 файлов.

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

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

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

Вам даже не нужна специальная usability-лаборатория - можно просто взять первого попавшегося человека и провести с ним небольщой usability-тест. Только не расказывайте им раньше времени как все работает. Попросите их "думать вслух" и задавайте открытые вопросы, пытаясь выяснить, какова их пользовательская модель.

Если модель вашей программы нетривиальна,
то она наверняка не соответствует модели пользователя

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

На картинке ниже показан экран компьютера Макинтош, изображающий две открытых "книги" Excel (Spreadsheet1 и Spreadsheet2), и один документ Word (Document 1). Любой пользователь, не знакомый с этой программой, подумает, что все окна независимы, ведь они выглядят независимыми:

Согласно модели пользователя, щелчок на окне Spreadsheet1 должен сделать его активным. Но на самом деле активным становится окно Spreadsheet2:

Оказывается, что программная модель MS Excel предполагает наличие "невидимых" листов, к которым как бы прикреплены окна документов. Когда вы делаете Excel активным приложением, все его окна тоже появляются сверху остальных.

Невидимые листы? Какова вероятность того, что модель пользователя включает в себя концепцию "невидимых листов"? Наверное около нуля. Таким образом пользователи ранее не работавшие с этой программй будут удивлены таким поведением.

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

Вернуться к списку статей