Vitamin – сервис для выгодного управления вашей рекламой
  • Все популярные рекламные сети в одном окне
  • Агентское вознаграждение до 16% на личный счет или рекламу
  • Любые дополнительные услуги под ваши потребности
  • Бесплатное обучение маркетингу
  1. Главная >
  2. Блог >
  3. UI/UX >
  4. Глава 13. Путеводитель по человеко-компьютерному взаимодействию: оценка юзабилити. Часть 1

Глава 13. Путеводитель по человеко-компьютерному взаимодействию: оценка юзабилити. Часть 1

Если говорить как можно проще, то в ходе аттестации юзабилити (Usability Evaluation — «оценка удобства использования») оценивается степень, в которой интерактивная система является удобной и приятной в использовании. В целом же этот вопрос является немного более сложным. Начнем его изучение с предложенного Гилбертом Коктоном (Gilbert Cockton), профессором теории дизайна британский Школы дизайна в Университете Нортумбрии (School of Design at Northumbria University), рассмотрения следующих положений по оценке юзабилити:

1. Удобство использования — неотъемлемое измеряемое свойство всех интерактивных цифровых технологий.

2. Исследователи в сфере человеко-компьютерного взаимодействия (Human-Computer Interaction; HCI) и специалисты по проектированию интеракций (Interaction Design; IxD) разработали методы оценки, при помощи которых они определяют, удобно ли использовать интерактивную систему или устройство.

3. В случае использования системы или устройства методы оценки удобства использования также определяют степень его юзабилити через применение надежных, объективных и достоверных показателей.

4. Методы и показатели аттестации юзабилити подробно описаны в материалах исследований в области HCI и публикациях специалистов-практиков. Все желающие развить опыт в этой области могут прочитать об этих методах, узнать, как их применять, а также овладеть умением определять, удобно ли использовать интерактивную систему или устройство, и если да, то в какой степени.

Вышеприведенные тезисы относятся к некому идеалу. Нужно понять, где нынешние исследования и практики не соответствуют этому идеалу — и в какой степени. Там, где всё еще существуют расхождения между идеалами и действительностью, следует разобраться, каким образом методы и показатели могут быть улучшены для ликвидации этого пробела. Как и в случае любой интеллектуальной деятельности, следует без предубеждений приступить к работе и признать, что некоторые или все вышеизложенные предложения не являются истинными.

Другие статьи из этого гайда:

1. От притеснения до расширения прав и возможностей

Удобство использования является основополагающей концепцией исследований и практики разработки интеракций, начиная с самого зарождения человеко-компьютерного взаимодействия (HCI) в качестве междисциплинарной деятельности. Для некоторых юзабилити было и остается основной концепцией HCI.

Для других удобство использования остается важным понятием, но только как одна из нескольких ключевых проблем в деле проектирования взаимодействий.

Было бы неплохо начать со всеобъемлющего определения юзабилити, но мы находимся на территории спорных утверждений. Определения будут представлены лишь в отношении конкретных позиций юзабилити. Вы должны выбрать то из них, которое соответствует вашей философии проектирования. Ниже приводятся три альтернативных определения.

Было бы также полезно рассказать, как оценивается юзабилити, но существование альтернативных систем взглядов на удобство использования приводит к возникновению различных видов практики. Профессиональная деятельность в этой сфере очень разнообразна, и многое выводы из нее не могут быть обобщены таким универсальным образом, чтобы их можно было без ущерба перенести от одного проекта на другой. Оценщики должны выбрать способ аттестации. Методы оценки должны быть спроектированы, а проектирование требует принятия решений.

1.1. Происхождение HCI и юзабилити

HCI и удобство использования ведут свое происхождение от падения цен на компьютеры в 1980-х годах, когда впервые для многих сотрудников стало возможным иметь собственный персональный компьютер (PC). В течение первых трех десятилетий компьютерной эпохи почти все пользователи были высококвалифицированными специалистами, работающими на дорогостоящем централизованном оборудовании. Тенденция к появлению менее хорошо обученных пользователей началась в 1960-х годах с внедрения таймшеринга (англ. «timesharing», здесь — «одновременная работа компьютерной системы с несколькими пользователями для выполнения различных задач») и миникомпьютеров. С распространением в 1980-х годах персональных компьютеров у пользователей все чаще не было высокой технической квалификации или наличествовало только базовое обучение применению операционных систем и прикладного программного обеспечения.

Тем не менее, практики разработки программного обеспечения продолжали косвенно воспринимать пользователей как знающих и компетентных специалистов, которые знакомы с техническими словарями и архитектурой систем, а также обладают способностью решать проблемы, возникающие в процессе использования компьютеров. Такие неявные предположения быстро стали неприемлемыми. Для обычного пользователя интерактивные компьютеры стали ассоциироваться с постоянными разочарованиями и последующими тревогами. Стало очевидно, что компьютеры были слишком сложны для большинства и часто совершенно непригодны для применения. Таким образом, юзабилити стало основной целью в проектировании любого интерактивного программного обеспечения, которое не предназначалось для квалифицированных технических специалистов. Популярные термины — такие как «удобный для пользователя» («user-friendly») — широко входили в повседневную жизнь. Первоначально как юзабилити, так и удобство для пользователя рассматривались как свойства интерактивного программного обеспечения. Программное обеспечение было либо используемым (полезным), либо нет. Неиспользуемое (unusable) программное обеспечение может быть сделано пригодным для использования (usable) в процессе перепроектирования. 

Происхождение HCI и юзабилити
Происхождение HCI и юзабилити
Происхождение HCI и юзабилити

Рисунок 1. A-B-C: использование домашнего персонального компьютера (ПК) и связанных с ним периферийных устройств в настоящие дни стало повседневной действительностью в миллионах домов по всему миру. Юзабилити стало критической проблемой с распространением ПК

1.2. От юзабилити к пользовательскому опыту через качество использования

В 1990-х годах более сложное понимание юзабилити сместилось от бинарного свойства «все или ничего» к постепенному переходу, охватывающему различные степени удобства использования. В то же время основное внимание исследователей в сфере HCI сместилось на контексты использования. Юзабилити перестало быть доминирующей концепцией человеко-компьютерного взаимодействия, и исследования все больше концентрировались на соответствии между интерактивным программным обеспечением и окружающими его контекстами использования. Качество использования (Quality in use) больше не представляло собой простой вопрос о том, как по самой своей сути используется интерактивная система, но насколько она соответствует ее контексту использования. Качество использования стало предпочтительным альтернативным термином для юзабилити в международных стандартах, поскольку оно не касалось последствий того, что удобство использования объявлялось абсолютным контекстно-независимым неизменным свойством интерактивной системы. Примерно в начале 21 века распространение сетевых цифровых медиа (например, интернет, мобильные технологии, интерактивное телевидение, объекты общественной инфраструктуры) добавило новые эмоциональные проблемы в поле интересов HCI, что вызвало появление еще одного более привлекательного термина, чем юзабилити: опыт пользователя (User eXperience, UX).

