Download - Зачем обращать внимание на пользовательские ожидания к интерфейсу и как это делать

1

Концепция и интерфейс: как?

2

twitter @op

3

В чём проблема?Методы выявления сложных для пользователя интерфейсов

4

Сложный интерфейс вызывает сильные эмоции

5

Работает ли страница?

6

Информационные запросы

7

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

8

Схема целевых областей страницы

9

Диван-тест

10

Нарисуйте по памяти

11

Поработайте с iPad'а

12

+25% к шрифту12

13

Почитайте вслух

14

Работает ли сайт?

15

Фиксация целей Пользователя

16

Диалог с системой-«чёрным ящиком»

17

Usability-тестирование

18

Словарь терминов

19

Повторение — мать раздражения

20

Контрольная закупка

21

Типовые ошибки

22

Намёк вместо объяснения22

23

SEO вместо информации

24

Технологии вместо стандартных решений

25

Клавиатура вместо мыши

26

Впечатление вместо результата

27

Телефон вместо сайта

28

Маркетинг вместо продаж

29

Тоже интерфейсыЭлектронная почта, телефон, социальные сети, реклама,...

30

Кто это будет делать?Интерфейсы — битва за право влияния

31

Бизнес, инженеры, пользователи.UX-спецы — представители пользователей.

33

Перекосы влияния?Лишь бы не за счёт отсутствующих!

34

Как ни собирай, всё равно автомат Калашникова получается?

35

Моделируйте пользователей:

• персонажи;• сценарии использования;• usability-тестирование;• мониторинг обращений;• анализ конкурентов.

35

36

Да, они бывают, именно такие люди!

37

Айсберг проектирования интерфейса:

• собственно проектирование;

•«описательное моделирование» интерфейса;•обсуждения и согласования;• моделирование пользователей.

37

38

Это не один айсберг, а целая династия

39

От чего страдают пользователи?

40

Неясно, что и зачем делать в системе

41

Бесчеловечный look&feel

42

Избыток контролов (интерфейсная слепота)

43

Непонятные тексты

44

Патовые ситуации с ошибками

45

...и тьма второстепенных проблем

46

Интерфейсное хамство

47

Игнор и бойкот.Взрыв мозга и эмоций.

48

Не играйте в Станиславских!

49

Будет больно и обидно

49

50

В usability-лаборатории

51

На демонстрации «маркетингу»

52

В блогах пользователей

53

И кошелёк тоже огорчится.Но никогда об этом не узнает.

54

В офисе каждый – носорог.А на Habr'е?

55

Есть люди, которые видят интерфейсное хамство. Верьте им.

56

Партизанские изменения?

57

Партизанской бывает только реализация.Никто никогда не видел партизанского прототипа.

58

Неплохо бы для начала поставить задачу.Письма и размахивания руками — не прототип.

59

«Улучшить» можно только в худшую сторону

60

Не трогайте look&feel, пожалуйста

61

Самовольная правка текстов — преступление

62

У модели интерфейса есть внутренние пользователи.Верстальщик, серверный программист, дизайнер, тестер и техпис.

63

Дискуссия — тоже интерфейс.И пользователям тоже должно быть удобно.

64

Зародыш системы — это модель, а не инструкция

65

Дураку полработы не показывают?Обставляйте ритуалами демонстрацию хрупких изделий.

66

Бесконечные согласования рюшечек — в обмен на информацию

67

Фиксируйте результаты обсуждений.Опять в модели, а не бантиком сбоку.

68

Ваш авторитет для пользователя — ничто.Вы — никто.И вашего босса тоже звать — никак.

69

Основной вопрос: почему так сделано?Плохо: заказчик, тех. ограничения, guidelines, "нет времени".Хорошо: подтверждается моделью пользователей.

70

Не врите!

71

Первая модель убьёт создателя

72

Почему всем так хочется?

73

Выпиливание контролов лобзиком.Чем бы дитя ни тешилось?

74

Интерфейс вырос из функциональной модели системы?Менеджеру: сам дурак, рихтуй в процессе.

75

Прототип («дизайн») не имеет отношения к задаче?Менеджеру: просыпайся, уже все умеют моделировать пользователей.

76

Кто сшил костюм?Когда выходят 100 человек, пользователю жмёт.

Как подойти к задаче?

Обзор способов, подходов в и техник старта

77

У прилавка

78

— Я хочу велосипед. Как у всех.79

— Купи себе ролики и не морочь людям голову.80

— Ааа! Позовите вашего директора!81

— Я директор. Так чего, какие ролики берёшь?82

Супермаркет

83

— Ты хочешь велосипед. Есть вот такой. Новинка.85

— Нет, колёса всё-таки нужны!86

— Может, такой? Хит сезона.87

— …и розовенький.88

— Тогда такой. И дуй уже на улицу, пока солнышко.89

Веломагазин

90

— Примерь-ка этот, подходит?92

— (покатался) Вроде ничего… А как на нём в поход?93

— Рюкзак отдельно купишь. Потом. Если захочешь.94

Где жмёт?

95

Хотят поговорить об этом96

Могут воспринимать только готовый дизайн97

Мечтают пощупать рабочую версию98

Зачем возиться?

99

Хотелка заказчика — объективная реальность100

«Я хочу поговорить об этом!» vs «Мы лучше знаем»101

Групповая психотерапия — 90% времени работы102

Хочешь, чтобы выстрелило — конструируй ружьё103

Кто решит проблему?

104

Чтобы ружьё выстрелило, нужна пьеса105

Картинки включают немножко мозга106

Мыслям тесно, а словам просторно. Или наоборот?107

Что вообще в мире делается?108

Солисты и массовка109

О чём договариваемся на входе?

110

Для кого представление?111

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

Аналоги и конкуренты113

Как?

114

Импровизация115

Живьём116

Верю — не верю117

Что это было?

118

Вовлечение заказчика119

Сбор требований для дизайнеров120

Тим-билдинг, ох ты мамочки121

Что получится?

122

Грубые прототипы123

«Волшебные формулировки»124

Блок-схемы125

Ключевые экраны126

Навык приоритезации127

Готовность работать128

По-ни-ма-ни-е модели результата129

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

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

130

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

131

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

132

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

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

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

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

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

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

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

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

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

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

Всё — обман!

133

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

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

• верстать;

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

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

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

Всё — обман!

134

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

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

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

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

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

135

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

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

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

136

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

137

Letters first!

138

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

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

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

139

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

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

140

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

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

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

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

141

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

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


142

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

законодательства):

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

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


143

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

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


144

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

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

145

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

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

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

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

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

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

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

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

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

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

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

147

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

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

148

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

149

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

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

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

150

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

Каждого!


151

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


152

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

интерфейса

153

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

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

154

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

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

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

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

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

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

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

Вариации155

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

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

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

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

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

•Долго ещё?

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

156

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

— и контроль!

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

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

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

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

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

157

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

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

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

158

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

159

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

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

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

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

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

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

160

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

• Scrivener

• ScreenSteps

• MS Word

• MS PowerPoint

• Wiki (Confluence, TiddyWiki)

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

161

Bonus Track

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

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

162

Спасибо[email protected]+7 (812) 640-49-21

163