Fonksiyonel Sabitlik Tasarım Kararlarını Nasıl Daraltır
Fonksiyonel sabitlik, bir nesneyi ya da bileşeni yalnızca alıştığınız işleviyle görme eğilimi. Tasarım işinde bunun bedeli çözümü kaçırmaktan çok, problemi yanlış çerçevede sabitlemek. Konuyla ilgili anlatılanların bir kısmı da kaynağının söylediğinden fazlasını iddia ediyor.
Mum problemi ne gösterir, ne göstermez
Kavramın çıkış noktası Karl Duncker'in mum problemi. Katılımcıya bir mum, bir kutu raptiye ve kibrit verilir, mumu duvara sabitlemesi istenir. Çözüm kutuyu boşaltıp raf olarak kullanmaktan geçer, ama kutu raptiyeyle dolu geldiğinde çoğu kişi onu yalnızca kap olarak görür. Raptiyeler masaya boşaltılmış halde verildiğinde aynı kişiler çözümü kolayca buluyor.
Bu deneyin küçük çocuklarla yapılan versiyonu, beş yaş civarındaki çocukların bu tuzağa düşmediğini, etkinin altı yaş sonrasında belirdiğini gösteriyor. Buradan "çocuklar daha yaratıcıdır" sonucunu çıkarmak fazla iyimser. Deneyin gösterdiği şey daha dar: nesneyle ilgili birikmiş deneyim, o nesnenin alternatif kullanımını görmeyi zorlaştırıyor. Yani sabitlik yeteneksizlik değil, uzmanlığın yan ürünü.
Günlük hayat örnekleri işi çözmüyor
Bu konuda dolaşan tavsiyelerin çoğu vidayı bozuk parayla çevirmek, paketi anahtarla açmak gibi örneklere dayanıyor. Eğlenceli, ama tasarım masasına taşınmıyor. Ekranda karşınıza çıkan problem "elimdeki nesneyi başka nasıl kullanırım" değil, "bu problemi kim, neden benim tanımladığım gibi tanımladı" sorusu.
Somut hali şöyle: ekip "filtre panelini nasıl iyileştiririz" diye gelir. Bu cümle, çözümün filtre paneli olduğunu çoktan kabul etmiştir. Aynı ihtiyacı "kullanıcı aradığı ürünü nasıl daha az adımda buluyor" diye yazdığınızda arama, sıralama ve varsayılan liste de masaya gelir. Problem cümlesindeki isim, çözümün sınırını çiziyor.
Aynı tuzak bileşen kütüphanesinde
Tasarım sistemlerinde fonksiyonel sabitlik en çok isimlendirmeden geliyor. Bir bileşene Card dediğinizde ekip onu kart olarak kullanır; oysa davranışı bakımından tıklanabilir bir kapsayıcıdır ve liste satırı, bildirim ya da form grubu olarak da işini görür. Davranışa göre isimlendirilen bileşenler yeniden kullanılıyor, göründüğü şeye göre isimlendirilenlerin ikizi bir süre sonra kütüphaneye ekleniyor.
Bunu bir kütüphanede sayarak görmek mümkün: birbirinin yüzde seksenini paylaşan iki bileşen varsa, sorun genellikle kodda değil, ilk bileşenin adında.
Grup beyin fırtınası neden zayıf araç
Kaynaklarda kalıbı kırmanın yolu olarak neredeyse otomatik biçimde beyin fırtınası öneriliyor. Ortak odada, herkes birlikte, yüksek sesle. Bu yöntemi, herkesin önce tek başına yazıp sonra fikirlerin havuzda birleştirildiği düzenden daha zayıf bulurum. Sebebi basit: aynı anda tek kişi konuşabildiği için diğerleri sırasını beklerken kendi fikrini unutuyor, üstelik odada ilk söylenen fikir sonrakilerin çerçevesini belirliyor. Yargının ertelenmesi tavsiyesi de bunu kurtarmıyor, çünkü sorun eleştiri değil, sıra.
Sessiz turdan sonra tartışmaya geçmek ise işe yarıyor. Önce on beş dakika kimse konuşmadan yazar, sonra fikirler anonim biçimde okunur, tartışma bundan sonra başlar. Farklı disiplinlerden insanları çağırmanın faydası da asıl burada ortaya çıkıyor, çünkü herkesin listesi kendi alanının kalıbıyla dolu ve kalıplar birbirini kırıyor.
Problemi soyutlarken nerede durmalı
Problemi genelleştirmek işe yarıyor, ama sınırsız değil. "Filtre paneli" yerine "ürünü bulma" demek kapıyı açar; "kullanıcının ihtiyacını karşılama" demek ise elinizde tutunacak hiçbir şey bırakmaz. Soyutlama basamağını bir kademe çıkın, orada bir süre durun, çözüm gelmezse bir kademe daha. Baştan tepeye çıkarsanız üretilen fikirler test edilemeyecek kadar geniş olur ve ekip birkaç toplantı sonra ilk çözüme geri döner.