Таким образом, нынешнее понимание юзабилити отличается от тех, что были распространены в начальную эпоху изучения человеко-компьютерного взаимодействия в 80-х годах прошлого века. С тех пор простота использования (Ease of use) улучшилась за счет двух факторов: привлечению внимания разработчиков к проектированию взаимодействия и повышению уровня компьютерной грамотности среди значительной части населения стран с высокоразвитой экономикой. Знакомство с основными компьютерными операциями в настоящее время достаточно широко распространено, о чем свидетельствуют такие термины, как «коренные жители цифрового общества» (Digital Natives) и «цифровая изоляция» (Digital Exclusion), которые в 1980-х годах не получили бы достаточной популярности.

Юзабилити больше не воспринимается автоматически как главная проблема в проектировании взаимодействия. Удобство использования по-прежнему важно, поскольку разочаровывающий опыт от применения сложных цифровых технологий все еще является весьма распространенным явлением. Плохое юзабилити до сих пор с нами, но мы отошли от проблемы, описанной Томасом Ландауэром (Thomas Landauer) в его книге «Проблемы с компьютерами» (Trouble with Computers, 1996 г). Когда персональные компьютеры, мобильные телефоны и интернет играют важную роль в основных международных потрясениях, таких как «Арабская весна» 2011 года, ценность цифровых технологий может значительно затмить их недостатки.

1.3. От проблем с компьютерами до трудностей с цифровыми технологиями как таковыми

Читатели из развивающихся стран сегодня могут воспринимать проблемы с компьютерами, описанные Ландауэром, как стоны сверхчувствительных слабо мотивированных западных пользователей. 26 января 1999 года в помещении NIIT (National Institute of Information Technology — Национальный институт информационных технологий) в Нью-Дели была вырезана «дыра в стене». Через это отверстие компьютер поступил в свободный доступ жителям из соседнего района трущоб Калкаджи. Цифровое устройство мгновенно обрело популярность, особенно у местных детей, которые, не имея никакого предыдущего опыта, научились самостоятельно использовать компьютер. Это побудило доктора Митру (Mitra) из НИИТ выдвинуть следующую гипотезу:

«Овладение основой компьютерной грамотности любой группой детей может быть достигнуто путем сопутствующего обучения, если учащимся предоставляется доступ к соответствующим вычислительным средствам с развлекательным и мотивирующим контентом — при некотором минимальном участии человека».

Здесь наблюдается сильный контраст с кризисом юзабилити восьмидесятых годов прошлого века. Компьютеры в 1999 году были более удобными в использовании, чем в 1980-х годах, но они по-прежнему создавали некоторые проблемы в работе с ними. Тем не менее, остаточные затруднения с точки зрения юзабилити имели ограниченную значимость для детей трущоб Калкаджи нынешнего века.

Мир сложен, все, что является важным для людей — тоже сложное, цифровые технологии разнообразны. В условиях этой разнообразной сложности не может быть простого «Судного дня цифровых технологий», когда одни из них отправятся в условный «Рай юзабилити», другие же — в «Ад непригодности».

История юзабилити — это «противоестественное путешествие» от простоты к сложности. Цифровые технологии развивались так быстро, что интеллектуальное понимание юзабилити никогда не успевало за реалиями использования компьютеров. Боль старых и новых мировых корпораций, пытающихся добиться отдачи от инвестиций в сферу высоких технологий в 1980-х годах, никак не сближается с использованием социальных сетей в борьбе за демократию в диктатурах третьего мира. Но мы не можем просто отказаться от концепции юзабилити и двигаться дальше. Использование цифровых технологий по-прежнему может быть разочаровывающим, раздражающим, излишне сложным или же вообще невозможным — даже для самых квалифицированных и опытных пользователей.

компьютер в «отверстии в стене» NIIT в Нью-Дели.

Рисунок 2: компьютер в «отверстии в стене» NIIT в Нью-Дели.

юные пользователи этого компьютера

Рисунок 3: юные пользователи этого компьютера.

1.4. От единственной цели HCI к непреходящему важному фактору пользовательского опыта

Профессор Коктон комментирует: «Эта запись в Энциклопедии HCI не представляет собой реквием по юзабилити. Хотя эта концепция похоронена под более широкими слоями качества использования и пользовательского опыта, она не мертва. Например, я при помощи SMS периодически выполняю роль службы технической поддержки для моей дочери. Однажды мне пришлось объяснить ей, как заставить перезагрузиться непокорный ноутбук. Ее последнее сообщение ко мне относительно возникшей проблемы было таким:

“Теперь все исправно! Я не знала, что удержание кнопки питания делает что-то другое — в отличие от простого нажатия на нее“.

Учитывая скрытую природу этой функциональности (короткое нажатие на кнопки питания переводит многие ноутбуки в спящий режим), неудивительно, что моя дочь не знала о существовании более продолжительного действия “удержания“ кнопки. Кроме того, учитывая редкие случаи “зависания“ ноутбука, у моей дочери было мало шансов научиться этому действию. Она должна была полагаться на мои знания в этой области. Она мало что могла бы узнать сама без предшествующего опыта (полученного, например, при отключении iPhone)».

нужно длительное удержание кнопки или короткое нажатие на нее? Кто должен это знать?

Рисунок 4: нужно длительное удержание кнопки или короткое нажатие на нее? Кто должен это знать?

Непреходящие реалии использования компьютеров, которые юзабилити стремится охватить, и сегодня остаются актуальными и не менее потенциально опасными для успеха дизайнерских разработок, чем это было более тридцати лет назад. Как и в отношении историй всех научных дисциплин, новое не стирало старое, но вместо этого — подобно образованию геологических слоев — новое накладывалось на старое, появление новых представлений об юзабилити подвергаются воздействию более интенсивно изменяющегося «ландшафта» пользовательского опыта. Как и в геологии, нам нужно понять существующий интеллектуальный ландшафт с точки зрения его основных исторических процессов и потрясений.

Таким образом, это не путешествие по ландшафту, а серия раскопок, показывающих, какое понимание юзабилити существовало в разные моменты в различных местах в течение последних трех десятилетий. При этом внимание будет сосредоточено на текущих изменениях ландшафта дизайна интеракций, которые должны обеспечить стабильность юзабилити в более широком понимании проектирования человеческих ценностей. Но на данный момент начнем с истоков и оттуда продолжим экскурсию по истории HCI, чтобы выявить неурегулированные противоречия относительно сущности юзабилити и его отношения к проектированию взаимодействий.

