-
В этом видео мы собираемся ввести технику, называемую эвристической оценкой.
-
Как мы говорили в начале курса, существует множество различных способов оценки программного обеспечения.
-
Те, с которыми вы могли быть лучше всего знакомы это эмпирические методы,
-
где некоторых уровня формальность, у вас есть фактические люди, которые пробуют ваше программное обеспечение.
-
Также возможно иметь формальные методы, где вы строите модель
-
того, как люди ведут себя в конкретной ситуации,
-
и это позволяет предсказать, как различные пользовательские интерфейсы будут работать.
-
Или, если вы не можете построить модель официального закрытия формы
-
Вы также можете попробовать ваш интерфейс с моделирование и автоматических тестов —
-
что может обнаружить ошибки юзабилити и эффективных конструкций.
-
Это особенно хорошо работает для низкоуровневых вещи; Это сложнее сделать для более высокого уровня вещи.
-
И то, что мы собираемся говорить о сегодняшнем дне подходы на основе критики
-
где люди дают вам обратной связи непосредственно, на основе их опыта или набор эвристики.
-
Как любой из вас, кто когда-либо принятых искусства или дизайн класса знают,
-
коллегиального критика может быть невероятно эффективной формой обратной связи,
-
и это может сделать вас сделать ваши проекты даже лучше.
-
Вы можете получить коллегиального критики действительно на любом этапе процесса проектирования,
-
но я хотел бы выделить пару, что я думаю, может быть особенно ценным.
-
Во-первых это действительно ценно для того чтобы получить коллегиального критика до пользователя тестирования,
-
потому что помогает вам не тратить ваши пользователи на вещи, которые только собирается получить взял автоматически.
-
Вы хотите иметь возможность сосредоточить ценные ресурсы пользователя тестирования
-
на вещи, которые другие люди не смогут забрать на.
-
Богатые качественной обратной связи, предоставляющий одноранговый критика
-
также может быть очень ценным до редизайн вашего приложения,
-
потому что она может сделать это он может показать вам, какие части вашего приложения, вы вероятно хотите сохранить,
-
и какие другие части, которые являются более проблематичными и заслуживают редизайн.
-
В-третьих иногда, вы знаете, что есть проблемы,
-
и вам нужны данные, чтобы быть в состоянии убедить других заинтересованных сторон, чтобы сделать изменения.
-
И сверстников критика может быть отличным способом, особенно если он структурирован,
-
чтобы иметь возможность получить обратную связь, что вам нужно, чтобы сделать изменения, которые вы знаете, должны произойти.
-
И наконец, этот вид структурированной коллегиального критика может быть очень ценным перед выпуском программного обеспечения,
-
потому что он помогает вам сделать окончательного шлифования весь дизайн и сгладить любые шероховатостей.
-
Как и в случае большинства типов оценки, обычно полезно начать с четкой цели,
-
даже если в конечном итоге узнаешь совершенно неожиданным.
-
И так, что мы будем говорить о сегодняшнем дне конкретный метод, называемый эвристический оценки.
-
Эвристический оценки была создана Якоб Нильсен и коллеги, около двадцати лет назад сейчас.
-
И цель эвристического оценки сможет найти юзабилити проблемы в дизайне.
-
Я впервые узнал о эвристический оценки
-
Когда я та 'd Джеймс Лэндэй введение в курс HCI, и я был использовать его и до сих пор его преподавания.
-
Это действительно ценный метод, потому что она препятствует вам получить обратную связь очень быстро
-
и это высокий стратегия bang за доллар.
-
И слайды, которые я здесь основаны покинуть Джеймс слайды для этого курса
-
и материалы доступны на веб-сайте Якоб Нильсен.
-
Основная идея эвристический оценки заключается в том, что вы собираетесь предоставить набор людей —
-
часто другие заинтересованные стороны на дизайн команды или за пределами дизайн экспертов —
-
с набором эвристики или принципов,
-
и они будут использовать их для поиска проблем в вашей конструкции.
-
Каждый из них сначала собирается сделать это самостоятельно
-
и поэтому они будут ходить через различных задач с помощью вашего дизайна для поиска этих ошибок.
-
И вы увидите, что различные оценщиков собираетесь найти различные проблемы.
-
И тогда они будут общаться и говорить вместе только в конце, после этого.
-
В конце этого процесса они собираются получить обратно вместе и говорить о том, что они нашли.
-
И этот «независимого во-первых, собирать потом»
-
Это, как вы получаете пособие «мудрость толпы» в том, чтобы несколько оценщиков.
-
И одна из причин того, что мы говорим об этом в начале класса
-
что это метод, который можно использовать, рабочий интерфейс пользователя либо на эскизы пользовательских интерфейсов.
-
И поэтому эвристический оценки работает очень хорошо в сочетании с бумаги прототипов
-
и другие методы быстрого, низкой точностью, которые вы можете использовать для того чтобы получить ваши идеи дизайна быстро и быстро.
-
Вот Нейлсен в десяти эвристики, и они чертовски хороший набор.
-
Тем не менее, нет ничего магии об этих эвристики.
-
Они делают очень хорошую работу, охватывающую многие из проблем, с которыми вы увидите во многих пользовательских интерфейсов;
-
но вы можете добавить на любой, что вы хотите
-
и избавиться от любого, что не подходит для вашей системы.
-
Мы собираемся идти на содержание этих десяти эвристики в следующей лекции пара,
-
и в этой лекции я хотел бы представить процесс, который вы собираетесь использовать эти эвристики.
-
Так вот что вы собираетесь иметь оценщики делать:
-
Дайте им пару задач использовать ваш дизайн
-
и они делают каждой задачи, шагая через тщательно несколько раз.
-
Когда они делают это, они будут держать перечень принципов, юзабилити
-
как напоминание о вещи обратить внимание.
-
Теперь принципы которой вы будете использовать?
-
Я думаю что Нильсена десять эвристики фантастическое начало,
-
и вы можете увеличить с ничего, что актуально для вашего домена.
-
Так если у вас есть цели конкретной разработки, которые вы хотели свой дизайн для достижения, в частности в списке.
-
Или, если у вас есть конкретных целей, которые вы создали
-
от конкурентного анализа образцов, которые уже там,
-
Это здорово.
-
Или если есть вещи, что вы видели ваши или другие конструкции excel на,
-
те тоже являются важными целями и могут быть включены в ваш список эвристики.
-
И затем важная часть очевидно, что вы собираетесь взять то, что вы узнаете из этих оценщиков
-
и использовать эти нарушения эвристики как способ решения проблем и реорганизации.
-
Давайте поговорим немного больше о почему вы можете иметь несколько оценщиков, а не только один.
-
Граф на этом слайде приспособлен от Иакова Нейлсен работы по оценке эвристический
-
и то, что вы видите каждый черный квадрат — это ошибка, что особое оценщика.
-
Индивидуальные оценщика представляет собой строку этой матрицы
-
и в этом наборе около двадцати оценщиков.
-
Столбцы представляют проблемы.
-
И что вы можете увидеть, что есть некоторые проблемы, которые были найдены на относительно небольшое число оценщиков
-
и другие вещи, которые почти все найти.
-
Поэтому мы будем называть вещи о праве легко проблемы и вещи на левой сложные проблемы.
-
И поэтому, в совокупности, что мы можем сказать что не оценщик найти каждой проблемы,
-
и некоторые оценщиков нашли больше, чем другие, так что лучше и хуже людей делать это.
-
Так почему бы не много оценщиков?
-
Ну как вы добавляете больше оценщиков, они находят больше проблем;
-
но он вроде сужается off с течением времени — вы потеряете что выгоды в конце концов.
-
И поэтому с точки зрения затрат, это просто останавливается, смысл после определенного точки.
-
Так где же пик этой кривой?
-
Это, конечно, будет зависеть от Пользовательский интерфейс, который вы работаете с,
-
сколько вы платите людей, сколько времени участвует — всевозможные факторы.
-
Якоб Нильсен правило для этих видов пользовательских интерфейсов и эвристический оценки
-
Это, что три-пять человек, как правило, работают очень хорошо; и это был мой опыт тоже.
-
И я думаю, что определенно одна из причин, что люди используют эвристический оценки
-
Это потому, что он может быть чрезвычайно экономически эффективным способом поиска проблем.
-
В одном исследовании, что побежал Якоб Нильсен
-
он подсчитал, что стоимость проблем, обнаруженных с помощью эвристической оценки составила $500,000
-
а стоимость выполнения оценки была чуть более $10000,
-
и так он оценивает, что доходы превосходят расходы в 48 раз для данного конкретного пользовательского интерфейса.
-
Очевидно эти цифры являются очень грубой оценкой, и ваши результаты будут отличаться.
-
Вы можете думать о том, как оценить доход, который вы получаете от чего-то вроде этого
-
Если речь идет о программном средстве для внутреннего использования [внутри компании], используйте что-то вроде повышения производительности —
-
как, если вы делаете cистему отчетов о расходах
-
или другую внутреннюю систему, которая позволит эффективнее использовать время людей —
-
это большая победа юзабилити.
-
А если речь идет о программном обеспечении, которое вы распространяете на открытом рынке,
-
Вы можете подумать о доходах от продаж или других подобных показателях.
-
Одна вещь, которую мы можем получить от этого графика является то, что у оценщиков больше шансов найти серьезные проблемы
-
и это хорошая новость;
-
и так с относительно небольшое количество людей,
-
Вы довольно вероятно наткнуться на наиболее важные вещи.
-
Однако, как мы видели только один человек в данном конкретном случае,
-
даже лучший оценщик нашли лишь около трети проблем системы.
-
И так вот почему ganging количество оценщиков, скажем пять,
-
позволяет вам получить большую часть дохода, которую вы можете получить.
-
Если мы сравним эвристическую оценку и пользовательское тестирование, одна из вещей, которыую мы увидим
-
что эвристическая оценки часто может быть намного быстрее-это займет всего час или два для оценщика —
-
а процедура подготовки и выполнения пользовательского теста может занять больше времени,
-
даже не приходится тот факт, что вы можете иметь для создания программного обеспечения.
-
Кроме того результаты эвристической оценки приходят pre-interpreted
-
потому что оценщики непосредственно предоставляют вам проблемы и вещи, которые следует исправить,
-
и поэтому он сохраняет для вас время на то, чтобы вывести из теста в чем может быть проблема или решение.
-
Теперь наоборот, эксперты, прогуливаясь по вашей системы
-
можно создавать ложных срабатываний, которые не произойдет на самом деле в реальной среде.
-
И это действительно произошло, и поэтому тестирование пользователями, вроде, по определению, будет более точным.
-
В конце дня я думаю, что это ценно для альтернативных методов:
-
Каждый все различные методы, которые вы узнаете в этот класс для получения обратной связи может быть ценным,
-
и что на велосипеде через них вы часто можете получить преимущества каждого.
-
И что может быть, потому что с пользователей оценки и тестирования пользователями, вы найдете различные проблемы,
-
и, запустив он или что-то нравится, что рано в процессе проектирования
-
Вы будете избегать тратить реальных пользователей, которые могут привести в дальнейшем.
-
Так что теперь, когда мы видели выгоды, каковы шаги?
-
Первое, что нужно сделать, это получить все оценщики до скорости,
-
на то, что история позади вашего программного обеспечения — любые необходимые знания они могут нуждаться —
-
и рассказать им о сценарий, который вы собираетесь иметь их пошагово.
-
Тогда очевидно, у вас есть этап оценки, где люди работают через интерфейс.
-
После этого каждый человек собирается выделить серьезности,
-
и вы делаете это индивидуально во-первых,
-
и затем вы собираетесь для объединения их в группы серьезности
-
и производят статистического отчета из этого.
-
И наконец, после того как вы получили этот агрегированных отчетов, вы можете поделиться что с дизайн команды,
-
и проектная группа может обсудить что делать с этим.
-
Этого рода экспертизы может действительно налогообложения,
-
и так для каждого из сценариев, в которых вы выложить в ваш дизайн,
-
Это может быть полезно иметь оценщика пройти через этот сценарий дважды.
-
Первый раз, они просто получить чувство и второй раз, они могут сосредоточиться на более конкретные элементы.
-
Если у вас есть некоторые ходить и использования системы, как машина билет куда-то,
-
Затем вы можете не дать людям любую справочную информацию на всех,
-
потому что если у вас есть люди, которые просто выйти на автобусе или поезде,
-
и они ходить к вашей машине без предварительной информации,
-
Это опыт, вы хотите оценщики иметь.
-
С другой стороны, если вы собираетесь иметь геномных системы или других экспертов пользовательский интерфейс,
-
Вы хотите к, чтобы убедиться, что независимо от обучения вы бы реальных пользователей,
-
Вы собираетесь дать ваш оценщиков.
-
Другими словами независимо от фона, она должна быть реалистка(ст).
-
Когда оценщики ходить через свой интерфейс
-
Это будет иметь важное значение для получения списка весьма специфические проблемы
-
и объяснить эти проблемы в отношении одного из дизайн эвристики.
-
Вы не хотите люди просто чтобы быть, как, «я не люблю его.»
-
И для того, чтобы maxilinearly проповедовать вам эти результаты для проектной группы;
-
Вы будете хотеть перечислить каждый из них отдельно, так что они могут решаться эффективно.
-
Отдельные списки также могут помочь вам избежать листинг же повторяющиеся проблемы снова и снова.
-
Если повторяется элемент на каждый одном экране, вы не хотите перечислить на каждый одном экране;
-
Вы хотите список его один раз, так что она может быть исправлена один раз.
-
И эти проблемы могут быть очень подробный, как «имя чего-то заблуждение»
-
или это может быть то, что должен делать больше с потоком пользовательского интерфейса,
-
или архитектура пользовательский опыт и что конкретно не связана с элементом интерфейса.
-
Оценщики могут также найти, что что-то не хватает, что должно быть там,
-
и это иногда может быть неоднозначной с ранних прототипов, как бумага прототипов.
-
И поэтому вы будете хотеть уточнить ли пользовательский интерфейс является то, что вы верите, чтобы быть полной,
-
или есть умышленное элементов отсутствует впереди времени.
-
И, конечно же, иногда есть особенности, которые собираются быть очевидно там
-
Это подразумевает интерфейсом пользователя.
-
Таким образом, мягкий и отдохнуть на тех.
-
После оценщики прошли через интерфейс,
-
они могут каждый самостоятельно назначить серьезности все проблемы, которые они нашли.
-
И это будет позволяют выделить ресурсы для устранения этих проблем.
-
Она также может помочь дать вам обратную связь о том, как хорошо вы делаете
-
с точки зрения юзабилити вашей системы в целом,
-
и дать вам своего рода эталоном ваши усилия в этом ключе.
-
Тяжести мерой, что оценщики собирается прийти вверх с собирается объединить несколько вещей:
-
Это будет объединить частоту, воздействия,
-
и распространенности этой проблемы, что они видят на экране.
-
Итак то, что только в одном месте может быть менее крупные сделки
-
чем то, что показывает вверх на протяжении весь пользовательский интерфейс.
-
Аналогичным образом собираетесь быть некоторые вещи, как неправильно выровненного текста,
-
который может быть безвкусный, но не дело убийцы с точки зрения вашего программного обеспечения.
-
И вот тяжести рейтинговой системы, создавшей Нильсен; Очевидно, что вы можете использовать все, что вы хотите:
-
Она колеблется от нуля до четырех,
-
где ноль «в конце дня ваш оценщика решает, что это на самом деле проблема не юзабилити»
-
весь путь до его что-то действительно катастрофическими, должен получать фиксированный сразу.
-
И вот пример конкретной проблемы
-
что наши та Робби найдено, когда он забирал CS147 как студент.
-
Он шел через чужой мобильный интерфейс, что элемент «вес» к нему;
-
и он понял, что после того, как вы ввели Ваш вес, нет никакой возможности изменить его после факта.
-
Так, что это своего рода неуклюжим, вы хотите, вы могли бы исправить это-возможно не катастрофа.
-
И так что вы видите здесь, что он перечислил проблемы, он дал его серьезности,
-
Он получил эвристические правила, что он нарушает, и затем он описывает именно то, что проблема.
-
И наконец, после всех ваших оценщиков прошли через интерфейс,
-
перечислены их проблемы и объединили их с точки зрения серьезности и важности,
-
Вы будете хотеть подведение итогов с проектной группой.
-
Это хороший шанс иметь возможность обсудить общие проблемы в пользовательский интерфейс и качественной обратной связи,
-
и это дает вам шанс пройти через каждый из этих элементов
-
и предложить улучшения в том, как решать эти проблемы.
-
В этом подведение итогов сессии, она может быть ценной для команды разработчиков
-
оценить количество усилий, что бы исправить одну из этих проблем.
-
Так, например, если у вас есть что-то это один тяжести масштабе и не слишком большой сделки —
-
Он может что-то делать с формулировки и ее просто исправить грязи —
-
Это говорит вам «идти вперед и это исправить».
-
И наоборот вы может иметь то, что катастрофа
-
который занимает гораздо больше усилий, но его значение приведет вас к исправить ее.
-
И есть другие вещи, где участвуют значение по отношению к стоимости
-
просто не имеет смысла бороться с прямо сейчас.
-
И это подведение итогов сессии может быть отличным способом для мозгового штурма идей будущего дизайна,
-
особенно когда у вас есть все заинтересованные стороны в комнате,
-
и идеи о том, что вопросы с пользовательским интерфейсом, свежи в их памяти.
-
В двух следующих видео мы пройти через Neilsons десять эвристики и больше поговорить о том, что они означают.
