Процесс дизайн-мышления: 5 этапов, объясненных для команд

Большинство команд относятся к дизайн-мышлению как к плакату на стене, а не как к рабочему процессу: они проводят один воркшоп по генерации идей и считают дело сделанным, а затем удивляются, почему выпущенная функция не попадает в цель. Реальная ценность заключается в том, чтобы воспринимать эмпатию, фокус, генерацию идей, прототипирование и тестирование как цикл, который работает параллельно с планированием спринта, а не как предшествующую ему фазу.

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

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

Stanford d.schoolформализовал дизайн-мышление как пятиэтапный нелинейный процесс, основанный на человеко-ориентированном проектировании: эмпатия, фокусировка, генерация идей, прототипирование и тестирование.[[//L1]] Тим Браун из IDEO описал его в статье для Harvard Business Review за 2008 год как использование чутья и методов дизайнера для согласования того, что нужно людям, с тем, что технически возможно и коммерчески жизнеспособно.

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

5 этапов дизайн-мышления (от эмпатии до тестирования)

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

Это пересечение становится более очевидным, как только вы видите, как эти этапы вписываются в полный рабочий процесс фронтенд-разработки: от передачи дизайна до сборки и развертывания.

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

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

Быстрое прототипирование — это аналог дизайн-спайка для нулевого спринта, низкоточный билд, измеряемый днями, а не производственная функция, измеряемая неделями. Тестирование замыкает цикл: цикл обратной связи по тестированию пользователей, который выполняется параллельно со следующим спринтом, так что выводы поступают до того, как функция будет выпущена, а не после.

Тим Браун из IDEO определяет это как человеко-ориентированный дизайн на практике: процесс работает, потому что он заставляет команды тестировать идеи на реальных пользователях до того, как инженеры выделят на них емкость спринта.

Этап эмпатии: понимание реальных пользователей до создания продукта

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

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

Вам не нужны сотни интервью, чтобы получить надежный сигнал: паттерны обычно повторяются уже в первой горстке бесед.

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

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

Этап фокусировки: формулирование четкого описания проблемы

Четкое описание проблемы преобразует результаты этапа эмпатии в одно предложение, по которому бэклог может действовать: пользователь, контекст, неудовлетворенная потребность. d.school Стэнфордского университета называет этот шаг синтеза «точкой зрения»; четырехфазная модель Harvard Business School Online объединяет его в свою первую фазу — «Уточнение». В любом случае, процесс дизайн-мышления должен давать четкое, ориентированное на пользователя описание проблемы, а не список пожеланий стейкхолдеров, замаскированный под спецификацию.

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

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

Этап генерации идей: работающие техники дивергентного мышления

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

Техника SCAMPER — один из наиболее надежных инструментов дивергенции для команд, близких к инженерии: Заменить (Substitute), Объединить (Combine), Адаптировать (Adapt), Модифицировать (Modify), Найти другое применение (Put to another use), Устранить (Eliminate), Обратить (Reverse).

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

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

Прототипирование и тестирование: быстрое прототипирование и цикл обратной связи

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

Скорость — это главное. Для Barometa, рекрутмент-технологического стартапа, Netguru прошла путь от одной сессии по определению объема работ до рабочего прототипа за 14 дней — достаточно быстро, чтобы показать концепцию пользователям и инвесторам, пока идею еще дешево менять.

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

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

Каждый раунд возвращает новые идеи в короткий этап конвергенции, а затем снова в цикл сборки и тестирования. Для разработчиков ПО это идеально ложится на существующий ритм спринтов: прототипирование и тестирование могут выполняться в рамках одного двухнедельного спринта вместе с уточнением бэклога, причем результаты юзабилити-тестирования попадают в бэклог в виде задач, а не в виде отдельного документа по дизайну, который передается разработчикам без предварительного обсуждения.

Почему дизайн-мышление нелинейно, а не каскадно

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

Каскадные диаграммы с пятью аккуратными прямоугольниками и стрелкой — это учебное пособие, а не то, как процесс работает на практике. Тим Браун из IDEO описывает его как три перекрывающихся пространства: вдохновение, генерация идей, реализация — именно потому, что линейный подсчет этапов скрывает итеративность.

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

Дизайн-мышление в программных и продуктовых командах

Процесс дизайн-мышления вписывается в гибкую разработку (agile), а не заменяет ее.

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

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

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

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

3, 4, 5 или 6 этапов: Сравнение моделей дизайн-мышления

Не существует единой канонической модели дизайн-мышления. Основные модели описывают одну и ту же работу с разной степенью детализации:

Трехфазная модель IDEO объединяет работу по эмпатии и определению в единую фазу вдохновения, в то время как d.school разделяет их, что помогает командам, которым требуется четкая передача результатов от исследований к формулировке проблемы. Четырех- и шестифазные модели добавляют явный шаг реализации в конце.

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

Часто задаваемые вопросы о дизайн-мышлении

Каковы этапы процесса дизайн-мышления?

Процесс дизайн-мышления состоит из пяти шагов: эмпатия, определение, генерация идей, быстрое прототипирование и тестирование. Стэнфордская d.school закрепила эту последовательность, в то время как IDEO оформляет ту же работу в виде трех фаз: вдохновение, генерация идей, реализация. Команды, создающие программное обеспечение, сопоставляют эти шаги с уточнением бэклога, планированием спринта и передачей задач в разработку, вместо того чтобы проводить их в виде отдельной процедуры. Команды, которым не хватает внутренней экспертизы, часто привлекают специалистов по дизайн-мышлению, чтобы руководить процессом и обучать команду на каждом этапе.

Почему дизайн-мышление является нелинейным процессом?

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

Кто изобрел дизайн-мышление?

Ни один человек не изобрел дизайн-мышление единолично. Его корни уходят в исследования методов проектирования 1960-х годов и позже; Рольф Фасте преподавал дизайн-мышление в Стэнфорде в 1980-х годах, а Дэвид Келли, основатель IDEO, в 2005 году основал d.school при Стэнфорде. Тим Браун, бывший тогда генеральным директором IDEO, представил этот термин широкой бизнес-аудитории в своей статье в Harvard Business Review за 2008 год.

Сколько времени занимает процесс дизайн-мышления?

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

Стоит ли получать сертификат по дизайн-мышлению?

Сертификат по дизайн-мышлению помогает, если вашей команде нужен общий словарь, но он не заменяет практический опыт работы с реальными пользователями. Собственные курсы IDEO и обучение UX от Nielsen Norman Group учат циклу «эмпатия — тест», однако ни то, ни другое не заменяет проведение реальных юзабилити-тестов вашего продукта. Если бюджет на сертификацию ограничен, лучше привлеките одного старшего дизайнера в свою инженерную команду.

Дизайн-мышление против бережливого подхода (lean) и гибкой разработки (agile): в чем разница?

Дизайн-мышление определяет, какую проблему стоит решать, lean проверяет жизнеспособность предложенного решения, а agile создает его с помощью итеративных спринтов. На практике дизайн-мышление работает как этап предварительного исследования, который подпитывает lean MVP, а разработчики затем доставляют его с помощью спринтов agile. Запускайте их все вместе: дизайн-мышление находит правильную проблему, а agile быстро ее выпускает.

Примените дизайн-мышление в своем следующем спринте

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

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