2. От юзабилити к пользовательскому опыту — противоречия и методы

Необходимость разработки интерактивных компьютерных приложений, которые можно было бы использовать, обладая лишь базовым пониманием компьютерного оборудования и операционных систем, была впервые признана в 1970-х годах, когда появились новаторские работы в области проектирования программного обеспечения под авторством Фреда Хансена (Fred Hansen) из Университета Карнеги-Меллон (CMU), Тони Вассермана (Tony Wasserman) из Калифорнийского университета в Сан-Франциско (UCSF), Алана Кея (Alan Kay) из научно-исследовательского центра Xerox в Пало-Альто (PARC) и других пионеров компьютерных наук. Это труд потребовал применения нескольких подходов — от руководств по детальному проектированию до высокоуровневых принципов как для софтверного дизайна, так и процессов его развития. Он объединял знания и навыки из областей психологии и информатики. Первоначальное объединение исследователей, известное в отрасли как «Общество психологии программного обеспечения» (Software Psychology Society), сформировалось в 1976 году в г. Вашингтон, округ Колумбия. Этот союз между научными работниками и специалистами из сфер когнитивной психологии и компьютерных наук выработал подходы к теории и практике, которые в течение почти 20 лет оставались доминирующей парадигмой исследований в области интерактивного дизайна/проектирования интеракций и сохранили сильное влияние еще на десятилетие. Тем не менее внутри этого сотрудничества скрывались противоречия в отношении природы удобства использования.

Первоначальная направленность была в значительной степени когнитивной — основное внимание исследователей концентрировалось на причинно-следственных связях между функциями пользовательского интерфейса (UI) и результативностью работы людей, но с разными представлениями о том, как происходит взаимодействие между функциями UI и способностями человека. Если человеческие когнитивные характеристики являются фиксированными и универсальными, то функции пользовательского интерфейса могут быть по сути своей либо пригодными для использования, либо непригодными, что делает юзабилити изначальным двоичным свойством интерактивного программного обеспечения. Иными словами, интерактивная система просто является или не является пригодной для использования. Программное обеспечение может быть по своей природе пригодным для использования в соответствии с руководящими принципами и положениями, которые могут быть обнаружены, сформулированы и подтверждены в ходе психологических экспериментов.

Однако, если когнитивные характеристики человека различаются не только между различными индивидуумами, но и в разных условиях, то удобство использования становится производным свойством, которое зависит не только от особенностей и качеств интерактивной системы, но и от того, кто ее использует и что он пытается сделать с ее помощью. Последняя позиция была значительно усилена в 1990-х годах «переходом к социальному» (Rogers, Yvonne, Bannon, Liam and Button, Graham (1994): Rethinking theoretical frameworks for HCI). Тем не менее, большая часть проблем здесь была урегулирована, поскольку исследования HCI охватили целый ряд специализированных сообществ, ориентированных на конференции Ассоциации вычислительных машин (Association for Computing Machinery; ACM), такие как конференции ACM по компьютерной поддержке кооперативной работы (Computer Supported Cooperative Work; CSCW) — с 1986 года — или симпозиумы ACM по программному обеспечению и технологиям пользовательских интерфейсов (UIST; User Interface Software and Technology) — с 1988 года. Социальное понимание юзабилити стало ассоциироваться с CSCW, а технологические аспекты — с UIST.

Психологические исследования методов юзабилити на главных конференциях ACM оставались по-прежнему значительными до начала 1990-х годов. Тем не менее, специалисты, на практике занятые решением проблем удобства использования, стали проявлять недовольство академическими исследовательскими форумами, и в 1992 году была организована первая конференция UPA (Usability Professionals Association — Ассоциация профессионалов юзабилити). Раскол в среде исследователей произошел всего через 10 лет после того, как Общество психологии программного обеспечения координировало конференцию в Гейтерсберге (Gaithersburg), с которого началась серия совещаний ACM по человеко-компьютерному взаимодействию. Это разделение удалило многие прикладные исследования юзабилити из поля зрения исследователей HCl, придерживающихся преобладающих тенденций. Упомянутый раскол в определенной степени был преодолен за счет учреждения UPA в 2005 году «Журнала изучения юзабилити» (Journal of Usability Studies).

Бен Шнейдерман (Ben Shneiderman), пионер психологии программного обеспечения, был автором первого учебника по HCI.

Рисунок 5: Бен Шнейдерман (Ben Shneiderman), пионер психологии программного обеспечения, был автором первого учебника по HCI.

2.1. Новые методы, «Поврежденные товары» и «Пугающий факт»

Таким образом, из вышеизложенного возникает дилемма, лежащая в основе самой концепции юзабилити: является ли удобство использования особенностью системы или свойством процесса использования? Последствием раскола 1990-х годов в области изучения HCI стало то, что важные концептуальные проблемы были отброшены в пользу прагматического подхода, доминирующего среди тех исследователей и практиков, которые сохранили профессиональный интерес к юзабилити. К началу 1990-х годов был разработан ряд методов оценки удобства использования. Пользовательское тестирование (User Testing) стало устоявшейся практикой к концу 1980-х, являясь, по существу, вариантом психологических экспериментов с только зависимыми переменными (тестируемая интерактивная система была провозглашена независимой постоянной). Методы дисконтирования (Discount methods) включали в себя быстрое малозатратное пользовательское тестирование, а также такие способы инспектирования как эвристическая оценка (Heuristic Evaluation). Продолжалось исследование методов на основе моделирования, таких как модель GOMS (Goals — цели, Operators — операторы, Methods — методы, Selection rules — правила отбора), но с началом 2000 годов репрезентативные публикации на эту тему становятся все более редким явлением.

С появлением возможности выбора между инспекционным, основанным на моделировании и эмпирическим (например, пользовательским тестированием) методами оценки, возникли вопросы о том, какой способ аттестации юзабилити является лучшим, когда и почему. Экспериментальные исследования попытались ответить на эти вопросы, рассматривая методы оценки как независимые переменные в сравнительных исследованиях, в ходе которых подсчеты проблем и/или их классификации фигурировали в качестве зависимых переменных.

