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

Tasarım Odaklı Düşünme: Tanımı Kısa Tut, Prototipi Erken Çıkar

Tasarım Odaklı Düşünme Pratikte Nasıl Yürütülür?

Tasarım odaklı düşünme çoğu yerde beş aşamalı bir şema olarak anlatılır: empati, tanım, fikir, prototip, test. Şemada sorun yok. Sorun, aşamaların sırayla ve birer kez yapıldığı varsayımında; pratikte prototip, tanım aşamasında verdiğiniz kararı bozar. Akışı bozulacağını bilerek kurmak gerekir.

Nerede işe yarar, nerede yaramaz

Çözümü bilinen, sadece uygulanması gereken işlerde bu süreç fazladan yük getirir. Fatura kesme akışını hızlandıracaksanız empati görüşmesi yapmanıza gerek yok, sürenin nereye gittiğine bakmanız yeter. Yaklaşım karşılığını, ekibin problemin ne olduğu konusunda hemfikir olmadığı yerde verir: kullanıcının söylediği ihtiyaçla ölçülen davranışın uyuşmadığı, ya da iki departmanın aynı soruna bambaşka isimler taktığı durumlar.

Empati aşamasını ne zaman kesmeli

Bu aşama pratikte görüşme, gözlem ve not tutmak demek. Zor kısmı başlamak değil, bitirmek. Kesme kuralı basit: yeni görüşme yeni bir şey söylemiyorsa aşama bitmiştir, sayıya bakmayın. Görüşme sayısını baştan takvime yazmak ise kendi kendini haklı çıkaran bir yatırıma dönüşür, çünkü ayrılan süre dolana kadar kimse durmak istemez.

Tanım aşamasına harcanan süre geri alınır

Yaygın söz şu: problemi doğru tanımlamak çözümün yarısıdır. Aynı metinler birkaç paragraf sonra prototipin öğrenme sağladığını, öğrenince yön değiştirmek gerektiğini söyler. İkisi aynı anda doğru olamaz. Prototip tanımı değiştirebiliyorsa, tanım aşamasında harcadığınız fazladan hafta bir yatırım değil, geri alınacak bir karardır.

Pratik karşılığı: problemi tek cümleye sıkıştır, yaz, tarih at, prototipten sonra aç. Cümle değişmediyse problemi zaten biliyordunuz, süreç onu doğrulattı. Değiştiyse, o cümleyi bir ay boyunca cilalamamış olmanız kârdır.

Prototip atılmak içindir

Prototipin tek işi bir soruyu cevaplamak. Hangi soruyu cevaplayacağı yazılmadan başlanan prototip, sonunda herkesin kendi beklediği cevabı gördüğü bir demoya dönüşür.

Bir projede prototipi doğrudan üretim kodunun içine yazmıştık; iki hafta sonra çalışıyor diye kimse atmaya kıyamadı ve prototip ürün oldu. Attığınızda canınızın yanmayacağı bir yerde durması, prototipin teknik bir detayı değil, sürecin çalışması için ön şartı.

Çapraz disiplinli ekip her zaman daha iyi değil

IDEO ve Google örnekleri bu yaklaşımın vitrini, ama oradan çıkarılan ders çoğunlukla yanlış okunuyor. Masaya farklı disiplinlerden insan oturtmak tek başına bir şey üretmez; fark, karar yetkisinin de dağıtılmış olmasından geliyor. Yetki tek kişideyse kalabalık ekip sadece toplantıyı uzatır, kararı yine aynı kişi verir ve geri kalanlar fikirlerini ikinci elden savunmak zorunda kalır.

Küçük ekipte başlayın, prototip bir soruyu cevaplayamadığında o soruya cevap verebilecek kişiyi çağırın. Ekibi baştan geniş kurmak, sürecin kendisinden önce koordinasyon maliyetini satın almak demek.