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

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

Подготовка участника к тестированию Действия ассистента во время тестирования Действия наблюдателя во время тестирования к оглавлению Подготовка участника к тестированию Большинство людей чувствуют себя неуютно, когда попадают в лабораторию, где им приходится выполнять задания, зная, что время выполнения замеряется и все их ошибки записываются для дальнейшего анализа, поэтому сделать так, чтобы пользователь чувствовал себя комфортно и спокойно, очень сложно. Объясните участнику, что он может в любой момент остановить тест, отлучиться в уборную или сделать перерыв, если это ему потребуется. Подчеркните, что вы подвергаете тестированию продукт, а не пользователей, и им не стоит чувствовать себя под давлением теста. Поблагодарите пользователей за участие в тестах. Большинство тестов требуют от участников предварительного заключения соглашения о неразглашении информации и подтверждения их согласия на произведение записей. В качестве части этой «бумажной работы», вы можете провести участников через анкетирование для того, чтобы идентифицировать знание предметной области, их позиции и отношения, или чтобы получить ещё немного информации о характеристиках пользователей. наверх     к оглавлению Действия ассистента во время тестирования Задача ассистента заключается только в том, чтобы объяснить пользователям, что им нужно сделать, просить их высказывать свои мысли вслух, слушать внимательно, что они говорят, и всячески оберегать их. Попробуйте, сначала протестировать себя. За день до проведения теста попробуйте выполнить самостоятельно то, что собираетесь просить делать участников тестирования, и убедитесь, что сможете справиться в отведенное время. Оберегайте участников тестирования. В ваши обязанности входит защита чувства собственного достоинства пользователей. Будьте внимательны и тактичны с ними. Если пользователь застрял где-то, ободрите его, похлопайте его по плечу (в переносном смысле), а в завершении тестирования обязательно поблагодарите (искренне). Дайте знать вашим пользователям, что их участие было очень ценным и полезным для вас. Сопереживайте участникам тестирования. Будьте добры и терпеливы к ним и старайтесь ободрять их. Дайте им ясно понять, что вы знаете, что они не глупы. Постарайтесь увидеть и понять, какие мысли возникают у них. Самая главная задача для вас - это попытаться наблюдать за ходом их мысли. Когда вы не уверены, что вам понятно, о чем они думают, спросите у них об этом. Если пользователь уставился на экран в течение 10 сек., то спросите у него: «На что вы смотрите?» или «О чем вы задумались?». Постарайтесь понять, какие на каждом шагу у них возникают ожидания и насколько программа соответствует этим ожиданиям. Когда пользователь уже готов щелкнуть мышью, спросите у него, что он ожидает увидеть. После того как он щелкнет мышью, узнайте, действительно ли результат оправдал его ожидание. Не подсказывайте им, что делать. Во многом это напоминает работу психиатра. Если пользователь говорит: «Я не знаю, что делать дальше», вам нужно спросить: «А как вы думаете, что бы вы могли сделать?» или «А что бы вы сделали, если бы были дома?». Ваши инструкции должны быть простыми. Их не так уж и много, поэтому их легко запомнить: Оглядите экран и скажите, чем это все является и по чему вы, скорее всего, щелкнули бы? Скажите, по чему вы щелкнули бы теперь, и как вы думаете, что вы увидите после этого? Постарайтесь как можно больше произносить свои мысли вслух. Не бойтесь повторять эти инструкции часто, тем более что это больше надоест вам самим, чем пользователю. Уточняйте, уточняйте, уточняйте. Трудность состоит в том, что нельзя отвлекать пользователей или оказывать на них влияния, но в то же время необходимо выяснить, что они в действительности думают (чего, кстати, они и сами могут не до конца понимать). Не бойтесь импровизировать. Например, если первые два пользователя безнадежно застряли в одном и том же месте и вам ясно, в чем там проблема и как ее решить, то не заставляйте и третьего пользователя без нужды возиться с ней. Как только он дойдет до этого места, объясните ему, что к чему и как продолжить работу дальше. Не расстраивайтесь, если пользователь окажется совсем неопытным или полностью запутается. Наблюдая за пользователем, который ни во что не «въезжает», вы можете узнать больше полезного. Более опытный пользователь обладает лучшими навыками для того, чтобы разобраться с проблемой «как получится», и вы можете даже не заметить, что на самом деле он не понимает, как «это» работает. Делайте записи после каждой сессии. Сразу после каждого тестирования делайте короткие записи о том, что вам запомнилось. Если вы не сделаете этого до начала следующего теста, то потом вам будет очень трудно вспомнить важные детали. наверх     к оглавлению Действия наблюдателя во время тестирования Работа наблюдателя на юзабилити-тестировании довольно простая. Все, что вам нужно будет делать в качестве наблюдателя, — это только слушать и смотреть, быть внимательным и попутно делать записи. Вот на что вам придется обращать внимание: Попробуйте, сначала протестировать себя. За день до проведения теста попробуйте выполнить самостоятельно то, что собираетесь просить делать участников тестирования, и убедитесь, что сможете справиться в отведенное время. Они понимают? Могут ли пользователи без посторонней помощи разобраться, чем является программа, каково ее назначение и откуда можно начать ей пользоваться? Могут ли они разобраться в структуре программы? Понятна ли навигация для пользователей? Ясна ли для пользователей функциональность и понятны ли названия, которые использованы для меню и кнопок? Моменты просветления. Вы сможете отличить эти моменты по следующему признаку: когда пользователь совершит или не совершит какое-то действие, все, кто наблюдает тестирование, внезапно хлопнут себя по лбу и воскликнут: «Почему же мы раньше об этом не подумали?» или «Почему же мы раньше этого не замечали?». Это очень важные моменты просветления. Моменты шока. В такие моменты вы, вероятно, также стукнете себя по лбу, но вместо «Почему мы не замечали этого?» вы воскликнете: «Почему же он (или она, речь идет о пользователе) не заметил(а) этого?» или «Почему же он(а) не понял(а) этого?». В отличие от решений, возникающих в моменты просветления, решение для «шоковой» проблемы не всегда легко найти, и, возможно, для этого вам придется вновь вернуться к «чертежной доске». Новые идеи. Пользователи часто подсказывают решения какой-либо проблемы, над которой вы уже давно бьетесь. Очень часто такие подсказки наводят вас на идеи, о которых вы уже раньше думали, но по каким-то причинам отклонили их. Ситуация, когда вы видите, как пользователь сталкивается с этой проблемой, иногда позволяет по-новому взглянуть на нее. Иногда случается, что в проект были внесены какие-то изменения (например, было решено применить другую технологию или сместились коммерческие приоритеты), и становится полезным тот метод или подход, который был отклонен в начале. Оглядите экран и скажите, чем это все является и по чему вы, скорее всего, щелкнули бы? Скажите, по чему вы щелкнули бы теперь, и как вы думаете, что вы увидите после этого? Постарайтесь как можно больше произносить свои мысли вслух. Восторг. Какие элементы программы действительно очень нравятся пользователю? Обращайте внимание на фразы вроде: «Это именно то, что я искал(а)!», «Когда же этим можно будет, наконец, пользоваться?». Во время тестирования вы заметите и много того, что пока не работает, ну, например, съехавшие подписи в опциях, не работающие функции, опечатки. Следует отмечать эти элементы, чтобы потом передать список тем, кто должен их исправить. Однако не забывайте, что это не является вашей основной задачей, и делайте это только попутно.

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

