Моделирование пользовательских ожиданий

Minimum Viable Product

Minimum: строгая функциональная диета

Viable: хотим, чтобы выстрелило и зацепило

Product: ответ на неявные ожидания

Плавно вписаться в жизнь пользователей

Что это за жизнь?

Рассказ один, а выводы разные

Выдумывай → Твори → Пробуй

Моделирование

Эстетические предпочтения в дизайне

Цепляют эмоции, а не технологии

Возьмите количеством и разнообразием

Подведите статистику под «нравится/не нравится»

Карточная сортировка

У каждого в голове своя структура

Эксперимент лучше угадайки

Пусть всем будет одинаково удобно-неудобно

Жизненные ситуации

Компьютер — это продвинутый костыль

Расскажите, когда людям неудобно

Пишите интересно, коротко и быстро

Убеждайте себя и других

Сценарии использования

Отклонения важней нормы

Объектно-информационная модель

Просто список вопросов

Надо же проверять работу дизайнера

Компромиссный рейтинг приоритетов

Слушайте тех, кто принимает решения

Пусть спорят друг с другом :)

Как должен работать дизайн?

Мы != наши пользователи

Семантический дифференциал

Эмоциональная кардиограмма

Customer journey

Что человек чувствует,когда работает с системой?

Проектирование

Wireframes или прототипы

Ручка и бумага

POP: бумага + iPhone

Axure: картинки + html

Blueprint: эмуляция мобильного приложения

Быстрая вёрстка ручками

Вовлечение

Мозговой штурм с историями

Бета-тестирование прототипа

Коридорное тестирование

Silverback — guerilla usability

A/B-тестирование

Тепловые карты кликов (взглядов)

Не закрывайте рот!

«Что проку в книжке без картинок и без разговоров?» —

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё — обман!

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

• щупать продукт руками;

• верстать;

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

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

• принимать решения «хорошо/плохо» в целом.

Всё — обман!

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

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

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

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

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

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

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

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

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

Letters first!

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

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

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

[1] Пользователь сообщает Терминалу, что хочет пополнить счёт. [2] Терминал запрашивает у Пользователя номер

телефона. [3] Пользователь сообщает Терминалу номер телефона. [4] Терминал удостоверяется, что номер телефона

введён корректно и пополнение возможно. [5] Терминал запрашивает у пользователя банкноты для пополнения счёта. [6] Пользователь передаёт Терминалу банкноты. [7] Терминал удостоверяется, что принятые банкноты можно использовать,

и пополняет счёт. [8] Терминал сообщает Пользователю об успехе пополнения и предлагает повторить операцию. [9]

Пользователь сообщает Терминалу своё решение: повторить операцию (возврат на шаг [5]) или закончить работу.

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

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

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

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

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

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

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

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

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

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

предупредить Пользователя о размерах комиссии.

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

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

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

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

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

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

базового сценария!Ошибки. Это нормально.

[1] Пользователь сообщает Терминалу, что хочет пополнить счёт. [2] Терминал удостоверяется, что пополнение возможно, и запрашивает у Пользователя

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

данные введены корректно. [5] Терминал запрашивает у пользователя банкноту для пополнения счёта. [6] Пользователь передаёт Терминалу банкноту. [7] Терминал удостоверяется, что принятую банкноту можно

использовать, и сообщает Пользователю размер внесённой в Терминал суммы. [8] Терминал предлагает пользователю выбор: продолжить вносить

деньги в Терминал или пополнить счёт. [9] Пользователь делает выбор и либо продолжает вносить деньги в терминал (возврат на шаг [5]), либо

распоряжается пополнить счёт (переход на шаг [10]). [10] Терминал пополняет счёт телефона Пользователя, выдаёт чек и сообщает Пользователю об успехе

операции.

Так-то лучше?

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

возможность прервать сценарий на этих шагах.

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

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

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

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

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

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

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

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

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

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

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

[2] Терминал удостоверяется {*}, что пополнение возможно, и запрашивает {Form, пустая форма} у

Пользователя номер телефона и, если нужно, сотового оператора. [3] Пользователь сообщает {Form, ввод

данных} Терминалу запрошенные данные. [4] Терминал удостоверяется {Form, проверка данных}, что данные

введены корректно.

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

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

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

Каждого!

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

Принимаем решения: Что есть «единица

интерфейса»? Обсуждайте с верстальщиками!

Как называть картинки? Единообразно :)

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

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

интерфейса

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

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

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

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

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

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

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

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

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

Вариации

Модель для Form• Информационные

запросы:

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

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

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

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

• Долго ещё?

Действия в контексте:ввести цифры номера;проверить, что всё верно;выбрать своего оператора (если система не поняла сама);«передумать» пополнять счёт;сказать «угу».

Зачем нужна объектно-навигационная модель

1. Постановка задачи проектировщику интерфейса — и контроль!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Scrivener

• ScreenSteps

• MS Word

• MS PowerPoint

• Wiki (Confluence, TiddyWiki)

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

Bonus Track

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

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

Спасибо!www.pavlova.ccsobaka@pavlova.cc+7 (812) 640-49-21