90% всех юзабилити-тестов - бесполезны
Девяносто % тестов юзабилити сайтов - бесполезны. Не говоря уже о том, что они не играют значимой роли в ходе разработки. Если тесты проводить верно, они способны улучшить и ваш сайт и процесс его разработки, однако существующая сейчас культура тестирования такова, что тесты нечасто приносят какую-то пользу. Хуже того, неправильное применение этой важной методики может подорвать во всей организации благоприятное к ней отношение.
Способ тестирования юзабилити берет свое старт из науки, изучающей процесс взаимодействия "человек-компьютер" (Human-Computer Interaction - HCI). Адепты этой науки - наиболее яростные защитники этого способа. Способ, который включает исследователя, подопытного, перечень задач, и время от времени даже секундомер, был разработан еще во времена мейнфреймов, на которых тестировались прикладные программы. И базировался этот способ на еще более древнем методе - методе анализа задач. Подход подразумевал строго выполняемые последовательности действий, результаты которых обрабатывались статистически. Хотя, когда этот способ стал применяться в Web для анализа поведения людей, он стал давать сбои, т.к. сайт - не только лишь утилита. С этим нужно считаться.
Контекст, а не измерения
Веб, будто какой-то Франкенштейн, - дикая смесь творческого потенциала и кода, вдохновения и обыденности, формы и функционала, искусства и науки. Хороший веб-дизайн соединяет себя все эти факторы, и нередко непросто заявить, где кончается 1 и начинается иной. Бестолково пробовать точно оценить точное время, нужное для решения какой-либо определенной задачи. Важнейший вопрос, на который в первую очередь требуется ответить, по какой причине пользователи останавливаются? Что они разглядывают? Что они об этом считают? Ваша навигация их запутала посему, что она неудачно разбита на категории, или из-за неверно выбранных слов, а может из-за неудачного расположения? А может из-за того, что она в различных разделах ресурса разная, или так как плохо написаны CSS стили? Традиционное тестирование юзабилити не даст вам ответы на эти вопросы.
Мы обязаны отказаться от мифа, что тестирование сайтов при помощи людей - количественный процесс. Фокусируясь только на числах и игнорируя иные типы данных, вы в итоге получаете только пустые высказывания типа "Дизайн А на 5% более удобен, чем дизайн Б" (или "90% всех тестов юзабилити - бесполезны"). Вместо этого исследования обязаны углубляться в качественные параметры дизайна с целью понять, как и по какой причине люди реагируют на то, что было создано, и, что более важно, как применять эти реакции в будущих работах.
Сделайте это сами
Есть устарелое мнение, что юзабилити тестирование требует особого непредвзятого профессионала, т.е. что ученые "с позиции" объективней вас самих оценят то, что делают ваши пользователи. Однако если вы не желаете просто полагаться на статистику, и при том вы хотите учитывать контекст эксплуатации вашего ресурса, всё, на что вы можете положиться - ваши собственные глаза.
Итак, наступило время закатать свои рукава. Для тестирования юзабилити веб-ресурса вовсе не нужны сторонние компании, которые никак не принимают участие в ходе его разработки. Тестирование должно быть включено как определенный этап в сам процесс разработки. Его требуется исполнять с полноценным привлечением всей команды разработчиков, так, чтоб любой мог взглянуть на собственную работу с позиции пользователя. Разработка и проведение юзабилити тестирования обязаны быть неотъемлемой задачей одного из членов вашей команды (при том многие думают, что это не должен быть сам дизайнер ресурса).
Не стоит ограничиваться только командой разработчиков. В тестировании обязаны участвовать и иные работники вашей компании. Любой, кто в любом случае связан с тестируемым проектом, должен быть привлечён к работе хоть на каком-то из этапов. Если в вашей компании необходимые люди увидят, что у настоящих людей появляются с продуктом реальные трудности (которые вы можете решить), они поймут и ваше значение для организации и важность выделения времени и ресурсов, которые позволят сделать хороший проект.
Тестирование юзабилити - часть проектирования, а не контроль качества
Изменив собственный подход к тестированию юзабилити, вы тоже обязаны понять, что результаты от тестирования не будут похожи на те, что вы ожидали до этого. В отличие от простой проверки, которая производится лишь 1 раз перед окончанием проекта, внутренний, качественный тест юзабилити, о коем мы ведем речь, проводится на более ранних стадиях проекта, проводится чаще, и проводится в качестве составной части процесса создания ресурса - а не его отдельно взятого этапа.
Традиционно тестирование юзабилити рассматривается как собственного рода контроль качества. В этом случае тестирование юзабилити относится к последним этапам проекта, выполняется "для галочки", чем возможно при случае и поступиться, если сроки по выходу новой версии веб-ресурса поджимают. Результаты этого тестирования как правило записывают в толстенном документе, где перечисляются все обнаруженные трудности веб-приложения, в частности и фундаментальные ошибки дизайна , которые нельзя поправить за несколько недель до выпуска проекта в свет. Согласитесь, это не наиболее наилучший метод сделать качественную вещь.
Если тестирование юзабилити рассматривается как часть процесса, результат получается абсолютно другой. Наиболее захватывающая работа, которую мне когда-или довелось видеть, случается на белой доске (whiteboard) в комнате наблюдений в то самое время, когда в соседней комнате проходит тестирование. В некоторых случаях мы даже вносили перемены прямо м/у раундами тестирования, пытаясь оценить реакцию следующего испытуемого на лишь что придуманное решение. С позиции статистики подобный подход - полное нарушение всех правил, однако с позиции дизайна - манна небесная.
Менее затрат
Проведение юзабилити тестирования совместно с вашей командой разработчиков ведёт к понижению затрат и времени на разработку,- дорогостоящие консультанты более не нужны! - что позволяет проводить тестирование чаще, по принятому в коллективе порядку работ. Подобный подход позволяет тестированию юзабилити превратиться из простого теста, ориентированного на разовый отчёт, во неоднократно повторяемый тест, влияющий на разработку. Создали несколько простых страниц-эскизов? Дайте паре ваших людей опробовать их. Сделали простой прототип? Представьте его группе из некоторого количества людей.
Подобный подход к делу позволяет вам вносить перемены тогда, когда они менее затратны. Намного легче изменить нечто фломастером на белой доске, чем в готовом эскизе; проще изменить эскиз, чем прототип; и, наконец, проще изменить прототип чем готовый продукт.