Обсуждение с участником пройденного тестирования Отчет о наблюдении Анализ полученных данных к оглавлению Обсуждение с участником пройденного тестирования После того, как задания были выполнены и тестирование завершено, пообщайтесь с его участником, обсудите тест. Пройдитесь с ним вместе по событиям, произошедшим во время теста, для того, чтобы получить дополнительную информацию, касающуюся того, о чём думал пользователь в то время. Одним из путей обзора события является его восстановление и обсуждение с участником тестирования. Кроме этого, вы можете просто спросить участника, что из случившегося во время теста показалось ему заслуживающим внимания. Поблагодарите пользователя за участие в тестировании. Помните, участники оказывают вам услугу своим присутствием на тестах, и важно дать им понять, как высоко вы это цените. Большинство лабораторий вручают участникам небольшие подарки по завершении тестирования: кофейную кружку, футболку или бесплатное программное обеспечение. В большинстве случаев вам не раз ещё потребуется привлечь этих пользователей для своих тестирований, поэтому очень важно, чтобы они остались довольны своим участием. наверх     к оглавлению Отчет о наблюдении После тестирования каждый наблюдатель и ассистент должен как можно быстрее написать небольшой отчет об основных проблемах, которые были им замечены во время тестирования, а также изложить свои мысли по поводу способов их устранения. Не надо писать полных и развернутых отчетов. Пусть это напоминает скорее резюме. В идеале, все участники группы по разработке должны прочитать эти отчеты (или хотя бы пробежать их глазами), поэтому они не должны по объему превышать страницу или две. На собрании рабочей группы раздайте копии всех отчетов и приложите к ним копии набросков и изображений, которые тестировались. Следует обсудить два вопроса: Отбор. Рассмотрите проблемы, с которыми сталкивались пользователи, и решите, какие из них должны быть исправлены. Поиск решений. Определите возможные решения для отобранных проблем. наверх     к оглавлению Анализ полученных данных В первую очередь ищите крупные проблемы Как правило, найти крупную проблему проще всего, поскольку они становятся заметны ещё при проглядывании заметок, сделанных во время наблюдения за пользователями. Если каждый участник сталкивался с проблемами при использовании определенного пункта меню, очевидно, что дизайн этого пункта нуждается в пересмотре. Подведите итог собранным данным по производительности Данным, касающиеся производительности, таким как частота возникновения ошибок и времена выполнения заданий, оценка даётся с помощью их статистического анализа. Большая часть такого анализа сводится к нахождению среднего значения и стандартного отклонения, а также к проверке достоверности полученных данных. Все ли тенденции выявляются этим набором данных? Где расположены наиболее сложные и трудные части продукта? Подведите итог данным, касающимся предпочтений пользователей Наблюдая за действиями пользователей и записывая их мнения, как во время теста (используя метод записи «мыслей вслух» или задавая вопросы), так и до или после теста с использованием анкет и опросных листов, вам удалось собрать большое количество информации, касающейся предпочтений пользователей. Большинство опросников имеют строение, позволяющее вам количественно измерить мнения, используя численную шкалу, и обнаруженные таким образом количественные данные могут анализироваться с помощью статистических методов так же, как и данные, касающиеся производительности. Также вы можете использовать цитаты из мнений участников тестирования в качестве «ударных фраз», включив их в итоговый отчёт.

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

