Статьи

Как развить творческое мышление

Apple. Starbucks. Nike. Disney. Uber. Всеми этими компаниями, движущими XXI век, управляет творческое мышление.

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

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

Согласованность между Agile и дизайном

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

Дизайн сразу и постоянно

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

Знать, кто принимает решения

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

Сформулировать ваши дизайнерские решения

Это относится и к дизайнерам, и к компаниям, которые их нанимают. Майк Монтейро объясняет эту идею в книге You’re My Favorite Client:

Дизайнер должен быть готов объяснить, почему он принял именно такое решение. Поэтому, когда я прошу вас дать дизайнеру возможность делать свою работу, вы имеете право напомнить ему, что часть его работы — это готовность ответить на вопрос «Почему ты сделал именно так?»

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

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