• Светлая
  • Темная
  • Ночное зрение
Русский

Язык

Палитра

  • Светлая
  • Темная
  • Ночное зрение

Визиты «вслепую» к пользователям на объекты

1 minutes286 просмотров

Как ходить на недоступные объекты для пользовательских исследований, если внезапно возникает возможность

Мостик судна

На днях после долгой паузы я снова побывал на судне для проведения пользовательских интервью и чтобы показать коллеге-дизайнеру, как в жизни используются системы, над которыми мы работаем. Думаю, стоит поделиться моим опытом таких визитов, когда работаешь над сложными системами, а доступ к пользователям и их работе в реальных условиях ограничен — объекты закрыты от посторонних, пользователей немного (не масс-маркет) и они где-то далеко от вас — в море ли на судне, под землей в шахте или за десятью контурами безопасности в центре управления чем-нибудь или в операционной комнате больницы. А ещё пользователи являются квалифицированными специалистами в своих отраслях, существующих куда дольше чем IT (тому же судовождению и лечению людей — тысячи лет) и, соответственно, мыслят совсем другими категориями, чем айти-специалисты и тем более UX-дизайнеры. И вот, внезапно кто-то из ваших коллег говорит вам, после очередного вашего нытья на барьеры отчуждения, что «доступ разрешен» и скоро организуется визит.

Разумеется, ситуаций возникновения визитов может быть много, но здесь я буду концентрироваться именно на таких визитах «вслепую». Я почти не буду трогать процесс исследований — будь то интервью, полевые наблюдения и т.п. Речь будет об «окружении» этого процесса. Хотя, думаю, часть материала пригодится и для более структурированных/целенаправленных случаев.

Как всегда напомню, что всё это не претендует на истину и системность, но в каком-то виде аккумулирует мой опыт.

Общий смысл визитов

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

Я глубоко уверен, что любой специалист, а не только UX-дизайнер, работающий над сложными системами, должен хотя бы раз побывать и поглядеть на них в реальных условиях — будь то программист, менеджер, тестировщик или технический писатель. Во-первых, это помогает с мотивацией — такие визиты часто показывают, нафига вы вообще тратите 8 часов в день своей жизни. Во-вторых, это убивает упомянутые барьеры отчуждения — мы часто страдаем системоцентричностью (именно из-за того что тратим 8 часов в день на систему), знаем всё от и до (или думем что знаем), но реальная жизнь, разумеется, отличается от наших представлений.

Если же говорить о UX, то сферический опыт идеальных процессов проектирования и сбора сведений в вакууме бывает крайне редко — скорее на словах преподавателей курсов, чем в реальности со спёртым воздухом, и полноценная работа с пользователями — скорее привилегия, чем норма, особенно в сложных профессиональных контекстах, где дистанция между UX-проектировщиками и конечными пользователями огромная. И возможность навестить объект с пользователями даже без ясных целей — это важный шаг вперед, чтобы получить и пользу о продуктах и контексте применениях, и наладить отношения с пользователями-экспертами, которые потом можно использовать куда более сфокусировано. А если вам ещё позволят делать фотографии и видео, то эти материалы вы будете использовать годами, поверьте мне, в том числе в спорах с менеджерами и разработчиками.

Цели визитов и управление ожиданиями

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

  • Узнать как используется продукт в реальных условиях
  • Ознакомиться с контекстом использования
  • Наладить отношения с пользователями для последующих подробных исследований и обмена идеями (это отдельная тема, и мы тут её не трогаем)
  • Разумеется, изучить конкретные вопросы, не дающие покоя — как используется существующая функциональность А, показать концепции и прототипы будущей функциональности Б и получить обратную связь
  • Обучить и промотивировать коллег, чтобы у них тоже болела душа за пользователя, а не только думали о премиях и отпуске (это помогает)

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

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

Контекст объектов

Перейдём к деталям, начнем с обсуждения контекста объектов — что обычно нас ожидает и к чему нужно быть готовым.

Объекты в большинстве закрыты от случайных людей, просто туда не попасть — это примерно как пассажира самолёта пустить в кокпит к пилоту во время полёта. Чем это заканчивается, например в сентябре, вы знаете. Поэтому чтобы туда попасть, нужно организовывать и согласовывать визит. И делать будете это скорее всего не вы (раз это первый визит на объект), а кто-то из продажников, менеджеров проекта или, в лучшем случае, аналитиков-экспертов. И обсуждать это они будут скорее всего не с конечными пользователями, а с их руководством, даже руководством руководства, которое в большинстве случаев далеко от пользовательских исследований, дизайна и т.п. Разумеется, там могут быть совершенно свои, сложные взаимоотношения с кучей политики.