В настоящее время меньшее внимание уделяется результатам, основанным на фактических данных, акцент делается на интерпретации этих результатов; можно видеть что в сравнении с сухими цифрами большую важность приобретают другие моменты, наблюдаемые в процессе тестирования. В частности, очень многие тестирования проводятся на базе записи «мыслей вслух» в сочетании с какой-либо разновидностью измерения производительности. Измерения производительности до сих пор обладают определенной полезностью для исследований, однако информация, получаемая при записи «мыслей вслух», способна гораздо быстрее отражаться на изменениях в продукте, поскольку она не нуждается в предварительном обобщении и статистическом анализе. Метод фокусных групп Проверка посредством наблюдения за пользователем Мыслим вслух Проверка качества восприятия Измерение производительности Карточная сортировка к оглавлению Метод фокусных групп Метод фокусных групп заключается в опросе специально отобранной группы пользователей. В исследование, которое обычно продолжается около 2 часов, вовлекается от 6 до 9 пользователей. Основное достоинство фокусных групп состоит в том, что они позволяют выявлять спонтанные реакции и идеи и оценивать отношение к этим идеям группы в целом. Как правило, участники группы воспринимают происходящее как относительно свободный неструктурированный процесс, но ведущий группы должен иметь предварительный сценарий работы, вытекающий из целей исследования, и следить, чтобы групповая дискуссия не выходила из русла обсуждаемой проблемы. Кроме того, необходимо добиваться равного участия в дискуссии всех членов группы. Достаточно часто бывает, что в группе выделяется лидер, доминирующий над остальными участниками. Такие ситуации мешают свободному выражению мыслей и идей остальных членов группы и также нуждаются в коррекции. Результаты работы фокусной группы заносятся в специальный протокол для дальнейшей обработки. Сбор детальной информации при этом методе затруднен из-за относительной стихийности группового процесса, поэтому рекомендуется проводить несколько фокусных групп, состоящих из репрезентативных пользователей. Метод фокусных групп подходит для того, чтобы быстро поучить диапазон мнений и оценок пользователей по поводу тех или иных вещей. Он очень полезен для определения, в самом общем виде, потребностей и предпочтений вашей аудитории. Он подходит для проверки того, насколько актуальна и востребована программа и насколько его «ценное предложение» привлекательно для пользователей. Кроме того, это хороший способ для подбора названий функции и опций, а также выяснения, что люди думают о ваших конкурентах. Однако метод фокусных групп не позволяет определить, как работает ваша программа и самое главное как ее можно улучшить. С помощью этого метода вы можете узнавать те вещи, которые нужно знать на ранних этапах, еще до начала непосредственной разработки. Конечно, этот метод можно применять и позже, например, для уточнения деталей или при пользовательском тестировании. Но метод фокусных групп не может вам показать, насколько людям удобно и легко пользоваться вашей программой, поэтому нельзя путать этот метод с другим – юзабилити-тестирование. наверх     к оглавлению Проверка посредством наблюдения за пользователем Один из самых простых видов тестирования. Пользователю дается задание, он его выполняет, его действия фиксируются для дальнейшего анализа на камеру, либо какой-нибудь программой записи состояния экрана (например, Lotus ScreenCam). Метод исключительно полезен для выявления неоднозначности элементов интерфейса. Поскольку каждая неоднозначность приводит к пользовательской ошибке, а каждая такая ошибка фиксируется, обнаружить их при просмотре записанного материала очень легко. В последствии можно посчитать количество ошибок и сделать соответствующие выводы. Кроме того, если замерять время выполнения задания (секундомером), можно оценить производительность работы пользователей. наверх     к оглавлению Мыслим вслух Запись или протоколирование «мыслей вслух» – очень распространённая методика, применяемая при юзабилити-тестированиях. В течение теста, пока участник выполняет то или иное задание в рамках своего сценария, экспериментатор просит участника вербализовать его мысли, чувства и мнения, возникающие в процессе взаимодействия с продуктом. Комментарии записываются на диктофон или камеру, а затем анализируются. Как производится протоколирование В первую очередь необходимо предоставить участнику сам тестируемый продукт (или прототип его интерфейса) и сценарий – список заданий, которые ему необходимо выполнить. Попросите участников в процессе выполнения заданий подробно сообщать всё, что возникает у них в голове, пока они работают с интерфейсом продукта. «Мысли вслух» позволяют вам понять, как пользователь подходит к интерфейсу и какими соображениями он руководствуется, используя этот интерфейс. Если последовательность шагов, которую пользователю потребуется пройти для выполнения задания, оказывается отличной от той, что он себе представлял, возможно, интерфейс излишне вычурный. Основную выгоду из использования данной методики вы извлекаете, получая лучшее понимание ментальной модели пользователя и его взаимодействия с продуктом (понимая, что в действительности происходит у него в голове), однако, вы можете обнаружить ещё некоторые полезные моменты. К примеру, терминология, которой участник пользуется для объяснения идеи или функции, может быть внедрена в дизайн продукта и использована при проектировании, или, по меньшей мере, при написании документации. Когда стоит использовать данную методику Используйте этот метод на любой стадии разработки. «Мысли вслух» – недорогой путь получения хорошей качественной ответной реакции в течение тестирования. наверх     к оглавлению Проверка качества восприятия Тест позволяет определить, насколько легко интерфейсу обучиться. Поскольку существует разница между понятиями видеть и смотреть, а запоминается только то, что увидено, необходимо обладать уверенностью в том, что пользователь увидит если не всё, то уж хотя бы всё необходимое. А значит – запомнит, благодаря чему в будущем ему не придется обшаривать меню в поисках «чего-то такого, что, я точно знаю, где-то здесь есть». Сама по себе методика проста. Пользователю даётся задание, связанное с каким-либо отдельным диалоговым окном. Пользователь его выполняет. Через несколько минут пользователя просят нарисовать (пускай даже грубо и некрасиво) только что виденное им окно. После чего рисунок сравнивается с оригиналом. Разумеется, пользователь запоминает только то, что ему кажется актуальным в процессе работы с окном (плюс еще что-нибудь за того, что ему показалось интересным, да и то не всегда). Это один из тех редких случаев, когда срабатывает ограничение на объем кратковременной памяти, так что количество запомнившихся элементов управления не может быть выше порога. Пример проверки качества восприятия. Пользователь, которому нужно сменить шрифт абзаца на Arial из всего диалогового окна выбора шрифта в MS Word запоминает только часть элементов управления. Разумеется, он помнит, что помимо них были и другие, но точно вспомнить остальные элементы он, как правило, не может. наверх     к оглавлению Измерение производительности Некоторые юзабилити-тестирования ориентированы на получение чётких, количественных данных. В большинстве случаев эти данные представлены в форме метрик производительности, – сколько времени занимает выделение блока текста с помощью клавиатуры, мыши или трекбола? Как расположение клавиши Backspace влияет на частоту появления ошибок? Часто в процессе проектирования продукта ориентируются на достижение подобных целей. Цели в таком случае могут формулироваться в виде условий, например: «пользователь должен иметь возможность установить соединение с Интернет без ошибок или по бесплатной линии» или «Основная задача должна выполняться за время не превышающее часа 75 процентами пользователей». Эти условия устанавливаются на базе изначального тестирования предыдущей версии или продуктов-конкурентов. Должна быть поставлена цель, определены задачи, спроектированы тесты и непосредственно поставлен эксперимент. При измерениях производительности необходимо учитывать следующие моменты: Критерий выполнения задачи должен быть количественно определён Как оговаривалось ранее, задачи должны быть выражены в величинах, подлежащих определению, однако, для измерений производительности необходимо, чтобы они имели чёткий критерий в виде численно-выраженой величины. К примеру, вы можете задаться вопросом: «что более эффективно, кнопки на управляющей панели или «горячие клавиши». Ответ на сформулированный таким образом вопрос можно получить при помощи тестирования двух интерфейсов, одного, ориентированного на «горячие клавиши», и второго, основанного на панелях с кнопками. Производительность каждого пользователя определяется при помощи замеров времени, потраченного им на выполнение каждого задания и при помощи журнала допущенных пользователем ошибок. Структура эксперимента действительно важна Поскольку задачей тестов с измерением производительности является получение корректных количественных данных, структура эксперимента также должна быть корректной. Количественные тесты предполагают, что изменения в независимых переменных (таких, как наличие кнопок на панели или доступность «горячих клавиш») отразятся на зависимых (в нашем случае, на времени, затрачиваемом на запуск команд, использующих одну или две опции). Это влияние называется экспериментальным эффектом. Тем не менее, если дополнительные факторы будут внесены в структуру теста, этот эффект может быть искажен и эксперимент окажется статистически недостоверен, поскольку будет испорчен влиянием неучтенных факторов. Эксперимент должен быть спроектирован с учётом возникновения возможных искажающих факторов, чтобы устранить всё, что может повлиять на экспериментальный эффект. Данные не сообщают всех подробностей По некоторым причинам тестирования, исключительно ориентированные на сбор данных, касающихся измерения производительности, не так распространены, как это могло бы показаться. Такие тестирования требуют очень скрупулезно спроектированных тестов и значительных ресурсов. У большинства компаний на такие тестирования нет ни времени, ни денег. Кроме этого, масштаб получаемых с их помощью результатов зачастую очень невелик. Действительно ли так важно, что использование «горячих клавиш» вместо панелей с кнопками даёт выигрыш в полсекунды? Возможно важно, если вы разрабатываете программное обеспечение для центров обработки заказов, и экономия половины секунды на каждом звонке, помноженная на тысячи операторов по всей стране, может сократить годовые расходы на миллионы долларов. Но для большинства офисных приложений экономия в половину секунды не представляет реальной важности. Когда стоит использовать данную методику Измерение производительности используется на начальных этапах для задания контрольных замеров для процесса проектирования. Также оно используется на протяжении всего проектирования для измерения того, насколько далеко удалось продвинуться относительно этих контрольных замеров. наверх     к оглавлению Карточная сортировка Карточная сортировка — это классификационный метод, при котором пользователи сортируют различные элементы разрабатываемого ПП по нескольким категориям. Для проведения карточной сортировки создается список параметров, которые предполагается подвергнуть классификации, после чего каждый из указанных параметров выписывается на отдельной карточке. Карточки предъявляются пользователям, которых инструктируют сгруппировать наиболее логичным, по их мнению, образом. Полученную в результате карточной сортировки информацию используют для организации пользовательского интерфейса.

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

