Программное обеспечение вычислительной техники и автоматизированных систем - РГР и ЛР (Дергачёв) / Проектирование пользовательского интерфейса

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

Построение прототипа ПИ << к предыдущей главе     к следующей главе >>

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

Этапы построения прототипа

Существуют четыре версии прототипа. Особый интерес представляют первые две. Третья и четвертая используются редко, т.к. не сильно отличаются от готовой программы. Первая версия. Бумажная Вторая версия. Презентационная. Третья версия. Псевдореальная. Четвертая версия. Реальная. Первая версия. Бумажная Необходимо нарисовать на бумаге все экраны и диалоговые окна (или распечатать соответствующие части схемы). Нужно только убедиться, что все интерфейсные элементы выглядят единообразно и сколько-нибудь похоже на реальные. Эта распечатка и является первым прототипом. На нём вполне можно тестировать восприятие системы пользователем и её основную логику. Достоинствами бумаги являются исключительная простота и скорость рисования. Польза начального прототипирования на бумаге заключается, во-первых, в простоте и скорости рисования, во-вторых, в исключительной простоте модификации по результатам тестирования, а в-третьих, в относительной простоте привлечения представителей целевой аудитории. Значительно легче завлечь субъекта к письменному столу, нежели к компьютеру, на котором надо что-то запускать, ждать, пока запустится и так далее. Кроме того, бумага помогает не думать о том, как интерфейс выглядит, позволяя сосредоточиться на том, как интерфейс работает. Вот в таком небрежном виде должен показываться бумажный прототип представителям целевой аудитории При рисовании прототипа на бумажке очень важно не стараться нарисовать его так, чтобы он был красив, например, не нужно стараться рисовать линии прямыми. На понимание работы интерфейса это не повлияет, зато здорово замедлит работу. Красоту же всё равно придется выбрасывать, когда будет нарисована новая версию. Так что основным критерием живописности должна стать скорость работы. Элементы интерфейса, которые нельзя нарисовать однозначно (например, раскрывающиеся списки, у которых значения до поры скрыты) эффективнее всего рисовать неоднозначными, важную же информацию из них лучше всего словами писать на полях. Разумеется, значение слова «версия», весьма условно. В действительности после обнаружения каждой ошибки схема и прототип исправляются, а тестирование продолжается уже на новом прототипе. Так что на этом этапе прототип может пережить множество исправлений и, соответственно, много версий. Вторая версия. Презентационная. После исчерпания возможностей бумажной версии прототипа стоит создать новую версию. Для этого точно так же рисуется интерфейс, но уже не на бумаге, но в какой-либо презентационной программе. С этой версией прототипа можно тестировать значительно более сложное взаимодействие человека с системой, нежели с бумажной. С другой стороны, исправление найденных ошибок значительно более трудоемко. Самым распространенным инструментом для создание прототипов второго типа является MS Visio. Некоторую конкуренцию ему могут составить MS PowerPoint и Macromedia FreeHand (и вообще любой иллюстративный пакет, обладающий возможностью работать с несколькими страницами), но возможности PowerPoint для такой работы слишком малы, а возможности FreeHand, напротив, слишком велики. Ни то ни другое скорость работы не увеличивает. Пример презентационной версии прототипа При работе с Visio можно выбрать одну из двух возможностей: можно либо рисовать все экраны на одном листе, соединяя взаимосвязанные элементы управления и экраны линиями, либо рисовать каждый экран на отдельном листе, связывая экраны ссылками. Первый вариант хорош для вас, поскольку позволяет оценить интерфейс в целом, второй – для заказчика и субъектов тестирования, поскольку его легче понять. Как правило, превратить второй вариант в первый оказывается гораздо легче. Если рисовать в PowerPoint, каждой экран удобно создавать как отдельный слайд, а результат нажатия кнопок имитировать переходами между слайдами. Среди многочисленных наборов заготовок в Visio есть и набор с элементами интерфейса Windows, однако эти заготовки выполнены довольно грубо, с огромным количеством лишних деталей. Пользоваться можно только заготовками для радиокнопок и чекбоксов (которые реализованы неплохо), а также заготовкой для полоски прокрутки. Поскольку создание собственных интерактивных заготовок непроблематично, рекомендуется создать свой набор и пользоваться им. Большим достоинством Visio является возможность записывать результат в HTML-файл, что позволяет без проблем тестировать интерфейс на территории субъектов тестирования. Раньше это мог только PowerPoint, чем, во многом, и объяснялась его популярность в качестве инструмента для создания прототипов. Сейчас это умеет и Visio (сохранение в HTML начало нормально работать только в Visio 2001). У многих разработчиков, особенно кто не понаслышке знаком с программированием есть соблазн воспользоваться для создания прототипа так называемыми «средствах быстрой разработки приложений» (Delphi, Visual Basic и т.д.). В этом случае прототип интерфейса воспринимается лишь как вспомогательная оболочка над программным кодом. Как следствие возникают следующие недостатки: Для тестирования прототипа на пользователях крайне желательно, чтобы он "немного работал", то есть, например, нажатие на кнопку вызывало другое окно или чтобы из выпадающего списка можно было выбрать значение. Так вот, в данном случае любое взаимодействие, как между отдельными элементами интерфейса, так и между различными формами реализуется только с помощью написания программного кода. Что совершенно незачем в данном контексте. Зачем усложнять то, что можно сделать проще? Ведь основной критерий создания прототипа это скорость. Чрезвычайно сложно создать принципиально новый элемент интерфейса либо модифицировать уже имеющийся. Подобные задачи очень часто встречаются на практике, так как для «хорошего» интерфейса стандартных элементов как правило не хватает. Затраты на создание/модификацию собственного элемента управления в данных средах разработки нельзя назвать адекватными. Каждый элемент управления здесь имеет несколько десятков различных свойств, тогда как для прототипизирования требуются лишь касающиеся внешнего вида настройки - шрифт, цвет, текст, размер. Естественный недостаток: нельзя разрабатывать веб-интерфейс. Фактически для большинства систем этой версии прототипа оказывается достаточно. Третья версия. Псевдореальная. В тех случаях, когда в интерфейсе появляются нестандартные элементы или необходимо проверить реальную скорость взаимодействия пользователя с системой, создается еще одна версия прототипа – реально выглядящая, но лишенная каких-либо алгоритмов и, соответственно, не показывающая реальных данных. Делать этот вариант можно как в средах разработки, благо в них есть визуальные инструменты создания интерфейсов, так и в редакторах изображений, что обычно быстрее. Фактически при этом создаются фальшивые снимки экрана, на которых и производят тестирование. Понятно, что существенно модифицировать эти экраны затруднительно, так что лучше не увлекаться такой работой, не получив каких-либо гарантий ее правильности. Четвертая версия. Реальная. Иногда необходимо тестировать взаимодействие пользователя не только с интерфейсом системы, но и с обрабатываемыми системой данными. Например, работая с графической программой, пользователь не только нажимает на экранные кнопки, но также создает и модифицирует изображения мышью. Область же редактирования данных зачастую вообще не содержит каких-либо визуальных интерфейсных элементов, из чего вовсе не следует, что интерфейса в ней нет, его, наоборот, много. Другой разговор, что счет в нем идет не на кнопки и переключатели, но на пиксели и миллисекунды. Понятно, что создание прототипа в таких условиях не поможет, поскольку прототип вообще не будет отличаться от проектируемой системы. В таких условиях лучше всего написать нужные участки кода до написания всего остального, и проводить тестирование уже на реальной системе.