Как следствие, любые ваши подробные пожелания о темах и т.п. могут быть просто потеряны в цепочке коммуникации или, хуже, искажены. Например, вам могут устроить экскурсию по судну, нечто в духе «показать детям чем их папы занимаются», но на мостик и к реальным пользователям не пустят. Стоит отметить, что названия ваших должностей — «дизайнер» или «UX-дизайнер» — в случаях подобных контекстов могут мешать, а не помогать, поскольку для большинства людей это какая-то несерьезная деятельность, just cosmetics — «мы тут атомной электростанцией управляем, а ща какие-то хипстеры придут» — а смысл названия своей роли вы вероятно не сможете объяснить напрямую. Поэтому можно спокойно просить ваших менеджеров и руководителей позиционировать во время согласования вас как продуктовых экспертов, аналитиков, эргономистов и так далее (в принципе это так и должно быть, см. часть ниже «Вы»), но в любом случае стоит подчеркивать продуктовую цель — получение обратной связи для улучшения продукта. «Побеседовать с пользователями» будет не понятно.

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

А если откажут — ну, пробуйте с другим объектом, причин может быть много, от натянутых отношений между клиентом и разработкой (причём даже ваши протеже могут быть не в курсе) до геополитики. Но, повторюсь, возможно, где-то была недооценена причина визита, что вероятнее, если разговор уже дошёл до согласования, и лица на встречающей стороне не поняли смысла всего этого отвлечения людей от важных дел. Как-то один итальянский менеджер рассказывал за вином про какие-то трудные переговоры, и там один из участников, перед тем как отказать в сделке, сказал: «если ты не можешь ясно объяснить, чем ты занимаешься, тебе нехрен делать в бизнесе». Тут примерно так же.

Ну ладно, поговорим о других особенностях. Кроме согласований и закрытости, объекты могут сильно отличаться от обычных офисных или домашних условий. Судно, если это не круизный лайнер, может болтать так, что с непривычки вы будете блевать или вылетать из кровати, если вам повезет попасть в длинный многодневный переход (один сервисный инженер рассказывал, как его выбрасывало несколько раз за ночь). В операционной могут быть стерильные условия и вас попросят переодеться. Вы можете оказаться на объекте глубокой ночью и всё что вы сможете зафиксировать — ноги операторов на приборных панелях и вы будете несколько часов откровенно скучать где-то в углу. А может на объекте в принципе всегда достаточно темно, пыльно и грязно — и это тоже будет влиять на ваш опыт присутствия и изучения. А ещё у вас может не оказаться доступа к розеткам чтобы заряжать технику. На вас могут очень нервно смотреть, если вы будете подходить к панелям и разглядывать их.

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

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

Пользователи

Обобщать не хорошо — все пользователи разные. Но из различных визитов складывается некоторая общая картина, которая с вариациями применима к пользователям, работающим на описываемых объектах. Не столько о профессиональных и личных качествах, сколько о том, как контекст влияет на них и взаимодействие с вами при визите.

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

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

Дело в том, что профсистемы часто автоматизируют какой-то фрагмент деятельности, и весь контекст знаний, условий, прочих систем, стоящих рядом, не являются предметом этой системы, не отражены в ней явно, но при этом существенно влияют на неё. Судовой радар для предотвращения столкновений судов сам по себе сложен, но это важный «молоток», а не набор всех инструментов «мастерской» по управлению движением судном. То же можно сказать про аппарат УЗИ, видеостену ситуационного центра и так далее.

И поэтому, если при общении с вами у него возникнет ощущение, что вы не разбираетесь в общем контексте, не понимаете каких-то фундаментальных принципов деятельности и предметной области, путаете термины или, хуже, аббревиатуры (видел, как дизайнеры путали COG и SOG — курс и скорость относительно грунта), он очень быстро захлопнется и потеряет интерес к беседе с вами.

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

И тут, конечно, перейдем к контексту — пользователя вы встречаете на работе, он занят или только освободился после смены и собирается на отдых/обед — или готовится к смене. Тут к нему приходит кто-то, отвлекает от обычного распорядка дня, о ком он понятия, как правило, не имел до этого (см параграфы выше про согласования и «хипстеров»), задаёт глупые на его взгляд вопросы и не понимает ответов. Ему надо с вами общаться? Нет.

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

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

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