Контрольные листы помогают удостовериться в том, что веб-сайт выполнен с учетом принципов функциональности дизайна. Обычно их используют на заключительной стадии работы в дополнение к экспертным методам для того, чтобы структурировать экспертные оценки по каким-то определенным признакам. Нельзя получить хороший результат, если не определены критерии качества и завершенности проекта. Контрольный список (или «чеклист») это документ с перечнем требований к выполняемой работе. Каждому свойству готовой работы присваивается весовой коэффициент (например, "отсутствие грамматических ошибок — 4%"), а работа считается выполненной, если сумма коэффициентов больше близкого к сотне числа (например, 97%). Благодаря этому исполнителю не требуется волноваться по поводу качества работы — от него требуется только соблюдать все изложенные в списке требования, а заказчик может быстро проверить качество выполнения, выборочно проверив отдельные параграфы. Наличие контрольного списка увеличивает производительность работы, так как не нужно тратить время на размышления двух тематик — что нужно вообще сделать и что нужно ещё сделать. Ответ на оба вопроса уже содержится в контрольном списке. Использование контрольных списков является эффективным и экономичным средством повышения уровня качества программных продуктов. Он позволяет глобально оценить состояние проекта, тратя на это очень мало времени. Естественно, что в каждом конкретном случае необходимо разрабатывать свой собственный контрольный список, поскольку он должен учитывать специфику разрабатываемого программного средства и возможности средств разработки. Поэтому контрольные списки представленные ниже является скорее шаблоном, в котором представлены основные разделы. Контрольный список интерфейса ПО Контрольный список Веб-интерфейса к оглавлению Контрольный список интерфейса ПО Окна При проектировании было учтено, при каком разрешении, а так же размере монитора и шрифтов будут работать пользователи. Заголовки Заголовки короткие и адекватные содержимому окна. Заголовки соответствуют названиям элементов, при помощи которых окна были вызваны. Если окно вызывается элементом, не имеющим явного названия, в заголовке окна отражается название экранной формы. Дизайн окна Тип окна (модальное, немодальное, возможность минимизации/максимизации) был выбран осознанно, в соответствии с задачами пользователей. Управляющие и информационные элементы расположены достаточно далеко друг от друга (не менее 7 DLU). Информация в окне адекватно сгруппирована (связанные элементы объединены в группы). Кнопки находятся в секции, на которую они оказывают непосредственное воздействие. Терминационные кнопки (управляющие окном) расположены либо снизу в ряд либо справа в колонку. Переход от элемента к элементу внутри окна, осуществляется сверху вниз слева направо. Диалоговые окна В диалоговых окнах отсутствуют меню или инструментальные панели. Диалоговые окна открываются не в центре экрана, а в центре текущего действия пользователя. Меню Пункты главного меню Пункты меню имеют адекватные названия. Первая буква в названии пунктов заглавная. Все пункты первого уровня активизируют выпадающее меню. Каждому пункту меню назначены общепринятые горячие клавиши (выделены подчеркиванием). Раскрывающиеся меню и элементы основного меню второго уровня Все элементы начинаются с заглавной буквы. Если в меню используются пиктограммы, они расположены слева от названия пункта меню. Все списки содержат более одного элемента. Высота меню не превышает размер экрана (меню не нужно прокручивать). Пункты меню адекватно сгруппированы. Осмысленно использованы разделители в меню. Пункты меню расположены в порядке связанности выполняемых функций, частоте использования, важности. Используются не более двух подуровней меню. Каждый пункт меню имеет соответствующую горячую клавишу. Название пункта меню соответствует названию вызываемого окна. Пункты меню, открывающие диалоговые окна, обозначены в конце многоточием (…). Недоступные пункты меню обозначены серым цветом шрифта. Всплывающие меню Каждому пункту всплывающего меню соответствует аналогичный пункт в основном меню. Инструментальные панели Каждому элементу инструментальной панели соответствует всплывающая подсказка. Элементы упорядочены и сгруппированы в соответствии с задачами пользователей. Для стандартных действий используются общепринятые графические элементы.  Управляющие элементы Переключатели (Check boxes) В одном окне используется не более 10 переключателей. Переключатели сгруппированы и каждой группе присвоено название. Внутри группы переключатели расположены строго вертикально. Переключатели не применяются для частого, оперативного использования. В названиях используется только позитивная, утвердительная форма. Командные кнопки Кнопки имеют краткие и ясные названия. В каждом диалоге используется не более 6 кнопок. Кнопки, выполняющие в разных диалогах идентичные функции, имеют одинаковые названия. Типовые кнопки имеют общепринятые названия и общепринятые горячие клавиши. Кнопки, вызывающие продолжение диалога в вложенных формах, обозначены многоточием (…). Недоступные кнопки имеют соответствующие атрибуты (серый цвет шрифта и т.п.). Опасные для пользователя кнопки не являются кнопками по умолчанию Редактируемые поля со списком (Сombo Box) Имеют функцию авто-выбора. Раскрывающиеся списки Высота выводимого на экран списка ограничена 3-8 элементами. Если список содержит более 50 элементов, используется фильтр или режим поиска. Если все элементы не умещаются в одном фрагменте списка, автоматически появляется полоса прокрутки. Группы элементов Каждая группа имеет осмысленное название, помимо рамки отделена от других групп и элементов свободным пространством. Подписи (Labels) Все элементы имеют подписи. Учтена возможность увеличения (уменьшения) длины подписей при использовании large fonts (small fonts). Подписи выровнены по левому краю поля (если они находятся над полем). Подписи расположены по середине высоты поля (если название находится с боку). Если элемент недоступен, подпись отображается серым шрифтом. Списки Если список содержит более 50 элементов, используется фильтр или режим поиска. Высота ограничена 3-8 элементами. Если все элементы не умещаются, автоматически появляется полоса прокрутки. Кнопки выбора (Option Buttons или Radio Buttons) В одной группе используется не более 6 кнопок. В пределах группы кнопки расположены по вертикали. Нет состояния, когда ни одна кнопка не выбрана. Последовательность расположения кнопок в группе учитывает частоту использования. Вкладки (Tabs) Названия вкладок выровнены по центру. Каждой вкладке присвоено осмысленное название. Количество рядов закладок не превышает двух. Все связанные между собой данные находятся внутри одной закладки. Кнопки, относящиеся ко всему блоку закладок, расположены за пределами блока закладок. Текстовые поля ввода (Text Box or Edit Field) Для недоступных полей используются серый цвет (название, текст и фон поля). Высота всех текстовых полей в окне одинакова. Содержимое полей выровнено по левому краю, за исключением полей с числовыми значением (напр., для вывода денежных сумм). Длина поля не меньше длины вводимых в него данных. Если в поле вводится численное значение границы диапазона выводятся во всплывающей подсказке. Порядок табуляции фокуса ввода При открытии окна фокус попадает на элемент внутри окна. Схема табуляции соответствует очередности заполнения полей (слева направо, сверху вниз). Командные кнопки включены в табуляцию. Невидимые и недоступные элементы исключены из схемы табуляции. Пиктограммы Направление теней во всех пиктограммах одинаково: слева сверху. Взаимодействие с пользователем Система, завершив какую-либо длительную операцию, пищит через встроенный динамик компьютера. Цифры, предназначенные для сравнения либо для копирования в буфер обмена, выводятся непропорциональным шрифтом. наверх     к оглавлению Контрольный список Веб-интерфейса Показывает ли ваш сайт возможность воспринять действия пользователя? По преимуществу это касается активных (изменяющих свой вид в зависимости от положения курсора) кнопок. Всегда ли вы предупреждаете пользователя о неприятных последствиях его действий? В основном вопрос касается апплетов, но также затрагивает необходимость предупреждать пользователя о длительном ожидании загрузки станицы (если она богата графикой). Постоянно ли доступны пользователю все управляющие элементы сайта? К примеру, постоянно ли доступна пользователю вся необходимая система навигации? Вопрос относительный, т.к. единственный на данное время способ сделать что-нибудь постоянно видимым — это кадры, которые сами по себе нехороши. Корректно ли сайт печатается? Очень важный вопрос для страниц, объёмом больших, нежели 2Kb (их чаще печатают). Надо проверить, как печатаются страницы на монохромных и цветных принтерах. Если вы режете большие тексты на множество отдельных страниц, вы должны предоставить пользователю возможность открыть и напечатать весь текст одной страницей (причём без красот экранного дизайна). Если глубина вашего сайта больше 5 страниц, предоставляете ли вы возможность текстового поиска? Отсутствуют ли страницы с дизайном, отличающимся от актуального в настоящее время? Есть ли страницы с содержанием, стилистически отличающегося от обычного? Вопрос, по преимуществу, об оставшихся от прежних версий сайта страницах, которые не были переделаны в отношении дизайна либо стилистики текста. Всегда ли корректно работает кнопка Back браузера? Некоторые страницы, переданные по шифрующему протоколу, не могут быть взяты браузером из кэша и их требуется загружать заново (в лучшем случае пользователю нужно самому нажать кнопку Refresh, в худшем — производить более сложные и неочевидные действия). При повторной загрузке таких страниц может также слететь установленная в браузере кодировка (и весь русский текст превратится в тарабарщину). Избегайте делать такие страницы. Также, если у вас есть страницы с формами ввода, добейтесь того, чтобы вернувшийся на эту страницу пользователь (не важно, копкой ли Back, либо благодаря гиперссылке) нашел её со всеми своими установками (это очень экономит время, если нужно вернуться и что-нибудь поправить). Частично этот вопрос перекликается с последующим. Видимы ли все изменения в содержании и дизайне, произошедшие из-за действий пользователя? Например, если пользователь установил какой-нибудь переключатель, то во всех страницах, демонстрирующих результаты его действий, должно быть показано, что этот переключатель установлен в соответственное положение. Принципом, послужившим основой этого вопроса, является утверждение, гласящее, что любое действие пользователя должно быть отражено интерфейсом. Хорошо ли выглядит ваш сайт на низкокачественных мониторах? Хорошо ли он выглядит на монохромных мониторах, шестнадцатицветных или показывающих только оттенки серого? Если вы используете какое-либо цветовое кодирование информации, то имеются ли иные способы индикации (текст, графическое воплощение и т.д.)? Всегда ли вы используете изображения для иллюстрации (индикации) команд, возможностей либо параметров вашего сайта (если это вообще возможно)? Использует ли графика метафоры, известные пользователю по обычной жизни? Лишаете ли вы её несущественных подробностей, без пользы усложняющих её восприятие? Вообще говоря, нет никакого смысла как в абстрактных пиктограммах, так и в пиктограммах, инспирированных компьютером. Место хранения файлов можно обозначить изображением жёсткого диска, но при этом от пользователя будет требоваться знание того, как этот диск выглядит. Что неправильно, т.к. от пользователя вообще нельзя ничего требовать. Лучше нарисовать шкаф. Если вы используете более или менее трёхмерные изображения, то все ли они обладают одинаково направленной тенью? Это одна из самых распространённых дизайнерских ошибок. Так как сайт представляет собой единое пространство, множество разных источников света сбивает с толку (и смешно выглядит). Избегаете ли вы использовать цвет в значимых областях страницы, если этого не требует необходимость выделять важную информацию? Этот вопрос не относится к общему фону страницы. Используете ли вы яркие (насыщенные) цвета только в небольших областях и только при необходимости? Используете ли вы только нейтральные фоновые цвета? Если вы используете тёмный или чёрный фон, установлено ли жирное начертание текста по умолчанию (на большинстве низкокачественных мониторов, которые и составляют большинство, тонкий светлый текст на тёмном фоне проявляет несведение лучей и от этого выглядит сильно размытым)? Уверены ли вы, что ваш сайт приемлемо выглядит с любым размером системного шрифта? Многие пользователи устанавливают его размер на максимальный, отчего практически любой дизайн разваливается (лишить их такой возможности можно с помощью стилевых листов). Организована ли информация так, чтобы наиболее важные данные находились в начале страницы (чтобы их можно было прочесть в первую очередь)? Используете ли вы только командно ориентированные фразы в текстовых сообщениях любой природы (либо фразы, ориентированные на прямые действия)? Например, "Нажмите кнопку Абв, чтобы узнать результаты забегов" вместо "При нажатии кнопки Абв откроется страница с результатами забегов" или вместо "Не нажимайте кнопку Абв, если не хотите узнать результаты забегов". Сохраняется ли смысловая последовательность текста при его верстке (очень часто последовательность портится при использовании таблиц). Правильная последовательность важна для индексирующих машин, причем её значение будет возрастать в будущем (например, это важно для воспроизведения страниц синтезирующими речь системами). Стараетесь ли вы использовать кнопки с глаголами, нежели иными частями речи, например "Показать" вместо "Готово"? Установлен ли соответствующий альтернативный текст на все значимые графические изображения? Отвечает ли этот текст на один из трёх (или больше) вопросов: "Что это?", "Что это делает?" и "Что произойдет, если по этому щелкнуть?" Обладает ли ваш сайт своей справочной системой? В идеале каждый тип страницы должен обладать страницей со справочной информацией (вроде "Нажмите на эту кнопку, чтобы перейти к следующему разделу"). Различаются ли цвета у пройденных и непройденных гиперссылок? Проверили ли вы грамматику и орфографию? Убедились ли вы, что все страницы имеют корректный заголовок (title)? Отражают ли заголовки страниц (title) путь пользователя к этим страницам?