Design Thinking Aşamaları: Empatinin Gerçekte Yakaladığı Şey
Design Thinking'i anlatan metinlerin çoğu aynı yerlerde bulanıklaşıyor: aşama sayısı kaynaktan kaynağa değişiyor, fikir üretme bölümünde nicelik mi kalite mi istendiği belirsiz kalıyor, empati ise ölçülemeyen bir iyi niyet beyanına dönüşüyor. Oysa yöntemin işe yarayan tarafı bambaşka bir yerde duruyor: kullanıcının söylediğiyle yaptığı arasındaki farkı görünür kılması. Aşamalara da o gözle, birbirine karıştıkları noktalarla birlikte bakmak gerekiyor.
Empati aşaması neyi yakalar
Empatiyi "kullanıcıyı nazikçe dinlemek" diye tarif eden anlatım aşamayı işlevsizleştiriyor. Dinlemek zaten yapılıyor. Bu aşamanın asıl işi, kullanıcının anlattığı ile yaptığı arasındaki boşluğu ortaya çıkarmak. İnsanlar ne yaptıklarını doğru hatırlamaz, neden yaptıklarını da çoğu zaman sonradan mantıklı bir hikayeye bağlar.
Somut hali şöyle görünür: bir isteğin sunucudan 400 milisaniyede dönmesi teknik olarak sorun değildir, kayıtlara baktığınızda da öyle durur. Ama o 400 milisaniye boyunca ekranda hiçbir şey değişmiyorsa kullanıcı "donuyor" der ve butona ikinci kez basar. Anket sorarsanız "yavaş" cevabı gelir, metriğe bakarsanız ortada problem yoktur. İkisi arasındaki farkı ancak birinin ekran başında ne yaptığını izleyerek görürsünüz, ve bu arada ikinci tıklamanın kayıt tablonuza çift satır yazıp yazmadığını da öğrenmiş olursunuz.
Beş aşama mı, altı mı
Kaynaklar burada birbirini tutmuyor. Stanford d.school'un yaygınlaşan modeli beş adım sayar: empati, tanımlama, fikir üretme, prototip, test. Altı adım anlatan metinler genellikle empatiyi ikiye böler ve "anlama" ile "gözlem" diye iki ayrı başlık açar. Bu bölme bir şey kazandırmıyor; gözlem, empatinin yöntemlerinden biri, kendi başına bir aşama değil. Peki sayı gerçekten önemli mi? Süreç zaten doğrusal işlemediği için değil.
Saymak yerine her aşamanın hangi soruyu kapattığına bakmak daha iyi işliyor:
- Empati: kim, hangi ortamda, ne yaşıyor?
- Tanımlama: hangi problemi çözüyoruz, hangisini bilerek çözmüyoruz?
- Fikir üretme: bu problemin kaç farklı çözümü olabilir?
- Prototip: çözüm somutlaştığında neye benziyor?
- Test: baştaki varsayım doğru muydu?
Bu haliyle test yanlış çıktığında nereye döneceğiniz de belli olur. Kullanıcı prototipi kullanamıyorsa prototipe dönersiniz; kullanıyor ama umursamıyorsa problem tanımına, hatta empatiye dönmeniz gerekir. "Nasıl yapabiliriz" soruları da tam burada işe yarar, yeter ki çözümü sorunun içine gizlice yerleştirmeyin. "Kullanıcı giriş ekranında zorlanıyor" cümlesini "girişi nasıl hızlandırırız" diye yeniden yazdığınızda, giriş ekranının orada durması gerektiğini çoktan kabul etmiş olursunuz.
Fikir üretmenin kendi içindeki çelişki
Aynı bölümde iki zıt talimat dolaşıyor: "olabildiğince çok fikir üret, eleştirme" ve "nicelikten kaliteye geç". Bir oturumda hem üretip hem eleyen ekip ikisini de kötü yapar, çünkü eleştirinin varlığını bilen kimse yarım fikri masaya koymaz.
Ayırmak gerekiyor. Üretim ve eleme iki ayrı oturum olsun, arada mümkünse bir gece geçsin. Daha faydalısı, eleme kriterlerini fikirler ortaya çıkmadan önce yazmak: teknik sınır, süre, kimin kullanacağı. Kriter sonradan yazılırsa, en yüksek sesli fikri haklı çıkaracak şekilde yazılır.
Prototipi ne kadar cilalamalı
Prototipi genelde kağıt üstünde ya da tek bir HTML dosyasında başlatırım. Sebebi tasarruf değil: cilalı bir maket, geri bildirimi "renk hoş olmamış" seviyesine indiriyor. Bitmiş görünen bir şeyi insanlar kırmaya çekinir, üstelik onu üreten ekip de savunmaya geçer. Bir haftada hazırlanmış interaktif maketi çöpe atma teklifi, bir gecede çizilmiş beş ekrana göre çok daha fazla direnç görür.
Ya etkileşimin kendisini test etmek gerekiyorsa? O zaman yüksek sadakatli prototip yerinde olur, ama sadece test edilecek akış için. Geri kalan ekranların kaba kalması sorun değil, hatta kullanıcının dikkatini asıl ölçmek istediğiniz yere toplar.
Design Thinking, Agile ve Lean aynı şeyi çözmez
| Yaklaşım | Odak | Başlangıç |
|---|---|---|
| Design Thinking | Kullanıcı ihtiyacı | Problemi tanımlamak |
| Agile | Teslimat ve değişime uyum | Geliştirilecek özellikler |
| Lean Startup | MVP ile doğrulama | Hipotez |
Sıralama tartışmaya açık değil bence: Design Thinking diğer ikisinden önce gelir. Agile, yanlış problemi hızlıca teslim etmenizi engellemez; Lean ise test edeceğiniz hipotezin nereden geldiğini söylemez. O hipotezi üreten şey empati aşamasıdır. Zaten Design Thinking'i tek başına uygulayan ekiplerin sıkışma noktası da bu: keşif güzel ilerler, sonra çıkan çözümü sürdürülebilir biçimde teslim edecek bir düzen olmadığı için iş sunum dosyasında kalır.
Süreç pratikte nerede tıkanır
En sık görülen tıkanma, empati aşamasının takvim baskısıyla yüzeysel geçilmesi. Beş kullanıcı görüşmesi yerine iki yönetici görüşü alınır ve süreç varsayım üstünde yürümeye başlar. İkincisi, fikir üretme oturumlarında en kıdemli kişinin ilk konuşması; ondan sonra söylenen her şey o fikrin etrafında toplanır, isteyen istemeyen. Fikirleri önce sessizce yazdırıp sonra paylaştırmak bunu büyük ölçüde çözer. Üçüncüsü, test sonuçlarının "kullanıcı anlamamış" diye yorumlanması. Kullanıcı anlamadıysa anlatım yanlıştır, kullanıcı değil.
Kaynak