Tasarım Odaklı Düşünme: Üç Farklı Tanım, Tek İsim

Tasarım odaklı düşünme herkesin bildiğini sandığı, kimsenin aynı şeyi kastetmediği bir terim. Aynı toplantıda üç kişi bunu söylerken biri beş adımlı bir süreçten, biri bir tutumdan, biri de istediğin yerden çekip alacağın bir yöntem çantasından bahsediyor olabilir. Üçü de savunulabilir, ama aynı anda geçerli olduklarını varsaymak ekibi yavaşlatıyor.

Aynı ismin altındaki üç ayrı şey

Birinci okuma süreç: empati, problem tanımı, fikir üretimi, prototip, test. Bu okumada tasarım odaklı düşünme bir sıralamadır, adımların hangi sırayla geleceği bellidir ve ekip aynı adımda mı diye bakılabilir.

İkinci okuma zihniyet: varsayımı sorgulama alışkanlığı, çözümü kullanıcıdan başlatma refleksi. Burada ölçülebilir bir adım yoktur, davranış vardır. Bu yüzden "biz tasarım odaklı düşünüyoruz" cümlesi bu okumada neredeyse doğrulanamaz.

Üçüncü okuma araç kutusu: problemin şekline göre yöntem seçersin, kimi projede kullanıcı görüşmesi yaparsın, kimi projede doğrudan prototipe geçersin. Sabit bir sıra yoktur, seçim vardır.

Bu üçünün karışması masum bir terminoloji sorunu gibi görünür ama sonuçları somuttur. Süreç okumasıyla çalışan bir yönetici takvimde beş kutu görmek ister. Araç kutusu okumasıyla çalışan tasarımcı o kutuları gereksiz bürokrasi sayar. İkisi de haklıdır, çünkü aynı kelimeyle farklı şeyleri savunuyorlar.

Süreç modelleri birbirini tutmuyor, bu bir kusur değil

Yaygın olarak öğretilen beş adımlı model tek model değil. İngiltere Tasarım Konseyi'nin Çift Elmas modeli süreci dört evrede kurar ve odağını ayrışma ile yakınsama hareketine verir. Bazı ekipler empati adımını ayrı saymayıp araştırmanın içine katar, bazıları teste ayrı bir doğrulama evresi ekler.

Adım sayısının modelden modele değişmesi, bu adımların doğanın yasası olmadığını gösteriyor. Onlar bir işi konuşulabilir hale getirmek için konmuş sınırlar. Buradan çıkacak sonuç modelleri boşlamak değil, birini seçip ekipte sabitlemek ve o seçimin gerekçesini bilmek.

Hizalanma sözlükle değil, karar noktalarıyla kurulur

Bu konudaki en sık tavsiye, ekipte ortak bir tanım belirlemek. Kulağa mantıklı geliyor, pratikte pek işlemiyor: tanım toplantıda kabul edilir, iki hafta sonra herkes yine kendi okumasına döner. Üstelik aynı metinlerde hem "tek bir ortak tanımda anlaşın" hem de "esnek bir araç kutusu olarak kullanın" tavsiyesi yan yana durur. Bunlar birbirini yer.

Ortaklaştırılması gereken şey kelimeler değil, kararlar. Şu dört soruya yazılı cevabınız varsa tanımın kendisi büyük ölçüde önemsizleşir:

• Neyi kanıt sayıyoruz? Beş kullanıcı görüşmesi mi, canlıdaki bir ölçüm mü, ikisi de mi?
• Bir fikri kim durdurabilir, hangi gerekçeyle?
• Yinelemeyi ne zaman bitiriyoruz? Süre dolduğunda mı, belirlenen eşik geçildiğinde mi?
• Prototip derken ne kastediyoruz?

Bir projede ekipteki herkesin "prototip" dediği şey farklıydı: biri tıklanabilir bir Figma akışını, biri gerçek veriye bağlı çalışan bir dalı kastediyordu, ikisi arasındaki fark iki gün ile iki haftaydı.

Prototipin faturası kime çıkıyor

Tasarım odaklı düşünmenin "hızlı ve düşük maliyetli prototip" vaadi, prototipin ne olduğuna göre tamamen değişir. Kağıt üzerinde bir akış gerçekten ucuzdur. Kullanıcıya gerçekçi gelsin diye gerçek veriye bağlanmış, oturum açma gerektiren, sunucuda çalışan bir prototip ucuz değildir ve genellikle atılmaz, ürünün ilk sürümüne dönüşür.

Bu yüzden prototip kararını tasarım tarafı tek başına vermemeli. Test edilecek soruyu önce yaz, sonra o soruya cevap verecek en ucuz biçimi seç. Yerleşim ve akış sorusuna tıklanabilir bir maket yeter. Gecikmenin, hata durumlarının ya da gerçek veri çeşitliliğinin yarattığı sorunları sormak istiyorsan maket sana yanlış bir iyimserlik verir, orada çalışan bir sürüm gerekir.

Tasarım odaklı düşünmenin değeri, yöntemin adında değil bu tür ayrımları görünür kılmasında. Ekip hangi soruyu sorduğunu, neyi kanıt saydığını ve ne zaman duracağını biliyorsa süreç mi zihniyet mi tartışması kendiliğinden küçülür.