Привет! Мы нашли очень крутую статью Designing Digital Products with Mental Models в блоге коллег из США, перевели ее и публикуем здесь. Автор статьи — дизайнер Тим Шеинер. Рекомендуем ее к прочтению всем, кто имеет отношение к разработке цифровых продуктов.
Лучший способ добиться взаимопонимания в проектной команде.
Перевод — это сложно
Когда-то, путешествуя по Индии, я купил недорогую книжку — «Преступление и наказание» Достоевского на английском. Я предвкушал, как с наслаждением прочту этот шедевр, но в итоге одолел его с большим трудом. Вместо восторга я испытывал недоумение: почему им так восхищаются? Как выяснилось позднее, текст, который я читал, был далек от первоисточника. Я узнал об этом, лишь добравшись до Бангкока, где попытался продать прочитанную книгу букинисту. Тот заявил, что ему она не нужна, поскольку перевод ужасен.
Этот случай говорит о том, что перевод — задача непростая. Его не только трудно сделать хорошо — определить, что он сделан плохо, может лишь эксперт. При разработке цифровых продуктов, которые автоматизируют операции, выполняемые человеком, вам приходится заниматься переводом в самом сложном варианте. Во-первых, вы должны перевести аналоговые итоги наблюдений за работой человека в цифровую форму, которую может интерпретировать компьютер. Во-вторых, нужно описать аналого-цифровые преобразования такими словами, которые означают одно и то же для инженеров, дизайнеров и продукт-менеджеров в вашей команде, а все они используют разную терминологию для формулировки идей. История с Достоевским показывает, что сохранить смысл даже при переводе на один уровень не так-то просто, а при разработке цифровых продуктов таких уровней два.
Решение — строим модели вместе
Мой подход к трудностям перевода при разработке цифровых продуктов состоит в том, чтобы первым делом свести к минимуму объем информации, которую нужно переводить. Для этого в самом начале члены команды должны вместе сконструировать пять ментальных моделей.
- Модель пользователя: для кого это?
- Модель ценности: почему это полезно?
- Модель взаимодействия: как это использовать?
- Модель объекта: как это устроено?
- Модель данных: как управлять состоянием этого?
Эту схему я называю «Цифровой машиной» и представляю ее так:
Эти пять моделей всегда существуют в виде неосознанных допущений в головах участников проекта. Такие допущения — основной источник неразберихи, поэтому предложенная схема помогает людям найти общий язык и эффективно обмениваться информацией, обсуждая представления, сложившиеся у них в голове.
Мой подход работает, потому что софт — это действительно цифровая машина.
Хотя она состоит из битов, а не из болтов и воплощена в коде, а не изготовлена из стали, ощущения от ее использования (то есть юзабилити) — во всяком случае, когда все продумано как следует — проистекают из того же источника, что и у любой машины: взаимоотношений оператора с устройством, где несложные вводные преобразуются в полезные результаты для решения значимых задач.
Проводя аналогию с машиной при разработке цифрового продукта, мы можем опираться на ту же визуальную и пространственную логику, что применима к физическим объектам.
Это означает, что, хотя увидеть или потрогать внутреннее устройство цифрового продукта невозможно, проводя аналогию с машиной при его разработке, мы можем опираться на ту же визуальную и пространственную логику, что применима к физическим объектам. А поскольку пространственное и образное — способности невербальные, такие модели, построенные совместно, легко воспринимаются участниками с разными взглядами.
Теперь, когда мы уяснили, для чего нужна схема «Цифровая машина», давайте остановимся на каждой модели подробнее.
Модель пользователя
Модель пользователя описывает того, кто использует цифровую машину. Это модель человеческого поведения — она определяет цели, действия и эмоции. Для любого проекта это вымышленный персонаж с определенными характеристиками:
Томас похож на реального человека, но таковым не является. Вы воспринимаете героев популярного телешоу как живых людей, но на самом деле это всего лишь актеры, которые играют свои роли. Для команды разработчиков вымышленный пользователь — это конкретная личность: все знают его в лицо и по имени, разве что в совещаниях он не участвует. Фокус в том, что, когда вы используете фото и имя, модель оживает и делает свое дело благодаря естественной склонности людей к эмпатии.
Именно эмпатия помогает нам достаточно точно прогнозировать поведение других людей, чтобы общаться и работать с себе подобными. К примеру, если сегодня мы с вами договорились, что любимый цвет Томаса — оранжевый, само собой, завтра это тоже будет оранжевый. Продолжая обсуждать Томаса, мы придем к единому пониманию его предпочтений и потребностей: не только какой цвет ему нравится, но и что он ждет от цифровой машины, которую мы для него разрабатываем. Это единое понимание становится критерием, который мы используем — часто бессознательно, — чтобы определить ценность добавления или удаления тех или иных функций.
Модель ценности
У цифрового продукта — как и у человека — есть лишь один шанс произвести хорошее первое впечатление. Модель ценности определяет, каким должно быть это впечатление с вашей точки зрения.
Она говорит пользователю:
- Что это за продукт?
- За счет чего он сделает мою жизнь проще (интереснее, эффективнее и т. д.)?
- Почему я должен купить/предпочесть/использовать именно этот продукт, что в нем особенного?
Первый вопрос — что это за продукт? — служит для пользователя фильтром самого высокого уровня. Томас — человек занятой, поэтому он очень быстро и большей частью интуитивно отнесет вашу машину к определенной категории. После этого все остальные впечатления от вашего продукта зависят от его ожиданий в отношении этой категории. Первым делом он определит, создали вы инструмент для записей, программу для редактирования изображений, игрушку, чтобы скоротать время на автобусной остановке, мессенджер для общения с друзьями или систему для анализа данных. Если соответствующая категория интересует Томаса, он изучит остальную часть вашей модели ценности, если нет — не станет тратить время.
Модель ценности можно представить в виде следующего высказывания:
[Название продукта] — это категория пользовательского опыта,
которая приносит мне такую-то пользу (и лучше альтернативных решений по таким-то причинам).
Последняя часть заключена в скобки, поскольку не всегда можно описать причины простым предложением. Определить эти отличительные особенности очень важно, но зачастую лучший способ донести их до пользователя — неявным образом, через модель взаимодействия.
Парадокс в том, что модель ценности — самая простая для понимания и самая сложная для описания. Самое трудное — найти формулировку, которая определяет ценность для человека, а не для организации, создающей пользовательский опыт. Человеку важно, что упрощается выполнение какой-то задачи, организации — что она получает доход или достигает стратегической цели. Ценность для человека первична, а ценность для организации носит производный характер: организация получает ценность в качестве вознаграждения за создание ценности для человека.
Самое трудное — найти формулировку, которая определяет ценность для человека, а не для организации, создающей пользовательский опыт.
Чтобы решить эту проблему, нужно сделать два важных шага. Во-первых, мысленно поместить цифровую машину внутрь более обширной бизнес-модели, где наш продукт — это лишь одна составляющая общего ценностного предложения организации для потребителя. Во-вторых, для создания убедительной модели ценности нужно выстраивать ее общими усилиями, применяя человекоориентированные методы разработки — и напрямую привлекая людей, похожих на целевого пользователя.
Модель взаимодействия
Модель взаимодействия определяет, как человек меняет состояние цифровой машины. Эту модель можно представить в виде диалога двух составляющих схемы «Цифровая машина» — человеческой и алгоритмической. В этом диалоге:
- действие оператора для изменения состояния машины —
- это вводные данные для алгоритма,
- который в ответ выдает результат,
- воспринимаемый оператором как сигнал обратной связи о том,
- что машина изменила свое состояние.
Поскольку пользователь взаимодействует с цифровой машиной, чтобы выполнить определенную задачу, и это взаимодействие меняет состояние цифровой машины, можно сказать, что назначение модели взаимодействия — изменить состояние цифровой машины.
Такое теоретическое осмысление модели взаимодействия необходимо, чтобы увязать ее с моделью объекта и моделью данных, о которых пойдет речь ниже, однако это не лучший подход к ее проектированию. В этом случае гораздо лучше представить модель взаимодействия как историю.
Вот пример такой истории для покупки книги на Amazon.
1.Зайдите на amazon.com.
2. Найдите книгу.
3. Просмотрите подробную информацию о книге.
4. Положите книгу в корзину.
5. Оформите заказ.
На каждом этапе я взаимодействую с системой, вводя текст, выбирая товар из списка или нажимая кнопку, чтобы совершить то или иное действие. Система реагирует, выдавая визуальные сигналы обратной связи, которые подтверждают, что она получила от меня вводные данные. На каждом этапе истории состояние системы меняется. В финале происходит глобальное изменение: я купил книгу — система выполнила свою задачу!
Еще одно название для истории, которая описывает, как человек достигает цели, — рабочий процесс. Мысль о том, что рабочий процесс — это история, работает как эвристика: если модель взаимодействия нельзя описать в виде простой правдоподобной истории, вы не закончили проектирование.
Другая важная мысль состоит в том, что модель взаимодействия всегда представляет собой сложную иерархическую структуру. Можно проиллюстрировать это, расширив пример, приведенный выше.
1. Зайдите на amazon.com.
2. Найдите книгу.
2.1. Воспользуйтесь диалоговым окном Search.
2.1.1. Поставьте курсор в диалоговое окно Search.
2.1.2. Напечатайте текст.
2.1.3. Просмотрите варианты в выпадающем списке частичных совпадений.
2.1.3.1. Выберите один из предлагаемых вариантов.
2.1.3.2. Просмотрите список результатов поиска.
2.1.4. Проигнорируйте варианты в выпадающем списке частичных совпадений, нажмите кнопку Return.
2.2. Просмотрите список результатов поиска.
2.3. Кликните по названию книги.
3. Просмотрите подробную информацию о книге.
4. Положите книгу в корзину.
5. Оформите заказ.
Мы видим, что при добавлении дополнительных подробностей модель взаимодействия все более четко описывает, как должен вести себя готовый софт.
Представив эту модель в виде набора иерархически связанных историй, мы можем проранжировать эти истории и определить, какие из них необходимы для рабочего процесса, а какие полезны, но не обязательны.
Поскольку модель взаимодействия рассказывает историю о том, что пользователь делает с софтом, участникам проекта проще всего обсуждать именно эту модель, которая помогает им прийти к взаимопониманию. Опасность в том — и это проблема большинства проектов по разработке ПО, — что команда слишком рано и безоглядно сосредотачивается на модели взаимодействия, не описав должным образом другие модели, от которых та зависит.
Модель объекта
До сих пор мы говорили о составляющих цифровой машины, которые связаны с пользователем и его опытом работы с продуктом. Модель объекта и модель данных позволяют нам обсудить техническую сторону дела.
Хотя все модели в цифровой машине важны, модель объекта — самая важная, потому что она определяет «детали» машины и их взаимосвязь. Поясним это на примере. Допустим, мы решили создать игру-симулятор для заезда на велосипедах. При проектировании модели объекта нам нужно первым делом представить себе велосипед. Понятно, что, хотя мы могли бы отобразить все детали велосипеда, нам понадобятся лишь те, которые взаимодействуют с велосипедистом и дорогой.
Удобный способ выполнить такой анализ объекта — представить модель взаимодействия в виде истории и выявить значимые существительные:
Когда велосипедист едет на велосипеде, он сидит на сиденье, поместив ноги на педали, а руками держит руль. Он управляет велосипедом, контролируя угол наклона и поворот руля в определенном диапазоне, так чтобы не упасть под воздействием силы тяжести и добраться из исходного пункта в место назначения, то есть совершить поездку.
Это можно изобразить так:
Или в более компактном виде:
поездка
> средство передвижения
> велосипедист
> велосипед
> руль
> поворот
> угол наклона
> позиция
> исходный пункт
> место назначения
Такое представление выявляет как объекты в модели, так и их взаимодействие. Иерархическая структура, которую мы уже обнаружили в модели взаимодействия, естественным образом появляется и здесь, поскольку эти две модели взаимосвязаны. Чем подробнее история в модели взаимодействия, тем выше детализация и точность описания объектов, вступающих во взаимоотношения. Верно и обратное: если разбить объекты на подобъекты, история их взаимодействия становится более подробной.
Схематично изобразить модель объекта чрезвычайно полезно, но нашей цифровой машине недостает финального штриха: механизма сбора данных о состоянии. Эту проблему решает модель данных.
Модель данных
Модель данных строится на основе простого принципа — пара имя/значение. Он означает, что при представлении данных каждому параметру дается имя и присваивается определенное значение. Чаще значение выражено числом, но оно может быть и текстом.
Принято сначала писать имя, а потом значение, например:
x = 3
π = 3.14
цвет = зеленый
город = Сан-Франциско
Пары имя/значение дают нам возможность зафиксировать данные о состоянии. Применяя этот принцип в нашем примере с велосипедом, можно написать:
позиция: {
широта: '37:78',
долгота: '-122:42'
}
Пары, которые описывают состояние объекта, часто называют свойствами объекта. Продолжая в том же духе, можно написать:
поездка = {
средство передвижения: {
велосипедист: {
имя: ‘Томас’
},
велосипед: {
руль: {
поворот: ‘12’,
угол наклона: ‘3’
}
},
текущая_позиция: {
широта: ‘37.78’,
долгота: ‘-122.42’
},
},
исходный пункт: {
название: ‘Сан-Франциско’,
позиция: {
широта: ‘37.78’,
долгота: ‘-122.42’
},
место назначения: {
название: ‘Лос-Анджелес’,
позиция: {
широта: ‘34.05’,
долгота: ‘-118.42’
}
}
}
Это модель данных для нашей игры. Фиксируя состояние всех объектов в нашей машине по отдельности, она тем самым фиксирует состояние машины в целом.
Теперь мы видим: чтобы пользователь ощущал, что он управляет скоростью и направлением движения велосипеда, нам нужно перевести данные, которые он вводит в игровой контроллер, в числовые значения и использовать их для обновления модели данных, а затем перевести эти изменения состояния в визуальную информацию, чтобы он мог получить сигнал обратной связи.
Таким образом, вся работа по разработке и реализации, которую я выполняю со своей командой, сводится к тому, чтобы дать пользователю возможность изменять несколько числовых параметров. Понимание этого проясняет ситуацию и одновременно сбивает спесь.
Подведем итоги
«Цифровая машина» — это схема, которая описывает цифровой продукт как совокупность пяти моделей.
- Модель пользователя: для кого это?
- Модель ценности: почему это полезно?
- Модель взаимодействия: как это использовать?
- Модель объекта: как это устроено?
- Модель данных: как управлять состоянием этого?
Эта схема помогает участникам проекта справиться со сложным процессом перевода потребностей человека в полезный продукт в трех аспектах.
- Правила коммуникации, задаваемые моделями цифровой машины, выявляют неосознанные предположения и допущения и позволяют оценить степень согласия участников проекта.
- Процесс проектирования становится более гибким, поскольку позволяет какое-то время работать над каждой моделью в отдельности, а затем вновь собрать их воедино и оценить как целостную систему.
- Совместно выстраивая модели цифровой машины, участники проекта задействуют свои способности к образному и пространственному , что помогает им прийти к общему пониманию того, как работает продукт.
Если вы дошли до этих строк, вы усвоили серьезный кусок теории проектирования. Однако для меня применение такого подхода отнюдь не теория — я ежедневно успешно использую эту схему в своей работе. Я постоянно рассказываю своей команде про модели, я рисую их на доске, включаю в презентации и делаю все возможное, чтобы каждому участнику проекта было удобно обсуждать модели. Хотя в новой команде это поначалу вызывает некоторую неловкость, эффективность общения резко возрастает, и мне было очень приятно, когда один из бывших боссов сказал мне: «Наверное, рано или поздно мы пришли бы к единому мнению по поводу наших ментальных моделей, но благодаря тому, что вы говорили о них все время, это случилось гораздо быстрее».
Спасибо Иэну Шену и Реймону Сутеджо за то, что они помогли привести мои соображения о моделях в читабельный вид. Спасибо и моим бывшим студентам из Калифорнийского колледжа искусств, которые задавали трудные вопросы. В поисках ответов я и разработал схему «Цифровая машина».
Литература
Цифровую машину и модели, из которых она состоит, изобрел не я. Моя заслуга (или вина) заключается лишь в том, что я изложил эту концепцию в статье и снабдил иллюстрациями. Для тех, кто хочет познакомиться с цифровой машиной и ее составляющими более подробно, я назову несколько источников.
Цифровая машина
Разработка цифровых машин — как и любой другой технологии — началась с поисков более совершенных способов убийства во время Второй мировой войны, когда нужно было взламывать вражеские шифры и совершенствовать системы наведения зенитных орудий. В 1945 году журнал The Atlantic опубликовал эссе «Как мы можем мыслить» (As We May Think). Его автор, американский инженер Ванневар Буш, впервые рассказал широкой читательской аудитории про машины, которые умеют думать. В 1948 году вышла в свет статья Клода Шеннона «Математическая теория связи» (The Mathematical Theory of Communication), где была дана первая научная характеристика информации, которая рассматривалась как измеримая механическая величина. Кроме того, рекомендую познакомиться с книгой «Введение в кибернетику» (Introduction to Cybernetics) Уильяма Росса Эшби, — хотя это не самое легкое чтение, здесь дано лучшее — строгое и в то же время доступное — определение цифровой машины.
Особое внимание советую обратить на книгу Conceptual Models: Core to Good Design Джеффа Джонсона и Остина Хендерсона, которая вышла в 2011 году, — именно она вдохновила меня на создание схемы «Цифровая машина». Авторы описывают абсолютно правильный подход, но я решил, что в целях обучения, обмена информацией и внедрения проще оперировать модульной системой моделей.
Модели, общая информация
Первые модели, которые служили для упрощенного осмысления мира, появились, когда древний человек нарисовал картину на стене пещеры. Более современная трактовка этого понятия, в первую очередь применительно к проектированию, содержится в книге Хью Дабберли Model of Models, изданной в 2009 году.
Модель пользователя
Модель пользователя давно и успешно используется в практике проектирования интерактивных цифровых продуктов, сред, систем и сервисов. Лучшая книга по теме — «Алан Купер об интерфейсе. Основы проектирования взаимодействия» (About Face 3: The Essentials of Interface Design). В статье Фрэнка Лонга Using Personas in Product Design описан остроумный эксперимент, который показывает, при каких условиях собирательные портреты пользователей усиливают эмпатию и тем самым повышают эффективность проектирования.
Модель ценности
Описанная в статье модель ценности напрямую связана с концепцией ценностного предложения, изложенной в книге Александра Остервальдера и Ива Пинье «Построение бизнес-моделей» (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers), которая была опубликована в 2010 году.
В 2011 году компания IDEO выпустила руководство Human-Centered Design Toolkit: An Open-Source Toolkit To Inspire New Solutions in the Developing World, где рассказывается, как выбрать целевого пользователя для построения модели ценности.
Модель взаимодействия
Описать взаимодействие в виде убедительной истории совместно с другими участниками проекта — очень непростая задача. Прекрасным подспорьем в этой работе будет книга Джеффа Паттона «Пользовательские истории. Искусство гибкой разработки ПО» (User Story Mapping: Discover the Whole Story, Build the Right Product), вышедшая в 2014 году.
Полезно познакомиться и со статьей Хью Дабберли What is Interaction, где рассматриваются разные варианты модели взаимодействия.
Модель объекта
Лучше всего построение таких моделей освещено в статье Софии Войцеховски Object-Oriented UX.
25 июля 2017
Автор: sobakapavlova
