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