"Paul Graham'ın 2003’de yazdığı bu makale, tasarım ve araştırma arasındaki farkı ve bu iki disiplinin nasıl birleştiğini inceliyor. Graham, iyi bir tasarımcının kullanıcının ihtiyaçlarına odaklanan ve kullanıcının ne istediğini değil, neye ihtiyaç duyduğunu belirleyen bir yaklaşım benimsemesi gerektiğini savunuyor. Ayrıca, tasarımcının kendisinin de bir kullanıcı olabileceğini ve bu durumun tasarımı daha da iyileştirebileceğini belirtiyor. Araştırmadan farklı olarak, tasarımın insan odaklı olduğunu ve bu nedenle tasarımın her zaman kullanıcıların beklentileri ve kısıtlamaları doğrultusunda şekillenmesi gerektiğini vurguluyor.

---

# Araştırma ve Tasarım Arasındaki İlişki Üzerine (Design and Research)

Ocak 2003

(Bu makale, NEPLS'nin 2002 yılı sonbahar toplantısında yapılan bir açılış konuşmasından alınmıştır.)

Bu ülkeyi ziyaret edenler genellikle şaşırır. Amerikalılar, bir sohbete ""ne yapıyorsun?"" diye sorarak başlamayı severler. Bu soruyu hiç sevmedim. Çünkü genellikle düzgün bir cevap alamazsınız. Ama sonunda bir çözüm buldum. Artık biri bana ne yaptığımı sorduğunda, doğrudan gözlerinin içine bakıyorum ve ""Lisp'in yeni bir lehçesini tasarlıyorum"" diyorum. Bu cevabı, ne yaptıklarının sorulmasından hoşlanmayan herkese tavsiye ederim. Konuşma hemen başka konulara dönecektir.

Ben programlama dilleri üzerine araştırma yapmıyorum. Ben sadece tıpkı birinin bir bina, sandalye veya yeni bir yazı karakteri tasarlaması gibi bir tane tasarlıyorum. Yeni bir şey keşfetmeye çalışmıyorum. Sadece programlama için iyi olabilecek bir dil inşa etmek istiyorum. Bazı yönlerden, bu varsayım hayatı çok daha kolay hale getirir.

Tasarım ve araştırma arasındaki fark, yeniye karşı iyi meselesi gibi görünüyor. Tasarım yeni olmak zorunda değil, ancak iyi olması gerekiyor. Araştırmanın iyi olması gerekmez, ama yeni olması gerekir. Bence bu iki yol en üstte birleşiyor: en iyi tasarım, yeni fikirler kullanarak öncüllerini aşar ve en iyi araştırma yeni olmayan fakat gerçekten çözülmeye değer sorunları çözer. Yani, sadece farklı yönlerden yaklaşarak aslında aynı hedefi amaçlıyoruz.

Bugün bahsedeceğim şey, hedefinizin arka plandan nasıl göründüğü. Programlama dillerini bir araştırma konusu olmaktan çok bir tasarım problemi olarak ele alındığında neyi farklı yapıyorsunuz?

En büyük fark, sizin kullanıcıya daha fazla odaklanmanızdır. Tasarım, bunun kimin için olduğunu ve neden buna ihtiyaçları olduğu sorularını sorarak başlar. Örneğin iyi bir mimar, daha sonra kullanıcılara dikte ettiği bir tasarım yaratarak değil, hedef kullanıcıları inceleyerek ve neye ihtiyaçları olduğunu bularak işe başlar.

Dikkat edin, ""ne istediklerini"" değil, ""ihtiyaçlarını"" söyledim. Tasarımcı olarak çalışmanın, müşteri ne derse onu yaparak bir tür kısa süreli aşçı gibi çalışmak anlamına geldiği izlenimini vermek istemiyorum. Bu, sanatta alandan alana değişir, ancak en iyi işin müşterilerin tam olarak onlara söylediklerini yapan insanlar tarafından yapıldığı herhangi bir alan olduğunu düşünmüyorum.

Müşteri, iyi tasarımın ölçüsünün kullanıcı için ne kadar iyi çalıştığı algısında her zaman haklıdır. Herkesi sıkan bir roman ya da oturması çok rahatsız edici bir sandalye yaparsanız, o zaman kötü bir iş yapmışsınızdır. Romanın ya da sandalyenin en ileri teorik ilkelere göre tasarlandığını söylemek bir savunma değildir.

Yani, kullanıcının işine yarayan bir şey yapmak, sadece kullanıcının size söylediklerini yapmak anlamına gelmez. Kullanıcılar tüm seçeneklerin ne olduğunu bilmezler ve çoğu zaman gerçekten ne istedikleri konusunda yanılıyorlar.

Bence paradoksun cevabı, kullanıcı için tasarlamanız gerektiğidir, ancak sadece kullanıcının istediğini söylediği şeyi değil, ihtiyaç duyduğu şeyi tasarlamanız gerektiğidir. Doktor olmaya oldukça benzer bir durumdur. Bir hastanın yalnızca semptomlarını tedavi edemezsiniz. Hasta size semptomlarını söylediğinde, onun sorununun aslında ne olduğunu bulmak ve bunu tedavi etmek zorundasınız.

Kullanıcıya bu odaklanma, iyi tasarım uygulamalarının çoğunun türetilebileceği ve çoğu tasarım sorununun etrafında merkezlendiği bir tür aksiyomdur.

İyi tasarım, kullanıcının ihtiyaç duyduğu şeyi yapacaksa, kullanıcı kimdir? Tasarımın kullanıcılar için olması gerektiğini söylediğimde, iyi tasarımın, en düşük ortak paydanın bir türünü hedeflediğini ima etmek istemiyorum. İstediğiniz herhangi bir kullanıcı grubunu seçebilirsiniz. Örneğin, bir araç tasarlıyorsanız, bu aracı yeni başlayanlardan uzmanlara kadar herkes için tasarlayabilirsiniz ve bir grup için iyi olan tasarım, diğeri için kötü olabilir. Sorun şu ki, bir grup kullanıcı seçmelisiniz.Tasarım hakkında konuşurken, bazen hedef kitlenin dışında da olsa, iyi veya kötü tasarım hakkında fikir yürütebileceğimizi düşünüyorum. Eğer tasarımcı, hedef kitlenin bir parçasıysa, iyi bir tasarım elde etme olasılığı daha yüksektir. Ancak, sadece kendinizin dışında bir grup için bir şeyler tasarladığınızda, genellikle daha basit ve sofistike olmayan bir şeyler ortaya çıkar.

Bu bir sorun olabilir çünkü kullanıcıya tepeden bakmak, ne kadar iyi niyetli olursanız olun, tasarımcıyı yozlaştırabilir. Örneğin, ABD'de çok az konut projesinin, içinde yaşamayı uman mimarlar tarafından tasarlandığından şüpheliyim. Aynı durumu programlama dillerinde de görebilirsiniz. C, Lisp ve Smalltalk, kendi tasarımcılarının kullanması için oluşturuldu. Cobol, Ada ve Java ise diğer insanların kullanması için yaratıldı.

Eğer bir şeyi aptallar için tasarladığınızı düşünüyorsanız, büyük ihtimalle aptallar için bile iyi bir şey tasarlamıyorsunuzdur.

En sofistike kullanıcılar için bir şeyler tasarlıyor olsanız bile, yine de insanlar için tasarlıyorsunuz. Araştırmada farklıdır. Matematikte soyutlamaları, insanların anlaması kolay olduğu için seçmezsiniz; ispatı daha kısa yapanı hangisiyse onu seçersiniz. Bunun genel olarak bilimler için geçerli olduğunu düşünüyorum. Bilimsel fikirlerin ergonomik olması anlamına gelmez.

Sanatta ise durum çok farklıdır. Tasarım tamamen insanlarla ilgilidir. İnsan vücudu garip bir şeydir, ama bir sandalye tasarlarken, insanlar için tasarlıyorsunuz ve bundan kaçış yok. Tüm sanat dalları, insanların çıkarlarına ve sınırlamalarına hitap etmelidir. Örneğin resimde, diğer tüm şeylerle içindeki insanların eşit olduğu bir tablo, olmayandan daha ilginç olacaktır. Rönesans'ın büyük resimlerinin hepsinin insanlarla dolu olması sadece tarihin bir rastlantısı değildir. Onlar olmasalardı, bir araç olarak resim yapmak, sahip olduğu bu prestije sahip olmayacaktı.

Beğenin ya da beğenmeyin, programlama dilleri de insanlar içindir ve insan beyninin de insan vücudu kadar topaklı ve kendine özgü olduğundan şüpheleniyorum. Bazı fikirlerin insanlar tarafından anlaşılması kolaydır, bazıları ise kolay değildir. Örneğin, ayrıntılarla uğraşmak için çok sınırlı bir kapasitemiz var gibi görünüyor. Programlama dillerini ilk etapta iyi bir fikir yapan gerçek budur; detayı halledebilseydik, sadece makine dilinde programlama yapabilirdik.

Ayrıca, dillerin öncelikle bitmiş programların bir formu olmadığını, fakat programların geliştirilmesi gereken bir şey olduğunu unutmamak gerekir. Sanatla ilgilenen herhangi biri, iki durum için farklı ortamlar isteyebileceğinizi söyleyebilir. Örneğin mermer, tamamlanmış fikirler için güzel ve dayanıklı bir ortamdır, ama yeni fikirler geliştirmek için tamamen esnek olmayan bir şeydir.

Bir program, tıpkı bir kanıt gibi, geçmişte her yerinde yanlış budama başlangıçlarına sahip olan bir ağacın budanmış bir versiyonudur. Dolayısıyla bir dilin testi, basitçe bitmiş programın içinde ne kadar temiz göründüğü değil, bitmiş programın yolunun ne kadar temiz olduğudur. Size mükemmel tamamlanmış programlar sunan bir tasarımın seçimi, size mükemmel bir tasarım süreci sunmayabilir. Örneğin, şimdi küçük taşlar gibi görünen iç içe geçmiş alıntılarla dolu birkaç makro yazdım, ancak onları yazmak, saatlerce süren deneme yanılma sürecinin en çirkin kısmıydı, ve açıkçası hala doğru olduklarından tam olarak emin değilim.

Biz sık sık bir dilin testinin, tamamlanmış programların içinde ne kadar iyi göründüğüymüş gibi hareket ederiz. Aynı programın iki dilde yazıldığını ve bir versiyonunun çok daha kısa olduğunu görmek çok inandırıcı görünüyor. Soruna sanat doğrultusundan yaklaştığınızda, bu tür testlere daha az bağımlı olursunuz. Mermer gibi bir programlama dili ile sonuçlanmak istemezsiniz.

Örneğin, Lisp'te okuma-değerlendirme-yazdırma döngüsü olarak adlandırılan interaktif bir üst seviyeye sahip olmak yazılım geliştirmede büyük bir kazançtır. Aynı zamanda, bir tanesine sahip olduğunuzda, bunun dilin tasarımı üzerinde gerçek etkileri vardır.Bir dilin değişkenlerini kullanmadan önce tanımlamanız gerektiğini düşünün. Sanki yüksek bir binanın tepesine çıkmadan önce merdivenlerini inşa etmek zorundasınız. Yalnızca üst düzey ifadeler yazarken, x'e bir değer atayabilmek ve ardından x'e bir şeyler yapmaya başlamak istersiniz. Ama önce x'in ne tür bir değişken olduğunu belirtmek istemez misiniz? 

Bazıları bu fikre itiraz edebilir, ancak bir dilin uygun olması için bir üst düzeye sahip olması gerektiğini düşünüyorum. Eğer zorunlu tür bildirimleri bir üst düzey ile uyumlu değilse, o zaman tür bildirimlerini zorunlu kılan hiçbir dilin programlanması uygun olamaz.

Pratikte, iyi bir tasarım elde etmek için kullanıcılarınıza yaklaşmanız ve onlara yakın olmanız gerekir. Fikirlerinizi, özellikle başlangıçta, gerçek kullanıcılar üzerinde sürekli olarak kalibre etmeniz gerekir. Jane Austen'ın romanlarının bu kadar iyi olmasının nedenlerinden biri, onları yüksek sesle ailesine okumasıdır. Bu nedenle, asla keyfine uygun olan gösterişli manzara tasvirlerine ya da gösterişçi felsefelere tenezzül etmez. Felsefe içerisinde bulunur, ancak felsefeyi bir etiket gibi yapıştırmak yerine hikayeyle iç içe geçirilir. 

Ortalama bir ""edebi"" roman açarsanız ve bunu arkadaşlarınıza sizin yazdığınız bir şeymiş gibi yüksek sesle okuduğunuzu hayal ederseniz, böyle bir şeyin okuyucuya nasıl bir dayatma olduğunu fazlasıyla hissedeceksiniz.

Yazılım dünyasında bu fikir, daha kötü daha iyi olarak bilinir. Aslında, daha kötü daha iyi kavramında birbirine karışmış birkaç fikir var, bu yüzden insanlar hala daha kötünün gerçekten daha iyi olup olmadığı konusunda tartışıyorlar. Ancak bu karışımdaki ana fikirlerden biri, yeni bir şey inşa ediyorsanız, mümkün olan en kısa sürede kullanıcıların önüne bir prototip koymanız gerektiğidir.

Alternatif yaklaşım, Hail Mary stratejisi olarak adlandırılabilir. Bir prototipi hızlı ve kademeli olarak geliştirmek yerine, bitmiş, tamamlanmış ürünü tek uzun bir geçiş süreci boyunca yaratmaya çalışırsınız. Bildiğim kadarıyla, bu bir felaket reçetesidir. Sayısız startup, İnternet miti sırasında kendilerini bu şekilde mahvetti. İşe yaradığı bir vakayı hiç duymadım.

Yazılım dünyasının dışındaki insanların anlayamayabilecekleri şey, daha kötü daha iyidir’in sanatın hemen her alanında bulunduğudur. Örneğin çizimde fikir Rönesans sırasında keşfedildi. Şimdi hemen hemen her çizim öğretmeni size doğru bir çizim elde etmenin doğru yolunun bir nesnenin çevresini yavaşça çevirmek olmadığını söyleyecektir, çünkü hatalar birikecek ve sonunda çizgilerin uyuşmadığını göreceksiniz. Bunun yerine, kabaca doğru yere birkaç hızlı çizgi çizmeli ve ardından bu ilk taslağı kademeli olarak iyileştirmelisiniz.

Çoğu alanda prototipler geleneksel olarak farklı malzemelerden yapılmıştır. Metalde kesilecek yazı tipleri, başlangıçta kağıt üzerinde bir fırça ile tasarlanmıştır. Bronza dökülecek heykeller mumla modellenmiştir. Halılara işlenecek desenler, mürekkep yıkamalı kağıt üzerine çizilmiştir. Taştan inşa edilecek binalar ahşapta daha küçük ölçekte test edilmiştir.

İlk kez onbeşinci yüzyılda popüler hale gelen yağlı boyayı bu kadar heyecan verici yapan şey, tamamlanmış işi prototipten gerçekten yapabilmenizdi. İsterseydiniz bir ön çizim yapabilirdiniz, fakat buna bağlı olmak zorunda değildiniz, resmi bitirirken tüm detayları çözebilir ve hatta büyük değişiklikler yapabilirsiniz.

Bunu yazılımda da yapabilirsiniz. Bir prototipin sadece bir model olması gerekmez; bitmiş ürün haline getirebilirsiniz. Bence yapabiliyorsan, bunu her zaman yapmalısın. Yol boyunca sahip olduğunuz yeni içgörülerden yararlanmanıza olanak tanır. Ama belki daha da önemlisi, moral için iyidir.

Tasarımda moral çok önemlidir. İnsanların bundan çok fazla bahsetmemesine şaşırıyorum. İlk çizim öğretmenlerimden biri bana şöyle dedi: Bir şey çizerken canın sıkılırsa, çizim sıkıcı görünecektir. Örneğin, bir bina çizmeniz gerektiğinizi ve her tuğlayı tek tek çizmeye karar verdiğinizi varsayalım. Bu, sıkıcı bir süreç olurdu, değil mi? Ama eğer biraz daha soyut bir şekilde düşünür ve sadece bina çizmek yerine bir hikaye anlatmak istediğinizi düşünürseniz, işte o zaman çizim süreci daha keyifli hale gelir. Bu yüzden, daha kötü daha iyi felsefesini sadece yazılım dünyasında değil, hayatın her alanında uygulayabilirsiniz.Eğer bir şeyler inşa etmeye karar verirsen, yolun yarısında sıkılmamak ve detaylara dalmak önemlidir. Çünkü bazen, tuğlaları tek tek incelemek yerine mekanik bir şekilde yapmaya başlarsan, sonuç sadece bir çizimden ibaret olabilir. Oysa bir prototipi aşamalı olarak geliştirerek bir şeyler inşa etmek, moral açısından çok daha iyidir. Çünkü bu senin ilgini canlı tutar. 

Yazılım dünyasında benim bir kuralım var: her zaman çalışan bir koda sahip ol. Eğer bir saat içinde test edebileceğin bir şey yazıyorsan, yakın bir ödül beklentisine sahip olmak seni motive eder. Aynı şey sanatta ve özellikle yağlı boya resimlerinde de geçerlidir. Çoğu ressam, bulanık bir eskizle başlar ve yavaş yavaş düzeltir. Bu şekilde çalışırsan, prensipte günü bitirmiş gibi hissetmezsin. Hatta ressamlar arasında bir deyim vardır: ""Bir resim asla bitmez, sadece üzerinde çalışmayı bırakırsın."" Bu fikir, yazılım üzerinde çalışmış olan herkese tanıdık gelecektir.

Moral, bir şeyler tasarlamanın zor olmasının bir başka nedenidir. Kendinden hoşlanmadığın bir şeye ilgi duymak oldukça zordur. Bir şeyi iyi yapmak için, ""Vay canına, bu gerçekten harika"" diye düşünmelisin, ""ne boktan şey; bu aptallar buna bayılacak"" şeklinde değil.

Tasarım, insanlar için bir şeyler yapmak anlamına gelir. Ancak sadece insan olan kullanıcılar için değildir. Tasarımcı da insandır.

Bunca zamandır ""tasarımcı"" hakkında konuştuğuma dikkat et. Tasarımın iyi olması genellikle tek bir kişinin kontrolü altında olmasını gerektirir. Yine de birkaç kişinin bir araştırma projesinde işbirliği yapması da mümkün görünüyor. Bu bana araştırma ve tasarım arasındaki en ilginç farklılıklardan biri gibi görünüyor.

Sanatta işbirliğinin birçok popüler örneği var, ancak bunların çoğu nükleer füzyondan ziyade moleküler bağlanma vakaları gibi görünüyor. Operada, bir kişinin librettoyu yazması ve diğerinin müziği yazması yaygındır. Ve Rönesans boyunca, İtalyan resimlerinin arka planındaki manzaraları yapmak için genellikle kuzey Avrupa'dan ustalar kullanıldı. Fakat bu gerçek bir işbirliği değildir. Onlar daha çok Robert Frost'un ""iyi çitler iyi komşular sağlar"" örneklerine benziyor. İyi tasarım örneklerini birbirine iliştirebilirsin, ancak bireysel her projede kontrolün bir kişide olması gerekmektedir.

İyi tasarımın bir kişinin her şeyi düşünmesini gerektirdiğini söylemiyorum. Muhakemeni güvendiğin birinin tavsiyesinden daha değerli bir şey yoktur. Ancak konuşma bittikten sonra ne yapılacağına dair karar bir kişiye bırakılmalıdır.

Neden araştırma ortak çalışanlar tarafından yapılabilir ancak tasarım yapılamaz? İlginç bir soru ve cevabını bilmiyorum. Belki tasarım ve araştırma birleşirse, en iyi araştırma aynı zamanda iyi tasarımdır ve aslında ortak çalışanlar tarafından yapılamaz. En ünlü bilim adamlarının çoğu yalnız çalışmış gibi görünüyor. Ancak bunun bir model olup olmadığını söyleyecek kadar fikrim yok. Basitçe pek çok ünlü bilim adamı, işbirliğinin daha az yaygın olduğu zamanlarda yalnız çalışmış olabilir.

Bu söylenti bilim dallarında ne olursa olsun, sanatta gerçek işbirliği yok denecek kadar az görünüyor. Komite tarafından yapılmış bir tasarım, kötü tasarımın eş anlamlısıdır. Neden böyle? Bu sınırlamayı aşmanın bir yolu var mı?

Bu durumun öyle olmadığını düşünmeye meyilliyim. İyi tasarım bir karar veren kişi gerektirir. Nedeni, iyi tasarım bir parçanın tamamı olmalıdır. Tasarım sadece insanlar için değil, bireysel insanlar içindir. Bir tasarım bir kişinin aklına yatan bir fikri temsil ediyorsa, fikir kullanıcının aklına yatmalıdır.""""

---

İlişkili Konseptler: tasarım ve araştırma, programlama dili tasarımı, kullanıcı merkezli tasarım, tasarım süreci, prototip iyileştirme, tasarım vs araştırma, kullanıcılar için programlama, tasarım morali, bireysel vs işbirlikçi tasarım, tasarım dikte etme, kullanıcı ihtiyaçları vs istekleri, Daha Kötüsü Daha İyi konsepti, etkileşimli tasarım, sofistike için tasarım, komite tarafından tasarım."