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