Юзабилити-тестирование

Какими бы не были совершенными логические соображения, приведшие к созданию интерфейса, всегда остается вероятность того, что интерфейс получился плохой, либо, что более вероятно, не такой хороший, каким бы он мог быть. Необходимо иметь какие-либо подтверждения его работоспособности. Всё, что для этого нужно, это несколько пользователей средней квалификации, никогда не видевшие тестируемой системы, плюс прототип (разумеется, при наличии основательного бюджета можно развернуться и пошире, например, купить прибор, фиксирующий направление взгляда пользователя). Существует распространенное заблуждение, что с помощью тестирования, можно решить все проблемы интерфейса. С помощью тестирования можно определить только слабые места интерфейса, но почти невозможно обнаружить сильные, поскольку они пользователями просто не замечаются, и совсем уж невозможно определить новые способы улучшения. Юзабилити-тестирование представляет собой постановку экспериментов с целью выявления специфичной информации, касающейся дизайна исследуемого продукта. Юзабилити-тестирование производится на протяжении всего цикла разработки продукта. На ранних стадиях разработки тестирование предыдущей версии или конкурирующих продуктов позволяет команде проектировщиков наметить контрольные точки, которых необходимо достигнуть в процессе разработки. В середине работы над продуктом, тестирование проверяет корректность произведённого дизайна и предоставляет обратную связь, сообщая места, где дизайн нуждается в улучшении. На заключительных этапах тестирование удостоверяет, что продукт соответствует тем целям, для которых был спроектирован. В целом, провести тестирование несложно. Нужно лишь взять несколько пользователей и выяснить, как именно они работают с исследуемым продуктом. Как правило, в процессе тестирования производятся индивидуальные наблюдения за каждым из пользователей, которые выполняют ряд специально подготовленных заданий, требующих работы с продуктом. Производится сбор всех возможных данных, касающихся того, как именно пользователь выполняет задания, – например, сколько времени уходит на выполнение каждого задания или сколько ошибок совершается в процессе работы. Затем производится анализ собранной информации с выявлением тенденций и закономерностей.

