Konu Başlıkları
Yükleniyor...

Tasarım Odaklı Düşünme Modelleri: Hangisi Ne Zaman İşe Yarar

On Tasarım Odaklı Düşünme Framework'ü Arasındaki Gerçek Fark

Tasarım odaklı düşünme etrafında dolaşan onlarca model var ve çoğu birbirinin adı değişmiş hali. Stanford'ın beş aşaması, IDEO'nun üçü, Double Diamond'ın dört fazı aynı iki hareketi yapar: önce aç, sonra daralt. Asıl soru hangi modelin doğru olduğu değil, hangisinin sizin tıkandığınız yere ağırlık verdiğidir.

Aynı döngünün on adı

Listedeki modellerin ortak iskeleti şu: kullanıcıyı anla, problemi yeniden yaz, çok sayıda fikir üret, birini elle tutulur hale getir, gerçek insana göster. Stanford d.school bunu beş adımda anlatır, IDEO'nun kısa versiyonu üçte (ilham, fikir, uygulama), LUMA yine üçte (gözlemle, anla, üret). Herbert Simon'ın yedi adımlı süreci araştırma ve öğrenme kısmını ayrı başlıklara böldüğü için daha uzun görünür; yaptığı iş aynıdır.

Aşama sayısını karşılaştırmak boşa vakit. Hangisini seçerseniz seçin ilk hafta aynı görünür.

Fark, ağırlığın nerede olduğunda

Ayrım isimlerde değil, hangi aşamanın şişirildiğinde ortaya çıkıyor.

  • Double Diamond problem alanını ve çözüm alanını ayrı ayrı açıp daraltır. Yanlış problemi çözme riskiniz yüksekse bu ayrımı görünür kılan tek model odur.
  • IDEO Human-Centered Design (dinle, yarat, sun) saha çalışmasına ağırlık verir. Kullanıcıyı uzaktan tahmin ettiğiniz projelerde yerini bulur.
  • Frog'un Collective Action Toolkit'i süreci değil grubu yönetir. Ekip dağınıksa buradan başlanır.
  • Designing for Growth'un dört sorusu bir yöntemden çok karar toplantısı gündemi. Yönetici masasında işe yarar, tasarım masasında değil.
  • AIGA'nın akıl, kalp ve el üçlüsü aşama değil kontrol listesi. Süreç kurmaz, kurulmuş süreçte hangi boyutun eksik kaldığını gösterir.

Numaralı liste sıra vaat eder

Kaynakların hemen hepsi "aşamalar sıralı değildir, aralarında geçiş yapabilirsiniz" der ve hemen ardından aşamaları 1'den 5'e numaralandırır. Ekipler numarayı okur, uyarıyı okumaz.

Sonuç tanıdık: test aşamasına gelinir, çıkan bulgu problemin baştan yanlış tanımlandığını gösterir, kimse başa dönmez. Çünkü takvimde empati haftası çoktan geride kalmıştır ve geri dönmek gecikme sayılır. Modeli tahtaya çizerken numaraları silin, okları bırakın. Küçük bir müdahale, ama geri dönüşü meşrulaştırıyor.

Prototip aşaması nerede tıkanır

Tasarım odaklı düşünmenin en çok konuşulan, en az uygulanan kısmı prototipleme. Sebebi basit: ekipler prototipi ürünün küçültülmüş hali sanıyor. Küçük ürün yapmak pahalıdır, pahalı olduğu için yapılmaz, onun yerine slayt hazırlanır ve slayta bakan kullanıcı nazik davranır.

Prototipi genelde tek bir statik HTML sayfasıyla çözerim; veritabanı yok, giriş ekranı yok, test edilecek akışın üç ekranı ve sahte veri var. Kullanıcıya sorduğunuz soru "bu adımı anladın mı" ise arkada çalışan bir sistem olmasının hiçbir katkısı olmuyor. Bir haftalık geliştirme yerine iki saatlik iş, ve yanlış çıktığında atmak kimsenin canını yakmıyor.

Hangisiyle başlamalı

Yeni başlayan ekip için Stanford'ın beş aşaması yeterli; en çok belge, en çok örnek onun etrafında birikmiş. Problemin kendisinden emin değilseniz Double Diamond'a geçin. Bunun ötesinde model değiştirmek ilerleme hissi verir, ilerleme vermez. Aynı döngüyü üçüncü kez yeni isimlerle kurmaktansa bir kullanıcıyla daha konuşun.

Kaynaklar