Сбор полной схемы

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

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

А) Проверка схемы по сценарию

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

Б) Экспертная оценка

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

Для проведения экспертной оценки нужно знать следующее:

Разные люди обнаруживают разные ошибки. Это значит, что метод работает лучше, когда количество экспертов больше единицы.

Лучше привлекать несколько экспертов не одновременно, а последовательно.

Чем больше информации о проектируемой системе будет предоставлено эксперту, тем более сложные проблемы он сможет выявить.

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

Координаты всех людей, способных выполнить такую работу, можно найти на сайте www.usability.ru.

В) Построение прототипа

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

Не полируйте прототип. Первый прототип стоит делать максимально примитивным. Только после того, как тестирование подтверждает его правильность, стоит делать более детализированный прототип.

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

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

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

Реально выглядящая, но лишенная каких-либо алгоритмов часть.

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

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

Г) Тестирование/модификация прототипа

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

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

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