А вот схема встречи с любым артефактом из главы и её версия в форме Карты процесса-опыта

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

📍О жизни, работе и книге неспешно

📍О создании книги и невыгорании

📍О перерождении CJM

📍О рабочих и пользовательских историях

Во вторник рассказываю про Карту процесса-опыта на IIBA Kazakhstan Chapter, а в четверг веду сборку карты в прямом эфире на канале UsabilityLab. Обе встречи открыты для посещения и участия

Начинаем презентацию Карты процесса-опыта на KZ Chapter IIBA — https://us06web.zoom.us/j/81889176749?pwd=oiqlaTivxXlmd4ka9xTZevxjQUhJUz.1

Взгляд юзабилистов на КПО

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

Коллеги по UX-цеху из UsabilityLab смотрят на неё как исследователи, дизайнеры и юзабилисты. По следам нашей первой встречи они описали своими словами, что такое Карта процесса-опыта для них.

Напоминаю, что сегодня в 16:00 по Москве буду картировать процесс-опыт в прямом эфире. Специальный гость расскажет свою ситуацию и для неё будет построена карта процесса-опыта.

Регистрация на сегодняшний мастер-класс

Юлия Кожухова, руководитель продуктовых исследований в сфере электронной коммерции, цитирует затронувший её отрывок из моей книги о Карте процесса-опыта. Рад тому, что подход находит отклик в сердцах коллег.

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

Этот танец и является современной услугой.

Проектирование процессов современной услуги — дело непросто и осложнено тем, что услуга — это что-то незримое. А то, что для нас невидимо, то и неподвластно. Не видя процессов во всех их подробностях, невозможно ни управлять ими, ни развивать их

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

Сегодня поделюсь секцией из книги «Рабочие истории. Проектирование через текстовые модели поведения с Картой реализации историй». Надеюсь закончить её черновик к концу сентября. В этом отрывке разобран щепетильный момент замены в историях пользователя на систему.

❦

Инверсия Носителя действия
В главе 7 мы встретили приём, когда рабочая история была переписана так, что в Носителе действия вместо пользователя появилась система. Этот приём как мощный, так и чрезвычайно опасный. Многие так и записывают требования к системе, вот небольшой отрывок из подобных описаний.

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

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

Рабочая история — это в первую очередь текстовая модель поведенческой потребности человека, и рассматривать в ней нужно действующее лицо. В период активного развития пользовательских историй в практике User Story Mapping допускалось записывать истории для разрабатываемой информационной системы, чтобы описать некоторые технические действия в ответ на предыдущую историю пользователя. Однако, на мой взгляд, все необходимые действия системы можно и лучше описать в Формах реализации под историей, так что отдельная история для системы не нужна. Когда же тогда допустимо записавать рабочии истории для системы?

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

Иными словами, мы обращаем внимание в истории с потребителя на систему тогда и только тогда, когда нам требуется защитить интересы бизнеса. Любые искусственные воздействия изменяющие движения пользователя по задумке и к выгоде бизнеса, следует записывать через того Носителя действия, что это движение создаст.

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

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

- Оператор видит какие параметры далеки от нормы, чтобы исправить ошибки настройки
- Колцентр понимает какие способы доставки в городе не на ходу и какими их допустимо заменить для оперативного восстановления логистического тракта
- Оператор видит суммарные статистические данные для использования их в пресс-релизах
- Оператор выгружает отчёт о текущих тарифах в формате Excel для субъекта доставки, чтобы получить данные для отчёта перед руководством.

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

Готовясь к первой лекции в вузе, вспоминал экстраординарные примеры интерфейсов, чтобы зажечь интерес студентов. В число примеров вошел чат головастиков, где каждый участник может подплыть к другим и что-то прокричать в надежде быть услышанным. А также два фрагмента из презентации «Изобретая на основе принципа» гениального Брета Виктора.

Любое из этих решений не найти в справочнике готовых решений. Они диковаты и удивительны, тем и будоражат творческое начало в нас

«Увидеть немедленно». Фрагмент из речи Брета Виктора «Изобретая на основе принципа»

«Сыграть анимацию собой», оттуда же