«Что проку в книжке без картинок и без разговоров?» — подумала Аня.

Льюис Кэрролл в переводе Владимира Набокова

1пятница, 25 марта 2011 г.

Скрещиваем сценарии и прототипы интерфейсов

2пятница, 25 марта 2011 г.

Люди не читают

3пятница, 25 марта 2011 г.

Картинки создают впечатление:

• полноты охвата;

• законченности;

• готовности к сдаче в работу;

• продуманности решения в целом;

• пригодности к использованию;

• реализованности «дизайна» (look and feel);

• продуманности текстов;

• единственно возможного решения;

• необходимости спроектированных сервисов и контекстов.

Всё — обман!

4пятница, 25 марта 2011 г.

Кажется, что с картинками можно:

• щупать продукт руками;• верстать;• выдавать программистам «готовую постановку»;

• сравнивать продукт с аналогами;• принимать решения «хорошо/плохо» в целом.

Всё — обман!

5пятница, 25 марта 2011 г.

На самом деле картинки:

• заведомо неполны;

• никогда не закончены;

• требуют доработок графическим дизайнером;

• нуждаются в проработке текстов.

6пятница, 25 марта 2011 г.

Буквам не повезло:

• «много букв», скучно читать;

• нет связи с картинками.

7пятница, 25 марта 2011 г.

Свяжем буквы и картинки

8пятница, 25 марта 2011 г.

Letters first!

9пятница, 25 марта 2011 г.

Ситуация: на телефоне закончились деньги.

Задача: пополнить счёт сотового телефона.

Предусловия: Пользователь — перед Терминалом.

10пятница, 25 марта 2011 г.

[1] Пользователь сообщает Терминалу, что хочет пополнить счёт. [2] Терминал запрашивает у Пользователя номер телефона. [3] Пользователь сообщает Терминалу номер телефона. [4] Терминал удостоверяется, что номер телефона введён корректно и пополнение возможно. [5] Терминал запрашивает у пользователя банкноты для пополнения счёта. [6] Пользователь передаёт Терминалу банкноты. [7] Терминал удостоверяется, что принятые банкноты можно использовать, и пополняет счёт. [8] Терминал сообщает Пользователю об успехе пополнения и предлагает повторить операцию. [9] Пользователь сообщает Терминалу своё решение: повторить операцию (возврат на шаг [5]) или закончить работу.

Осторожно, тьма ошибок!

11пятница, 25 марта 2011 г.

Не учтены технологические ограничения:

[2] Номера телефона недостаточно. Нынешние терминалы не умеют гарантированно определять оператора по номеру телефона.

[5] Терминал может «пережёвывать» банкноты только по одной штуке.

Ошибки. Это нормально.

12пятница, 25 марта 2011 г.

Не учтены бизнес-требования:

[7] Размер комиссии зависит от суммы платежа. Таким образом, пополнение счёта «побанкнотно» воспринимается Пользователем как обман. Необходимо дать возможность пополнять счёт после передачи банкомату всех банкнот.

Ошибки. Это нормально.

13пятница, 25 марта 2011 г.

Не учтены «ограничения среды» (в данном случае — требования

законодательства):[4] Перед получением денег Терминал обязан предупредить Пользователя о размерах комиссии.

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

Ошибки. Это нормально.

14пятница, 25 марта 2011 г.

Не учтены особенности человеческого поведения:

[9] Пользователь в этот момент уже решил задачу. Наивно полагать, что он захочет сообщать Терминалу, что закончил работу.

Ошибки. Это нормально.

15пятница, 25 марта 2011 г.

Не проработаны отклонения от

базового сценария!

Ошибки. Это нормально.

16пятница, 25 марта 2011 г.

[1] Пользователь сообщает Терминалу, что хочет пополнить счёт. [2] Терминал удостоверяется, что пополнение возможно, и запрашивает у Пользователя номер телефона и, если нужно, сотового оператора. [3] Пользователь сообщает Терминалу запрошенные данные. [4] Терминал удостоверяется, что данные введены корректно. [5] Терминал запрашивает у пользователя банкноту для пополнения счёта. [6] Пользователь передаёт Терминалу банкноту. [7] Терминал удостоверяется, что принятую банкноту можно использовать, и сообщает Пользователю размер внесённой в Терминал суммы. [8] Терминал предлагает пользователю выбор: продолжить вносить деньги в Терминал или пополнить счёт. [9] Пользователь делает выбор и либо продолжает вносить деньги в терминал (возврат на шаг [5]), либо распоряжается пополнить счёт (переход на шаг [10]). [10] Терминал пополняет счёт телефона Пользователя, выдаёт чек и сообщает Пользователю об успехе операции.

Так-то лучше?17пятница, 25 марта 2011 г.

Отклонения:[2], [3], [4], [5] Пользователь передумал пополнять счёт. Терминал даёт Пользователю возможность прервать сценарий на этих шагах.

[2] Пополнение невозможно по техническим причинам. Терминал сообщает Пользователю о невозможности операции. Может быть, тогда и не предлагать шаг [1]?

[4] Данные введены некорректно. Терминал сообщает Пользователю об ошибке и повторяет шаг [3].

