Юрий Ветров Как показать интерфейс клиенту Так, чтобы не было мучительно больно. - презентация

1 Юрий Ветров Как показать интерфейс клиенту Так, чтобы не было мучительно больно

2 О чем этот рассказ? Почему, даже предлагая хорошее решение, мы часто сталкиваемся с необоснованной критикой? Почему экономия на презентации работ часто выходит боком. Что, как и когда можно показывать клиенту. 2

3 1.Анти-кейс я никогда, никогда, никогда больше не буду отправлять результаты работ по электронной почте 2.Проблемные места неприятное последствие 4.Как решить проблему 5.Что и когда презентовать 6.А может все-таки сэкономим? 3

4 ...в один из типичных рабочих дней, как это принято, отправляю клиенту пачку структурных схем страниц по проекту. 4

5 На утро приходит ответ с парой десятков замечаний и легким недовольством в тоне письма. 5

6 Многие из комментариев противоречивы – где-то не заметили очевидного, где-то не так поняли, где-то поменяли первоначальное мнение, где-то предлагают неуместное решение. 6

7 Спустя пару десятков писем в переписке все, кажется, утвердили. Но красивая изначальная идея уже не так хороша. И хуже того – со следующими страницами эпопея повторяется. 7

8 При этом на живых презентациях всегда было более гладко – есть взаимопонимание, уходят многие вопросы. И даже если само обсуждение сложное – результат есть и он позволяет проекту двигаться вперед. 8

9 В какой-то момент мы поняли, что практику «отправил и ждешь» нужно забыть – все, что может быть понято неправильно, будет понято неправильно. С этого момента при любой возможности стараемся презентовать работы лично. 9

10 10

11 1.Анти-кейс 2.Проблемные места почему так происходит неприятное последствие 4.Как решить проблему 5.Что и когда презентовать 6.А может все-таки сэкономим? 11

12 Почему так происходит? При проектировании интерфейса мы можем решить поставленную задачу несколькими способами. 12

13 Один из этих подходов быстрее и дешевле во внедрении. 13

14 Другой способ позволит сделать максимально эффективными ключевые сценарии использования. 14

15 Третий вариант продаст больше рекламы. 15

16 Проблема в том, что таких требований десятки и все их нужно как-то сочетать в предлагаемом решении. 16

17 И из пространства возможных решений приходится выбирать 1-2 наиболее оптимально подходящих к требованиям. 17

18 Но когда результат отправляется клиенту без особых пояснений, он в пространстве решений часто видит не то что мы. 18

19 И, скорее всего, он уже пишет вам письмо с читающимся между строк вопросом «что за халтуру вы мне прислали?!». 19

20 А значит процесс работы над проектом затягивается до выяснения обстоятельств. И отношения постепенно накаляются… 20

21 1.Анти-кейс 2.Проблемные места неприятное последствие к чему приводит недопонимание 4.Как решить проблему 5.Что и когда презентовать 6.А может все-таки сэкономим? 21

22 К чему кроме испорченных нервов приводит недопонимание? 22

23 Увеличение объема работ за счет незапланированных переделок. А это съедает маржу и отвлекает ресурсы. 23

24 Увеличение издержек на ведение проекта – менеджер тратит больше времени, своего и клиента. 24

25 Увеличение сроков работ – а это ломает планы и клиента, и команды проектирования. 25

26 Ухудшение качества итогового результата – путем нарастающего потока правок красивая изначальная концепция рушится. 26

27 Все это делает проект менее интересным для подрядчика – как в плане прибыли, так и в плане примера для портфолио. 27

28 И, конечно, снижает вероятность повторного обращения со стороны клиента. 28

29 Все это плохо не только для компании- подрядчика – в случае in-house-команды разработчики в следующий раз постараются сделать интерфейс сами, чтобы не сталкиваться с проблемными коллегами. А ваша концепция может сильно пострадать в результате такой самодеятельности. 29

30 Никому не нужна лишняя головная боль, так что проблему лучше решать. Это поможет и текущему проекту, и последующим. 30

31 1.Анти-кейс 2.Проблемные места неприятное последствие 4.Как решить проблему несколько способов предусмотреть сложности 5.Что и когда презентовать 6.А может все-таки сэкономим? 31

32 Наша задача – сделать так, чтобы и мы, и клиент одинаково понимали пространство возможных решений и выбрали из него оптимальный вариант. 32

33 Слышали ли вы от него фразу «Так покажите же нам и плохие варианты»? 33

34 Она о том же – клиент тоже хочет знать, какие еще решения задачи могут быть. 34

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

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

37 Как мы можем «синхронизировать» понимание задачи с клиентом? 37

38 Формировать правильные ожидания в начале работ. 38 Отдельный доклад на тему управления ожиданиям читался на конференции Software People

39 Обучать клиента – хорошо, если он понимает о чем мы говорим. 39

40 Скрывать уровни абстракции – в этом случае тратить времени на обучение клиента нужно будет меньше. 40

41 И главное – регулярно презентовать результаты работ и то, как мы решаем с их помощью поставленную задачу. 41

42 1.Анти-кейс 2.Проблемные места неприятное последствие 4.Как решить проблему 5.Что и когда презентовать десяток способов вовлечь клиента в работу над интерфейсом 6.А может все-таки сэкономим? 42

43 Выбор того что показывать достаточно большой, причем многие из демо- материалов в любом случае готовятся в ходе работ. 43

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

45 Структурные схемы страниц и дизайн-макеты 45

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

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

48 Выбор из пространства решений 48

49 К тому же многие сталкивались с тем, что часть клиентов не мыслит абстрактно и не понимает wireframes. Личная презентация в таком случае чуть ли не единственный способ быть понятым. 49