Подготовка к тестированию << к предыдущей главе     к следующей главе >>

Цели исследования Проектирование исследования Подбор участников тестирования Подготовка необходимого инструментария Подготовка тестовой группы к оглавлению Цели исследования Что вам необходимо узнать об исследуемом продукте? Начните с общей цели вашего исследования; возможно, вас интересует, почему после выхода последней версии продукта участились звонки в службу техподдержки. Или ваше положение на рынке пошатнулось и вы желаете знать, не вызвано ли это тем, что продукция конкурента более удобна в использовании. Разбейте цель эксперимента на несколько чётких задач. «Удобен ли мой продукт?» – хороший пример плохой постановки задачи. Задачи должны быть поставлены таким образом, чтобы по результатам тестирования можно было легко определить решение каждой из них, они должны касаться того, что можно непосредственно заложить в тестирования, например: Является ли задержка при загрузке Java-апплета причиной ухода с сайта посетителей? Насколько сложной для новичка является процедура заполнения налоговых форм с помощью данного продукта? Предоставляет ли онлайн-система подсказки достаточное количество информации о налоговом кодексе? Эта информация изложена простым, доступным для понимания языком, а не на юридическом жаргоне? наверх     к оглавлению Проектирование исследования Характеризуйте пользователей, которые станут участниками тестирования. Это необходимо, потому что когда вы займётесь непосредственно подбором участников, очень важно будет знать, кто именно вам нужен: новички, эксперты или опытные пользователи, мужчины, женщины, или же вы нуждаетесь в представителях обоих полов; также важен возраст пользователей. Кто является целевой группой пользователей вашего продукта? Если вы тестируете дисплеи реактивных истребителей, вам ни к чему пропускать через ваши тесты орды тинэйджеров. Если ваш продукт – автомат для продажи газировки, в таком случае те же тинэйджеры придутся как нельзя кстати. Выявление профиля пользователей вашего продукта важно для проектирования эксперимента и непосредственно для подбора его участников. Определите структуру вашего эксперимента Композиционное строение вашего тестирования описывает, как вы будете проводить отдельные тесты, в каком порядке они будут выстроены, чтобы исключить из рассмотрения и дальнейшего анализа все переменные, не представляющие интереса. Предположим, что вы тестируете программный продукт, связанный с налогообложением. Нужны ли вам пользователи, уже использовавшие ваш продукт в работе и уже обладающие некоторыми сведениями и навыками, касающимися именно вашего продукта? Возможно, вы предпочтёте разбить участников тестирования на две группы, разделив их на новичков и пользователей, уже имеющих некоторый опыт работы с продуктом. Определите задания, которые будут предложены участникам тестирования во время проведения каждого теста Эти задания, несомненно, должны быть заимствованы и основаны на тех задачах, которые пользователи решают с помощью вашего продукта в процессе его нормального использования. Укажите всё, что понадобится вам для того, чтобы определить сценарий теста: состояние автомата, машины или компьютера, экраны, документацию, другие средства помощи и подсказки, которые должны присутствовать. Также укажите, каким образом определяется успешное завершение выполнения каждого задания, – например, если пользователь успешно сохранит отредактированный документ или выполнит некоторую производственную операцию, достигнув определённого законченного результата. Опишите инструментарий исследований В традиционных научных экспериментах, например, биологических или химических исследованиях, лежащих в самых корнях методологии юзабилити-тестирования, инструментарием исследования является оборудование лабораторий, пробирки, мензурки, горелки и другие устройства, используемые в процессе эксперимента. Для юзабилити-тестирований, таким инструментарием будет компьютер и установленное программное обеспечение, или макет изготавливаемой рабочей станции, или прототип приборной доски автомобиля. Инструментарий также может включать в себя устройства, используемые в процессе проведения тестов, такие как видеокамеры для записи поведения пользователей, преобразователи развёртки для записи того, что происходит на экранах мониторов, диктофоны и записывающая аудиоаппаратура для протоколирования вербального общения и записи вербальных протоколов, односторонние зеркала, позволяющие наблюдателям и экспериментатору оставаться невидимым для участников тестирования и так далее. Вы можете собрать много полезной информации, пользуясь простыми любительскими видеокамерами или даже вообще без видеозаписей. Характеризуйте требуемый персонал Вам понадобится как минимум один экспериментатор (ассистент), который будет проводить тестирование, начиная от оглашения его темы, объяснения плана тестирования и заканчивая непосредственной работой с участником тестирования над каждым заданием. Для того, чтобы уменьшить нагрузку на экспериментатора, связанную с фиксацией получаемых данных (ведением журналов-логов), вы можете включить в состав команды одного или двух наблюдателей. Также во время тестирования должны присутствовать наблюдатели – участники проекта, имеющие непосредственное отношение к разработке программы и интерфейса, которые будут находиться в соседней комнате за односторонним зеркалом или у телевизора, на который поступает сигнал с видеокамеры. наверх     к оглавлению Подбор участников тестирования Составьте список пользователей, из которого вы будете подбирать участников для каждого теста Вам понадобится количество пользователей, достаточное, чтобы создать выборку в требуемой для теста пропорции опыта, навыков и демографических характеристик, – поскольку в противном случае неучтенные факторы могут закрасться в структуру проводимого эксперимента и повлиять на полученные в ходе тестов данные. Профиль пользователей, который вы определили в ходе подготовки и проектирования эксперимента, поможет вам создать модель типового пользователя вашего продукта. Например, приборной доской реактивного истребителя могут пользоваться не только сами пилоты, но и обслуживающие рабочие, механики, инструкторы и диагностирующий персонал. Тем не менее, для тех целей, которые преследуете вы («Позволяет ли использование дисплея радара ближайшего окружения самолёта избежать столкновений в процессе полёта на спине?»), вы можете быть заинтересованы в рассмотрении только одного сегмента всей выборки – в нашем примере, только пилотов. Даже если вы уже сузили выборку до единичного профиля, например, «пилоты мужского и женского пола со зрением 20/20 в возрасте от 22 до 35 лет, имеющие учёную степень не менее бакалавра или эквивалентную», вам все ещё необходима дополнительная информация, касающаяся ваших пользователей. Каким опытом работы с данным типом дисплея обладает каждый пользователь? Пользуются ли они устаревшими механическими индикаторами или предпочитаю компьютеризированные дисплеи? Есть ли среди них дальтоники? Какой глаз является доминантными для каждого из них? Список вопросов можно продолжить, поскольку чем лучше вы знаете участников тестирования, тем меньше сюрпризов преподнесут неучтённые и спонтанные факторы, способные исказить ваши экспериментальные данные. Как вам найти всех этих пользователей? Всеми возможными способами. Попросите своих коллег по работе, их друзей и родственников. Привлеките для поиска людей агенства по найму и компании, занимающиеся маркетинговыми исследованиями (вам придётся заплатить за их услуги, однако, скорее всего, вы облегчите себе работу по сортировке и отбору, используя предоставленные характеристики). Используйте записи звонков в службу техподдержки и списки постоянных клиентов-лидеров по покупкам для того, чтобы привлечь наиболее активных пользователей продукта. Поместите рекламное объявление в Интернет или в прессу. Отправьте приглашения на ознакомительную и производственную практику в школы. наверх     к оглавлению Подготовка необходимого инструментария Инструментарий юзабилити-тестирования включает в себя компьютер и установленное на нём программное обеспечение для тестирования программного продукта, или машину, автомат или его макет для тестирования оборудования. Некоторые тесты производятся на прототипах системы, в таком случае необходимо удостовериться, чтобы все состояния агрегата, которые могут возникнуть в процессе тестирования по каждому сценарию теста, были реализованы в прототипе. Также в инструментарий входят материалы, предоставляемые участнику и экспериментатору в течении тестов. Участнику тестирования обычно выдаётся список заданий, которые ему необходимо выполнить. Часто последовательность шагов, необходимых для выполнения каждого задания, намеренно опускается, особенно в том случае, если вы хотите определить, насколько легко обнаружить определённые последовательности управляющих действий. Экспериментатор обычно получает основное описание того, как он должен сообщать задания участникам теста, и вспомогательную форму для фиксации своих наблюдений в течении теста. В некоторых случаях оказывается удобным использовать предварительно согласованные условные обозначения для стенографирования событий, чтобы ничего не упустить в стремительном водовороте процесса. Если вы используете видеокамеру, то стоит провести кабель от нее в соседнюю комнату, в которой каждый, кто участвует в разработке, мог бы сам наблюдать за ходом тестирования по телевизору. Видеокамера должна фиксировать то, что видит пользователь (на экране монитора или на бумаге, в зависимости от того, что вы тестируете), а также то, что произносят пользователь и ассистент. наверх     к оглавлению Подготовка тестовой группы Ваша тестовая группа – это группа пользователей, которые примут участие в данном тесте. Сколько вам потребуется человек? Наиболее распространённые руководства рекомендуют привлекать в среднем 4-5 участников для того, чтобы обнаружить большинство проблем, связанных с юзабилити. Подберите вашу тестовую группу на основе ваших задач и профиля пользователей, учитывая доступность участников в дни, на которые вы назначили проведение теста. Вероятнее всего, уже первые три пользователя помогут выявить все самые значительные проблемы. Якоб Нильсен и Том Ландауэр утверждают, что тестирование пяти пользователей позволяет обнаружить уже как минимум 85% проблем интерфейса, и далее с каждым дополнительным пользователем отдача от тестирования существенно снижается. К тому же, намного важнее провести больше циклов тестирования, чем стремиться собрать всю возможную информацию из каждого цикла. Тестирование в цикле только трех пользователей, скорее всего, позволит вам провести хотя бы еще один цикл. Кроме того, после корректировки проблем, обнаруженных в первом цикле, те же самые пользователи, приглашенные на следующий цикл, возможно, обнаружат другие проблемы, поскольку застревать на исправленных они уже не будут. Если вы тестируете только трех или четырех пользователей, то вы можете обсудить полученные результаты в тот же день и сразу сделать нужные изменения. Если же в вашем тестировании участвует более четырех пользователей, то объем заметок, сделанных в процессе тестирования, становится слишком большим, чтобы их можно было быстро прочитать. К тому же, большинство из этих заметок будет касаться мелких проблем, возникнет опасность потерять главное. Так что постарайтесь сосредоточиться на главных проблемах, корректируйте их, и затем как можно скорее тестируйте снова.