2 июня 2020
Последние несколько лет моё сознание активно занималось личными вопросами, а вот подсознание, очевидно, нашло для себя более интересное занятие: крутило, вертело, пережёвывало и переваривало мой профессиональный опыт... собирало фрагменты мозаики в единую картинку. Так появился этот текст, который буквально выползал из моей головы через руки и фломастер на бумагу последние несколько месяцев. В итоге получилась научная фантастика на тему будней UX-дизайнера.
Сначала я рассказываю о предпосылках к появлению этого концепта, основанных на реальных наблюдениях за своей профессиональной отраслью, потом описываю модель базы знаний UX-дизайнера, пробую систематизировать запросы команды цифрового продукта к ux-дизайнеру и размышляю над примерами использования этой базы знаний с применением методик визуализации информации.
О чём может мечтать ux-дизайнер? Об исследованиях / тестированиях.
Разумеется, нет. Исследования / тестирования — это средство, а не цель. Цель — предлагать команде обоснованные (методологически взвешенные) дизайн-решения. Прекрасно, когда на каждый вопрос команды у ux-дизайнера есть пучок сочных фактов о реальном поведении людей, однозначно определяющий, какое решение следует принять команде. Однако этого часто не хватает. Тем временем, крупные компании, производящие свои цифровые продукты, и агентства, помогающие им делать их лучше, ежедневно собирают и собирают эти данные о пользователях. Так чего же конкретно мне сейчас не хватает?
Во-первых, катастрофически не хватает обмена знаниями, фактами о поведении пользователей будь то крупная корпорация с собственными цифровыми продуктами или юзабилити-агентство. Везде мне встречалась одна и та же картина. К примеру, всего за один год всего один исследователь может провести 900+ сессий интервью с пользователями. Что от них остаётся? Тонны цифровых артефактов, например, отчётов о проведённых мероприятиях, и знания в голове этого исследователя. Исследователь вместе со своей головой в любой момент может оказаться недоступным навсегда. Остаются тонны разнообразных отчётов. Представим ситуацию, что команда пришла к своему (другому) исследователю с задачей, для решения которой нужно больше фактов о поведении людей, например, в заданной ситуации при решении заданной задачи, чем у исследователя есть. Он хочет найти все полезные (для решения поставленной задачи) факты, быстренько обрести все знания, накопленные в его компании, по теме вопроса команды. Представим на минуту, что у него есть чудо-хранилище отчётов с волшебной системой поиска / навигации / фильтрации: легко формулируется запрос на поиск нужных отчётов, полнота и точность результатов поиска близки к 100%. В итоге мы получим стопку полезных отчётов.
Кому хочется изучать эти солидные труды в поисках нужных фактов о поведении людей? Немногим. У кого есть время это делать? Почти ни у кого. При всём огромном уважении к авторам этих отчетов, моим драгоценным коллегам. Функция отчётов как удобного носителя ценной информации уже давно выполнена. По большому счёту, теперь они полезны лишь в образовательных целях.
Другая крайность отчётам: давайте встречаться и рассказывать друг другу об интересных находках. Мне нравится эта идея, но хотела бы я посмотреть, где это прижилось и эффективно работает долгое время.
Вот бы собирать в любой момент всех авторов отчётов и интервьюировать их каждый раз, когда это требуется команде!
В самом начале любая команда владеет малой частью знаний об окружающем мире, в котором их будущий цифровой продукт будет жить и приносить людям пользу и удовлетворение. Этот окружающий мир многомерен, а каждое ux-исследование должно приносить новые (и ценные для команды) факты об объектах этого мира, их параметрах и взаимосвязях между объектами. Исследователь собирает и интерпретирует наблюдения, а затем он должен дополнить картину окружающего мира, доступную для использования любым членом команды в любой момент. Знания об этом мире, о людях и о их реальных жизненных ситуациях должны накапливаться, чтобы команда не была похожа на слепых со слоном из старинной притчи.
Какие наблюдения, полученные исследователями, стоят того, чтобы аккумулировать их? Наблюдения за поведением людей в заданной предметной области вообще, они необходимы, чтобы строить и проверять «гипотезы о проблеме», и наблюдения за соответствием поведения цифрового продукта или его прототипа ожиданиям пользователей, они нужны, чтобы проверять «гипотезы о решении». Два базовых типа гипотез, с которыми работают ux-дизайнеры.
Начнём со второго, наблюдений о поведении продукта. Эти факты важны «здесь и сейчас», с ними сразу поработали, сделали выводы и пошли дальше. Потом они интересны только в образовательных целях.
Теперь про первое, наблюдения за поведением людей. Из этих данных может вырасти тьма следствий: от идеи о совершенно новом продукте или идеи о новом крупном функционале существующего продукта до совершенствования мелких операций в продукте.
Во-вторых, очень не хватает уверенности, что у всех наших исследований максимальный КПД. Особенно это касается крупных компаний с собственными цифровыми продуктами, разветвлёнными, разнородными, с распределёнными командами и прочими «рас...». Из чего складывается эта неуверенность?
Во-первых, при отсутствии добротного обмена знаниями между распределёнными командами одного продукта или между сотрудниками одного и того же крупного агентства высока вероятность того, что собираться будут одни и те же (плюс-минус) данные в разное время и в разных местах компании. Часть исследователей при следующих походах «в поля» будут рыхлить граблями поверхность, а не копать в глубину. Чтобы планомерно рыть котлован во все стороны, необходимо каждое следующее исследование планировать с учётом уже имеющихся знаний.
Во-вторых, не так уж редко бывает, что когда результат исследования на заданную тему нужен уже прямо сейчас (или даже «вчера»), на эту задачу бросаются все силы, которые остались у команды. Интервью с пользователем проводят менеджеры, разработчики, очень юные исследователи и так далее. Насколько развиты у них навыки в этой области? Насколько они умеют в нужный момент расслабиться и погрузиться в мир респондента, копнуть, куда нужно, и извлечь, что нужно, – увидеть картинку в объёме, чтобы задать нужные вопросы? Как часто они практикуют навык активного слушания и намеренно запускают механизм эмпатии, в конце концов?
Нужно, создать комфортную обстановку для респондентов, чтобы они раскрылись, а если исследователь сильно нервничает, бегает взглядом с респондента на свои бумажки и обратно, торопится и, судя по вопросам, недостаточно глубоко вникает в рассказанные истории, то и респондент будет чувствовать себя как минимум неловко. Нужно, чтобы после сессии он ушёл удовлетворённый от процесса и от ощущения собственной значимости – он интересно провёл время, да, ещё и пользу принес другим людям, а если снова пригласят принять участие в исследовании, то согласится, и всем своим близким будет транслировать положительный опыт. Сказанное не отменяет закона «лучше один раз своими глазами увидеть реального пользователя, чем сто раз услышать о нём от коллеги», всей команде полезно иногда выглядывать в поля, но сами исследования должен проводить тот, кто натренирован, остальные пусть наслаждаются наблюдением или сразу результатом.
Если у вас в команде так не бывает, вы –– молодцы.
Что касается скорости проведения юзабилити-мероприятий. Представим ненадолго, что существует такая технология: тысяча специально отобранных респондентов по команде (например, приходит им напоминание в мобильном приложении), где бы они не находились, надевают специальный шлем и сидят так пару минут спокойно, потом снимают шлем и возвращаются к своим привычным делам. За эти пару минут шлем стимулирует специальными электрическими токами кору головного мозга респондента, вызывая у них всякие ментальные реакции на заданную тему, и считывает электромагнитное излучение. В результате всего за пару часов исследователь получает цветные мультики с воспоминаниями и рассуждениями респондентов от первого лица, причём все данные уже автоматически проанализированы, и есть возможность сразу обратиться с списку искомых фактов. Быстро? Да, очень. Пусть эта технология будет массово доступной и дешёвой. Тогда, кажется, никаких знаний о мире пользователей хранить у себя не надо, можно в любой момент снова спросить / переспросить, никого тренировать проводить юзабилити-мероприятия тоже не надо...
Однако разве не хочется каждый следующий раз прощупывать новые фрагменты ментальных картин у людей? Строить новые гипотезы на уже накопленных данных, а затем исследовать, чтобы их проверить? А смотреть за динамикой изменения поведения людей (за трансформацией наших знаний о «персонажах» и составе их деятельностей), чтобы строить прогнозы про будущие изменения в потребностях людей? Чтобы первым предложить им такой цифровой продукт, о котором они могли только мечтать? Опять получился мостик к базе знаний.
Отсюда легко вытекает «в-третьих», обычно мы начинаем собирать данные (приглашаем респондентов), когда конкретная тема для исследования уже есть, а появлению этой темы никакая программная интеллектуальная система не способствует. Я имею в виду, что нет базы знаний о мире пользователей, которая поддерживает деятельность по генерации новых идей. Нет какого-то навигатора по пространству потенциальных проблем у пользователей и их потенциальных решений, который сигнализировал бы о том, на что стоит обратить вниманием в ближайшем будущем в первую очередь, делал бы какие-нибудь полезные прогнозы на основе данных, сообщал бы о тенденциях и неожиданностях / отклонения в данных, сообщал бы интересные факты о динамике развития потребностей и способностей людей, вовлечённых в интересующую нас деятельность, обнаруживал бы появление новых корреляций между объектами и их параметрами и прочие любопытные результаты автоматического анализа накопленных данных о поведении реальных людей.
В-третьих, не хватает бережного отношения к главному ресурсу исследования – респондентам. Мало того, что это хлопотное и материально затратное дело – регулярно получать доступ к правильным респондентам, так ещё и растёт понемногу в нашем обществе усталость от назойливых предложений пройти опрос. Особенно в крупных городах. Это ещё один аргумент в пользу «зачем спрашивать то, что кому-то в другом подразделении уже известно / в прошлых проектах выяснили?!», берегите время и внимание хороших респондентов.
В-четвёртых, катастрофически не хватает автоматической взаимосвязи между данными, полученными качественными методами, и статистическими данными, собирающимися автоматически каждый день и круглые сутки. Мы «сидим» на гигантских базах данных о клиентах бизнеса, которому помогает наш цифровой продукт, а как этими данными эффективно пользоваться ux-дизайнеру далеко не всегда очевидно. Сиюминутные запросы к базе знаний о том, как часто клиенты выполняют операцию Х и сколько таких клиентов у нас сейчас есть, полезны, но целую картину мира не дополняют, потому что редко где-то фиксируются.
Вот, если бы данные от всех качественных и количественных юзабилити-мероприятий с участием респондентов, а также данных из множества других источников стекали бы в единую базу знаний о людях и их деятельностях. Представьте себе два непрерывных и параллельных потока данных:
1. «Оперативный» поток данных. Проводим юзабилити-мероприятия для решения текущих задач. Проверяем различные «гипотезы о решении» (тестируем прототипы / действующий функционал), реже проверяем «гипотезы о проблеме» (например, «такие-то люди испытывают трудности при решении такой-то задачи в таких-то условиях»), ещё реже собираем данные для формулировки новых «гипотез о проблеме» (щупаем окружающий мир вокруг одной конкретной фичи, поиск новых фактов «в глубину» в чётко заданном направлении).
В результате в базу знаний исследователя попадают новые сведения о жизни людей и их поведении, способные обогатить знание команды о мире пользователей, если, разумеется, такие удалось обнаружить, а также данные об оценке интерфейсного решения команды, если это решение того стоит.
2. «Идеологический» поток данных. Проводим юзабилити-мероприятия для решения будущих задач. Собираем данные для формулировки новых «гипотез о проблеме» (щупаем окружающий мир в любых направлениях, которые вызывают у команды интерес, «в ширину», «в глубину», как угодно), проверяем «гипотезы о проблеме» (такая проблема есть, и её нужно решать).
Мониторим окружающую среду нашего цифрового продукта: что ещё мы не знаем о деятельности людей, в которой наш цифровой продукт является основным инструментом для решения задач; что ещё мы не знаем о родственных деятельностях (или как-то иначе связанных с нашей); как все они меняются со временем; насколько всё ещё актуально наше представление о жизни пользователей и так далее. Особенно, если мы хотим не только догонять – удовлетворять всем известные потребности, но и держать руку на пульсе общества – обнаруживать первыми такие новые обстоятельства, которые порождают новые потребности, и первыми их удовлетворять посредством цифрового продукта, а, может, даже самим формировать новые потребности в новых обстоятельствах.
В результате в базу знаний исследователя попадают новые вкусные и полезные факты. В любой момент проектирования или разработки к ним можно обратиться.
Эти потоки непрерывно льются из таких типовых источников как:
1. Качественные и количественные модерируемые исследования (силами своей команды или нанятой команды из агентства).
2. Качественные немодерируемые исследования, например, dscout и его аналоги, и количественные немодерируемые исследования.
3. Системы сбора статистических данных о сессиях использовании функционала цифрового продукта пользователями.
4. Внутренние базы данных о клиентах и их взаимодействии с бизнес-продуктами.
И все они сливаются в единую базу знаний о реальном мире, окружающем наш цифровой продукт! Там они очищаются, кристаллизуются и фиксируются на нужных местах.
Как это всё могло бы работать, если помечтать?
Как изменилась бы жизнь ux-дизайнера с появлением такого инструмента?
Любой цифровой продукт «живёт» в рамках определённой деятельности человека (или в рамках набора определенных деятельностей людей как, например, в случае с «суперприложением»). Некоторые продукты способны сами формировать новую для людей деятельность, в любом случае вне деятельности продукт не «живёт». В начале всего стоит деятельность человека. Цифровой продукт – это просто инструмент для достижения поставленных человеком целей (утилитарных, эстетических, развлекательных и других).
Чтобы органично вписать свой цифровой продукт в жизнь людей, потребуется вжиться в каждую жизненную ситуацию, почувствовать себя «в шкуре» персонажа, чтобы объёмно увидеть и осознать контекст использования продукта и скрытые потребности человека в этой ситуации, увидеть в красках как это всё на самом деле происходит.
Для этих целей лучшего способа записи, чем истории, рассказанные людьми, не придумаешь. Вся деятельность для ux-дизайнера – это множество историй о жизненных ситуациях, в которых люди, которые увлечены или вынуждены заниматься некоторой деятельностью, решали те или иные задачи из этой деятельности. В эти истории мы добавляем диалоги с цифровым продуктом и получаем новые истории.
Итак, история — это повествование о том, как конкретный человек решает конкретную задачу (в рамках конкретного вида деятельности) при конкретных условиях (обстоятельствах).
Допустим, мы имеем постоянный поток наблюдений за людьми (текущими и потенциальными пользователями нашего продукта). Тогда эти наблюдения преобразовываются в сущности базы знаний о пользователях. Например, если сгруппировать все наблюдения за этой деятельностью по особенностям поведения людей, то получим группы людей с одинаковым поведением, где яркий представитель каждой группы — персонаж в нашей базе знаний.
Интересно, для разных видов деятельности получатся разные разбиения наблюдений? В общем случае, полагаю, разные. Тогда допустим, что есть сильная корреляция между деятельностями. Люди склонные к виду деятельности А, обычно слабо вовлечены в деятельность Б.и тому подобное. Предположим, что нам удастся сделать «суперразбиение» наблюдений так, чтобы получить «суперперсонажи» – группы людей со схожими образами жизни и мысли. Эти «суперперсонажи» и будут использоваться в гипотетической базе знаний, для краткости дальше они будут называться просто персонажами.
В терминах базы знаний определение истории можно уточнить так:
История (S) — это рассказ о том, как конкретный персонаж (P) решает конкретную задачу (T) при конкретных условиях (С) в рамках деятельности (А).
Итак, центр моей вселенной данных — множество историй S, каждый элемент которого имеет следующие параметры: сниппет (краткий текст) и частота, с которой эта история встречается у персонажа из истории.
История описывает фрагмент одной из множества видов человеческой деятельности А.
Каждая деятельность из множества А имеет следующие параметры:
– название этой деятельности,
– множество всех деревьев задач этой деятельности,
– комментарий к этой деятельности.
Здесь деятельность понимается в том смысле, в каком предлагается теорией деятельности (точнее деятельностным подходом) Леонтьева А. Н. – концептуальным фреймворком, выросший из русской социокультурной традиции в психологии. Базовым концептом является понятие «деятельности», которая понимается как целенаправленное, трансформирующее и развивающее взаимодействие между действующими лицами («субъектами») и миром («предметами») [2]. Основные предположения теории – предположения о социальной природе человеческого разума и неразделимости человеческого разума и деятельности. Главные отличия деятельности от других форм взаимодействия с окружающим миром: во-первых, субъект деятельности имеет потребности, для удовлетворения которых он вынужден предпринимать какие-то действия и взаимодействовать с миром, во-вторых, деятельности и их субъекты взаимно определяют друг друга. В ходе деятельности трансформируются как субъекты, так и предметы. Предметы не обязательно должны быть физическими объектами, это могут быть любые объекты из нашего «вымышленного» мира, о которых все договорились, что они существуют, например, такие неосязаемые как грамматическая структура языка (деятельность – «изучение нового языка») или рентабельность компании (деятельность – «создание прибыльной компании»). Предметы мотивируют и направляют деятельности, деятельности скоординированы вокруг них и в них кристаллизуются.
Человеческая деятельность, согласно теории деятельности, – это единицы жизни, которые организованы в три иерархических слоя.
Иерархическая структура деятельности [2]
Верхний слой – это сама деятельность А, которая ориентирована на мотив, соответствующий определенной потребности. Мотив – это предмет, обладания которым в конечном счёте должен добиться субъект.
Средний слой – это множество задач (actions) из T, которые являются сознательными процессами, направленными на цели, которые необходимо достичь, чтобы добиться предмета. Цели можно разбить на подцели, подцели и так далее.
Нижний слой – это операции, или низкоуровневые задачи из T, через них реализуются задачи более высоких уровней. Операции – это рутинные процессы, обеспечивающие корректировку решения задачи в текущей ситуации. Они ориентированы на условия, при которых субъект пытается достичь цели. Люди обычно не замечают своих операций. Операции возникают двумя способами. Во-первых, операция может быть результатом постепенного доведения до автоматизма первоначально сознательного действия (например, с течением времени задача по смене полос движения при езде на автомобиле может превратиться в привычную операцию, которая не будет требовать сознательного контроля). Когда такие операции терпят неудачу, они часто снова превращаются в сознательные задачи. Во-вторых, операция может быть результатом «импровизации», спонтанной корректировки задачи на лету (например, в аварийной ситуации водитель может действовать «инстинктивно», не задумываясь).
На практике реализация этих принципов в построении образа деятельности вместе с его деревьями в реальной базе знаний может оказать очень непростой задачей. Выявление конечных мотивов человека или мелкозернистой структуры автоматических операций может оказаться трудным, если не невозможным. Это ограничение трехслойной модели Леонтьева как аналитического инструмента можно преодолеть, если использовать экспансивную стратегию «сначала задачи» [2]. Эта стратегия предполагает начало анализа со слоя задач, который относительно легко поддается качественным методам исследования. В частности, люди обычно знают о своих целях и могут сообщить или выразить их определенным образом. Затем анализ может быть расширен в обе стороны: «вверх» – на цели более высокого уровня и, в конечном счёте, на мотивы, и «вниз» – на подцели и операции. Расширение объема анализа может не охватывать всю структуру рассматриваемой деятельности, но может быть достаточным для выполнения поставленной задачи [2].
Полагаю, что между задачами (подзадачами) также могут быть горизонтальные связи, например такие как предлагает метод иерархического анализа задач: фиксированные последовательности подзадач (сначала эта, потом та), опциональные задачи (могут отсутствовать), задачи с разделением времени (одновременно выполняются), циклы задач и так далее [3].
Итак, в базе знаний вершина любого дерева задач соответствует самой деятельности с её мотивом, имеет следующие параметры:
– вовлечённость деятельностью («сколько места в жизни персонажа занимает эта деятельность (время, мысли, мечты, страхи, финансы и другие факторы)?», некоторый количественный показатель, например «12 из 24»),
– опыт в этой деятельности («насколько сложные задачи из этой деятельности решает, как давно он этим занимается», некоторый количественный показатель),
– ментальная модель этой деятельности у этого персонажа («как относится к этой деятельности, как себе её представляет, зачем ею занимается»).
Под ментальной моделью деятельности или задачи из деятельности человека здесь понимается понятие ментальной модели, данное Аланом Купером [1]. Упрощённая мысленная схема, описывающая взаимодействие с окружающим миром и устройствами, не всегда точно отражающая реальное положение вещей, реальную внутреннюю механику, но достаточную, чтобы в этом мире решать свои задачи и пользоваться устройствами. Каждый персонаж имеет собственную ментальную модель для каждого вида деятельности.
С точки зрения нашей базы знаний некоторая деятельность может отсутствовать у некоторого персонажа только в одном случае: если он о ней вообще никогда не слышал. Во всех остальных случаях у персонажа будет своё дерево задач вне зависимости от их вовлечённости этой деятельностью. В крайнем случае у персонажей, у которых нет ни одной задачи из рассматриваемой деятельности, в дереве будет только один узел – вершина, хранящая знание о ментальной модели деятельности. Что думает об этой деятельности персонаж? Почему она его не интересует?
Каждая ментальная модель деятельности имеет параметры:
– мотив и отношение к деятельности («зачем занимается этой деятельностью, насколько привязан к этой деятельности»),
– «картина мира» для этой деятельности («что вообще думает об этой деятельности, как она устроена в общих чертах»),
– барьеры («что мешает получать удовлетворение от этой деятельности»).
Каждому узлу дерева типа «задача» соответствует задача из множества всех задач T. Каждая задача из этого множества имеет следующие параметры:
– название задачи,
– экспертная модель этой задачи,
– множество вариантов этой задачи, соответствующих одному из персонажей.
Каждый вариант задачи имеет следующие параметры:
– цель задачи («чего хочет добиться персонаж»),
– частота задачи в деятельности этого персонажа,
– важность задачи в деятельности этого персонажа,
– ментальная модель решения этой задачи у этого персонажа,
– опыт решения этой задачи этим персонажем (например, некоторое количественное его выражение).
Легко вычислить значимость каждой задачи как функцию частоты и важности.
Ментальная модель решения задачи персонажем – это цитатник респондентов, принадлежащих к группе людей, образом которой является этот персонаж – множество ключевых фраз, которые передают мысли респондентов об этой задаче, как она устроена, что нужно для её решения, какие есть ожидания о ходе решения задачи и итоговом результате и тому подобное на языке самих респондентов (лексикон персонажа).
В каждой истории действие разворачивается в конкретном контексте – одном из множества контекстов задач С. Каждый контекст из множества С имеет параметры: внешний контекст и внутренний контекст.
Внешний контекст (EC) – это окружающая среда и её параметры, пространство, время, окружающие объекты. Каждый внешний контекст имеет параметры:
– место действия (например, «в офисе на рабочем месте», «дома на диване», «в кафе», «в школе на перемене», «в цехе на заводе», «на пляже», «на привокзальной площади», «за рулём автомобиля» и др.);
– физическая среда: освещённость, шумность, влажность, тряска и тому подобное;
– время и его ограничения: запас времени на задачу, частота прерываний, время суток;
– социальное окружение (например, «совсем один», «с друзьями / семьёй небольшой компанией», «в очереди к банкомату», «в толпе на стадионе», «на приёме у врача», «на совещании с коллегами» и др.);
– устройство –– вид устройства, благодаря которому доступен цифровой продукт (например, часы, наушники, смартфон, планшет, ноутбук, настольный компьютер, умная колонка, автомобильная система для водителя, терминал, постамат и другие);
– канал –– частная технология, благодаря которой в устройстве доступен цифровой продукт (например, для пары «устройство / канал» могут быть такие варинты «смартфон / мобильной приложение» или «смартфон / веб-версия»).
Внутренний контекст (IC) – это внутреннее состояние личности в момент решения задачи, которое будем характеризовать такими параметрами:
– эмоциональное состояние (например, «совершенно спокоен и сосредоточен» , «очень торопится» , «до трясучки боится что-то сделать не так» , «дёрганный и нервный» , «в предвкушении удовольствия», «мысленно в другом месте», «очень уставший физически и психически» и другие);
– «моторика» и её ограничения (например, «одна рука занята», «руки и пальцы испачканы фаршем для котлет», «бежит», «плывёт», «только на ощупь (зрение занято другим делом)» и другие);
– сиюминутный барьер или страх, вызванный предыдущим опытом решения задачи (например, «вечно забываю, куда записал этот код»);
– сиюминутный мотив, вынуждающий преодолеть страх и решить задачу сейчас (например, «скорее уже с этим разделаться и бежать с чистой совестью...”).
Персонажем в каждой истории является один из множества персонажей P. Каждый персонаж из множества P имеет параметры:
– имя;
– социально-демографические признаки (SD);
– психотип (PSY);
– профессиональная среда (PROF);
– финансовое положение (FIN);
– субкультура (CULT);
– ограничения физических возможностей (ACCESSIBILITY);
– комментарий.
Социально-демографические признаки (SD) имеют, например, такие параметры:
– возраст,
– пол,
– семейное положение (количество членов семьи и др.),
– дети (количество детей, возраст детей);
– образование;
– нацинальность.
Психотип (PSY) – один класс из выбранной в вашей команде системы классификации людей по характеру и стилю мышления. Это может быть любая удобная команде схема, хоть четыре типа темперамента в классификации Гиппократа, хоть типология К. Г. Юнга и её производные типологии, хоть что-то выращенное внутри компании. Её предназначение – лучше понимать и прогнозировать поведение людей.
Профессиональная среда (PROF) заметно влияет на ментальные модели разных задач в разных видах деятельности: накладывает отпечаток на лексикон, на видение объектов предметной области и взаимосвязей между ними. Этот параметр является множеством ключевых фраз, характеризующих профессиональную деятельность (например, {«повар в ресторане итальянской кухни», «специализация – пицца»}, {«библиотекарь», «детский досуговый клуб»}).
Финансовое состояние (FIN) определяет не только возможности человека приобретать всё новые и новые товары и услуги, но и личное отношение к окружающей действительности. Его влияние отражается на составе множества деятельностей и ментальных моделях этих деятельностей, на разнообразии внешних контекстов, на опыте решения повседневных задач и в целом на поведение персонажа. Этот параметр является множеством ключевых фраз, характеризующих финансовое состояние.
Субкультура (CULT) здесь понимается в смысле наличия какого-то яркого увлечения, хобби, например, коллекционирование марок, занятие велоспортом, мотоспортом, любители пива, заядлые собачники, владельцы яхт, «помешанные» на работе, «помешанные» на театре, кулинары-любители, фанаты сериалов или компьютерных игр и многие другие. Человек глубоко погружен, проводит много времени в этой среде, изучает материалы, общается с товарищами по увлечению, непосредственно занимается этим увлечением, готовится к этим занятиям и тому подобное. Это всё не может не сказаться на его мировоззрении, а следовательно, и поведении. Этот параметр является множеством ключевых фраз, характеризующих возможную деформацию личности под влиянием некоторого увлечения.
Любые другие описания, позволяющие глубже понять характер и поведенческие особенности персонажа можно в свободном стиле описать в текстовом комментарии.
Если у команды есть уже запущенный цифровой продукт, то истории могут содержать повествование о взаимодействии с этим продуктом в ходе решения задач персонажами. Цифровые продукты, как правило, представлены множеством своих лиц – интерфейсами пользователя, одно лицо – один из множества интерфейсов HCI. Сейчас меня интересуют только такие параметры интерфейса:
– рабочее название;
– платформа / канал;
– версия.
В результате попытки решения любой задачи у людей, как правило, остаётся эмоциональный осадок. Он может быть нейтральным («сделал на автомате и забыл»), а может быть ярко позитивным или негативным. Последний, разумеется, сильнее запоминается. Было бы чудесно, если бы эта информация сохранялась о каждой истории, например, в виде оценки (Е) с параметрами:
– удовлетворённость;
– усилия («насколько трудной в решении оказалась задача в этих условиях», «как много времени пришлось потратить на решение этой задачи в этих условиях»);
– успех («в конце концов, задача решена?»);
– некоторый обобщающий предыдущие количественный критерий.
Точно такая же оценка может собираться отдельно для каждой задачи (из множества T) и показывать, например, оценку своего опыта персонажами целиком по одной задаче (учитывая все истории про эту задачу) или оценку опыта некоторой выборки персонажей по этой одной задаче, а также оценку опыта всех персонажей при решении всех задач (в ходе всех историй) с помощью конкретного лица цифрового продукта – интерфейса (из множества HCI).
МЕСТО ДЛЯ ПРИМЕРА
Какие вопросы меня сейчас не волнуют, или в моей научно-фантастической истории приняты следующие допущения:
1. Вопросы трудоёмкости ввода данных. Пусть всё волшебным образом «парсится» из аудио- и видеозаписей с респондентам при минимальном участии специалиста.
2. Вопросы актуальности данных. Пусть они всегда будут актуальными. Пусть данные непрерывно стекаются из множества разнообразных источников в наше хранилище. Пусть автоматически встраиваются в текущую картину, распределяются по нужным слотам, автоматически дополняются / уточняются значения характеристик объектов модели, корректируются взаимосвязи между объектами модели и прочее. Пусть единственным поводом «дёрнуть» специалиста и привлечь его внимание на появление новых данных в системе будут сигналы о потенциальных «любопытностях», неожиданностях, новых корреляциях, новых исключениях (выбросах), новых экстремумах и тому подобное – о том, что может быть принципиально интересным для будущего развития цифрового продукта.
3. Любые вопросы конкретной программной реализации системы. Пусть это вообще не проблема будет, а простая задача.
Мечтать, так мечтать… то есть с начала хочется увидеть и пощупать идеальный вариант системы. Посмотреть, насколько он хорош. А потом уже решать вопросы типа «что мешает реальной системе быть идеальной».
В первом приближении модель данных для UXR Tool готова. Можно двигаться дальше.
Итак, у нас есть модель данных для гипотетической базы знаний о мире пользователей некоторого цифрового продукта (текущих и потенциальных). Хотелось бы посмотреть сценарии её использования главным персонажем – ux-дизайнером. Для этого нужно представить его профессиональную деятельность и получить список задач (для начала – всех типовых задач).
В зависимости от типа компании (продуктовая компания или агентство), масштаба компании, форматов взаимодействия внутри команды и тому подобному ежедневный список задач ux-дизайнера может заметно различаться. Хорошо бы объединить их в некоторые «смысловые» классы, которые будут передавать суть каждой группы задач, и эти задачи могут решаться одинаковым образом. А что если посмотреть на задачи ux-дизайнера с точки зрения работы всей команды? Обобщить каким-то образом с чем работает вся команда цифрового продукта и выделить классы запросов (вопросов) команды, находящиеся в области компетенции ux-дизайнера…
Что интересует команду больше всего, о чём большинство разговоров? Об идея, о фичах, о технологиях, о пользователях и, разумеется, о KPI цифрового продукта. Интерфейс пользователя не сам по себе живет. Его обсуждают в связи с чем-то, например, в связи с идеей нового функционала или в связи с конкретной фичей продукта, или в связи с возможностями и ограничениями аппаратно-программной платформы (буду называть просто технологии), или в связи с появлением новых данных о пользователях и их реальном мире, или в связи с желанием владельцев продукта увеличить / изменить его KPI.
Теперь представим вот такое пространство, в котором могут жить классы запросов команды к ux-дизайнеру.
Имеем три оси:
1. Ось «Деятельность».
а) Уровень «Мотив деятельности» (Д3):
объектом интереса команды становится одна или несколько как-то связанных деятельностей пользователя целиком, например, когда команда ищет новые возможности для своего вполне успешного цифрового продукта, или команда ищет нишу для совершенно нового продукта.
б) Уровень «Задача» (Д2):
объектом интереса команды становится одна конкретная задача из конкретной деятельности людей, например, команда работает над одной или несколькими фичами, помогающими пользователям в решении этой задачи.
2. Ось «Идея и фичи»:
а) Уровень «Идея не конкретизирована» (ИФ3):
команда находится в самом начале пути, имеет множество идей будущего цифрового продукта (или будущего крупного раздела в уже существующем продукте), но все они ещё обсуждаются, нет единой чётко сформулированной идеи, от которой все были бы в восторге.
б) Уровень «Идея конкретная, список фич не конкретизирован» (ИФ2):
об идее продукта команда договорилась, сформулировала её конкретно и всем понятно, список фич будущего продукта (или будущего крупного раздела в уже существующем продукте) ещё обсуждается, нет определённости ни по составу, ни по приоритетам (последовательности реализации) фич.
в) Уровень «Идея конкретная, фичи конкретные» (ИФ1):
об идее продукта команда давно договорилась, давно сформулировала её конкретно и всем понятно, договорилась о списке фич и порядке их следования в разработке, выбрала конкретные фичи (одну или несколько) и собралась их (или её) реализовывать, или, может, договорились только об одном, что сейчас делаем вот эту конкретную фичу.
3. Ось «Технология» (программно-аппаратная платформа):
а) Уровень «Технология пока любая» (Т3):
команда имеет неограниченные возможности в выборе технологии реализации своего цифрового продукта в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом.
б) Уровень «Технология одна из конкретного списка» (Т2):
команда сузила выбор технологии реализации своего цифрового продукта до узкого списка (в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом).
в) Уровень «Технология конкретная» (Т1):
команда выбрала одну конкретную технологию реализации своего цифрового продукта в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом.
Не исключаю, что на эту диаграмму можно нанести ещё несколько измерений. Например, такой вариант «бизнес-измерения» как «срок» («быстро», «терпимо», «долго»), от него зависит выбор методики исследования / тестирования и формат производимых артефактов. Но здесь мне хочется сосредоточиться на этих трёх измерениях. Они являются принципиальными (с разных точек зрения) для работы ux-дизайнера:
— ось «Деятельность» — это про людей, или в какой заботе нуждаются текущие и/или потенциальные пользователя цифрового продукта;
— ось «Идея и фичи» — это про бизнес, или где команда сейчас находится, в какой ux-заботе нуждается;
— ось «Технология» — это про программно-аппаратную реализацию, или как технически команда пытается решать свои задачи по реализации продукта.
В таком ракурсе эта диаграмма напомнила мне «табуретку Нормана».
Итак, пройдёмся по объектам на диаграмме типа «роза ветров», и для каждого объекта поразмышляем над его ситуацией.
«Роза ветров» и объект типа «Д3-ИФ3-Т3»
Д3. «Деятельность» на уровне «мотива деятельности»: объектом интереса команды становится одна или несколько как-то связанных деятельностей пользователя целиком, например, когда команда ищет новые возможности для своего вполне успешного цифрового продукта, или команда ищет нишу для совершенно нового продукта.
ИФ3. «Идея и фичи» на уровне «идея не конкретизирована»: команда находится в самом начале пути, имеет множество идей будущего цифрового продукта (или будущего крупного раздела в уже существующем продукте), но все они ещё обсуждаются, нет единой чётко сформулированной идеи, от которой все были бы в восторге.
Т3. «Технология» на уровне «технология пока любая»: команда имеет неограниченные возможности в выборе технологии реализации своего цифрового продукта в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом.
Мы хотим сделать новый продукт (или новый крупный раздел в уже существующем продукте), который органично впишется в заданную деятельность людей, а также даст им некоторую суперсилу в решении каких-то задач в рамках этой деятельности. KPI такой-то. Сейчас у нас нет заразительной для всех идеи, готовы рассмотреть любые инсайты о пользователях.
У нас есть ресурс, позволяющий перенести выбор конкретных технологий на более поздний срок, когда ux-дизайнер выполнит свою работу и рекомендует со своей точки зрения, какие способы взаимодействия с продуктом и функции продукта создадут привлекательный опыт. Поэтому технология любая, например: задана программно-аппаратная платформа (например, приложение для iOS), а что внутри «под капотом», какие там технологии — любые программные расширения; либо вообще любая программно-аппаратная платформа, любое устройство или экосистема устройств, которые наиболее органично впишутся в контекст деятельности людей.
Деятельность: «домашнее питание».
В каком цифровом продукте могут нуждаться люди, вовлечённые в заданную деятельность?
Нужно изучить данную деятельность у всех персонажей с целью поиска «жемчужин» — ценных фактов из жизни людей, которые послужат отправными точками для проектирования концепта (идея, ключевые фичи, принципы взаимодействия и др.).
Чтобы максимально расширить пространство продуктового решения, хорошо бы осмотреть заданную деятельность всесторонне, копнуть сначала «в ширину», осмыслить общую картину, выделить её яркие черты: что здесь самое обыденное и самое исключительное, самое характерное и самое редкое, что самое проблемное и самое приятное, какие здесь наблюдаются важные, крупные взаимосвязи. Копнуть «в глубину» мы ещё успеем, когда будем точнее понимать направление, куда следует копать. Сначала стоит изучить ландшафт данной деятельности: кто, почему и насколько занимается этой деятельностью; все «самые» задачи и их истории, все «самые» контексты и их истории, все «самые» истории по остальным параметрам, самые популярные и самые редкие ментальные модели для самых популярных задач и так далее. Везде обращать внимание на «Всё ли здесь прекрасно?” Что мешает истории иметь более счастливый конец?
Скрыты ли в истории неудовлетворённые потребности (полностью или частично)? Или может быть содержатся обстоятельства, потенциально благоприятные для формирования новой потребности в заданной деятельности? Нужно изучить истории, искать проблемы, негативные эмоции, высокие усилия, большое время на задачу, пробелы между подзадачами, нехватку данных в момент решения задач и тому подобное. Покрутить данные с разных углов зрения вокруг выбранной деятельности у всех персонажей. В итоге насобирать множество наблюдений и отобрать ценные («жемчужины»).
Подробнее – см. сценарий одного дня ux-дизайнера в поиске ответа на этот запрос команды в главе «Концепт для случая Д3-ИФ3-Т3».
Множество «жемчужин» — ценные факты из жизни людей, которые послужат отправными точками для проектирования концепта (идея, ключевые фичи, принципы взаимодействия).
Вместе с командой «поворкшопить» над множеством найденных наблюдений, получить множество концептов будущего продукта (нового раздела существующего продукта), взвесить эти концепты сразу со всех точек зрения и скомбинировать итоговый концепт с чётко сформулированной идеей, базовым списком фич и основными технологиями.
«Роза ветров» и объект типа «Д2-ИФ2-Т2»
Д2. «Деятельность» на уровне «задачи»: объектом интереса команды становится одна конкретная задача из конкретной деятельности людей, например, команда работает над одной или несколькими фичами, помогающими пользователям в решении этой задачи.
ИФ2. «Идея и фичи» на уровне «идея конкретная, список фич не конкретизирован»: об идее продукта команда договорилась, сформулировала её конкретно и всем понятно, список фич будущего продукта (или будущего крупного раздела в уже существующем продукте) ещё обсуждается, нет определённости ни по составу, ни по приоритетам (последовательности реализации) фич.
Т2. «Технология» на уровне «технология одна из конкретного списка»: команда сузила выбор технологии реализации своего цифрового продукта до узкого списка (в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом).
Мы сейчас занимаемся списком фич будущего продукта (или будущего крупного раздела в уже существующем продукте), у нас есть идея продукта, но нет определённости ни по составу, ни по приоритетам (последовательности реализации) фич. Дизайн-решения могут применять любую технологию реализации из заданного списка на выбор с целью оптимизировать опыт взаимодействия пользователей с продуктом.
Идея нашего продукта: «Мы хотим сделать инструмент для любителей домашней кухни, который даст им вдохновение для своих повседневных завтраков, обедов, полдников, ужинов и др. и поможет комфортно спланировать на любой срок свои ежедневные приёмы пищи. KPI такой-то.»
Деятельность: «домашнее питание».
Одна задача (объект интереса команды): «повседневная готовка для себя и своей семьи».
Примеры подзадач:
– поиск конкретного рецепта;
– подбор рецептов по некоторым кулинарным параметрам;
– подбор рецептов для разных членов семьи;
– изучение рецептов;
– приготовление найденных рецептов;
– планирование и покупка продуктов питания для желаемых блюд (рецептов);
– демонстрация и/или обсуждение рецептов после их приготовления;
– планирование супов на неделю;
– составление расписания разнообразных блюд на целый день;
– просмотр развлекательно-познавательных материалов на кулинарную тему;
– изучение новых способов приготовления пищи;
– освоение новой кухонной техники;
– обнаружение интересных кулинарных лайфхаков;
– изучение питательных свойств продуктов;
– изучение календаря сезонных продуктов;
– составление собственной кулинарной книги из очень понравившихся рецептов;
– домашнии импровизации;
– сохранение и демонстрация рецептов собственного изобретения;
– и многие другие.
Каким должен быть минимальный набор фич, чтобы продукт стал ценным для его пользователей?Что дальше?
Каким должен быть минимальный набор подзадач (на фичи поделим потом) из всех известных подзадач у задачи «повседневная готовка для себя и своей семьи», чтобы продукт стал ценным для его пользователей? Что дальше?
То есть чтобы продукт органично вписался в данную деятельность людей, и позволил бы им решать данную задачу привлекательным для них способом. Нужно выяснить всё необходимое про деятельность, задачу и что люди сочтут привлекательным способом решения. С помощью базы знаний изучить деятельность всех персонажей вокруг заданной задачи с целью поиска «жемчужин» — ценных фактов из жизни людей, которые послужат отправными точками для дальнейшего проектирования. Изучить – значимые, частые (типовые) и редкие (исключительные) задачи; частые (типовые) и редкие (исключительные) контексты, проблемные и счастливые истории… покрутить с разных углов зрения данные вокруг заданной задачи у всех персонажей. В итоге насобирать множество наблюдений и отобрать ценные («жемчужины»).
Множество «жемчужин» — ценных фактов из жизни людей, которые послужат отправными точками для «воркшопа», сессии совместного проектирования.
Вместе с командой «поворкшопить» над множеством найденных наблюдений, получить множество списков фич, взвесить концепты разных списков сразу со всех точек зрения и и скомбинировать итоговый список. Например, минимальным набором подзадач может быть самая значимая (или самая типовая) задача плюс несколько других, с которыми она находится в горизонтальной зависимости, или несколько наиболее значимых задач вместе с зависимостями.
«Роза ветров» и объект типа «Д1-ИФ1-Т1»
Д1. «Деятельность» на уровне «операции»: объектом интереса команды становятся одна или несколько операций для заданной задачи из заданной деятельности людей, например, команда работает над всем спектром взаимодействия пользователя с цифровым продуктом (включая мелкие детали и микровзаимодействия) при решении конкретной задачи в рамках конкретной деятельности людей..
ИФ1. «Идея и фичи» на уровне «идея конкретная, фичи конкретные»: об идее продукта команда давно договорилась, давно сформулировала её конкретно и всем понятно, договорилась о списке фич и порядке их следования в разработке, выбрала конкретные фичи (одну или несколько) и собралась их (или её) реализовывать, или, может быть, договорились только об одном, что сейчас делаем вот эту конкретную фичу.
Т1. «Технология» на уровне «технология конкретная»: команда выбрала одну конкретную технологию реализации своего цифрового продукта в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом.
Мы сейчас занимаемся фичей F, которая помогает в решении задачи «поиск рецепта в кулинарной книге» в деятельности «домашнее питание», решили создать на 100% гладкий опыт взаимодействия, сейчас спустились до низкоуровневых задач и операций, интересуют операции, связанные с подзадачей «ввод поискового запроса на естественном языке». Любое дизайн-решение только в рамках текущей технической платформы.
Какие автоматизмы здесь могут быть, и что с ними нужно делать?
Какие действия производит человек без сознательного контроля при решении подзадачи «ввод поискового запроса на естественном языке»? Вследствие развития каких навыков какие действия превратились в рутинные? Как различаются эти навыки у разных персонажей?
Например, само написание поисковой фразы – это навык, доведённый до автоматизма у большинства взрослых людей, человек в этот момент думает о другом – о смысле фразы, о том, что он хочет найти, и как это сформулировать. Правда, полагаю, что это верно только для письма на бумаге или для письма в цифровом продукте при благополучном стечении обстоятельств (пальцы точно попадают на «клавиши», встроенный словарь предлагает только то, что нужно и так далее). Часто ли попадают персонажи в такие контексты при решении подзадачи «ввод поискового запроса на естественном языке», когда подобные обстоятельства перестаю быть благополучными? Например, мокрые пальцы и сенсорный экран, очень эмоциональное содержание сообщения, множество слов собственного сочинения, преобладающая рука занята и другие.
Другой пример, это интерфейсные привычки людей, помогающие им с каждым разом всё быстрее решать свои задачи с помощью цифровых продуктов, к которым люди привыкают. С течением времени в процессе взаимодействия какие-то фрагменты диалога человека и цифрового продукта доходят до автоматизма. Пользователи уже не размышляют над тем, что делает «галочка», а думают только над ответом на вопрос «нужна ему эта опция или нет». А вот когда смысл поисковой фразы захочется уточнить с использованием каких-то инструментов «расширенного поиска», например, явно указать область поиска и формат результатов поиска, этот вариант решения задачи окажется в поле внимания сознания или нет? Персонаж с таким же хладнокровием и уверенностью как и в случае «простого поиска», сам не замечая своих действий, совершит все нужные микровзаимодействия с интерфейсом и получит ожидаемый результат? Зависит от конкретного персонажа, от его навыка и опыта.
Здесь придётся обратить внимание на гайдлайны и паттерны платформы производителя устройства, на собственные гайдлайны по разработке своего цифрового продукта, на то как решение этой задачи («поиск рецепта в кулинарной книге») представлено в других цифровых продуктах, на то как решение аналогичных задач («поиск на естественном языке...») представлено в других цифровых продуктах, активно используемых нашими персонажами. Какие привычки взаимодействия будем поддерживать? Или будем формировать совсем другие привычки и зачем? Насколько различаются привычки у разных персонажей? Какие привычки идут на пользу, а какие во вред решению заданной задачи, и их стоит аккуратно заместить новыми и полезными?
Предложение о решениях дизайна взаимодействия (interaction design), основанные на собранных наблюдениях.
«Роза ветров» и объект типа «Д3-ИФ2-Т3»
Д3. «Деятельность» на уровне «мотива деятельности»: объектом интереса команды становится одна или несколько как-то связанных деятельностей пользователя целиком, например, когда команда ищет новые возможности для своего вполне успешного цифрового продукта, или команда ищет нишу для совершенно нового продукта.
ИФ2. «Идея и фичи» на уровне «идея конкретная, список фич не конкретизирован»: об идее продукта команда договорилась, сформулировала её конкретно и всем понятно, список фич будущего продукта (или будущего крупного раздела в уже существующем продукте) ещё обсуждается, нет определённости ни по составу, ни по приоритетам (последовательности реализации) фич.
Т3. «Технология» на уровне «технология пока любая»: команда имеет неограниченные возможности в выборе технологии реализации своего цифрового продукта в целом или некоторой фичи, или некоторых операций (в рамках этой фичи) в ходе взаимодействия с цифровым продуктом.
Продолжение следует...
Черновик готов, чиcтовик в процессе...
Черновик готов, чиcтовик в процессе...
1. Купер А., Рейман Р., Кронин Д. Алан Купер об интерфейсе. Основы проектирования взаимодействия. 2009.
2. Kaptelinin V. Activity Theory: The Encyclopedia of Human-Computer Interaction
3. Dix A., Finlay J. E., Abowd G. D., Beale R. Human-Computer Interaction (3 ed.). Pearson Education. ISBN 9780130461094.