Design Thinking Nedir, Süreç Pratikte Nasıl İşler?

Design Thinking, bir problemi çözmeden önce onu doğru kurmaya çalışan bir çalışma biçimi. Bilimsel yöntem tek doğru cevabı arar; tasarım düşüncesi önce olabildiğince çok cevap üretir, sonra eler. Aradaki fark yöntemin adımlarında değil, hangi aşamada karar vermeyi ertelediğinizde.

Önce genişlet, sonra daralt

Sürecin tamamı iki hareketin sırayla tekrarlanmasından ibaret. Ayrık (divergent) düşünmede olabildiğince çok seçenek üretirsiniz ve hiçbirini elemezsiniz. Yakınsak (convergent) düşünmede üretilenleri kısıtlara vurur, ayakta kalanı seçersiniz.

Uygulamada işi bozan şey bu ikisinin karışması. Fikir toplantısında biri "onu zaten yapamayız" dediği anda ayrık aşama biter ve masada üç tanıdık seçenek kalır. İki hareketi ayrı oturumlara bölün, aralarına en az bir gün koyun. Eleme oturumuna kısıtları yazılı getirin: bütçe, takvim, mevcut altyapının kaldıracağı yük. Kısıt sözlü kaldığında eleme fikre değil, fikri savunan kişiye göre yapılıyor.

Kavramın kökeni 1960'lara uzanıyor, 1980'lerde Peter Rowe ve ardından Richard Buchanan'ın çalışmalarıyla bugünkü adını aldı. Tarihçesi ilginç ama bir toplantıyı kurtarmıyor; asıl mesele iki hareketi karıştırmamak.

Adımlar ve sıradaki yanıltıcı taraf

Süreç genelde şu adımlarla anlatılır: tanımla, araştır, fikir üret, prototiple, uygula, test et.

Bu sıralamanın ilk iki maddesi kendi içinde çelişiyor. Problemi baştan tanımlamak, araştırmadan önce cevabın ne olduğunu bildiğinizi varsayar. Oysa yöntemin kendi iddiası tam tersi: kullanıcıyla konuştuktan sonra problemin ilk yazdığınızdan farklı çıkması beklenen sonuçtur. Stanford d.school'un beş adımlık versiyonunda empati aşaması tanımlamadan önce gelir, sebebi de bu.

Pratik karşılığı basit. İlk tanımı bir cümleyle yazın, ama taşa kazımayın. Araştırma bittiğinde o cümleyi yeniden yazamıyorsanız araştırma yapmamışsınız, doğrulama yapmışsınız. İkisi aynı şey değil.

Son adım olan test de aslında son adım değil. Çıktı yeni bir tanım cümlesi üretir ve döngü baştan başlar. Bu yüzden süreci bir proje planı gibi Gantt şemasına dizmek işe yaramaz; her tur bir öncekinin varsayımını kırar.

Prototip, fikri ucuza yanlışlamak içindir

Prototipin amacı fikri göstermek değil, yanlış olduğunu ucuza öğrenmek. Bu ayrım maliyeti belirliyor: göstermek için yapılan prototip cilalanır, yanlışlamak için yapılan prototip sadece test edilecek soruyu taşır.

Bir akışın anlaşılır olup olmadığını ölçecekseniz kağıda çizilmiş beş ekran yeter. Ama "bu liste kullanılabilir mi" sorusunda kağıt yanıltır, çünkü gerçek veri kağıtta hep düzgün görünür. Ben bu tür soruları genelde sahte veriyle beslenmiş, tek sayfalık çalışan bir HTML ile çözerim: iki saat sürer, kullanıcının ismi 40 karakter olduğunda hücrenin taştığını da aynı gün gösterir.

Görsel anlatım da aynı işi görüyor. Bir akış diyagramı, üç paragraflık açıklamanın gizlediği kopuk adımı bir bakışta ortaya çıkarır. Ekip içinde tartışma uzuyorsa çoğunlukla sebep, herkesin kafasındaki şemanın farklı olması.

Nerede işe yarar, nerede yaramaz

Design Thinking, problemin ne olduğunun tartışmalı olduğu yerlerde iyi çalışır: yeni bir ürün fikri, kullanıcının neden vazgeçtiğini bilmediğiniz bir akış, birden fazla paydaşın farklı şey istediği kurumsal süreçler.

Problem net ve ölçülebilirse gereksiz yük getirir. Ödeme adımında hata oranı yüksekse orada ihtiyacınız olan şey ideasyon oturumu değil, loglar. Yöntemi her işe uygulamak, onu tanımlamayı reddettiği şeye, yani hazır şablona çevirir.

Plattner ve Meinel'in saydığı ilkeler arasında en çok atlanan da bu: belirsizliği kucaklamak, belirsizlik yokken belirsizlik üretmek anlamına gelmiyor.

Kaynaklar

• Design Thinking, Essential Problem Solving 101 - It's More Than Scientific | IxDF - interaction-design.org