Какой процент выполнения и невыполненения заданий при юзабилити-тестированиях?
Разбирал старые конспекты книг и наткнулся на кривоватый мой перевод Сауро про количественные методы исследования, он в одной из вставок приводит свои бенчмарки, сколько в среднем в любом случае респонденты не справляются с выполнением заданий при ю-тестах.
"
Что такое хороший успешный показатель выполнения задач при юзабилити-тестировании? — из файлов Джеффа Сауро
Данные 1189 задач, выполненных в 115 тестах на удобство использования. Анализ почти 1200 задач на удобство использования показывает, что средний показатель выполнения задач составляет 78% (Sauro, 2011). При установке цели для показателя выполнения задач контекст имеет значение.
Если издержки от провала задачи высоки (потеря денег, потеря жизни),то вам нужно стремиться к 100%. Если последствия менее существенны, то вы можете немного снизить показатель. Я часто видел пользовательские веб-приложения для пользователей, которые можно использовать без предварительной подготовки, с целевым показателем выполнения 70%.
То есть задача считается достаточно хорошей, если есть доказательства тестирования, что не менее 70% выполнили задачу с первой попытки. Несмотря на то, что контекст имеет значение, может быть полезно иметь представление о том, насколько хорошо ваш показатель выполнения задач складывается с другими, полученными во время теста на удобство использования.
"
Тут, конечно, хорошо было бы посмотреть на данные юзабилити-тестирований не 2011 года, да и в России, но мечты мечты.
Кажется, что такое распределение 80 на 20 вызывает некоторый скепсис. Но вообще мой опыт подтверждает что-то похожее на правду, что если у нас на "гомеопатической выборке" из 10 респондентов двое не справились с заданием это повод задуматься, а если три, то это уже повод зафиксировать важный барьер. Вопрос о том, что является целевым показателем выполнения, ведь пока даже в литературе - волюнтаризм
Разбирал старые конспекты книг и наткнулся на кривоватый мой перевод Сауро про количественные методы исследования, он в одной из вставок приводит свои бенчмарки, сколько в среднем в любом случае респонденты не справляются с выполнением заданий при ю-тестах.
"
Что такое хороший успешный показатель выполнения задач при юзабилити-тестировании? — из файлов Джеффа Сауро
Данные 1189 задач, выполненных в 115 тестах на удобство использования. Анализ почти 1200 задач на удобство использования показывает, что средний показатель выполнения задач составляет 78% (Sauro, 2011). При установке цели для показателя выполнения задач контекст имеет значение.
Если издержки от провала задачи высоки (потеря денег, потеря жизни),то вам нужно стремиться к 100%. Если последствия менее существенны, то вы можете немного снизить показатель. Я часто видел пользовательские веб-приложения для пользователей, которые можно использовать без предварительной подготовки, с целевым показателем выполнения 70%.
То есть задача считается достаточно хорошей, если есть доказательства тестирования, что не менее 70% выполнили задачу с первой попытки. Несмотря на то, что контекст имеет значение, может быть полезно иметь представление о том, насколько хорошо ваш показатель выполнения задач складывается с другими, полученными во время теста на удобство использования.
"
Тут, конечно, хорошо было бы посмотреть на данные юзабилити-тестирований не 2011 года, да и в России, но мечты мечты.
Кажется, что такое распределение 80 на 20 вызывает некоторый скепсис. Но вообще мой опыт подтверждает что-то похожее на правду, что если у нас на "гомеопатической выборке" из 10 респондентов двое не справились с заданием это повод задуматься, а если три, то это уже повод зафиксировать важный барьер. Вопрос о том, что является целевым показателем выполнения, ведь пока даже в литературе - волюнтаризм
Вид с высоты птичьего полета на тексты. Новое чтение?
Автор блога alexandrevariengien создал вид на тексты с высоты птичьего полета, интерактивный инструмент визуализации, который позволяет вам изучать большие коллекции текста сверху, как будто вы смотрите на пейзаж с самолета. Вместо последовательного чтения или фильтрации контента вы получаете полное представление о масштабе документа, сохраняя при этом возможность масштабирования определенных областей.
Эта перспектива позволяет вам постепенно наращивать понимание в своем собственном темпе, перемещаясь между высокоуровневыми семантическими кластерами и углубленным чтением отрывков.
Зачем? Сразу можно оценить объем семантики, объем той или иной категории слов, качественной оценки показателей LLM. Те языковая модель нагенерировала 100 разных достаточно глупых ответов, визуализация его ответов представляет карту ответов, которая отражает языковую реальность ЛЛМ
Чем это интересно для UX и HCI? Можно смотреть на карту диалогов не так грустно как на ветки диалогов в чат-гпт, где надо возвращаться назад, переключатся на другую ветку общения, здесь наглядно могут показать карту диалогов нейронкой
https://alexandrevariengien.com/birds-eye-view
Автор блога alexandrevariengien создал вид на тексты с высоты птичьего полета, интерактивный инструмент визуализации, который позволяет вам изучать большие коллекции текста сверху, как будто вы смотрите на пейзаж с самолета. Вместо последовательного чтения или фильтрации контента вы получаете полное представление о масштабе документа, сохраняя при этом возможность масштабирования определенных областей.
Эта перспектива позволяет вам постепенно наращивать понимание в своем собственном темпе, перемещаясь между высокоуровневыми семантическими кластерами и углубленным чтением отрывков.
Зачем? Сразу можно оценить объем семантики, объем той или иной категории слов, качественной оценки показателей LLM. Те языковая модель нагенерировала 100 разных достаточно глупых ответов, визуализация его ответов представляет карту ответов, которая отражает языковую реальность ЛЛМ
Чем это интересно для UX и HCI? Можно смотреть на карту диалогов не так грустно как на ветки диалогов в чат-гпт, где надо возвращаться назад, переключатся на другую ветку общения, здесь наглядно могут показать карту диалогов нейронкой
https://alexandrevariengien.com/birds-eye-view
В период с 2014 по 2023 год было подано 54 000 заявок на изобретения, связанные с GenAI (патентные семейства), и опубликовано более 75 000 научных публикаций. Первая десятка крупнейших заявителей на патенты GenAI: Tencent (2074 изобретения), Ping An Insurance (1564 изобретения), Baidu (1234 изобретения), Китайская академия наук (607), IBM (601), Alibaba Group (571), Samsung Electronics (468), Alphabet (443), ByteDance (418), Microsoft (377).
Всемирная организация интеллектуальной собственности (ВОИС) опубликовала «Отчет о патентном ландшафте генеративного ИИ» - тут много достаточно скучного, но показательно, что речь идет в первую очередь о разработке софта, Generative adversarial network GAN, а вот языковые модели скорее на втором месте
Отчет в комментариях
Всемирная организация интеллектуальной собственности (ВОИС) опубликовала «Отчет о патентном ландшафте генеративного ИИ» - тут много достаточно скучного, но показательно, что речь идет в первую очередь о разработке софта, Generative adversarial network GAN, а вот языковые модели скорее на втором месте
Отчет в комментариях
Плагиат Монополии и настольные игры как иллюстрация политической теории?
В начале 20 века (1906 год) женщина-экономист изобрела антикапиталистическую настольную игру: эта игра была создана, чтобы показать, какие нежелательные экономические эффекты приносит монополия на землю и как земельный налог помогает справиться с ними. Это была эпоха моды на движение джорджизма и для иллюстрации идей о том, что все земельные блага должны принадлежать всем, а вот созданное людьми,наоборот, - самим людям. Игра получила название "Землевладелец" и в нее играли студенты колледжей
В начале 1933 года Ричард Брейс Дарроу отправился на званый ужин, где его научили новой игре. Он так хорошо провел время и так воодушевился, что хозяева напечатали правила игры и отправили Дарроу копию. Затем Дарроу нарисовал свою собственную версию на круглом куске клеенки. (Версия, в которую он играл на званом ужине, также была самодельной!) Дарроу был продавцом обогревателей, который потерял работу, а времена были тяжелыми. Он решил взять свой прототип и представить игру Parker Brothers. Правила были точно такими же, как у его друзей, вплоть до неправильного написания Marven Gardens как Marvin Gardens. Инвесторы не сразу клюнули, но потом клюнули, и Дэрроу стал миллионером.
https://en.wikipedia.org/wiki/Lizzie_Magie
https://publicdomainreview.org/collection/the-landlords-game
Тут показательно, конечно, что для политической теории США игры уже тогда играли огромную роль
В начале 20 века (1906 год) женщина-экономист изобрела антикапиталистическую настольную игру: эта игра была создана, чтобы показать, какие нежелательные экономические эффекты приносит монополия на землю и как земельный налог помогает справиться с ними. Это была эпоха моды на движение джорджизма и для иллюстрации идей о том, что все земельные блага должны принадлежать всем, а вот созданное людьми,наоборот, - самим людям. Игра получила название "Землевладелец" и в нее играли студенты колледжей
В начале 1933 года Ричард Брейс Дарроу отправился на званый ужин, где его научили новой игре. Он так хорошо провел время и так воодушевился, что хозяева напечатали правила игры и отправили Дарроу копию. Затем Дарроу нарисовал свою собственную версию на круглом куске клеенки. (Версия, в которую он играл на званом ужине, также была самодельной!) Дарроу был продавцом обогревателей, который потерял работу, а времена были тяжелыми. Он решил взять свой прототип и представить игру Parker Brothers. Правила были точно такими же, как у его друзей, вплоть до неправильного написания Marven Gardens как Marvin Gardens. Инвесторы не сразу клюнули, но потом клюнули, и Дэрроу стал миллионером.
https://en.wikipedia.org/wiki/Lizzie_Magie
https://publicdomainreview.org/collection/the-landlords-game
Тут показательно, конечно, что для политической теории США игры уже тогда играли огромную роль
Роль human factors и UX в пожаре Нотр-Дам.
Ок, ладно, это даже круче, чем авария на АЭС Три-Майл-Айленд и прошло мимо меня.
Система безопасности в Соборе Нотр-Дам не учитывала скорость распространения огня по крыше, кроме того, на крыше не было специальных разбрызгивателей и противопожарных стен. NYT пишет, что это произошло из-за того, что в разработке противопожарной системы, растянувшейся на шесть лет, приняло участие слишком много разных экспертов. «Когда единственное, что система должна была сделать, — сообщить о пожаре и его конкретном месте, она выдала практически нерасшифровываемое сообщение». Сначала система назвала одну из четырех зон — ту, в которой был обнаружен огонь, — «Attic Navy Sacristy» (которое охранник интерпретировал как крыша ризницы), а затем номер одного 160 дымовых детекторов: «ZDA-110-3-15-1».
Более важно здесь то, что на подобного рода оповещения повлиял и фактор нового сотрудника (привет системам онбординга и требования противопожарной безопасности).
В 18:18 вечера 15 апреля новый охранник (это был его третий день) увидел предупреждающее сообщение в системе пожарной безопасности: ZDA-110-3-15-1. Но он не знал, что это значит. Оно должно было подсказать ему, где искать пожар, но для него это ничего не значило, и он не был обучен понимать это. Для инженеров, которые строили систему, код идентифицировал конкретное место расположения пожарного датчика в огромном соборе, но охранник этого не знал. В суматохе второй охранник искал пожар на неправильной стороне комплекса. Если бы пожар был обнаружен раньше, его можно было бы локализовать, но 25 дополнительных минут суматохи до того, как его обнаружили, позволили огню выйти из-под контроля. И его восстановление обошлось почти в 1 миллиард долларов.
Это из книжки, читать ее, пожалуй, не буду
https://whydesignishard.substack.com/p/the-900-million-ux-mistake-at-the
А вот уже официальные данные противопожарной организации ЕС https://cfpa-e.eu/delayed-alert-cost-notre-dame-dearly/
Это критическая временная задержка по отношению к тому, что могут сделать аварийные службы в случае пожара. – В здании такого возраста разница заключается в том, можно ли потушить пожар или просто контролировать его, говорит Тим Оле Симонсен, директор по операциям и начальник пожарной охраны Большого Копенгагена. Он подчеркивает, что не знаком с точными подробностями последовательности событий пожара в Нотр-Даме, но добавляет: – Задержка такого калибра обычно означает, что есть много дыма, из-за которого трудно добраться до огня, и может возникнуть опасность обрушения конструкции. Если вы приедете быстро, вы иногда сможете потушить пожар на ранней стадии. Если пройдет больше времени, тушение пожара может занять от 12 до 24 часов. Задержка в 25 минут в этом отношении фатальна.
Вопрос только вот в чем: а насколько наши системы безопасности и пользовательские сценарии обычных финансовых онлайн-сервисов или торговых центров - готовы к авариям с точки зрения интерфейсов, онбординга и обучения? Ответ на этот вопрос предлагает сама жизнь
Ок, ладно, это даже круче, чем авария на АЭС Три-Майл-Айленд и прошло мимо меня.
Система безопасности в Соборе Нотр-Дам не учитывала скорость распространения огня по крыше, кроме того, на крыше не было специальных разбрызгивателей и противопожарных стен. NYT пишет, что это произошло из-за того, что в разработке противопожарной системы, растянувшейся на шесть лет, приняло участие слишком много разных экспертов. «Когда единственное, что система должна была сделать, — сообщить о пожаре и его конкретном месте, она выдала практически нерасшифровываемое сообщение». Сначала система назвала одну из четырех зон — ту, в которой был обнаружен огонь, — «Attic Navy Sacristy» (которое охранник интерпретировал как крыша ризницы), а затем номер одного 160 дымовых детекторов: «ZDA-110-3-15-1».
Более важно здесь то, что на подобного рода оповещения повлиял и фактор нового сотрудника (привет системам онбординга и требования противопожарной безопасности).
В 18:18 вечера 15 апреля новый охранник (это был его третий день) увидел предупреждающее сообщение в системе пожарной безопасности: ZDA-110-3-15-1. Но он не знал, что это значит. Оно должно было подсказать ему, где искать пожар, но для него это ничего не значило, и он не был обучен понимать это. Для инженеров, которые строили систему, код идентифицировал конкретное место расположения пожарного датчика в огромном соборе, но охранник этого не знал. В суматохе второй охранник искал пожар на неправильной стороне комплекса. Если бы пожар был обнаружен раньше, его можно было бы локализовать, но 25 дополнительных минут суматохи до того, как его обнаружили, позволили огню выйти из-под контроля. И его восстановление обошлось почти в 1 миллиард долларов.
Это из книжки, читать ее, пожалуй, не буду
https://whydesignishard.substack.com/p/the-900-million-ux-mistake-at-the
А вот уже официальные данные противопожарной организации ЕС https://cfpa-e.eu/delayed-alert-cost-notre-dame-dearly/
Это критическая временная задержка по отношению к тому, что могут сделать аварийные службы в случае пожара. – В здании такого возраста разница заключается в том, можно ли потушить пожар или просто контролировать его, говорит Тим Оле Симонсен, директор по операциям и начальник пожарной охраны Большого Копенгагена. Он подчеркивает, что не знаком с точными подробностями последовательности событий пожара в Нотр-Даме, но добавляет: – Задержка такого калибра обычно означает, что есть много дыма, из-за которого трудно добраться до огня, и может возникнуть опасность обрушения конструкции. Если вы приедете быстро, вы иногда сможете потушить пожар на ранней стадии. Если пройдет больше времени, тушение пожара может занять от 12 до 24 часов. Задержка в 25 минут в этом отношении фатальна.
Вопрос только вот в чем: а насколько наши системы безопасности и пользовательские сценарии обычных финансовых онлайн-сервисов или торговых центров - готовы к авариям с точки зрения интерфейсов, онбординга и обучения? Ответ на этот вопрос предлагает сама жизнь
Why Design Is Hard
The $900 million UX mistake at the Notre Dame Cathedral fire
Will we always make the same errors in building things?
Large Concept Models
Meta AI представил новую архитектуру, бросающую вызов LLM. Они называют ее Large Concept Models (LCM). В отличие от традиционных LLM, которые работают на уровне токенов, LCM работают на более высоком уровне семантического представления, называемого «концепциями». Эти концепции не зависят от языка и представляют более широкие идеи или действия, что делает их более соответствующими уровням абстракции человека.
Работают как на картинке, позволяют делать реазонинг основанным на больших концептах, а не на токенизации, убирая несколько шагов
https://ai.meta.com/research/publications/large-concept-models-language-modeling-in-a-sentence-representation-space/
Простой пересказ
https://aipapersacademy.com/large-concept-models/
Meta AI представил новую архитектуру, бросающую вызов LLM. Они называют ее Large Concept Models (LCM). В отличие от традиционных LLM, которые работают на уровне токенов, LCM работают на более высоком уровне семантического представления, называемого «концепциями». Эти концепции не зависят от языка и представляют более широкие идеи или действия, что делает их более соответствующими уровням абстракции человека.
Работают как на картинке, позволяют делать реазонинг основанным на больших концептах, а не на токенизации, убирая несколько шагов
https://ai.meta.com/research/publications/large-concept-models-language-modeling-in-a-sentence-representation-space/
Простой пересказ
https://aipapersacademy.com/large-concept-models/