Tasarım Odaklı Düşüncede Sık Yapılan Hatalar ve Süreci Bir Üst Seviyeye Taşımak
Neden Bazı Ekipler Tasarım Odaklı Düşünmeyi Uygularken Sonuç Alamıyor?
Süreç doğru sırayla uygulansa bile ekiplerin çoğu benzer noktalarda takılır. Bu son derste sekiz temel dersi tekrar etmeden, sahada en sık görülen hataları, bu hataların altında yatan yanlış varsayımları ve süreci bir üst olgunluk seviyesine taşıyacak somut yöntemleri ele alıyoruz. Amaç, süreci "bilmek" ile süreci "doğru işletmek" arasındaki farkı kapatmak.
1) En Sık Görülen Beş Hata
| Hata | Altında Yatan Yanlış Varsayım | Sahada Nasıl Görünür |
|---|---|---|
| Empatiyi atlamak veya hızlıca geçmek | "Biz zaten kullanıcıyı/müşteriyi tanıyoruz" | İki gün süren proje, yarım günde "görüşme yaptık" denip ideation'a geçilir |
| Ideation'da erken eleştiri | "Zayıf fikirler zaman kaybıdır, hemen eleyelim" | Beyin fırtınasında yönetici veya en kıdemli kişi ilk 10 dakikada "bu olmaz" der, oda susar |
| Prototipi bitmiş ürün sanmak | "Madem çalışıyor, artık üretime geçebiliriz" | Kağıt/tıklanabilir prototip test edilmeden yatırım kararına konu olur |
| Tek tur testle yetinmek | "Bir kere test ettik, geri bildirim aldık, yeter" | İlk kullanıcı testinden sonra sürece geri dönülmez, doğrudan geliştirmeye geçilir |
| Süreci doğrusal (tek yönlü) sanmak | "Empati → Tanım → Fikir → Prototip → Test, bir kez yapılır biter" | Test aşamasında çıkan yeni bilgi empati aşamasına geri taşınmaz, süreç orada kilitlenir |
Empatiyi Atlamanın Bedeli
Bir ekip düşünün: yeni bir masraf onay uygulaması için empati görüşmelerini atlayıp doğrudan "mobil onay ekranı" fikriyle prototipe geçiyor. Üç hafta sonra saha testinde ortaya çıkıyor ki kullanıcıların asıl sorunu ekranın tasarımı değil, onay yetkisinin kimde olduğunun belirsizliği. Harcanan üç haftalık tasarım emeği, yanlış problemi çözdüğü için sıfırdan başlıyor. Kural: Empati aşamasına ayrılan süre toplam proje süresinin en az beşte biri olmalı; bu süre kısaltılacaksa bilinçli bir risk kararı olarak, gerekçesiyle kayıt altına alınmalı.
Ideation'da Erken Eleştirinin Görünmeyen Maliyeti
Erken eleştiri sadece o fikri öldürmez; odadaki herkesin bir sonraki fikrini de sansürler. Bir fikir üretim oturumunda ilk beş dakikada bir fikir eleştirilirse, geri kalan süre boyunca katılımcılar güvenli, sıradan fikirler önerme eğilimine girer. Pratik çözüm: Oturuma başlarken "değerlendirme, üretimden ayrı bir aşamadır" kuralını sözlü olarak hatırlatın ve fikir sayısı hedefine (örneğin oturum başına en az 20 fikir) ulaşılmadan hiçbir yorum yapılmasına izin vermeyin.
Prototip = Bitmiş Ürün Yanılgısı
Prototip, bir hipotezi ucuza ve hızlıca sınamak içindir; onay almak veya yatırımcıyı ikna etmek için değildir. Bir ekip, tıklanabilir bir arayüz prototipini yönetime sunduğunda "güzel görünüyor, geliştirmeye başlayın" onayı alabilir — oysa prototip hiç kullanıcıyla test edilmemiştir. Sonuç: gerçek geliştirme bütçesi, test edilmemiş bir varsayım üzerine harcanır. Kural: Hiçbir prototip, en az bir kullanıcı testi turundan geçmeden "sonraki aşamaya hazır" olarak etiketlenmemeli.
2) Süreci İzlemek İçin Kullanılabilecek Göstergeler
Sürecin sağlıklı işlediğini anlamak için sayısal bir "başarı skoru" icat etmek yerine, aşağıdaki davranışsal göstergelere bakabilirsiniz:
| Gösterge | Sağlıklı Süreç Belirtisi | Uyarı Belirtisi |
|---|---|---|
| Empati → Tanım geçişi | Problem tanımı, görüşmelerden çıkan doğrudan alıntılarla desteklenir | Problem tanımı, projeye başlamadan önceki varsayımla birebir aynıdır |
| Ideation oturumu | Fikirler arasında birbirine zıt, "çılgın" olanlar da var | Tüm fikirler birbirine benzer, güvenli ve tanıdık |
| Prototip-test döngüsü | En az iki test turu yapılmış, ikinci turda prototip değişmiş | Tek tur test yapılmış, prototip test sonrası değişmemiş |
| Ekip içi tartışma | "Kullanıcı ne dedi?" sorusu kararları yönlendiriyor | "Ben olsam ne isterdim?" sorusu kararları yönlendiriyor |
3) Süreci Bir Üst Seviyeye Taşıyacak Üç İpucu
- Geri dönüş noktalarını önceden planlayın: Proje takviminde "test sonrası empatiye dönüş" için ayrı bir zaman bloğu ayırın; bu blok olmadan ekip test sonucunu görmezden gelme eğilimine girer.
- "Neden şuna inanıyoruz?" listesi tutun: Her önemli karardan önce, kararın dayandığı varsayımı tek cümleyle yazın (ör. "Kullanıcılar mobil bildirimi e-postaya tercih eder"). Test aşamasında bu listeyi tek tek doğrulayın veya çürütün.
- Olgunluk seviyesini ekip içinde açıkça konuşun: "Bu proje empatiye mi, yoksa hız kazanmaya mı öncelik veriyor?" sorusunu proje başında sorun; ekip bunu netleştirmeden ilerlerse yukarıdaki hataların çoğu otomatik olarak tekrarlanır.
Kısa Öz-Değerlendirme Şablonu
Bir projeyi kapatırken ekiple birlikte şu üç soruyu yanıtlayın ve yanıtları bir sonraki projenin başlangıç notuna ekleyin: (1) Empati aşamasında bizi şaşırtan bulgu neydi? (2) Ideation'da hangi fikir en "cesur" olandı ve neden hayata geçmedi? (3) Prototip testinde neyi yanlış tahmin etmiştik?
Kapanış
Tasarım odaklı düşünme, doğrusal bir kontrol listesi değil; her aşamada geri dönülebilen, tekrar eden bir öğrenme döngüsüdür. Bu dersteki hataların ortak kökü aynıdır: süreci hızlandırmak için bir adımı atlamak ya da erken bir kararla kilitlemek. Ekibinizi bir üst seviyeye taşımak için tek başına yeni bir teknik öğrenmeniz gerekmiyor; mevcut sekiz adımı, geri dönüşlere ve doğrulanabilir varsayımlara açık şekilde işletmeniz yeterli.
Bu dersi kayıt olmadan izleyebilirsin. İlerlemeni kaydetmek, sertifika almak ve puan tablosuna girmek için ücretsiz üye ol: Kayıt Ol