Renk Değil İskelet: Yapay Zekâ Arayüzleri Neden Hep Aynı Görünüyor?

On iki farklı ürünün açılış sayfasını yan yana koyduğunuzu düşünün. Logolar, renkler ve yazı tipleri değişiyor. Biri mor geçişli, biri siyah-beyaz, diğeri pastel tonlarda. Fakat biraz geri çekildiğinizde aynı sayfayı tekrar tekrar görmeye başlıyorsunuz: ortalanmış büyük bir başlık, altında kısa açıklama, iki düğme, geniş bir ürün ekran görüntüsü ve hemen ardından üç özellik kartı.

Bu benzerlik çoğu zaman “Yapay zekâ zevksiz tasarım yapıyor” diye açıklanıyor. Sorun gerçekten zevk olsaydı daha iyi renk paleti, daha şık gölge veya farklı bir yazı tipi yeterli olurdu. Oysa bunları değiştirdiğimiz hâlde sayfanın tanıdıklığı kaybolmaz. Çünkü asıl yakınsama yüzeyde değil, iskelettedir.

Bu yazıda bir arayüzün yapısal parmak izini okumayı öğreneceğiz. Tema, bileşen ve makro yapı arasındaki farkı ayıracak; rastgele farklılık yerine kontrollü çeşitlilik kuracağız. Ardından Hallmark adlı Agent Skill’in yaklaşımından yararlanarak üç sayfalık doldurulmuş bir denetim yapacak, yeni tasarımın mevcut işlerden ne kadar ve hangi yönde ayrılması gerektiğini belirleyeceğiz.

Jeneriklik neden renk sorunu değildir?

Bir sayfanın görünümünü üç katmanda düşünebiliriz:

• Tema: Renk, yazı karakteri, köşe yuvarlaklığı, gölge, çizgi kalınlığı ve genel görsel ton.
• Bileşen: Düğme, kart, sekme, fiyat kutusu, referans alıntısı veya form gibi tekrar kullanılabilen parçalar.
• Makro yapı: Bu parçaların sayfa boyunca hangi sırada, ölçekte ve ilişkide yer aldığı.

Tema bir odanın boya ve malzemelerine, bileşenler mobilyalarına, makro yapı ise mimari planına benzer. Aynı planı farklı renklere boyadığınızda başka bir atmosfer elde edebilirsiniz; fakat odalar arasındaki dolaşım aynı kalır. Yapay zekâ arayüzlerindeki tekrar hissinin önemli bir bölümü de buradan doğar.

Örneğin şu iki sayfa yüzeyde farklı görünebilir:

• Birinci sayfa lacivert zeminde beyaz başlık, yuvarlak turuncu düğme ve 3B ürün görseli kullanır.
• İkinci sayfa krem zeminde serif başlık, köşeli siyah düğme ve çizim kullanır.

Fakat ikisinde de başlık ortadaysa, açıklama aynı genişlikteyse, iki çağrı düğmesi aynı yerdeyse ve görsel hemen altında duruyorsa yapısal parmak izleri büyük ölçüde aynıdır. Kullanıcı yeni bir marka görür; fakat yeni bir anlatım biçimi görmez.

Karar kuralı: Bir tasarımın özgünlüğünü sınarken önce renkleri zihninizde griye çevirin. Geriye kalan blok düzeni hâlâ tanıdık geliyorsa sorun büyük olasılıkla temada değil, makro yapıdadır.

Yapısal parmak izi nasıl çıkarılır?

Yapısal parmak izi, sayfanın ekran görüntüsünü tek bir etikete indirgemek değildir. Birkaç ekseni birlikte kaydettiğimiz kısa bir tanımdır. Böylece “Bu tasarım diğerine benziyor” gibi öznel bir yargıyı tartışılabilir kararlara dönüştürebiliriz.

Bir açılış ekranı için en az şu altı eksene bakmak yararlıdır:

1. Başlık konumu: Ortada mı, sol sütunda mı, görselin üstünde mi, ekranın kenarına mı yaslanıyor?
2. Gövde ilişkisi: Metin tek blok mu, iki sütun mu, ürünün kendisiyle iç içe mi?
3. Ayraç ve ritim: Bölümler boşlukla mı, çizgiyle mi, renk alanıyla mı, katmanlı panellerle mi ayrılıyor?
4. CTA düzeni: Tek eylem mi, iki eşit seçenek mi, form mu, aşağıdaki kanıt bölümüne geçiş mi?
5. Görsel rolü: Dekor mu, ürün kanıtı mı, anlatının merkezi mi, arka plan mı?
6. Hareket: Hiç yok mu, dikkati belirli bir sırayla mı taşıyor, yoksa yalnızca sürekli hareket eden süsler mi var?

Bunlara bilgi sırası da eklenebilir: Sayfa önce vaat mi sunuyor, problemi mi gösteriyor, ürünü çalışırken mi sergiliyor, yoksa müşteri kanıtıyla mı başlıyor? Aynı blokların sırasını değiştirmek bile anlatının mantığını değiştirebilir.

Doldurulmuş bir parmak izi örneği

Bu tablo sayesinde tasarım tartışması “Biraz daha yaratıcı olsun” seviyesinden çıkar. Tasarımcı veya ajan, hangi eksende değişiklik yapacağını ve değişikliğin kullanıcı deneyimine ne katacağını bilir.

Rastgelelik ile kontrollü çeşitlilik aynı şey değildir

Yapısal yakınsamayı fark edince kolay bir tuzağa düşebiliriz: Ajana “alışılmadık, şaşırtıcı, daha önce görülmemiş bir sayfa yap” demek. Bu talimat farklılık üretebilir; ama işe yarayan bir tasarım üretmeyi garanti etmez. Başlığı okunması zor bir yere taşımak veya düğmeyi gizlemek de farklılıktır. Farklılık tek başına kalite ölçütü değildir.

Kontrollü çeşitlilikte önce değişmeden kalacak sınırlar belirlenir. Örneğin:

• Kullanıcı ilk ekranda ürünün ne yaptığını anlayabilmeli.
• Birincil eylem diğer seçeneklerden ayırt edilebilmeli.
• Klavye odağı, okunabilirlik ve dar ekran davranışı korunmalı.
• Görsel unsur iddiayı desteklemeli; yalnızca boşluğu doldurmamalı.
• Hareket, anlam veya geri bildirim taşımalı; sırf hareket olsun diye eklenmemeli.

Sonra yalnızca seçili eksenlerde çeşitlilik aranır. Bir varyant başlığı sola alırken görseli ürün kanıtı olarak kullanabilir. İkincisi etkileşimli bir örneği merkeze koyup metni kenar açıklamasına dönüştürebilir. Üçüncüsü problemi gösteren bir “önce/sonra” karşılaştırmasıyla başlayabilir. Üçü de anlaşılır ve erişilebilir kalır; ama aynı anlatım kalıbını tekrar etmez.

Buradaki amaç zar atmak değildir. Yapısal seçim ile iletişim amacı arasında gerekçe kurmaktır. Örneğin güven gerektiren bir finans ürününde önce kanıt ve açıklama göstermek mantıklı olabilir. Deneyimlenerek anlaşılan bir yaratıcı araçta ise ürünün çalışan örneğini ilk ekrana taşımak daha güçlüdür.

Uygulama kuralı: Her sıra dışı yapısal karar için “Bu değişiklik hangi kullanıcı sorusuna daha iyi cevap veriyor?” sorusunu sorun. Net bir cevap yoksa karar büyük ihtimalle anlamlı çeşitlilik değil, süstür.

Hallmark’ın önerdiği şey: Ajana sonuç değil karar ortamı vermek

Hallmark, yeni bir model veya görsel üretici değil; Claude Code, Cursor ve Codex gibi kodlama ajanları için hazırlanmış, MIT lisanslı bir Agent Skill. Proje, ajanı yalnızca “güzel bir arayüz üret” talimatıyla baş başa bırakmak yerine tasarım bilgisini yüklenebilir referanslara, makro yapılara, proje geçmişine, öz-eleştiriye ve kalite kapılarına ayırıyor.

4 Ağustos 2026 tarihli araştırma anında depo sayfasında 21,3 bin yıldız ve 1,1 bin fork görünüyordu. Bu rakamlar ilginin göstergesi sayılabilir; tasarım kalitesinin kanıtı değildir. Projenin “daha iyi tasarım” iddiası da şimdilik büyük ölçüde kendi örneklerine dayanıyor. Bağımsız ve karşılaştırmalı bir sonuç değerlendirmesi olmadan Hallmark’ı kanıtlanmış reçete değil, incelenmeye değer bir yöntem olarak görmek daha sağlıklıdır.

Yöntemin güçlü tarafı, “zevk” denen belirsiz özelliği daha küçük işlemlere ayırmasıdır:

• Tekrarlanan makro yapıları fark et.
• Bağlama uygun referansları gerektiğinde yükle.
• Önceki proje kararlarını kaydet.
• Çıktıyı yalnız estetik beğeniyle değil, belirli hata sınıflarıyla eleştir.
• İlk çıktıyı nihai cevap sayma; anlamlı varyantları karşılaştır.

Bu yaklaşım, bir ajana sihirli biçimde insan zevki kazandırmaz. Daha sınırlı ama daha gerçekçi bir iş yapar: Ajanın tekrar eden varsayımlarını görünür kılar ve kararlarını sınanabilir bir sürece bağlar.

Proje hafızası neden tasarım çeşitliliğinin parçasıdır?

Bir ajan her göreve sıfırdan başlarsa yalnızca genel eğitiminde sık gördüğü kalıplara ve mevcut talimata dayanır. “Modern SaaS sayfası” dendiğinde benzer çözümlere dönmesi şaşırtıcı değildir. Üstelik her çıktı tek başına kabul edilebilir görünse bile art arda üretilen beş sayfa aynı iskelete yaklaşabilir.

Proje hafızası burada “Markamızın rengi mavidir” notundan daha fazlasını taşımalıdır. Hangi yapıların yakın zamanda kullanıldığını, neden seçildiğini, neyin işe yaramadığını ve yeni sayfanın hangi yönde ayrışması gerektiğini kaydetmelidir.

Doldurulmuş proje günlüğü kaydı

Proje: Takım içi araştırma aracı
Sayfa: Ürün açılış sayfası, sürüm 3
Ana kullanıcı: Dağınık kaynakları tek raporda birleştiren araştırma lideri
Korunacak amaç: İlk 10 saniyede kaynak → sentez → doğrulama akışını anlatmak
Son kullanılan yapı: Ortalanmış başlık + iki CTA + geniş ekran görüntüsü + üç kart
Tekrarlanmayacak karar: Özellikleri eşit ağırlıklı üç kartta sunmak
Yeni yapısal yön: Solda kaynak yığını, ortada dönüşüm hattı, sağda doğrulanmış rapor
Birincil CTA: “Örnek raporu incele”
Görselin görevi: Ürünü süslemek değil, bilginin dönüşümünü açıklamak
Hareket sınırı: Yalnız kullanıcı başlatınca üç aşamayı sırayla vurgulamak
Kabul ölçütü: Gri kutu görünümünde bile önceki iki sayfadan ayırt edilebilmek
Kaçınılacak risk: Akış diyagramının küçük ekranda okunamaz hâle gelmesi
Doğrulama: 390 px genişlikte sıralı dikey akış; klavye ile CTA erişimi; hareket azaltma tercihi

Böyle bir kayıt yalnızca gelecekteki ajana bağlam vermez. Ekipteki insanlar için de kararın gerekçesini korur. Üç ay sonra “Neden alışıldık kahraman alanını kullanmadık?” sorusu çıktığında cevap zevk tartışmasına değil, kullanıcı amacı ve önceki tekrar kaydına dayanır.

Üç sayfayı denetleme egzersizi

Şimdi kurgusal bir yazılım şirketinin mevcut üç sayfasını inceleyelim. Şirket araştırma ekiplerine kaynak toplama ve rapor hazırlama aracı satıyor. Yeni bir “doğrulama çalışma alanı” sayfası tasarlanacak.

İlk bulgu açıktır: İlk iki sayfa tema ve içerik bakımından farklı olsa da aynı yapısal aileye aittir. Üçüncü sayfa başlık konumunu değiştirmiştir; fakat yine klasik metin-sol, görsel-sağ bölünmesini kullanır. Yeni sayfada yalnızca başlığı sağa taşımak yeterli mesafe yaratmayacaktır.

Yeni doğrulama sayfasının temel kullanıcı sorusu şudur: “Bu sistem rapordaki bir iddiayı kaynağına kadar nasıl izliyor?” Bu soru, yapısal kararı da yönlendirebilir. İlk ekranda büyük bir slogan yerine tek bir iddia kartı gösterilir. Kullanıcı kartı seçtiğinde sayfa aşağı doğru üç bağlı katman açar: iddia, kaynak bölümü ve denetim durumu. Açıklama metni bu nesnelerin yanında kısa notlar hâlinde yer alır. Birincil eylem “Örnek iddiayı denetle” olur.

Bu tasarım mevcut sayfalardan şu eksenlerde ayrılır:

• Başlık, sayfanın mutlak merkezi olmaktan çıkar; ürün nesnesi anlatıyı başlatır.
• Görsel, ekran görüntüsü değil etkileşimli kanıt zinciridir.
• İki satış CTA’sı yerine görevi deneyimleten tek eylem kullanılır.
• Yatay blok dizisi yerine aşağı doğru açılan nedensel bir akış kurulur.
• Hareket dekor değil, kaynak ile iddia arasındaki ilişkiyi açıklayan geri bildirimdir.

Fakat yapısal mesafenin de sınırı vardır. Kullanıcı sayfanın ne anlattığını anlayamıyor, denetim eylemini bulamıyor veya etkileşim olmadan temel bilgiye erişemiyorsa özgünlük işlevi yenmiştir. Bu nedenle yeni tasarımın iki hâli sınanmalıdır: etkileşim çalışan tam sürüm ve hareket kapalıyken görülen durağan sürüm. İkisinde de iddia–kaynak–durum ilişkisi anlaşılabilmelidir.

“Slop testi”ni nasıl sağlıklı kullanmalı?

Hallmark, sık rastlanan yapay zekâ arayüz alışkanlıklarını kalite kapılarıyla yakalamaya çalışıyor. Buradaki değer, belirli bir görsel tercihi sonsuza kadar yasaklamak değil; ajanın varsayılan seçimini gerekçelendirmeye zorlamaktır. Çünkü ortalanmış başlık veya kart düzeni kendi başına kötü değildir. Problem, bağlam ne olursa olsun otomatik cevap hâline gelmesidir.

İyi bir kalite kapısı üç soruyu birlikte sorar:

1. Tekrar var mı? Bu yapı son projelerde gereğinden sık kullanıldı mı?
2. Gerekçe var mı? Seçim, kullanıcı görevi veya içerik yapısıyla açıklanabiliyor mu?
3. Bedel nedir? Farklılaşma okunabilirliği, erişilebilirliği, performansı veya bakım kolaylığını bozuyor mu?

Projenin README dosyasında 57, güncel slop-test dosyasında ise 58 kapıdan söz edilmesi küçük fakat öğretici bir tutarsızlıktır. Açık v1.2 çalışmalarıyla birlikte bu fark, skill’lerin sabit birer prompt değil, sürümü ve davranışı değişen bağımlılıklar gibi yönetilmesi gerektiğini gösterir. Bir ekip Hallmark veya benzeri bir skill kullanıyorsa sürümü sabitlemeli, değişiklikleri incelemeli ve kendi kabul testlerini üçüncü taraf kurallarından ayrı tutmalıdır.

Uygulanabilir bir çalışma döngüsü

Yeni bir sayfada kontrollü çeşitlilik ararken şu döngü yeterince küçüktür ve gerçek projede uygulanabilir:

1. Görevi tek cümlede tanımlayın: “Araştırma lideri, rapordaki bir iddianın hangi kaynağa dayandığını ilk ekranda anlayabilmeli.”
2. Son üç işin parmak izini çıkarın: Başlık, gövde, ayraç, CTA, görsel ve hareket kararlarını tabloya yazın.
3. Korunacak sınırları belirleyin: Okunabilirlik, birincil eylemin görünürlüğü, dar ekran davranışı ve erişilebilirlik.
4. Üç yapısal varyant üretin: Yalnız renkleri değil, anlatının başlangıç noktasını ve bilgi sırasını değiştirin.
5. Gri kutu testi yapın: Renk, logo ve gerçek metin olmadan varyantlar hâlâ birbirinden ayrılıyor mu?
6. Görev testi yapın: Kullanıcı ne sunulduğunu ve sıradaki eylemi açıklayabiliyor mu?
7. Kararı günlüğe yazın: Seçilen yapıyı, reddedilen alternatifleri ve gerekçeyi kaydedin.

Üç varyanttan biri çok özgün ama anlaşılmaz, biri güvenli ama önceki işlerin kopyası, üçüncüsü ise görevle uyumlu ve yapısal olarak farklı olabilir. Amaç en sıra dışı olanı seçmek değil; kabul sınırları içinde en anlamlı mesafeyi kurmaktır.

Sonuç: Zevk, denetlenebilir kararlar zincirine dönüşebilir

Bir ajana “daha zevkli tasarla” demek, hangi kararın neden değişmesi gerektiğini anlatmaz. Buna karşılık yapısal parmak izi, çeşitlilik eksenleri, proje günlüğü ve kalite kapıları belirsiz estetik talebi somut bir çalışma sistemine dönüştürür.

Hallmark bu yönde ilginç bir örnek sunuyor: tasarım bilgisini tek ve dev bir talimata sıkıştırmak yerine bağlama, yapılara, hafızaya ve öz-eleştiriye ayırıyor. Yine de popülerlik ile kanıtlanmış başarıyı karıştırmamak gerekir. Bağımsız değerlendirme olmadan doğru soru “Hallmark iyi tasarımı çözdü mü?” değil, “Bu yöntem bizim tekrarlarımızı görünür kılıyor ve gerçek kullanıcı görevini daha iyi çözen varyantlar üretmemize yardım ediyor mu?” olmalıdır.

İlk uygulama için yeni bir proje beklemeyin. Son ürettiğiniz üç sayfanın ekran görüntüsünü açın, renkleri görmezden gelin ve altı eksenli parmak izlerini çıkarın. Aynı iskelet tekrar ediyorsa yalnızca yeni bir tema istemeyin. Bir kullanıcı sorusu seçin, üç farklı bilgi sırası kurun ve her varyantı aynı kabul testiyle sınayın. Özgünlük böylece esrarengiz bir yetenek olmaktan çıkar; gerekçesi kaydedilen, sınırları korunan ve sonucu doğrulanan bir tasarım pratiğine dönüşür.

Kaynaklar

• Nutlope/hallmark GitHub deposu
• Hallmark SKILL.md
• Hallmark yapı çeşitliliği referansı
• Hallmark slop-test dosyası
• Hallmark yol haritası
• Agent Skills format belirtimi
• From Registry to Repository: How AI Agent Skills Are Written, Adapted, and Maintained