Иногда же контакт не получается по другим причинам. Например, оператор боится показать, что он недостаточно знаком с продуктом (все мы знаем, что пользователи часто имеют тенденцию ругать себя, а не систему, даже не показывая этого внешне), стыдиться этого. Иногда оператор страдает нарциссизмом. Иногда оператор ненавидит систему и, разумеется, тех кто её сделал такой отвратительной. Чем лучше вы управляете контактом, тем, возможно, чаще он будет материться, показывая обсуждаемые сценарии. В общем, причин много, что-то можно устранить во время беседы, но бывает что и нет. Нужно быть гибким.

В один из визитов я сделал ошибку — на радостях, что я на борту (понятно, что при всей рациональности есть и куча эмоций от редких визитов), я забыл уточнить пару вопросов, операторы были открыты, мы начали активно обсуждать кучу тем и вокруг продукта, и в нем самом, но относительно быстро беседа начала «плыть». Тут до меня дошло и я уточняю — а вы с вахты или перед вахтой? Оказалось, что операторы за час до беседы пришвартовали эту 15-этажную и двухсотметровую коробку, переводили системы в режим стоянки, писали отчёты, а до этого отстояли ночную вахту и уже собирались на покой, а тут прибегает какой-то долговязый чувак и начинает их грузить всякими концептуальными вопросами. Я попросил ещё немного времени, но стало ясно, что пора закругляться, и скоро мы уже пошли на обед.

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

Вы

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

Постараюсь не повторять упомянутые ранее моменты, кроме одного, самого главного — при визитах нужно быть не ролью (UX-дизайнером), а человеком, широким экспертом, разбираться и в продукте, и в предметной области. Изучите продукт, пройдите те же курсы о нём, что проходят пользователи. Если не хватает опыта — берите того, кто продукт знает (старшего товарища, эксперта-аналитика или того, кто работал в отрасли до того, как уйти в это ваше IT). Это сильно поможет. Когда-то ровно также меня водил за ручку мой коллега и объяснял что есть что и на что обращать внимание. Пык-мык.

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

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

Опять же, операторы довольно часто задают вопросы по продукту, и если вы ему на месте поможете что-то настроить, показать, помочь — это верный способ наладить контакт и дальше получать честные ответы. Я регулярно сталкивался с этим и честно записывал проблемы, доносил до разработчиков (если баги) и злился, если не получилось решить.

Смешно, но пару лет назад, уже давно не занимаясь одним видом систем и работая в совсем другой компании, я оказался в процессе яхтенного трипа на шведском острове и, проходя по пути в магазин мимо спасательного судна в марине, увидел за окном знакомые интерфейсы. На обратном пути я заметил выходящего из судна человека и спросил его — «о, вы все еще используете эту систему?». Слово за слово, и вот я сижу на лодке и отвечаю на вопросы нескольких навигаторов (там был какой-то тренинг как раз молодого поколения), как прокладывать маршруты и что-то ещё. Даже, попрощавшись, забыл там пакет с продуктами. Было кайфово.

Говоря о вежливости, не стоит забывать и о банальных правилах этикета. Попросить разрешения на фотосъемку и запись видео/аудио. Если вам предложили кофе — не ходить с кружкой над панелями, а лучше вообще держать руки за спиной, разглядывая что-нибудь, дабы не заставлять нервничать, что вы что-то не то нажмёте или сломаете. Закончив, спросить куда посавить кружку и может даже помыть. Да, уточните сколько времени у вас есть, не стоит ли сделать перерыв. Мелочи важны.

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

И последний момент — бывает, что вы сделали все дела, а объект покинуть вы не можете, или у вас есть несколько свободных часов ожидания. Например, судно прибудет на следующий день, или вас заберут/выведут только когда закончится смена, или сейчас пересменка/обед. Лучше на всякий случай уточнить заранее, что вам можно делать, а что нельзя. Например, на одном из пассажирских судов я был официально членом экипажа на момент визита, соответственно я должен был подчиняться правилам для всех сотрудников — например, мне было запрещено ходить в магазины для пассажиров, никакого дьюти-фри, а питание только в столовой для экипажа (зато там был самый вкусный хлеб в моей жизни). В другой раз на одном из «земных» объектов мне провели довольно интересную экскурсию, в том числе я побывал наверху антенной вышки на огромной высоте. А в третий, после окончания испытаний, меня довезли на катере в центр одного из городков прямо к причалу гостиницы. Бывало всякое, и если у вас выстроился «коннект», вполне можно перед завершением дел спросить «а не проведете экскурсию» — кто знает, вдруг и не откажут.

* * *

Фуф. Вижу что получилось много букв, но, надеюсь, из этого что-то аукнется. А если есть вопросы (уверен, что тут много не раскрыто), спрашивайте в телеграм-канале.