Тестировать БП

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

Существуют 3 роли для команды разработчиков:

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

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

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

Как и во всех командах есть роли:

a) ПК

a. моделирует прототип;

b. не дает никакой лишней обратной связи, которую не дает ПК;

b) Помощник

a. Представляет интерфейс и дает пользователю задания;

b. Подталкивает пользователя думать вслух, не помогая ему;

c. Поддерживает дисциплину.

c) Наблюдатель

a. Держит рот на замке, сидит на руках если надо

b. делает записи, если не сидит на руках.

БП прототип помогает найти концептуальную модель нашего интерфейса. Исправить базовые проблемы, проверить понимает ли пользователь метафору:

· Концептуальная модель — понимает ли ее пользователь?

· Функциональность — Делал ли он то, что нужно? Упустил ли что-то?

· Навигация — могут ли пользователи найти решение, понятны ли предварительные условия?

· Терминология — понимают ли надписи пользователи?

· Содержимое экрана — что должно быть на экране и где?

Чего мы не можем понять из БП:

1. Внешний вид: цвет, шрифт, пустоты ит.д.

2. Ощущения: проблемы закона Фиттса

3. Время ответа

Но БП не решает все проблемы usability, потому как мы выяснили, есть проблемы с верностью на вид и на ощущения. Большие ли кнопки, далеко ли они расположены — не расскажет нам БП (потому как не мышкой работаем). Работа человеческого ПК явно отличается от электронного — посему не ясна проблема времени реакции системы.

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

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

Оценка

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

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

Кнопки

Кнопка — инструмент очень важный. Наверняка каждого из Вас довольно сильно раздражали маленькие кнопки, по которым еще нужно умудриться попасть. Такая себе тренировка на снайперские умения, да. Хотя кнопки могут отличаться по размерам и форме, дизайн и форма конкретного типа кнопки должны оставаться постоянными во всем приложении. Стандартные имена и описание функциональности кнопки перечислены в таблице 1.1.

Таблица 1.1 – стандартные имена и описание функциональности кнопок

Имена	Описание
OK	Подтверждает какие-либо изменения и закрывает окно. Confirms any information changed in a window and the window is closed.
Apply	Любые изменения в окне будут применяться и отображаться в окне.
Reset	Сбрасывает любые изменения, которые не были подтверждены.
Cancel	Закрыть окно после того как изменения были подтверждены.
Help	Отображает контекстная справку по пункту или помощь для всего окна.

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

Рисунок 1.2 – Пример кнопки

Кнопка справа. Довольно часто используется в поисковых формах — там ей самое место. Существуют предположения, что если кнопка располагается справа от подлежащего ей поля, то она не должна быть больше самого поля, потому что тогда акцент внимания пользователя будет смещен именно на саму кнопку, и процесс её нажатия, чем на обдумывания правильного поискового запроса, который, собственно, и является целью поиска. Пример приведен на рисунке 1.3.

Рисунок 1.3 – Пример кнопки

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

o Авторизация

Грубо говоря, это «войти на сервис». Т.е. довольно стандартные 2 поля для ввода логина и пароля, и кнопка «Войти». Пример приведен на рисунке 1.4.

Рисунок 1.4 – Пример кнопки

o Регистрация

Регистрация на сайте является явным примером структуры «множество полей + чекбокс + кнопка». Из множества комбинаций стоит выделить всего две.

1) когда поле находится каждый на своей строке, соглашение с правилами на своей, и кнопка соответственно тоже;

2) когда поля группируются по надобности, соглашение с правилами и кнопка на отдельной строке, но вместе.

o Опрос

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

Структур как уже повелось всего две. Подразумеваются адекватные структуры, а не «кнопка голосования над пунктами выбора». Итак, вот они:

· сверху пункты выбора, снизу кнопка;

· только пункты выбора, без кнопки.

Преимущества первой в том, что если человек нечаянно выбрал не тот пункт, опрос не начнет отправлять данные о проголосовавшем. Отправка начинается только после клика на кнопку.

Куда же поместить кнопку под опросом? Оптимальный вариант: на некотором расстоянии от пунктов голосования, но всёже достаточно близко, чтобы можно было понять, что это единое целое. Располагать лучше посредине или с правого края, т.к. нажатие на кнопку переводит на следующий шаг.

o Кнопки очистки

Кнопками очистки не следует баловаться, по меньшей мере, без предупреждения. Нажмешь нечаянно, и будет лень заново кропотливо вводить данные. Но если без кнопки отмены (или очистки) никак не обойтись — делайте её на порядок меньше, чем остальные кнопки, и располагайте на расстоянии от кнопки, которая ведет на следующий шаг. Пример приведен на рисунке 1.5.

Рисунок 1.5 – Пример защиты от «дурака»

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