Войти в систему
Войти с помощью соц. сетей:
В сравнении с творческим процессом, любая другая деятельность должна играть второстепенную роль, в особенности та, что связана с наблюдением. Получается, что программисты занимаются творчеством, а юзабилити безмолвно ставит их у руля со словами: «Сначала вы создадите нечто, а затем я проведу тестирование и смогу оценить, насколько хорошо вы выполнили свою задачу». Однако в связи с тем, что мир высоких технологий вращается с невероятной скоростью, только что созданные продукты моментально выходят на рынок. И тестирование, выполняемое постфактум, уже не сможет что-либо изменить.
Я мог бы сравнить методы юзабилити-тестирования с наждачной бумагой. Сотвори вы стул, наждачная бумага сгладит все его шероховатости. Сделали стол – и вновь наждачная бумага все отшлифует. Однако никакая шлифовка не сделает стул из стола. И все равно мне неоднократно приходится наблюдать, как тысячи людей усердно шлифуют столы посредством приемов юзабилити в надежде получить стулья.
Бесспорно, вполне возможно проводить этап юзабилити-тестирования до начала этапа программирования, но в этом случае сама сущность и ценность всего процесса будет подвергнута радикальным преобразованиям. При таком подходе тестирование больше похоже на классическое исследование, характерное для университетской среды. Один мой коллега из крупной компании, занятый в сфере разработки ПО, как-то провел типичный юзабилити-тест, в ходе которого ему удалось выявить как сильные, так и слабые места такого предваряющего этапа тестирования. В своем тестировании он намеревался понять, насколько эффективна строка состояния в самом низу окна программы. В ходе эксперимента участникам нужно было выполнить несложное задание в электронной таблице. При этом каждые пять минут в строке состояния отображалась надпись: «К обратной стороне вашего стула приклеена банкнота в $50. Заберите ее!» Тестирование продолжалось целый день, однако за это время не нашлось ни одного участника (а их было более десяти), кто предпринял бы попытку забрать купюру.
Бывает весьма полезно осознать тот факт, что пользователям обычно нет никакого дела до надписей в строке состояния, хотя в программистской среде она столь популярна. Тем не менее это не делает более ясным суть проблемы: что должно представлять собой это состояние, чтобы для пользователя это было действительно полезно? И нужно ли вообще что-то отображать? Где именно это лучше сделать? На все эти вопросы касательно проектирования ответов по-прежнему нет.
В профессиональной литературе приведено множество различных методик и советов относительно проведения тестирования, только они содержат весьма незначительное количество упоминаний способов тестирования на том этапе, когда продукта еще фактически нет. На практике существует необходимость в создании и тестировании хоть какой-то программы. Как правило, в роли макета выступает наскоро сверстанный прототип или некое подобие «кукольного театра» – форма из бумажных вырезок и иных низкобюджетных материалов.
Разумеется, отслеживая реакцию пользователя при демонстрации спектакля в этом «кукольном театре», вы можете узнать много интересного, однако, пропуская этап проектирования, вы в итоге можете прийти к осознанию, что тестировали совсем не то, что нужно. Более того, при такой форме эксперимента любое незначительное действие, исходящее от инициатора тестирования, вроде кивка головой, мимолетно сказанного слова, неосторожного взгляда, может оказать сильное влияние на результаты, искажая их.
Наиболее адекватные результаты можно получить, если прибегнуть к дорогостоящему методу сравнительного тестирования, когда создается два варианта программы и каждая предлагается пользователям. Но даже при таком подходе все, что вы сумеете узнать, – это какой из двух вариантов лучше. Вы по-прежнему не сможете понять, какой в реальности могла бы быть самая подходящая для пользователя программа.
Грамотное юзабилити-тестирование помогает выявить те предположения, которые оказались ошибочны, на взгляд проектировщика. Вариант, при котором вы сначала показываете результаты проектирования пользователям, а затем вносите изменения методом итераций, всегда является более выигрышным, чем полное отсутствие проектирования. Ввиду того что часть новых технологий, например распознавание речи, изучена еще недостаточно хорошо, даже простейшие юзабилити-тесты могут сыграть значительную роль.
Пожалуй, одним из самых ценных моментов тестирования можно назвать присутствие на эксперименте программистов, наблюдающих за битвой пользователей с их разработками из-за одностороннего зеркала. Программистов обычно крайне изумляет поведение пользователей, вплоть до недоверия, и они выражают недовольство: «В тесте участвуют какие-то недоумки!» Так юзабилити-тестирование метко цепляет упрямых разработчиков ПО, указывая им на то, что проблема действительно имеет место. Точно так же оно может открыть глаза и руководителям.
Говоря словами одного популярного рекламного слогана о зубной пасте: с помощью юзабилити-тестирования можно эффективно предотвратить «кариес», если внимательно следовать советам специалистов и придерживаться целеориентированного подхода к проектированию. Главное здесь – не забывать, что все еще остаются факторы, способные оказать более сильное влияние.
Войти с помощью соц. сетей: