В поисках идеальной юзабилити-проблемы
Статей, посвященных базовым вопросам, никогда не бывает слишком много. Поэтому я тоже решил покопать давно избитую и всем известную тему. Сегодня мы с вами поговорим о каноничном определении и описании юзабилити-проблемы.
В статье сознательно не будет кейсов и примеров, потому что сейчас нам особенно важно сфокусироваться на основополагающих принципах юзабилити-тестирования, не спускаясь в обсуждение единичных примеров.
Почему я считаю это важным? Юзабилити-тест — это тот метод исследования, в котором, на самом деле, не так много разночтений. Он очень ограничен и прост, но именно в ограничениях его сила. И то же самое относится к его результатам, мы можем очень четко определить, что является юзабилити-проблемой и как её описать.
Но зачастую нам кажется, что мы можем этим методом охватить больше, чем то, для чего он предназначен. И подобное размытие может лишить метод его сильных сторон, а также снизит доверие к нашему исследованию.
Особенности юзабилити-тестрования как метода
В юзабилити-тесте у нас четко определен объект исследования — интерфейс. Цели и задачи у нас тоже однозначные — мы ищем юзабилити-проблемы, с которыми сталкивается пользователь и измеряем юзабилити тестируемого продукта.
Благодаря тому, что объектом юзабилити-теста является интерфейс, мы можем делать сильные выводы на небольшой выборке. Нам не нужно особенно думать о валидности результатов, ведь изучаем мы не мнение, а интерфейс. Мы буквально видим перед глазами те особенности интерфейса, которые приводят к проблемам на тесте, и понимаем, что их необходимо так или иначе исправлять.
Ограничивая объект исследования, мы получаем уникальную в качественных исследованиях возможность. Наши выводы гораздо меньше похожи на предположения, у нас есть твердая, строгая аргументация. Именно эта ограниченность фокуса позволяет нам делать выводы на микроскопической для любого другого исследования выборке.
В большинстве случаев критика результатов юзабилити-теста упирается в незнание этих особенностей метода. “А мы точно можем верить этим респондентам? Ну скажут они, что им неудобно, но это же всего лишь два человека”, или же “А почему мы уверены, что другие пользователи будут сталкиваться с этими проблемами? А может это респонденты у вас тупенькие?”. Все это не несет в себе смысла, если мы понимаем, что на юзабилити-тесте мы оцениваем не пользователей, и даже не их поведение, а интерфейс. Ошибки, которые совершает респондент на тесте, позволяют увидеть нам те элементы, которые могут вызвать проблемы в реальном использовании продукта и почему они происходят. Респондент в юзабилити-тесте играет роль инструмента, они помогают нам оценить интерфейс.
Однако если мы смещаем фокус исследования, и начинаем изучать не интерфейс, а пользователя, то начинаются проблемы. Как метод, юзабилити-тест с достаточно простыми требованиями к выборке, имеет очень ограниченные возможности для изучения и мнения и поведения пользователей. Если мы начинаем пытаться с его помощью изучить пользователей, то у нас сразу вырастает выборка, появляется необходимость выстраивать 4–8 оконную структуру. Наш сценарий разрастается и мы добавляем туда больше вариативности. Это усложняет анализ, увеличивает наш отчет. И в итоге мы по факту проводим глубинные интервью с элементами юзабилити-теста, а не юзабилити-тест. Это сильно отражается и на сроках и на стоимости исследования.
Мы можем поступить по-другому, мы можем никак не видоизменять методологию теста, но при этом пытаться работать с респондентами и результатами так, как если бы мы проводили глубинные интервью. Тогда мы, скорее всего, не доходим до точки информационной сатурации и строим свои выводы на очень зыбких основаниях, довольно сильно их экстраполируя. Что в итоге снижает для нас ценность исследования, и снижает его валидность в глазах тех, кто смотрит результаты.
Именно поэтому, на мой взгляд, для того, чтобы полностью использовать сильные стороны юзабилити-тестов — скорость, простоту, низкие требования к выборке, четкие и однозначные результаты, мы должны осознанно держать фокус нашего исследования под контролем.
Результаты в юзабилити-тесте
В юзабилити-тестировании мы всегда должны осознавать разделение на главные и второстепенные результаты. Главным результатом юзабилити-теста всегда является набор юзабилити-проблем, еще в них может быть знание о степени удобства использования продукта, но не более того. Пользовательские ожидания, запросы на функционал, мнения о продукте, особенности использования продукта — это тоже невероятно важно, но в этом конкретном исследовании они второстепенны. Чтобы изучить их, нам нужно воспользоваться более подходящим методом. На юзабилити-тесте мы не получим достаточно сильного результата, максимум — гипотезы и идеи для последующих, более валидных по методологии исследований.
Таким образом мы подходим к идее идеального описания результатов юзабилити-теста, к идеальной юзабилити-проблеме.
Чтобы описать идеальную юзабилити-проблему, обратимся к классическому определению юзабилити:
Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.
Из этого определения мы можем вывести определение юзабилити проблемы:
Юзабилити-проблема — это особенность интерфейса, которая мешает эффективному и быстрому решению пользовательской задачи и снижает удовлетворенность от использования системы.
Это определение очень важно, потому что исходя из него мы также можем описать, чем юзабилити-проблема не является:
Юзабилити-проблема не может быть отсутствием желания что-то делать в продукте. Она не может выражаться в том, что человек не хочет что-то сделать. Мы сознательно ограничиваем наш фокус в юзабилити-тесте и убираем вопросы желания воспользоваться тем или иным продуктом и его функциями. Исследовать востребованность функционала сложнее, чем его удобство, для этого нам потребуется другой метод исследований.
Юзабилити-проблема не может быть багом, потому что баг — это заведомо некорректное поведение системы. Если мы пытаемся юзабилити-тестом изучить баги или технические свойства системы (например скорость загрузки данных, быстродействие анимаций и прочее), то мы рискуем сделать наши выводы на изначально некорректной выборке. Для грамотного технического тестирования нам необходим отдельный парк устройств и отдельные методы проверки. Поэтому часто QA-тестирование — это отдельная функция в компании, это не просто другой метод, это иной принцип работы с продуктом.
Юзабилити-проблема не может быть недостатком функционала. В юзабилите-тесте мы изучаем удобство использования текущих возможностей продукта. Мы можем получить комментарии о том, что чего-то в продукте не хватает, но они всегда будут лишь поводом для дальнейшего исследоваания, а не самостоятельным результатом.
Юзабилити-проблема не является отсутствием решения, потому что проблема — это проблема, а не отсутствие решения. Здесь очень тонкий момент. Юзабилити-проблема — это некое свойство интерфейса. Это какой-то элемент, который мешает пользоваться продуктом. Здесь мы сокращаем наше пространство решений. Отсутствие решения не может быть проблемой. Если мы формулируем проблему как “Нет решения Х”, то мы упускаем, что юзабилити-проблему можно было бы решить другими способами. Это как если бы мы приходили ко врачу и говорили не “У меня болит голова”, а “У меня недостаток обезболивающего”. Физически мы можем так сказать, но практически это ограничивает нас только одним решением, которое не обязательно самое лучшее.
Идеальная юзабилити-проблема
И теперь, на основании всего вышенаписанного, мы можем приступить к определению идеального описания юзабилити-проблемы
В юзабилити-проблеме должно быть:
- Описание свойства интерфейса, которое приводит к проблеме. Мы должны описать, как работает проблемный элемент, потому что он и является источником нашей проблемы.
- Объяснение, почему мы считаем это поведение системы проблемным. Это позволяет нам описать механизм возникновения проблемы и аргументировать, почему мы считаем эту юзабилити-проблему проблемой. Особенно важно тут описать, какие действия респондента с проблемным элементом приводят к сложностям.
- Описание влияния проблемы на юзабилити. Юзабилити-проблемы по определению приводят к снижению основных юзабилити-метрик, и нам важно показать это негативное влияние.
Дальше мы можем проиллюстрировать нашу юзабилити-проблему цитатой респондента и добавить рекомендации по их решению.
Как мы видим, мнение респондента является не сутью юзабилити-проблемы, а ее иллюстрацией. Это особенно важно, потому что объект нашего исследования — это интерфейс, а не пользователь.
Если мы будем строго держаться ограничений юзабилити-тестов, то его проведение и обработка результатов будут занимать бесконечно мало времени и ресурсов по сравнению с глубинными интервью. И именно поэтому я считаю, что юзабилити-тест должен быть простым как молоток. Ведь именно в этих ограничениях его сила.
В этой статье я постарался подробно описать свое понимание особенностей юзабилити-тестирования и описания его результатов. Как и все, что я пишу, это является больше моим личным профессиональным мнением, чем учебником или объективной истиной. В любом случае, не стесняйтесь писать под статьей ваши мысли и комментарии, мне всегда их приятно и интересно читать.
По всем вопросам можете писать мне в telegram, спасибо огромное за то, что дочитали до конца!
