Design Thinking: Beş Aşama ve Sürecin Nerede Tıkandığı
Design thinking, bir problemi çözmeye kalkışmadan önce onu doğru tanımlamaya çalışan bir çalışma biçimi. Tasarımcılara özgü değil; ürün, yazılım ve hizmet tarafında da aynı şekilde işliyor. Asıl mesele beş aşamayı ezberlemek değil, o aşamaların hangi koşulda gerçekten çalıştığını bilmek.
Yöntem aslında ne yapıyor
Klasik problem çözme genellikle "bu nasıl olmalı" varsayımıyla başlar. Design thinking o varsayımı ertelemeyi önerir: önce insanların gerçekte ne yaptığına bakarsın, problemi oradan tanımlarsın, çözümü en ucuz haliyle denersin. Aşamalar empati, tanımlama, fikir üretme, prototipleme ve test diye sıralanır. Sıralama basit görünüyor; zorluk sıralamada değil.
Beş aşama
- Empati: Kullanıcıyı kendi ortamında gözlemlemek, ne söylediğiyle ne yaptığı arasındaki farkı görmek.
- Tanımlama: Toplanan izlerden tek ve net bir problem cümlesi çıkarmak.
- Fikir üretme: Elemeden önce seçenek sayısını artırmak.
- Prototipleme: Fikri, atılabilecek kadar ucuz bir biçimde somutlaştırmak.
- Test: Prototipi ekibe değil, gerçek kullanıcıya göstermek.
Bu liste her yerde aynı çizilir ama döngü pratikte tek yönlü ilerlemez. Test aşaması çoğu zaman seni tanımlama aşamasına geri gönderir, çünkü yanlış problemi çözdüğünü ancak orada fark edersin.
Prototip ucuz kaldığı sürece işe yarar
Prototipin tek işi atılabilmek. Bir projede prototipi doğrudan üretim kodunun içine yazmıştık; iki hafta sonra kimse iki haftalık emeği çöpe atmayı göze alamadı ve test aşaması bir onay törenine dönüştü.
Peki prototipin ucuz olması ne demek? Saat cinsinden değil, vazgeçme maliyeti cinsinden ölçülür. Kağıda çizilmiş bir akış yirmi dakikada çöpe gider. Çalışan bir ekran, üstüne veritabanı şeması ve iki entegrasyon eklendiği anda, artık test edilen değil savunulan bir şeydir. Prototipi hangi malzemeyle yapacağına karar verirken sorulacak soru "ne kadar sürede biter" değil, "yanlış çıkarsa atmak canımı yakar mı".
Empati aşaması atlanırsa geri kalan her şey varsayım
Kullanıcıyla hiç konuşmadan hazırlanan bir empati haritası, kullanıcının değil ekibin kendi tahminlerinin resmidir. Sonraki dört aşama bu resmin üzerine kurulduğu için süreç kusursuz işliyor gibi görünür, çıktı da kendi içinde tutarlı olur. Tutarlılık doğruluk anlamına gelmiyor.
Peki kullanıcıya erişim yoksa? Kurumsal işlerde bu sık olur: son kullanıcıyla görüşme izni çıkmaz, arada üç katman vardır. O durumda yöntemi uygulanmış gibi yapmak yerine ikinci el izlere bakmak daha dürüst bir yol. Destek talepleri, site içi arama sorguları, terk edilen form adımları, hata kayıtları. Bunlar seyreltilmiş veridir ama uydurma değildir; hayali persona ise sadece uydurmadır.
"Wicked problem" ile beş adımlı listenin çelişkisi
Design thinking anlatıları neredeyse her zaman wicked problem terimini kullanır. Rittel ve Webber'in tanımında bu tür problemlerin ayırt edici özelliği durma kuralının olmaması: çözüm doğru ya da yanlış değil, daha iyi ya da daha kötüdür ve süreci bitiren şey problemin çözülmesi değil, zamanın ya da paranın bitmesidir.
Aynı metinler bu terimi andıktan sonra sonu "test" ile biten beş maddelik bir liste çizer. İkisi bir arada duramaz. Ya problem wicked değildir ve liste yeterlidir, ya da problem gerçekten wicked'dır ve listenin sonu yoktur. Pratikteki karşılığı şu: sürecin çıktısını "çözüldü" diye değil, "şu an elimizdeki en iyi hali, şu koşullar altında" diye raporla. Bu bir kaçamak değil, sürecin doğru okunması.
Nerede kazandırır, nerede geciktirir
Problem tanımı belirsizse, kullanıcı davranışı bilinmiyorsa ve yanlış yöne gitmenin maliyeti yüksekse yöntem kazandırır. Gereksinim netse, kabul kriteri yazılıysa ve tek bilinmeyen uygulamanın kendisiyse döngü yalnızca gecikme üretir. Ekipte "her işi bu yöntemle yapalım" eğilimi belirdiğinde sorulacak tek soru var: burada gerçekten bilmediğimiz bir şey var mı, yoksa bildiğimiz şeyi yapmayı mı erteliyoruz?
Kaynak