Тем не менее, для последовательного применения все вышеперечисленные методы слишком неполно определены, что позволило Уэйну Грею (Wayne Gray) и Мэрилин Зальцман (Marilyn Salzman) объявить не имеющими ценности несколько ключевых исследований юзабилити в своей статье «Поврежденные товары» (Damaged Merchandise) от 1998 года. Комментарии к этой статье не смогли компенсировать ущерб от обвинений, прозвучавших в «Поврежденных товарах». Дальнейшие статьи, опубликованные в первое десятилетие наступившего века, добавили больше беспокойства не только по поводу сравнительных исследований, но и в отношении обоснованности самих методов оценки юзабилити. Так, в 2001 году Мортен Герцум (Morten Hertzum) и Нильс Якобсен (Niels Jacobsen) опубликовали свой «пугающий факт» об использовании методов аттестации юзабилити: сама по себе оценка имеет существенные последствия. Это заявление не должно было удивить кого-либо, кто глубоко понял суть критики Грея и Зальцмана, поскольку несоответствия в методах оценки юзабилити делают возможность их корректного сопоставления приближающейся к невозможной даже в официальных исследованиях, причем расхождения будут еще более обширными в неконтролируемых тестированиях.

Критические аналитические выкладки Грея и Зальцман — а также Герцума и Якобсена — сделали практические исследования юзабилити еще менее привлекательными для ведущих журналов и конференций HCI. Методологическая направленность таких исследований уменьшилась, при этом критические анализы выявили не только последствия неопределенности в отношении причин плохого юзабилити (система, пользователь или оба вместе?), но и отсутствие договоренности по поводу того, что попадает под определение «удобство использования».

все методы оценки юзабилити в 2020 году удостоятся заслуженных медалей

Рисунок 6: все методы оценки юзабилити в 2020 году удостоятся заслуженных медалей.

2.2. Мы можем работать: внедрение методов оценки на их «рабочие места»

Исследования по юзабилити и методам с конца нулевых годов были заменены изучением пользовательского опыта и практики юзабилити (Usability work). Пользовательский опыт — это более широкая концепция, чем удобство использования, и выходит за рамки эффективности, качества задачи и расплывчатой «степени удовлетворенности пользователей» в направлении всестороннего рассмотрения когнитивных, аффективных, социальных и физических аспектов взаимодействия.

Практика юзабилити — это работа, выполняемая специалистами в области удобства использования. Методы способствуют этой работе. Методы не используются изолированно и не должны оцениваться в отдельности. Изолированная оценка методов игнорирует тот факт, что практика юзабилити объединяет, настраивает и приспосабливает несколько методов для конкретных проектов или организационных контекстов. Признание этого факта отражается в смещении направленности исследований от методов к практике юзабилити.

Акцент на фактической работе обеспечивает реалистический подход к методам проектирования и оценки. Методы — это только один аспект практики юзабилити. Они не являются отдельным компонентом практики юзабилити, характеризующимся детерминированными эффектами, то есть определенными последствиями, которые гарантированно будут иметь место и будут идентичными во всех проектных и организационных контекстах. Вместо этого следует ожидать обширного последствий оценки из-за различных масштабов и качества ресурсов для проектирования и оценки при разных вариантах разработки.

Вместо этого следует ожидать широких эффектов оценки из-за различной степени и качества ресурсов проектирования и оценки в разных вариантах развития. Это означает, что мы не можем и не должны оценивать методы оценки юзабилити в условиях искусственно изолированного исследования. Вместо этого исследования должны начинаться с конкретных реалий практики юзабилити, и в этом случае следует рассматривать подлинный характер методов оценки и их влияние.

Рисунок 7: эксперт по юзабилити за работой: Алан Вулрич (Alan Woolrych) из Университета Сандерленда (University of Sunderland) использует минимальную конфигурацию мобильной юзабилити-лаборатории, включающую в себя веб-камеру, микрофон и устройство отслеживания движений глаз.

Рисунок 7: эксперт по юзабилити за работой: Алан Вулрич (Alan Woolrych) из Университета Сандерленда (University of Sunderland) использует минимальную конфигурацию мобильной юзабилити-лаборатории, включающую в себя веб-камеру, микрофон и устройство отслеживания движений глаз.

2.3. Длинная и извилистая дорога: путешествие юзабилити от «тогда» к «сейчас»

Юзабилити теперь является одним из аспектов пользовательского опыта, а методы юзабилити в настоящие методы — это уже нечетко сконфигурированная область работы с UX. Тем не менее, удобство использования остается важным. Ценность недавнего расширения внимания к пользовательскому опыту заключается в том, что он помещает практику юзабилити в контекст. Больше не предполагается, что практика юзабилити обособленно установит ценность методов — вместо этого она сейчас является одним из нескольких дополнительных факторов, способствующих качеству проектирования.

Юзабилити в качестве центра внимания внутри HCI прошло через фазы психологической теории, методологического прагматизма и интеллектуального разочарования. Самые актуальные акценты на качество использования и пользовательский опыт дают понять, что проектирование взаимодействия не может просто сосредоточиться на характеристиках и свойствах интерактивных продуктов.

Вместо этого следует сконцентрировать внимание на взаимодействии пользователей и программного обеспечения в конкретных ситуациях. Мы не можем рассуждать исключительно в том смысле, что цифровой продукт (лендинг, сайт, приложение) по своей сути пригоден для применения или нет, но вместо этого нужно учитывать, что произойдет во время взаимодействия между пользователем и ним, будь результат успехом, провалом или сочетанием того и другого. Когда мы фокусируемся на взаимодействии, неизбежно возникает более широкий взгляд на происходящее, благоприятствующий обнаружению множества проблем — в отличие от подходов, базирующихся на концентрации внимания на программных и аппаратных средствах. 

Что такое корабль?
Что такое корабль?

8 A-B: Что такое корабль? Судно в отдельности, или оно же, но снабженное экипажем и находящееся в особых морских условиях? Подобный вопрос возникает и в отношении используемых систем.

Многие из первоначальных проблем практики юзабилити 1980-х годов сегодня столь же актуальны, как и 30 лет назад. Изменилось то, что мы больше не ожидаем, что юзабилити станет единственным или даже доминирующим человеческим фактором в успехе интерактивных систем. Что не изменилось, это потенциальная путаница в отношении того, что такое юзабилити, существующая с первых дней HCI, то есть это пригодность к использованию продукта или способа, которым это делается.

Хотя это может показаться каким-то неуместным философским крючкотворством, ответ на озвученный вопрос имеет серьезные последствия для оценки юзабилити.

Если программное обеспечение может быть изначально пригодным для использования, то удобство использования можно оценить исключительно путем прямого контроля. Если юзабилити можно установить только посредством изучения процесса использования, то для оценки должны применяться методы косвенного контроля (пошаговые руководства) или эмпирические методы (пользовательское тестирование).

2.4. Будущее юзабилити: от понимания противоречий к их разрешению