[6] Пользователь долго ничего не передаёт терминалу. Терминал переходит в режим ожидания.

[7] Банкноту использовать нельзя. Терминал возвращает Пользователю банкноту и повторяет шаг [5].

[9] Пользователь долго не принимает решение. Терминал самостоятельно переходит на шаг [10].

[9] Пользователь передумал пополнять счёт. Интерфейсно решение не поддерживаем!

[10] Техническая ошибка при пополнении. Что делаем?

[11] Невозможно выдать чек (например, нет бумаги). Что делаем?

18пятница, 25 марта 2011 г.

Почему не блок-схемы?

Вы пробовали их читать?А вместе с заказчиком?

19пятница, 25 марта 2011 г.

Зарождение картинок

20пятница, 25 марта 2011 г.

[2] Терминал удостоверяется {*}, что пополнение возможно, и запрашивает {Form, пустая форма} у Пользователя номер телефона и, если нужно, сотового оператора. [3] Пользователь сообщает {Form, ввод данных} Терминалу запрошенные данные. [4] Терминал удостоверяется {Form, проверка данных}, что данные введены корректно.

Каждое действие участников пьесы должно быть поддержано

интерфейсом. Иногда отсутствующим :)

21пятница, 25 марта 2011 г.

Ставим ссылку на прототип после каждого глагола. Каждого!

[2] Терминал удостоверяется {*}, что пополнение возможно, и запрашивает {Form, пустая форма} у Пользователя номер телефона и, если нужно, сотового оператора. [3] Пользователь сообщает {Form, ввод данных} Терминалу запрошенные данные. [4] Терминал удостоверяется {Form, проверка данных}, что данные введены корректно.

22пятница, 25 марта 2011 г.

Принимаем решения:1. Что есть «единица интерфейса»? Обсуждайте с верстальщиками!2. Как называть картинки? Единообразно :)

[2] Терминал удостоверяется {*}, что пополнение возможно, и запрашивает {Form, пустая форма} у Пользователя номер телефона и, если нужно, сотового оператора. [3] Пользователь сообщает {Form, ввод данных} Терминалу запрошенные данные. [4] Терминал удостоверяется {Form, проверка данных}, что данные введены корректно.

23пятница, 25 марта 2011 г.

Переходим к проектированию интерфейса

24пятница, 25 марта 2011 г.

Здравствуй, объектно-навигационная модель.

Нам тебя так не хватало.

25пятница, 25 марта 2011 г.

Form — форма ввода параметров платежа:

1. Пустая форма.

2. Ввод данных:a. мало данных для определения оператора;

b. оператор определён по номеру телефона;

c. оператора надо указать вручную.

3. Проверка данных.

4. Повторный ввод после ошибки.

Вариации26пятница, 25 марта 2011 г.

Модель для FormИнформационные запросы:

• Что мне делать?

• Какой у меня номер телефона?

• Как сюда вводить данные?

• Куда вводить код и номер? Вместе или отдельно?

• Долго ещё?

Действия в контексте:

★ ввести цифры номера;

★ проверить, что всё верно;

★ выбрать своего оператора (если система не поняла сама);

★ «передумать» пополнять счёт;

★ сказать «угу».

27пятница, 25 марта 2011 г.

Зачем нужна объектно-навигационная модель1. Постановка задачи проектировщику

интерфейса — и контроль!

2. Программист: можно/нельзя сделать.

3. Верстальщик: набор данных + ссылки + управление.

4. Копирайтер: как рассказать и объяснить?

5. Тестер: действия делаются, а на запросы есть ответы.

6. Бизнес: обсуждение задач интерфейса, а не рюшечек.

28пятница, 25 марта 2011 г.

Много букв про астральную связь с картинками:

• Сценарии — рамка прототипа, его очень грубая граница. Интерфейс должен поддерживать сценарии «на отлично». Проектировщик, глядя в сценарий, понимает, какие взаимодействия пользователя и системы должны быть отражены в интерфейсе. Соответствие сценариев прототипу — минимальное требование к системе.

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

29пятница, 25 марта 2011 г.

И только теперь начинаем рисовать!

30пятница, 25 марта 2011 г.

Весь прототип интерфейса:

1. Сценарии: что Пользователь делает? Функционал.

2. Модель: что Пользователю может понадобиться? Рюшечки.

3. Прототип: вот так реализуем сценарии и модель.

4. Буквы: ...говорим при этом такие слова.

5. Look and Feel: ...и производим такое впечатление.

31пятница, 25 марта 2011 г.

Инструменты для сбора постановки

• Scrivener

• ScreenSteps

• MS Word

• MS PowerPoint

• Wiki (Confluence, TiddyWiki)

Кросс-ссылки решают всё!

32пятница, 25 марта 2011 г.

Bonus Track

Прототипы нужно комментировать. Буквами. Подробно.

Но это уже совсем другая история.

33пятница, 25 марта 2011 г.

Спасибо за внимание

Ольга Павлова, UsabilityLabolga-pavlova.ru twitter @op

Презентацию вышлю всем желающим по почте — дёргайте.

34пятница, 25 марта 2011 г.