Процессы UXD
User Experience Design (UXD, UX-дизайн) – часть процесса разработки продукта.
Американский предприниматель Эрик Рис стал законодателем мод в области разработки ПО, когда в своей книге «Бизнес с нуля. Метод Lean Startup»[64] предложил заменить тяжеловесные методологии PMBOK (Project Management Body of Knowledge) и RUP (Rational Unified Process) своей шустрой моделью Lean Cycle. В то время начали появляться компании-разработчики, не имевшие за плечами опыта ведения корпоративных процессов, им была чужда и незнакома эта тяжеловесная инженерная культура с обилием документации и многолетним планированием.
В основе подхода лежат основные тренды современного производства ПО:
• дизайн, в центре которого находится пользователь (User Centered Design);
• гибкость (Agile);
• бережливость (Lean).
Главная идея подхода заключается в максимально быстром и экономном переходе между фазами цикла:
1) генерация идей;
2) разработка;
3) анализ результатов;
4) генерация идей…
Очевидно, что процессы UX-дизайна включены в каждый этап производства. Как уже было описано выше, команда может начать генерацию идей как с нуля, так и имея на руках результаты предыдущих итераций.
Мы рассмотрим UXD-процессы, начиная с самого старта продукта.
Популярные процессы UX-дизайна, наложенные на Lean Cycle
Процессы растут и развиваются вместе с продуктом, людьми, организацией. Они рождаются, живут и умирают. Очень важно не пропустить момент, когда необходимо запустить тот или иной процесс или исключить, если он превратился в бессмысленный ритуал. Хорошей практикой будет периодически проводить «ретроспективы» – встречи, на которых команда принимает решение прекратить/продолжить/начать конкретные процессы.
Многие популярные дизайн-процессы уже упоминались ранее. Далее рассмотрим их подробнее.
Дизайн-мышление и его производные
Дизайн-мышление – когнитивный процесс, в результате которого появляются дизайн-концепции.
Термин развивался с 1950-х годов, а широкую популярность получил благодаря компании IDEO – ее основатели агрегировали опыт, накопленный ведущими дизайн-командами, и в начале 1990-х начали активно консультировать корпорации. Именно их интерпретация процесса и подразумевается под дизайн-мышлением, связанным с созданием цифровых продуктов.
Популярности процесса способствовало несколько факторов. Постепенно технологические патенты и ноу-хау стали давать меньше преимуществ, и производители сосредоточились на определении текущих и создании новых потребностей клиентов. Индустрия менялась все стремительнее, так что компаниям требовалось найти более быстрые способы не только производства, но и генерации идей.
В дизайн-мышлении объединились лучшие на тот момент практики генерации идей и принятия решений – мозговой штурм, латеральное мышление[65], циклы «создай-протестируй-повтори» и многие другие.
Процесс происходит в несколько этапов:
• эмпатия – концентрация на переживаниях пользователя и запись откровений;
• фокусировка – оформление разрозненных находок в виде артефактов: персон, карт следования, гипотез в формате «Как мы можем помочь» (HMW, How Might We);
• генерация идей – поиск решений для выявленных проблем и пользовательских контекстов;
• приоритизация идей – коллективное принятие решений с применением лучших практик;
• прототипирование – быстрое создание прототипов решений с помощью разных способов;
• тестирование прототипов – проверка прототипов, по результатам которой возможен возврат на один из предыдущих шагов с последующей корректировкой.
Этапы дизайн-мышления
Сессия дизайн-мышления может занимать от нескольких часов до нескольких дней.
Цель коротких сессий на несколько часов – трансформировать мышление компании, сменить парадигму с Product Centered Design на Human Centered Design, сформировать ценность коллективного творчества, внедрить лучшие практики генерации идей и принятия решений и придать ускорение существующим процессам. Воркшопы (творческие мастерские, рабочие группы) дизайн-мышления – это discovery-процесс бизнеса в миниатюре. Участие в таких практических мероприятиях позволяет участникам прочувствовать важность всех этапов, обрести «мышечную память» и ощутить чувство быстрой победы.
Длинные, многодневные сессии играют роль kick-off-встреч[66] или стратегических сессий, призванных скорректировать курс на заданный цикл – год или квартал. В этом случае получаются более проработанные гипотезы и прототипы, и сессия может служить импульсом для запуска Lean Cycle.
Несмотря на то что дизайн-мышление часто критикуют за оторванность идей от реалий производства и бизнеса, такие сессии нередко становятся первым толчком для раскручивания маховика, ведущего к положительной трансформации бизнеса.
Многие компании разработали свои варианты дизайн-мышления, адаптированные под их ситуацию и процессы. Наиболее известные, такие как Google Ventures Design Sprint и IBM Design Thinking, получили широкое распространение и пользуются популярностью.
Google Ventures Design Sprint
Это альтернативная пятидневная версия дизайн-мышления от венчурного фонда GV (ранее Google Ventures), известного в том числе высоким уровнем экспертности в области продуктового дизайна, на которую могут рассчитывать подопечные ему технологические стартапы.
Этот процесс значительно отличается от оригинального, он приближен к цифровому производству, более приземлен с точки зрения бизнеса и технологий, а также задействует более качественные инструменты, помогающие создавать и отсеивать визуальные идеи для прототипов.
Процесс позволяет глубоко проработать идеи для нового цифрового продукта или привести в форму существующий.
Описание пятидневного процесса Design Sprint
IBM Design Thinking
IBM одной из первых среди корпораций почувствовала необходимость трансформировать свои процессы и процессы клиентов с ориентацией на гибкость и пользовательский опыт.
Подход IBM Design Thinking ориентирован на непрерывный цикл производства и вовлечение пользователей в творческий процесс
Подход IBM Design Thinking отличает фокусировка на итерационном цикле и активное вовлечение пользователей в дизайн-процесс.
Jobs to be done (JTBD)
Подход Jobs to Be Done занимает практически то же место в производственном цикле, что и процессы дизайн-мышления, но имеет радикально иную природу. Подход был популяризирован гарвардским профессором Клейтоном Кристенсеном.
…стремление узнавать все больше и больше о пользователях уводит компанию по неправильному пути. В действительности ей следует сфокусироваться на том, чего хочет достичь клиент в заданных обстоятельствах – к чему он надеется прийти. Это и есть «работа к выполнению» (Jobs to Be Done).
‹…› Когда мы покупаем продукт, то в сущности «нанимаем» его, чтобы он помог нам сделать некую работу. Если продукт хорошо себя показал, в следующий раз в тех же обстоятельствах мы будем склонны нанять этот продукт опять. Если продукт сработал некачественно, то мы «увольняем» его и ищем альтернативы{9}.
В своих статьях и выступлениях Клейтон описывает процесс потребления продукта как результат конкуренции за «наем». При этом в моделировании ситуации потребления (см. подробнее главу 6, раздел «Моделирование персон») прежде всего делается акцент на общем контексте, а не на общих характеристиках потребителей.
Несмотря на интуитивность рассуждений и чистоту примеров, долгое время было тяжело приспособить фреймворк к разработке цифровых продуктов. Роль основного двигателя в этом вопросе играла компания Intercom. Пол Адамс, популяризатор JTBD для разработки цифровых продуктов, в своей статье{10} описывает Job Story как альтернативу User Story.
Алан Клемент в своих статьях сравнивает User Story и Job Story
Место персон из User Story в шаблоне Job Story занимает жизненная ситуация (Situation); блок мотивации (Motivation) вертится вокруг найма/увольнения, а совершаемое действие заменено на ожидаемый результат (Outcome).
Обычно команда испытывает большое облегчение, когда описание функциональных требований переходит c формата сценариев использования (Use Cases) на пользовательские истории (User Story). Участники получают большую свободу и автономию – они самостоятельно ищут способы реализации, максимально эффективные с точки зрения как дизайна, так и кода. Но на практике я часто сталкиваюсь с тем, что красивая история заходит в бэклог (см. главу 4, раздел «Фактор 13») в подобном виде:
А после декомпозиции и обсуждения в команде превращается в такое:
Как видно, пользовательская история в предельных ситуациях часто превращается в нечто уже совсем другое. Персона оборачивается контекстом, действие – сценарием использования, а мотивационная часть опускается или превращается в отписку.
Так что здесь Job Story может быть действительно более качественным пограничным объектом, чем User Story.
Дизайнеры и разработчики в таком случае перейдут на более высокий уровень решения проблем, думая уже не о том, как упростить пользователю совершение конкретного действия, а о том, как победить в конкурентной борьбе с другими продуктами за «наем» конкретного решения.
Подход Jobs to Be Done подразумевает значительную трансформацию классических дизайн-процессов в компании, но вместе с тем может дать очень конкурентоспособный результат.