Форма слова «юзабилити» подразумевает свойство, которое требует эссенциалистской (от лат. essentia «сущность») установки, то есть такой, которая видит свойства и качества как неизменно присущие некоторым объектам, как естественным, так и искусственным (в философии это называется эссенциалистской или субстантивистской онтологией). Буквальное понимание слова «юзабилити» требует, чтобы интерактивное программное обеспечение было по своей сути пригодным для использования или же нет. Хотя более реалистичное толкование воспринимает юзабилити как свойство интерактивного использования, а не только собственно программного обеспечения, нет смысла говорить об использовании как «пригодном для использования», так же, как нет смысла говорить о том, что еда «съедобна». Вот почему термин качество использования предпочтительнее для некоторых международных стандартов, поскольку это открывает широкое пространство возможных качеств интерактивной деятельности, как с точки зрения того, что ощущается, так и с точки зрения того, что достигается, например, взаимодействие может быть «успешным», «полезным», «разочаровывающим», «неприятным», «сложным» или «неэффективным».

Большая часть истории юзабилити отражает противоречие между жестким «софтверным» представлением и более широким социотехническим мнением о границах системы. Если говорить в более абстрактных терминах — это коллизия между веществом (субстанцией, эссенцией) и отношением, то есть между неотъемлемыми качествами интерактивного программного обеспечения и возникающими качествами взаимодействия. В философии позиция, провозглашающая, что отношения более фундаментальны, нежели сущности сами по себе, характерна для реляционной онтологии.

Онтологии — это теории бытия, существования и реальности. Они ведут к совершенно разному пониманию мира. Технические специалисты и многие психологи в рамках HCI попадают под влияние эссенциалистских онтологий и стремятся добиться юзабилити преимущественно за счет использования функций пользовательского интерфейса.

Специалисты, уделяющие больше внимания человеку как стороне интеракции, в основном обращаются к реляционным онтологиям и стремятся понять, как контекстуальные факторы взаимодействуют с функциями пользовательского интерфейса, чтобы сформировать опыт и производительность. Каждая онтология занимает свое место на территории HCI. Оба направления теперь пересматриваются по очереди. Затем кратко характеризуются методы оценки юзабилити. Хотя противоречие между этими двумя философскими позициями доминировало в эволюции юзабилити как в теории, так и на практике, выход из тупика существует.

Ниже будет представлена ​​стратегия преодоления этой существующей долгое время напряженности, а будущие направления юзабилити в рамках пользовательского опыта будут указаны в заключительном разделе.

3. Определение юзабилити в области программного обеспечения: рекомендации, эвристика, шаблоны и ISO 9126

3.1. Рекомендации по использованию пользовательских интерфейсов

Самое раннее руководство по юзабилити пришло от ученых, работавших в области компьютерных наук, таких как Фред Хансен из Университета Карнеги-Меллон (CMU) и Тони Вассермана, работавшего в Калифорнийском университете в Сан-Франциско (UCSF). На информатику сильно влияет математика, в которой объекты, такие как подобные или равносторонние треугольники, обладают вечными абсолютными неотъемлемыми свойствами. Ученые-компьютерщики стремятся установить аналогичные имманентные свойства для компьютерных программ, в том числе те, которые обеспечивают юзабилити для интерактивного программного обеспечения.

Таким образом, первоначальные рекомендации по дизайну GUI базировались на техноцентрической убежденности в том, что удобство использования может быть обеспечено только с помощью программных и аппаратных средств. Пользовательский интерфейс был бы изначально — в силу самой своей природы — полезен, если бы он соответствовал руководящим положениям, например, именованию, упорядочиванию и группировке опций меню, предложению типов и форматов ввода и диапазонов значений для полей ввода данных, структуры сообщений об ошибках, времени отклика и отмены возможностей. Следующие четыре примера взяты из сборника Смита (Smith) и Мозера (Mosier) «Руководство по разработке программного обеспечения с пользовательским интерфейсом» (Guidelines for Designing User Interface Software)1986 года, составленного по заказу ВВС США:

1.0/4 + Быстрое реагирование

Убедитесь, что компьютер быстро подтверждает действия по вводу данных, чтобы работа пользователей не замедлялась из-за задержек в ответе компьютера; для нормальной работы задержка отображаемой обратной связи не должна превышать 0,2 секунды.

1.0/15 Хранение данных в краткой форме

Для данных, чисел и т. д. сохраняйте записи данных короткими, чтобы длина отдельного элемента не превышала 5-7 символов.

1.0/16 + Разделение длинных элементов данных

Когда требуется ввести длинный элемент данных, он должен быть разделен на более короткие группы символов для ввода и отображения. Пример: 10-значный телефонный номер может быть введен как три группы цифр, NNN-NNN-NNNN.

1.4/12 + Маркировка обязательных и необязательных полей данных

При проектировании форм дисплеев четко и последовательно различать требуемые и необязательные поля ввода.

Спустя 25 лет после публикации вышеуказанного руководства все еще существует множество современных правил оформления веб-форм, разработчикам которых будет выгодно придерживаться этих рекомендаций. Тем не менее, в то время как последующие руководства могут значительно улучшить удобство использования программного обеспечения, сборник рекомендаций Смита и Мозера этого гарантировать уже не может. 

Эта книга содержит больше рекомендаций, чем кто-либо мог бы вообразить

Рисунок 9: Эта книга содержит больше рекомендаций, чем кто-либо мог бы вообразить

3.2. Управляемые рекомендации: применение эвристик для проектирования пригодных к использованию UI

Профессор Коктон комментирует: «Мой оригинальный бумажный вариант руководства Смита и Мозера занимает 10 см ценного пространства на полке. Ему больше 25 лет, и я никогда не читал его. И скорее всего, я никогда этого не сделаю. В книге слишком много рекомендаций для того, чтобы считать ее полезной (с другой стороны, в прошлом я прочитал полные руководства по стилям для пользовательских интерфейсов Windows и Apple).

«Раздувание» количества сборников рекомендаций не устранило привлекательность техноцентричных взглядов на юзабилити. В качестве альтернативы сотни руководств были переработаны в десять эвристик Рольфа Молича (Rolf Molich) и Якоба Нильсена (Jakob Nielsen). Они были дополнительно оценены и уточнены в окончательном варианте в статье Нильсена 1984 года «Эвристическая оценка» (Heuristic Evaluation) как метод проверки, в котором анализируются функции программного обеспечения в качестве источника потенциальных причин плохого юзабилити. Эвристики обобщают более детализированные рекомендации сборников, подобных тому, что составили Смит и Мозер. У многих эвристик наблюдается техноцентрическая направленность, например:

Видимость состояния системы

Система должна всегда информировать пользователей о том, что происходит, при помощи соответствующей обратной связи, осуществляемой в разумные сроки.

Пользовательский контроль и свобода действий

Пользователи часто выбирают системные функции по ошибке и нуждаются в четко обозначенном «аварийном выходе», чтобы покинуть нежелательное состояние системы без необходимости проходить расширенный диалог. Поддержка отмены и повтора действий.

Предотвращение ошибок

Более эффективный подход, чем даже своевременное оповещение об ошибках — это тщательное проектирование, изначально предотвращающее возникновение проблем. Либо устраните ведущие к появлению ошибок операции, либо проверьте их и представьте пользователям опцию подтверждения действия, прежде чем они совершат его.

Узнавание, а не вспоминание

Минимизируйте нагрузку на память пользователя, делая объекты, действия и параметры узнаваемыми. Пользователю не нужно запоминать информацию при переходе от одной части диалога к другой. Инструкции по использованию системы должны быть видимыми или легко извлекаемыми, когда это необходимо.

Гибкость и эффективность использования

Невидимые для новичков «ускорители действий» часто убыстряют взаимодействие специалиста, так что система должна быть предназначена как для неопытных, так и для опытных пользователей. Разрешите пользователям настраивать под себя часто совершаемые действия.

Эвристическая оценка была самым популярным ориентированным на пользователя проектировочным подходом в 1990-х годах, но стала менее заметной со смещением акцента с настольных на мобильные приложения. «Быстрое и грязное» пользовательское тестирование вскоре опередило эвристическую оценку по востребованности.

по одной эвристике от Нильсена на каждый палец руки

Рисунок 10: по одной эвристике от Нильсена на каждый палец руки.

3.3. Непобедимая неотъемлемость: шаблоны и стандарты поддерживают важность юзабилити

Переход от системно-центрических подходов в рамках ориентированного на пользователя проектирования не сигнализировал о конце методов юзабилити, которые фокусируются исключительно на программных артефактах, при этом практически не обращая внимания на использование устройств. Это может быть связано с отделением сообществ юзабилити (теперь — разработки пользовательского опыта) от специалистов по разработке программного обеспечения. Ориентация на систему остается распространенной в языках программирования, применяемых для разработки шаблонов пользовательского интерфейса. Например, ниже представлен шаблон от Дженифер Тидуэлл (Jenifer Tidwell), обновившей руководство Смита и Мозера под потребности современных веб-дизайнеров (designinterfaces.com/Input_Prompt).

Шаблон: подсказка вводимого текста

Предварительно внесите в текстовое поле или раскрывающееся меню подсказку, которая сообщает пользователю, что нужно делать или вводить.

пример шаблона интерфейса, разработанного Дженифер Тидуэлл

Рисунок 11: пример шаблона интерфейса, разработанного Дженифер Тидуэлл

На стандарт ISO 9126 от 1991 года, касающийся качества продукции при разработке программного обеспечения (Software Engineering — Product Quality) сильно повлияли эссенциалистские предпочтения в области информатики, поскольку удобство использования в нем определяется как:

набор свойств [продукта], оказывающие воздействие на усилия, необходимые для его использования, и на индивидуальную оценку такого использования заявленным или подразумеваемым кругом пользователей.

Это первое из трех определений, представленных в этой статье. Свойства здесь считаются скорее характеристиками программного продукта, нежели параметрами пользовательской интеракции. Тем не менее, реляционный (контекстный) взгляд на использование, предпочитаемый в HCI, постепенно стал преобладать. К 2001 году ISO 9126 был пересмотрен для нового определения юзабилити в виде:

возможности программного продукта быть понятым, изученным, использованным и привлекательным, когда он применяется в определенных условиях.

Этот пересмотренный вариант остается ориентированным на продукт (эссенциалистским), но оговорка «когда» сместила ISO 9126 от полностью эссенциалистской позиции относительно юзабилити, неявно признавая влияние контекста использования («определенные условия»), который выходит за пределы «заявленного или подразумеваемого круга пользователей».

В попытке согласовать технический стандарт ISO 9126 с стандартом, регламентирующим человеческие факторы — ISO 9241 (см. ниже), ISO 9126 был расширен в 2004 году четвертым разделом, касающимся качества использования, что привело к установлению непростого компромисса между разработчиками программного обеспечения и экспертами по человеческим факторам. Этот компромисс сохранился и при замене ISO 9126 стандартом 2011 года ISO 25010, сохраняющим эссенциальный подход к юзабилити. В ISO 25010 удобство использования трактуется и собственная качественная характеристика продукта, так и подмножество качеств использования (включающее в себя производительность, результативность и удовлетворенность). В качестве характеристики продукта в ISO 25010 юзабилити обладает следующими внутренними характеристиками:

  • целесообразность
  • узнаваемость
  • обучаемость
  • работоспособность («степень, в которой продукт или система обладают свойствами, которые облегчают обслуживание и управление»)
  • защищенность от пользовательских ошибок
  • эстетичность пользовательского интерфейса
  • доступность

Таким образом, ISO 25010 должен был включать примечание, выявляющее внутренний конфликт между разработкой программного обеспечения и человеческими факторами.

Юзабилити можно либо указать или измерить как качественную характеристику продукта с точки зрения подмножества его свойств, либо указать или измерить непосредственно с помощью мер, которые являются подмножеством качества использования.

Аналогичное примечание касается обучаемости и доступности. В мире стандартов разработки программного обеспечения математическое мировоззрение тесно связано с эссенциалистской позицией относительно юзабилити. В HCI, где точка зрения с позиции контекста доминирует в течение десятилетий, этот подход может показаться невероятно искаженным. Однако вопреки многофакторному пониманию юзабилити в рамках человеко-компьютерного взаимоотношения, которое автоматически следует из контекстуальной позиции, царящей в данной области, гнев «евангелистов» HCI по поводу плохого удобства использования всегда фокусируется на программных продуктах. Даже при том, что на юзабилити влияют, как известно, пользователи, задачи и контексты, для улучшения удобства использования следует только аппаратное или программное обеспечение, одобряя тем самым позицию софтверных разработчиков в соответствии со стандартом ISO 25010 (свойства, которые делают программное обеспечение легким в обслуживании и управлении). Хотя мировоззрение HCI обычно отвергает эссенциальные монокаузальные (касающиеся только одной причины) объяснения юзабилити, когда эксперты по человеко-компьютерному взаимодействию выступают от имени рассерженного пользователя, то программное обеспечение всегда получает свою долю обвинений.

Должно быть ясно, что проблемы юзабилити проще сформулировать, чем решить.

