Мы попросили одного разработчика сыграть роль «компьютера», он должен был изображать поведение программного обеспечения, оперируя листами бумаги. Например, если клиенты хотели открыть документы в Windows , им нужно было коснуться слова «Файл» в меню. «Компьютер» реагировал, вытаскивая листок бумаги, содержащий опцию меню «Файл». Клиент далее вызывает опцию «Открыть», компьютер при этом показывает открытый диалоговый ящик.
Два дня ушло на тестирование бумажного прототипа. В каждой сессии тестов участвовали два человека, представляющих целевой сегмент. Мы демонстрировали им работу программного обеспечения, не объясняя при этом, как работает интерфейс – вместо этого их попросили проделать реальные операции с помощью прототипа. «Компьютеру» не разрешалось что-либо подсказывать пользователям, он мог только совершать операции в соответствии с назначением интерфейса.
Участников тестов не спрашивали об их мнении относительно интерфейса; наблюдались только их фактические действия с программным обеспечением (бывали ситуации, когда люди выражали позитивное отношение к продукту, хотя испытывали при этом трудности в использовании, или наоборот). Все разработчики наблюдали за ходом тестов, делая пометки в тех случаях, когда обнаруживались проблемы в использовании интерфейса.
Разработчики были удивлены огромным количеством выявленных проблем. В некоторых случаях, возникали споры по поводу слабых мест, не обнаруженных пользователями. К тому же обнаружились серьезные недоработки интерфейса, о которых никто даже не подозревал. Благодаря Usability-тестированию каждый специалист увидел все узкие места продукта, которые могли бы повлиять на успех следующей партии.
После каждого двухчасового тестирования, разработчики обсуждали свои наблюдения и сразу же вносили коррективы в бумажные прототипы. С бумажными прототипами вся команда могла участвовать в разработке дизайна, вместо того, чтобы взвалить весь объем работы на одного или двух программистов. Специалисты команды разработчиков (инженеры, маркетологи, управленцы, специалисты по обучению), используя фломастеры и ножницы, отражали свое экспертное мнение в бумажных прототипах.
Изменения в бумажных моделях менее болезненны, чем уже выпущенном программном продукте. С готовым продуктом – сложнее: из-за существенного объема весьма трудоемкой работы, затраченной на создание, сотрудники команды разработчиков склонны защищать свое изделие, прикладывая максимум эмоций, даже когда для всех очевидна необходимость изменений – ведь, на самом деле, очень сложно выбросить на ветер потраченные усилия. В противоположность этому, из-за простоты создания и возможности безболезненно вносить изменения в1 бумажные прототипы, соответственно, сотрудникам незачем тратить энергию на их «защиту». В результате разработчики становятся более гибкими, мобильными и охотнее экспериментируют с новыми идеями. В рассматриваемом нами случае команда затратила около двух часов на внесение изменений.
После ланча были приглашены еще два пользователя, для выполнения тех же самых заданий, чтобы посмотреть, сделали мы в итоге продукт лучше или хуже исходного. Выяснилось, что большинство изменений оказались усовершенствованиями. Некоторые изменения были так просты, как, например, использование различных слов, перемещение значка с верха экрана вниз или предоставление примера в справочном файле. Другие изменения были более существенными – мы были свидетелями того, как разработчики практически полностью переработали свои продукты, буквально за ночь, после того, как поняли, что первоначальный дизайн был просто обречен на провал.
После двух дней тестирования были определены самые существенные проблемы в интерфейсе. На 6-й день мы снова встретились с командой специалистов, чтобы проранжировать по уровню важности оставшиеся недоработки продукта, используя при этом уже не субъективные мнения и оценки, а научно обоснованные данные, полученные в ходе usability-тестов. Учитывая жесткий график, (оставался месяц до beta-тестирования) члены команды знали, что должны сосредоточиться на наиболее рискованных моментах для, того, чтобы следующий выпуск был успешным. И только на седьмой день ребята смогли отдохнуть.
Используя бумажные прототипы и usability-тестирование, разработчики имеют возможность контролировать риски, сосредоточившись на них в самом начале работы над проектом, пока еще есть время для внесения изменений. При этом начать необходимо с определения узких мест, могущих серьезно повлиять на успех последующих серий выпуска продукта – мест наибольшего риска. Наш основной вопрос специалистам был такой: «Что является следующим наибольшим риском?» В итоге они поняли, как использовать бумажные прототипы и usability-тестирование для информационного обеспечения принятия ключевых решений, ведущих к разработке качественного продукта, отвечающего потребностям целевого рынка.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.