50 Дизайн? 50 А почему все черно-белое? А что, градиентов и картинок не будет? А почему ширина правой колонки – 205 пикселей? А кто будет это верстать?

51 Еще лучший способ рассказать о решении – показать весь процесс в динамике. 51

52 Идеальный вариант – интерактивный прототип. Во-первых, система уже «работает» – клиент сам может покликать ее, а тому кто видел это своими глазами сложно переоценить достигнутый эффект. 52

53 Во-вторых, можно пройтись по основным процессам, попробовать выполнить типовые задачи, понять насколько удобны конкретные решения на практике. 53

54 Интерактивный прототип 54

55 Еще лучше то, что можно поэкспериментировать с разными решениями задачи и, опять же, сразу пощупать их вживую. 55

56 Версии интерактивного прототипа 56

57 А если прототип будет достаточно проработанным – он включает в себя JavaScript-динамику, имитирует работу с сервером, выполнен в финальном дизайне – клиенту и вовсе не придется мыслить абстрактно. 57

58 Да и сам клиент сможет показать свой будущий продукт коллегам, партнерам и потенциальным клиентам – а это уже начало возврата инвестиций в проектирование. 58

59 С интерактивным прототипом есть только одна проблема – хороший прототип долго создавать и не всегда просто поддерживать. 59

60 Поэтому есть и другие способы показать процесс в динамике. В первую очередь это диаграммы процессов и переходов между страницами. 60

61 Пользовательский сценарий 61

62 Они показывают, как система решает конкретную задачу с помощью страниц интерфейса – например, покупка товара в интернет-магазине или регистрация нового пользователя. 62

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

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

65 Мы выделяем на этих диаграммах основные и второстепенные сценарии работы, показываем точки входа и выхода из процесса, связываем это все с портретами пользователей. 65

66 А если нам известны данные веб-аналитики – можно объединить диаграмму процесса с «воронкой» и наглядно показать, где и сколько пользователей мы теряем. 66

67 Диаграмма + воронка конверсии 67

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

69 Особенно приятно то, когда клиенты просят оставить такие листы ватмана себе – причем случается это достаточно часто. 69

70 Альтернативный способ показа будущего продукта в динамике – заранее подготовленное видео или презентация с проходом по основным сценариям. 70

71 Презентация этапа работ 71

72 Они подходят скорее для случаев, когда лично встретиться нет возможности. Хотя это достаточно скучные вещи (интерактивность у них невысокая), работают они в любом случае лучше простого письма. 72

73 А что делать, если на текущей стадии нет конкретных результатов работ – только данные предварительного исследования или анализа? Это могут быть, например, персонажи, описание сценариев взаимодействия, moodboards. 73

74 Предварительные документы 74

75 Нужно показывать и их тоже – ведь наша задача не только в том чтобы сдать работы в виде пачки структурных схем страниц и дизайн-макетов, но и обеспечить гладкий процесс работы над проектом. Хорошо, когда клиент вовлечен в процесс, понимает куда мы идем и на чем основываем свои решения. 75

76 Обзор процесса работы 76

77 Кроме того, мы можем получить полезные инсайты и комментарии. Ведь документы это не только результат работ, но и приглашение к обсуждению проблемы. Многим проще критиковать, чем предлагать свое и стоит использовать эту особенность на пользу дела. 77

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

79 Кстати, говоря о вовлечении, можно пойти еще дальше – включать клиента в процесс продумывания интерфейса. 79

80 Самый простой способ – рисование скетчей, когда мы вместе рисуем экраны на бумаге, флипчарте или маркерной доске. 80

81 Скетчи интерфейса 81

82 Это позволяет показывать процесс нашей работы, то как мы выбираем оптимальные решения из пространства доступных. 82

83 Работа над скетчами 83

84 Правда, скетчи чересчур абстрактны для многих клиентов и не гарантируют принятие созданных на их основе структурных схем страниц. 84

85 Еще лучший способ оживить рассказ и вовлечь клиента в процесс – сбор интерфейса из готовых компонентов. 85

86 Это может быть построение формы из набора полей на листе бумаги. 86

87 Сбор формы из готовых элементов 87

88 Или попытка собрать страницу из готовых интерфейсных блоков, вырезанных из бумаги. 88

89 Сбор интерфейса из компонентов 89

90 Эти способы вряд ли применимы на всех этапах – требуют от встречи приличного количества времени. Но они здорово помогут вам и клиенту лучше понять друг друга. 90

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

92 1.Анти-кейс 2.Проблемные места неприятное последствие 4.Как решить проблему 5.Что и когда презентовать 6.А может все-таки сэкономим? идеальный способ окружить себя проблемами 92

93 И вот вопрос в том, стоит ли тратить столько времени и сил на разжевывание чего-то каждому клиенту? 93

94 Может все-таки экономить на этом этапе? Тем более, что уже поджимают сроки на других проектах… 94

95 Да и тут, в общем-то, все и так понятно – решения хорошие и проверенные, не хуже чем в целом по отрасли – откуда быть проблемам? 95

96 Мы думали так не раз, на многих проектах. И очень часто повторялась все та же история – недопонимание, бесконечные переделки, цепочка проблем. 96

97 А значит по факту тратилось намного больше времени, чем было сэкономлено. 97

98 Хуже того – мешая другим проектам и заставляя пытаться сэкономить и там. 98

99 Хуже того – мешая другим проектам и заставляя пытаться… Упс, кажется это уже где-то было. 99

100 Тоже не хотите попадать в этот порочный круг? Помните о том, что лучше не экономить на презентациях. 100

101 Спасибо! Юрий Ветров