1. Сделайте дисплей чётким. Читаемость дисплея является важным критерием в проектировании дисплея. Если символы или объекты отображаются нечётко, то пользователь не может эффективно их использовать.
2. Избегайте абсолютно строгих границ. Не просите пользователя определить уровень переменной на основе лишь одной сенсорной переменной (например цвет, размер, громкость). Эти сенсорные переменные могут содержать множество различных уровней.
3. Обработка сверху-вниз. Сигналы воспринимаются и толкуются в соответствии с ожиданиями, сформированными на основе более раннего опыта пользователя. Если сигнал представлен вопреки ожиданиям пользователя, то потребуется больше его представления, чтобы доказать, что сигнал был понят верно.
4. Чрезмерная выгода. Если сигнал представлен более одного раза, больше шансов, что он будет понят верно. Это возможно сделать с помощью представления его в альтернативных физических формах (например, цвета, форма, голос и т. д.), так как избыточность не подразумевает повторения. Светофор является прекрасным примером избыточности, так цвет и положение являются избыточными.
5. Сходства приводят к путанице. Используйте отличающиеся элементы. Похожие сигналы будут приводить к путанице. Соотношение схожих признаков к различным признакам является причиной схожести сигналов. Например, А423В9 больше похоже на А423В8, чем 92 на 93. Ненужные похожие признаки должны быть удалены, а непохожие признаки должны быть выделены.
6. Принцип изобразительного реализма.Экран должен выглядеть как переменная, которую он представляет (например, высокая температура на термометре показана высшим вертикальным уровнем). Если есть множество составляющих, то они могут быть настроены так, как они будут выглядеть в среде, где они будут представлены.
7. Принцип движущейся части. Движущиеся элементы должны двигаться по той схеме и в том направлении в каком это происходит в мысленном представлении пользователя, как оно движется в системе. Например, движущийся элемент на высотометре должен двигаться вверх с набиранием высоты.
Метрики предпочтений
Один из наиболее простых и популярных методов оценки практичности заключается в использовании метрик предпочтений. Технология такова: берете несколько ничего не подозревающих субъектов — пользователей или потенциальных пользователей — и спрашиваете их, что они думают о данной системе. Естественно, у субъективной пользовательской оценки есть как плюсы, так и минусы. Плюсы— в относительной дешевизне и простоте получения информации, минусы— в том, что не всегда именно эта информация требуется разработчикам. Оценка пользователей не только субъективна сама по себе, но и пользовательские предпочтения весьма относительно коррелируют с реальной простотой использования и другими стандартными показателями практичности. Пользователи будут говорить вам про невиданное удобство использования и указывать при этом на запутанные или неэффективные системы. Попробуйте спросить, что они думают по поводу Web-сайтов, и в их ответе вы найдете подтверждение этим словам. Тем не менее субъективные впечатления конечных потребителей продукта игнорировать нельзя. Удовлетворение пользователя — это, несомненно, одна из составляющих практичности и важный фактор успеха на рынке. Ведь в самом деле, удовлетворение пользователя лучше подскажет, какой продукт «пойдет» на рынке, чем практичность сама по себе.
Метрики производительности
Некоторые вопросы удается решить, только поработав с реально функционирующей системой; соответственно, в задачи тестирования практичности входит создание условий, достаточно реалистично моделирующих такую работу. Мера «достаточности» в данном случае определяется мерой искажения ответов пользователей. Метрики производительности служат показателями того, как пользователи выполняют задания с помощью системы в лабораториях тестирования практичности либо на своих рабочих местах .Можно измерять множество аспектов производительности, например время, затрачиваемое на решение задачи или нескольких задач, количество ошибок, частоту обращения к справочной системе.
1. Замените память наглядной информацией: мировое знание. Пользователь не должен сохранять важную информацию исключительно в рабочей памяти или извлекать её из долговременной памяти. Меню/перечень могут помочь пользователю упростить использование памяти. Однако, использование памяти иногда может помочь пользователю, так как избавляет от необходимости ссылаться на некоторые типы знаний в мире (например, компьютерный специалист скорее использовал бы прямые команды из памяти, чем обращался к руководству). Для эффективной разработки должны быть сбалансированы знания в голове пользователя и знания в мире.
2. Принцип предиктивной помощи. Проактивные действия, как правило, более эффективны, чем реактивные действия. Дисплей должен исключать ресурсоёмкие когнитивные задачи и заменить их более простыми задачами, чтобы сократить использование умственных ресурсов пользователя. Это позволит пользователю сконцентрироваться не только на текущей ситуации, но и также подумать о возможных ситуациях в будущем. Пример предиктивной помощи — дорожный знак, который информирует о расстоянии до пункта назначения.
3. Принцип совместимости. Старые особенности других дисплеев легко перенести в разработку новых дисплеев, если их разработки совместимы. Долговременная память пользователя будет срабатывать на выполнение уместных действий. В ходе разработки должен быть принят во внимание данный факт и учитывать совместимость между разными дисплеями.
При проектировании пользовательских интерфейсов необходимо учитывать психофизические особенности человека, связанные с восприятием, запоминанием и обработкой информации.
Исследованием принципов работы мозга человека занимается когнитивная психология.
Информация о внешнем мире поступает в наш мозг в огромных количествах. Часть мозга, которую условно можно назвать «процессором восприятия», постоянно без участия сознания перерабатывает ее, сравнивая с прошлым опытом, и помещает в хранилище уже в виде зрительных, звуковых и прочих образов. Любые внезапные или просто значимые для нас изменения в окружении привлекают наше внимание, и тогда интересующая нас информация поступает в кратковременную память. Если же наше внимание не было привлечено, то информация в хранилище пропадает, замещаясь следующими порциями.
Когнитивное бессознательное — это те ментальные процессы, которые вы не осознаете в тот момент, когда они происходят.
Когнитивное сознательное включается в тот момент, когда вы сталкиваетесь с ситуацией, которая кажется новой или представляет угрозу, или, когда требуется принять нешаблонное решение.
Фокус-группа — это метод исследования, при котором группа пользователей приглашается для принятия участия в тестировании пользовательского интерфейса. Как правило, пользователи, которым предлагается оценить удобство интерфейса, являются потенциальными клиентами.
Проведение интервью с пользователями ведется по заранее подготовленному сценарию. Пользователю ставятся вопросы либо задачи, которые ему необходимо выполнить при работе с интерфейсом приложения. Все действия пользователя, реакция на определенные элементы интерфейса, его реплики и эмоции записываются на аудио и видео носители для дальнейшего анализа.
Исследования этого типа включают четыре общих элемента:
1. Вовлечение нескольких респондентов, собранных в одном месте.
2. Взаимодействие участников. Если во многих других типах исследований считается, что любая дискуссия между участниками искажает чистоту ответов, то на заседаниях фокус-групп субъекты поощряются к взаимодействию друг с другом.
3. Весь ход обсуждения осуществляется профессионалом-модератором. Он направляет течение групповой дискуссии в соответствии с целями, поставленными на предварительной стадии.
4. При проведении фокус-групп используется сценарий. Если в количественном исследовании при сборе информации применяется законченный, формализованный, структурированный инструментарий, то путеводитель обычно имеет форму относительно незавершенного руководства. Его основное назначение — фокусирование проблемы, настраивание на определенную тему. Одновременно он должен давать возможность спонтанным высказываниям участников, обеспечивать групповую динамику.
Предсказывающие метрики
Метрики проектирования являются объективными показателями качества, которые можно получить, используя элементы проекта, такие как визуальный дизайн экранных решений. Эти метрики называются предсказывающими, поскольку они позволяют предположить или предсказать некоторые аспекты реальной производительности уже построенной системы. Корректные метрики проектирования будут достаточно точно коррелировать с реальной простотой использования, эффективностью, уровнем ошибки другими показателями прикладной практичности. Разработчики ПО могут рассматривать метрики проектирования как альтернативу субъективным пользовательским оценкам или как тестирование практичности, проводимое уже после создания функционального прототипа или системы. Большим преимуществом метрик проектирования является то, что они позволяют быстро и дешево оценивать и сравнивать разные проекты. При этом не требуется заранее специально для тестирования разрабатывать систему, модель или рабочий прототип.
1. Принцип изобразительного реализма. Экран должен выглядеть как переменная, которую он представляет (например, высокая температура на термометре показана высшим вертикальным уровнем). Если есть множество составляющих, то они могут быть настроены так, как они будут выглядеть в среде, где они будут представлены.
2. Принцип движущейся части. Движущиеся элементы должны двигаться по той схеме и в том направлении в каком это происходит в мысленном представлении пользователя, как оно движется в системе. Например, движущийся элемент на высотометре должен двигаться вверх с набиранием высоты.
3. Минимизация времени доступа к информации. Когда внимание пользователя перемещается из одного места в другое в целях доступа к необходимой информации, то затрачивается много времени и усилий. Конструкция дисплея должна уменьшить данные затраты, так часто используемый источник должен находиться в ближайшей позиции. Однако не должна быть утеряна понятность.
4. Принцип совместимости. Разделённое внимание между двумя источниками может быть необходимо для выполнения одной задачи. Эти источники должны быть мысленно взаимосвязаны и иметь мысленную близость. Время доступа к информации должно быть небольшим и это может быть достигнуто различными способами (например, близкое расположение, одинаковый цвет, узоры, формы и т. д.). Однако, близость отображения может привести к путанице.
5. Принцип большого количества ресурсов. Пользователь может более просто обрабатывать информацию с разных ресурсов. Например, зрительная и слуховая информация может быть представлена одновременно, чем представлять всю зрительную и всю аудио информацию.
Модель GOMS (расшифровывается как "themodelofgoals, objects, methods, andselectionrules") позволяет предсказать время, необходимое для выполнения задачи с помощью конкретного интерфейса. Разработчики этой модели обнаружили, что для решения поставленной задачи при работе с компьютером пользователь совершает определенный набор жестов. Таким образом, время выполнения задачи складывается из времени выполнения этих жестов и из промежутков между жестами, которые требуются для обдумывания.
В результате тщательного лабораторного исследования удалось получить среднее время выполнения различных жестов:
K = 0.2 c - время, необходимое для нажатия клавиши клавиатуры
P = 1.1 с - время, необходимое для перемещения указателя мыши к определенной позиции на мониторе
H = 0.4 - время, необходимое для перемещения руки пользователя с клавиатуры на мышь
M = 1.35 - ментальная пауза, т.е. время, необходимое пользователю на обдумывание следующего шага.
Время реакции при выборе из некоторого числа альтернативных сигналов зависит от их числа.
Закон Хика — утверждение, что время реакции при выборе из некоторого числа альтернативных сигналов зависит от их числа. Впервые эта закономерность была получена в 1885 г. немецким психологом И. Меркелем, а в 1952 г. получила экспериментальное подтверждение в исследованиях В.Э. Хика, в которых она приобрела вид логарифмической функции:
ВР = а*log(n+1), где ВР — среднее значение времени реакции по всем альтернативным сигналам; n — число равновероятных альтернативных сигналов; а — коэффициент пропорциональности. Единица в формулу введена для учета еще одной альтернативы, в виде пропуска сигнала.
Согласованность позволяет пользователям переносить имеющиеся знания на новые задания, осваивать новые аспекты быстрее и благодаря этому фокусировать внимание на решаемой задаче, а не тратить время на уяснение различий в использовании тех или иных элементов управления, команд и т.д. Обеспечивая преемственность полученных ранее знаний и навыков, согласованность делает интерфейс узнаваемым и предсказуемым.
Согласованность важна для всех аспектов интерфейса, включая имена команд, визуальное представление информации и поведение интерактивных элементов. Для реализации свойства согласованности в создаваемом программном обеспечении необходимо учитывать его различные аспекты.
1. Согласованность в пределах продукта. Одна и та же команда должна выполнять одни и те же функции, где бы она ни встретилась, причем одним и тем же образом. Например, если в одном диалоговом окне команда копировать означает немедленное выполнения соответствующих действий, то в другом окне она не должна требовать от пользователя дополнительно указать расположение копируемой информации. Другими словами, нужно использовать одну и туже команду, чтобы выполнить функции, которые кажутся подобными пользователю.
2. Согласованность в пределах рабочей среды. Поддерживая согласованность с интерфейсом, предоставляемым операционной системой (например, ОС Windows), приложение может "опираться" на те знания и навыки пользователя, которые он получил ранее при работе с другими приложениями.
3. Согласованность в использовании метафор. Если поведение некоторого программного объекта выходит за рамки того, что обычно подразумевается под соответствующей ему метафорой, у пользователя могут возникнуть трудности при работе с таким объектом. Например, если для программного объекта Корзина определить операцию Запуск, то для уяснения ее смысла пользователю, скорее всего, потребуется посторонняя помощь.
Диаграмма прецедентов (диаграмма вариантов использования) в UML — диаграмма, отражающая отношения между актёрами и прецедентами и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне[1].
Прецедент — возможность моделируемой системы (часть её функциональности), благодаря которой пользователь может получить конкретный, измеримый и нужный ему результат. Прецедент соответствует отдельному сервису системы, определяет один из вариантов её использования и описывает типичный способ взаимодействия пользователя с системой. Варианты использования обычно применяются для спецификации внешних требований к системе
Основное назначение диаграммы — описание функциональности и поведения, позволяющее заказчику, конечному пользователю и разработчику совместно обсуждать проектируемую или существующую систему.
При моделировании системы с помощью диаграммы прецедентов системный аналитик стремится:
чётко отделить систему от её окружения;
определить действующих лиц (актёров), их взаимодействие с системой и ожидаемую функциональность системы;
определить в глоссарии предметной области понятия, относящиеся к детальному описанию функциональности системы (то есть, прецедентов).
Работа над диаграммой может начаться с текстового описания, полученного при работе с заказчиком. При этом нефункциональные требования (например, конкретный язык или система программирования) при составлении модели прецедентов опускаются (для них составляется другой документ)
Для отражения модели прецедентов на диаграмме используются:
рамки системы (англ. system boundary) — прямоугольник с названием в верхней части и эллипсами (прецедентами) внутри. Часто может быть опущен без потери полезной информации,
актёр (англ. actor) — стилизованный человечек, обозначающий набор ролей пользователя (понимается в широком смысле: человек, внешняя сущность, класс, другая система), взаимодействующего с некоторой сущностью (системой, подсистемой, классом). Актёры не могут быть связаны друг с другом (за исключением отношений обобщения/наследования),
прецедент — эллипс с надписью, обозначающий выполняемые системой действия (могут включать возможные варианты), приводящие к наблюдаемым актёрами результатам. Надпись может быть именем или описанием (с точки зрения актёров) того, «что» делает система (а не «как»). Имя прецедента связано с непрерываемым (атомарным) сценарием — конкретной последовательностью действий, иллюстрирующей поведение[2]. В ходе сценария актёры обмениваются с системой сообщениями. Сценарий может быть приведён на диаграмме прецедентов в виде UML-комментария. С одним прецедентом может быть связано несколько различных сценариев.