Тупиковая ситуация, отображенная в стандарте ISO 25010, указывает на необходимость придавать в рамках HCI большее значение влиянию софтверной разработки на юзабилити. Если пользователи, задачи и контексты не должны меняться, то единственное, что мы можем изменить, это аппаратное и/или программное обеспечение. Несмотря на психологическую маргинализацию опыта и квалификации разработчиков, выраженных в рекомендациях, шаблонах и эвристиках, эти знания могут стать нашим самым важным ресурсом для достижения наилучшей практики юзабилити. Мы должны помнить об этом, поскольку мы переходим к рассмотрению доминирующей контекстной позиции HCI относительно удобства использования.

4. Определение юзабилити в контексте взаимодействия: контексты использования и стандарты ISO

Тенденции в международных стандартах можно было разглядеть еще в эвристиках Нильсена — за десятилетие до появления компромиссного стандарта ISO 9126 в 2004 году. В то время как пять эвристик, упомянутых в предыдущем разделе, относятся к характеристикам программного обеспечения, существует еще одна эвристика, фокусирующаяся на взаимосвязи между проектированием и контекстом использования:

Равенство между системой и реальным миром

Система должна говорить на языке пользователей, пользуясь словами, фразами и концепциями, знакомыми пользователю, а не системно-ориентированными терминами. Следуйте соглашениям реального мира, представляя информацию в естественном и логичном порядке.

Этому отношению удобства использования к «реальному миру» был предоставлен дополнительный параграф в стандарте ISO 9241-11 («Human Factors»), который связывает юзабилити с контекстом использования следующим образом:

Степень, в которой продукт может применяться конкретными пользователями для достижения указанных целей в определенном контексте с эффективностью, результативностью и удовлетворенностью.

Это второе из трех определений, представленных в этой статье. В отличие от первоначальных и пересмотренных определений (ISO 912) оно было сформулировано не инженерами-программистами, а специалистами по человеческим факторам с опытом в области эргономики, психологии и тому подобного.

Согласно стандарту ISO 9241-11, различаются три компонента фактора юзабилити: производительность, результативность, удовлетворенность. Это результат многофакторного взаимодействия между пользователями, целями, контекстами и программным продуктом. Юзабилити — это не характеристика, свойство или качество, а степень в многомерном пространстве. Эта степень проявляется в том, что люди действительно могут достичь с помощью программного продукта и расходов на эти достижения. С практической точки зрения любое суждение о юзабилити — это целостная оценка, сочетающая многоаспектные характеристики в едином суждении.
Такие единичные суждения имеют ограниченное применение. Для практических целей более целесообразно сосредоточиться на отдельных конкретных качествах пользовательского опыта, то есть на том, в какой степени для разных качеств будут соблюдаться пороговые значения.

Например, программный продукт не будет считаться пригодным для использования, если ключевые задачи не могут выполняться в нормальных рабочих контекстах в течение приемлемого времени. Здесь основное внимание будет уделено критериям производительности. Существует много контекстов использования, где время ограничено. Основы для временных ограничений значительно различаются и включают в себя физику (баллистика в боевых действиях), физиологию (медицинская травма), химию (управление процессами) или социальные контракты (предельные сроки выпуска печатных изданий или трансляций новостных передач).

Критерий результативности усугубляет сложность пороговых значений качества. Военная система может быть производительной, но она не результативна, если ее использование приводит к тому, что иносказательно называют «сопутствующим ущербом» (Collateral damage), включая ошибочное открытие «огня по своим» (Friendly fire, буквально «дружественный огонь»). Мы можем вообразить программное обеспечение для реанимации при травмах, позволяющее своевременно реагировать в кризисных ситуациях, но приводящее к «осложнениям» (еще один эвфемизм, но из другой области) — которых можно было бы избежать — после стабилизации состояния пациента. Система управления технологическими процессами способна поддерживать своевременные вмешательства и их течение, но также может содействовать разбазариванию средств или нанесению ущерба окружающей среде, что ограничивает результативность мер реагирования со стороны операторов. Точно так же система новостей может поддерживать быструю подготовку контента, при этом затрудняя доставку высококачественной информации.

С точки зрения удовлетворенности использование может быть объективно производительным и результативным, но при этом создавать неудобный пользовательский опыт, который приводит к высоким темпам текучести кадров (как это часто бывает в колл-центрах). Аналогичным образом сотрудники могут внимательно изучить продвинутую мультимедийную инструкцию по технике пожарной безопасности, но она может быть гораздо менее производительной (и, следовательно, потенциально смертельно опасной) по сравнению с результативностью ее скучной текстовой версии с обычными иллюстрациями.

Три фактора удобства использования по ISO 9241-11 в последнее время стали пятью факторами качества использования согласно стандарту ISO 25010:

  • производительность
  • результативность
  • удовлетворенность
  • отсутствие рисков
  • охват контекстов

Особый интерес представляют два добавленных фактора. Охват контекстов — это более широкая концепция, чем контекстная подгонка совпадений между системами и эвристика Нильсена, декларирующая равенство между системой и реальным миром. Этот принцип расширяет конкретных пользователей и определенные цели потенциально до любого аспекта контекста использования. Он должен включать в себя все факторы, имеющие отношение к отсутствию рисков, поэтому интересно уделить им особое внимание, нежели доверить производительности и удовлетворенности выполнить здесь всю работу. Однако такие фрагментарные расширения в рамках ИСО 25010 раскрывают вопрос об полноте и значимости. Например, почему такие факторы, как легкость обучения, либо игнорируются, либо скрыты внутри результативности или производительности? 

типичное заседание по обсуждению стандартов ISO

Рисунок 12: типичное заседание по обсуждению стандартов ISO.

4.1. Охват контекстов усложняет проектную повестку дня

Реляционные позиции относительно юзабилити по своей сути более сложны, чем эссенциалистские. Последние позволяют проверять интерактивные системы для оценки юзабилити, основываясь на их конструктивных особенностях.

Эссенциалистские подходы остаются привлекательными, поскольку оценки могут быть полностью обеспечены ресурсами посредством руководств, шаблонов и подобных задокументированных воплощений передовых практик проектирования интеракции. Реляционные подходы нуждаются в более сложном наборе координированных методов. Реляционные положения усложняются, так как при переходе от ISO 9241-11 к ISO 25010 требуется применять более широкий диапазон методов оценки. В рамках реляционного представления юзабилити является результатом комплекса сложных взаимодействий, который проявляется в целом ряде факторов использования. Очень сложно понять, как один метод оценки может учитывать все эти факторы. Независимо от того, достижимо это теоретически или нет, такого метода в настоящее время не существует.

