Генерация идей в дизайн-процессе с помощью инструмента ТРИЗ. Часть 1.

Проблема

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

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

Я расскажу о том, как сделать этап генерации более структурным и обоснованным.

Решение

В ТРИЗ есть инструмент, который позволит нам приблизиться к обоснованным идеям и неожиданным решениям сложных проблем с первого подхода.

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

Этап генерации идей в дизайн-процессе для кого-то выглядит слабо

Речь пойдет о методе причинно-конфликтного анализа RCA+, с которым меня познакомил автор этого метода, мастер ТРИЗ Валерий Сушков.

Итак, поехали.

Как это работает

Для того, чтобы применить инструмент RCA+, нам предстоит пройти через несколько этапов:

1. Выбрать проблему;
2. Провести анализ и декомпозицию выбранной проблемы;
3. Выбрать ключевую подпроблему;
4. Решить подпроблему, сгенерировать идеи;
5. Провести ранжирование идей.

1. Выбираем проблему

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

После этого мы с командой определяем проблемную область с которой дальше будем работать.

Затем, когда проблемная область определена, мы используем метод HMW (“как мы могли бы?”) для того, чтобы сместить свой фокус с проблемной области в область решений, посмотреть на проблему под другим углом. Иногда угол получается очень широким))

Как будем действовать мы?

Наш кейс:

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

На нашем CJM есть данные об этом и можем сформировать проблемное поле. То что они не пользуются кардиостимуляторами — наше проблемное поле.

Фиксируем нашу проблему:

2. Анализ и декомпозиция выбранной проблемы

Если мы с нашей проблемой сразу перейдем к вопросам how might we, то команда сгенерирует их много. Например:

“как мы можем помочь людям с больным сердцем начать использовать кардиостимуляторы, чтобы снизить риск их преждевременной смерти?”

или,

“как мы можем научить их пользоваться кардиостимуляторами, чтобы они осознали эту потребность?”.

Потом команда выберет какой-то один вариант и пустится генерировать идеи.

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

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

Метод запуска двигателя “с кривого”))

ТРИЗ дает нам инструмент, чтобы отправиться другим путем. Немного более длинным, но значительно более результативным. Мы постараемся для команды сделать процесс генерации обоснованным и системным.

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

То что мы будем делать немного похоже на технику “5 почему”, но имеет ключевые отличия:

1. Мы не задаем вопрос “почему”, а задаем вопрос “что явилось причиной”. Вопрос “почему” для четкого определения причины не подходит, так как он двоякий. Ответ может подразумевать и причину возникновения и цели/намерения. Например, если спросить “Почему ты идешь на рыбалку?”, можно получить ответы и “Потому что мне нечего сегодня делать“ (причина) и “Чтобы поймать рыбу” (цель/намерение);
2. В отличие от техники “5 почему” мы ведем анализ не только по вертикали вглубь, но и по горизонтали вширь. Ведь причин одной проблемы может быть несколько;
3. Мы анализируем каждую причину нашей проблемы на предмет того, вызывает ли она положительный эффект. И если находим положительный эффект, то это значит, что мы нашли противоречие и мы прекращаем в этом месте копать дальше вглубь.

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

Причины основной проблемы

У нас получилось три причины нашей проблемы:

1. Не интересуются состоянием своего здоровья;
2. Неверно поставлен диагноз;
3. Ценовая недоступность.

Мы проанализировали наши три причины и увидели, что у причины “Не интересуются состоянием своего здоровья” есть и положительный эффект : “Живут без нервов по поводу своего недуга”. У нас появилось первое противоречие.

Как же правильно его сформулировать?

Для начала удобно представить его в такой таблице:

Анализ противоречия

Ну а теперь его легко сформулировать. Другими словами, наше противоречие звучит так:

“Клиенты должны быть осведомлены для того, чтобы начать лечение и должны быть не осведомлены, чтобы не нервничать”.

После нахождения противоречия ветку дальше можно не прорабатывать в глубину.

Идем дальше.

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

Причинно-конфликтная структура нашей проблемы

После полного анализа мы получили еще два противоречия.

Так же представим их сначала в табличном виде, а потом сформулируем их:

Анализ противоречий

Итого у нас три противоречия:

1. Клиенты должны быть осведомлены для того, чтобы начать лечение и должны быть не осведомлены, чтобы не нервничать

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

3. Обследований должен много, чтобы получить детальный результат и мало, чтобы это не было недоступно по цене

Теперь мы можем вместе с командой сформулировать вопросы how might we:

1. “Как мы могли бы рассказать клиентам об их состоянии здоровья, при этом не вызвав слишком много тревоги и нервов для того, чтобы они начали использовать кардиостимуляторы?”
2. “Как мы могли бы помочь врачам обеспечить необходимую пропускную способность, чтобы максимальное число пациентов имело возможность попасть на прием — и, в то же время, чтобы у врача было достаточно времени на постановку качественного диагноза?
3. “Как мы можем обеспечить множество подробных обследований для наших пациентов и при этом не сделать процедуру неподъемно дорогой, чтобы наши пациенты могли себе это позволить?

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

И, казалось бы, вот сейчас уже можно начинать генерировать идеи, но…

Мы не торопимся и сейчас.

Во второй части статьи я расскажу, как нам теперь выбрать ключевое противоречие и как с помощью таблиц ТРИЗ приблизиться к решению.

Будет интересно.

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

Подписывайтесь и не пропустите продолжение.