Реляционные подходы к юзабилити требуют применения целого ряда методов оценки, чтобы установить степень удобства использования. Степень вводит дополнительные сложности, поскольку все идентифицированные факторы юзабилити должны быть измерены, затем должно быть вынесено суждение о том, адекватны ли проектируемой интеракции достигнутые степени удобства пользования. Здесь оценка юзабилити не является простым вопросом проверки, но вместо этого она становится сложной логистической операцией, ориентированной на реализацию проектной повестки дня (Design agenda).

Повестка дня — это список дел, которые необходимо выполнить. Следовательно, проектная повестка дня представляет собой список задач, которые необходимо контролировать в рамках процесса разработки. В ISO9241-11 имеется неявная (имплицитная) проектная повестка дня, согласно которой от разработчиков интеракции требуется определить для конкретного проекта целевых бенефициаров, цели использования и уровни производительности, результативности и удовлетворенности. Только тогда становится возможна детальная и надежная оценка юзабилити. Обратите внимание, что этот подход относится к стандарту ISO 9241-11 и аналогичным принципам оценки. Это не относится к некоторым другим философиям дизайна, порождающим отличающиеся от описываемого типа проектные повестки дня.

Таким образом, ключевая задача в повестке дня для оценки по стандарту ИСО 9241-11 — это измерение степени юзабилити посредством скоординированного комплекса показателей, в котором, как правило, сочетаются количественные и качественные меры, часто с сильным уклоном к той или иной составляющей из этих двух. Однако измерения только обеспечивают оценку. Для проведения аттестации они должны дополняться контрольными показателями. Определение таких показателей является еще одной важной задачей из повестки дня при аттестации согласно ИСО 9241-11. Это часто достигается за счет использования типовых шкал оценки серьезности проблем (Severity Rating Scales). Чтобы использовать такие ресурсы, специалисты по оценке должны интерпретировать их в контекстах конкретных проектов. Это указывает на то, что многоразовые оценочные ресурсы не являются полностью повторно используемыми решениями. Требуется работа по превращению этих ресурсов в выполнимые задачи по оценке юзабилити.

Например, два самых тяжелых (верхних) уровня серьезности проблем по шкале Чонси Уилсона (Chauncey Wilson, архитектор пользовательского опыта в компании Autodesk, Inc) выглядят так:

  • Уровень 1 — катастрофическая ошибка, вызывающая либо необратимую потерю данных, либо повреждение аппаратного оборудования или программного обеспечения. Проблема может привести к крупномасштабным сбоям, которые не позволят множеству пользователей выполнить свою работу. Производительность настолько плоха, что система не может достичь бизнес-целей.
  • Уровень 2 — серьезная проблема, могущая послужить причиной возможной потери данных. У пользователя нет временного способа решения проблемы. Производительность настолько низка, что повсеместно считается «ничтожной».

Каждый уровень серьезности требует ответов на вопросы о конкретных показателях и контекстуальной информации, то есть как следует интерпретировать следующие выражения в конкретном контексте проекта: «множество пользователей не может выполнять работу»; «не может достичь бизнес-целей»; «производительность считается ничтожной». Эти два верхних уровня также требуют информации о программном продукте: «потеря данных»; «повреждение аппаратного оборудования или программного обеспечения»; «нет временного способа решения».

На дальнейших, более низких уровнях шкалы Уилсона добавляются такие факторы как «потерянное время», «увеличение количества ошибок или повышение требований к обучению» и «важная функция не работает должным образом». Все они добавляют в проектную повестку дня вопросы, на которые необходимо ответить. Таким образом, чтобы знать, что производительность считается ничтожной, нам нужно будет выбрать показатели, релевантные нашим субъективным суждениям. Другие критерии более сложны: например, как мы можем узнать, не растрачено ли время работы впустую и могут ли быть достигнуты поставленные бизнес-цели? Первое требование зависит от определенных проектировщиками значений. Идея «затрат времени» (по аналогии с деньгами) является характерной для некоторых культурных контекстов, а также зависит от того, как долго будут выполняться задачи с помощью новой системы и сколько времени можно потратить на ее изучение и обучение пользователей. Что касается бизнес-целей, то бизнес может добиваться того, например, чтобы его рассматривали как социально и экологически ответственный, но не может ожидать, что каждая функция любой без исключения корпоративной системы будет поддерживать эти цели.

Как только пороговые значения для критериев серьезности проблем определены, становится неясно, как дизайнеры могут или должны сбалансировать относительно друг друга такие факторы, как производительность, эффективность и удовлетворенность. Например, пользователи могут не ощущать удовлетворенности даже тогда, когда они превышают целевые показатели производительности и результативности, или, наоборот, они могут быть удовлетворены, даже если их эффективность не оправдывает проектные показатели. Таким образом, целевые пороговые значения направляют, а не диктуют интерпретацию результатов и способы реагирования на них. 

реляционные подходы к оценке юзабилити нуждаются в установлении многочисленных критериев

Рисунок 13: реляционные подходы к оценке юзабилити нуждаются в установлении многочисленных критериев.

Таким образом, требования к методам существенно различаются между эссенциальными и реляционными подходами к юзабилити. Для высококачественной оценки, основанной на любой реляционной позиции, а не только на стандарте ISO 9241-11, оценщики должны иметь возможность модифицировать и комбинировать существующие многократно используемые ресурсы для контекстов конкретного проекта. В идеале «многоразовые» ресурсы будут выполнять большую часть работы, что приведет к производительной, результативной и вызывающей удовлетворенность оценке юзабилити. В противном случае качественная оценка юзабилити будет представлять собой сложную логистическую проблему, требующую от эксперта по оценке обширных знаний и выделения конкретных ресурсов под каждый проект.

Высоких вам конверсий!

По материалам: interaction-design.org

blog comments powered by Disqus
Vitamin – сервис для выгодного управления вашей рекламой
  • Все популярные рекламные сети в одном окне
  • Агентское вознаграждение до 16% на личный счет или рекламу
  • Любые дополнительные услуги под ваши потребности
  • Бесплатное обучение маркетингу
copyright © 2011–2024 Все права защищены
Запрещено любое копирование материалов ресурса без письменного согласия владельца — ООО "Феникс-Маркетинг". ИНН:7725812838, КПП:772501001, ОГРН: 513774619323915280, Москва, ул. Ленинская слобода, д. 19, стр. 1, этаж/пом 3/25

Генеральный партнёр: STRATE FZ-LLC License number 47005249 Address: B03-227 Business Center 02 RAKEZ Business Zone-FZ RAK (Ras Al Khaimah), United Arab Emirates Email: corporate@strate.ae