Blog

Okunabilir Tasarım Sistemleri & AEO

Figma kütüphanelerini YAML ve Markdown tabanlı tek bir DESIGN.md dosyasına dönüştürerek, AI kod ajanlarının marka uyumlu UI üretmesini ve arama motorlarında AEO/GEO görünürlüğü kazanmasını sağlama.

Okunabilir Tasarım Sistemleri & AEO
İçindekiler

Web tasarımı ve frontend geliştirme süreçlerinde, Figma kütüphaneleri ve stil dökümanları geleneksel olarak sadece insanlar için hazırlanmıştır. Ancak kod tabanlarımızda geliştirmeleri yürüten yapay zekâ ajanları ve tarayıcı botları bu görsel kaynakları doğrudan okuyamaz. Çözüm, tasarım sistemimizi makinelerin en rahat parse edebileceği Markdown ve YAML formatında tek bir dosyaya (DESIGN.md) dönüştürmektir. Bu incelemede, Vercel'in Geist sisteminde de uyguladığı bu tasarım modelini ve bu modelin yapay zekâ motorlarındaki görünürlüğümüze (AEO/GEO) olan doğrudan katkılarını inceliyorum.

DESIGN.md: Makinelerin Tasarımı Anlaması

Tasarım kararlarımızı (renk kodları, font boyutları, kenarlık yarıçapları, boşluk kuralları) kod ajanlarının okuyabileceği şekilde yapılandırmak, yapay zekanın sitenin görsel dilini bozmadan (design drift) geliştirme yapabilmesini sağlar. Bir DESIGN.md dosyası, üst bilgisinde (YAML front-matter) tüm renk paletlerini ve tasarım token'larını taşırken, altındaki gövdede (markdown prose) tasarım ilkelerini barındırır. Peter Yang'ın önerdiği design.md öncelikli geliştirme akışı sayesinde, ajan önce tasarım kurallarını okur, ardından bileşenleri kodlar ve son olarak insan gözüyle doğrulanıp yayına alınır. Bu yaklaşım, ajanların jenerik ve kalitesiz arayüzler (AI slop) üretmesini engeller. Bu prensipleri kullanarak nasıl dönüşüm odaklı web projeleri hazırladığımı görmek için Dijital Rakip ve Web Geliştirme çözümlerimizi inceleyebilirsiniz.

Impeccable ile Ajan UI Üretiminde Linting

Tasarım kurallarını sadece yazmak yetmez, ajanın kod yazarken bu kurallara uymasını mekanik olarak zorunlu kılmak gerekir. İşte bu noktada Impeccable gibi tasarım-sistemi-uyumlu linter araçları devreye girer. Ajan kod tabanında bir dosyayı değiştirdiğinde, linter arka planda çalışarak DESIGN.md dosyasındaki kurallarla kodu karşılaştırır. Palette olmayan bir renk kullanıldığında veya kuralsız bir kenarlık yarıçapı girildiğinde ajana anında geri bildirim vererek hatayı düzeltmesini talep eder. Vercel'in de vurguladığı gibi, ajan kalitesini artırmak bir zevk (taste) problemi değil, test edilebilir kurallarla yönetilen bir mühendislik problemidir. Mekanik kontrolleri otomatikleştirdikten sonra, estetik ve görsel kalitenin son kararı her zaman insan onay kapısında kalmalıdır.

AEO ve GEO Görünürlüğünü Artırma

Sitenin yapay zekâ motorlarında kaynak gösterilmesini (citation) sağlamak, modern SEO dünyasının en kritik hedefidir. Burada iki katmanı birbirine karıştırmamak gerekir: DESIGN.md kod ajanlarının arayüz üretirken uyacağı kuralları taşır; arama ve cevap motorlarının gördüğü şey ise üretilen sayfanın kendisidir. Yani makine okunabilirliği tasarım tarafında ajan kalitesini, yayın tarafında ise sayfanın alınabilirliğini iyileştirir - ikisi aynı dosya değildir. Programatik üretim süreçleriyle birleştiğinde bu ayrım daha da önemlidir; ayrıntısı Programmatik SEO ve Yapay Zekâ rehberinde ele alınmıştır.

Çalışılmış Örnek: Tek Bir Buton Kuralının Makineye Aktarılması

Aşağıdaki akış, insanlara yazılmış bir tasarım kuralının makineye aktarılınca ne kazandırdığını tek bir bileşen üzerinden gösterir. Örnek temsilîdir; belirli bir müşteri projesine ait veri içermez.

Girdi. Tasarım dosyasında yazan kural şudur: birincil butonlar marka mavisi, 12 piksel köşe yarıçapı, yalnız sayfada bir kez kullanılır. Bu cümle bir insan için nettir; bir kod ajanı için ölçülebilir değildir, çünkü ne rengin token adı ne de kuralın nerede biteceği yazılıdır.

  1. Kuralı token'a çevirme: Renk, yarıçap ve boşluk değerleri ada bağlanır. Ajan artık serbest bir renk kodu yazmaz; ada başvurur. Aynı değer sonradan değiştiğinde tüm bileşenler tek yerden güncellenir.
  2. Kısıtı yazıya dökme: Sayfada tek birincil buton kuralı, gövde metninde değil kontrol edilebilir bir kısıt olarak yazılır. Yazılmamış kısıt, ajan için var olmayan kısıttır.
  3. Ajanın üretimi: Ajan bileşeni üretir, ancak ikinci bir birincil buton ekler ve palette olmayan bir gri kullanır.
  4. Mekanik geri bildirim: Linter iki ihlali de yakalar ve ajana geri gönderir; ajan düzeltip yeniden dener. Bu tur insan gözü olmadan tamamlanır.
  5. İnsan kapısı: Mekanik kontrolleri geçen çıktı insana gelir. İnsanın bakacağı şey artık renk kodu değil, arayüzün amaca hizmet edip etmediğidir.

Çıktı. Aynı kural artık üç yerde birden geçerlidir: tasarımcının kafasında, ajanın ürettiği kodda ve kod incelemesinde. Kazanç ajanın daha zeki olması değil, kuralın ölçülebilir hâle gelmesidir; ölçülemeyen kural her üretimde yeniden tartışılır.

Veri ve Ölçüm: Makine Okunabilirliği Neyi Değiştirir, Neyi Değiştirmez?

Bu alanda en değerli veri, neyin gerekmediğini söyleyen resmî ifadedir - çünkü makine okunabilirliği etrafında satılan işlerin bir kısmı arama tarafında karşılığı olmayan işlerdir.

Google'ın arama dokümantasyonu açıktır: AI Overviews veya AI Mode içinde görünmek için ek bir gereklilik ya da özel bir optimizasyon bulunmadığını, sayfanın yalnızca indekslenmiş ve snippet ile gösterilmeye uygun olması gerektiğini yazar; yeni makine-okunur dosyalar, yapay zekâ metin dosyaları veya özel bir schema.org işaretlemesi eklemenin gerekmediğini de belirtir. Aynı şekilde Google-Extended tokenı aramaya dahil olmayı etkilemez ve sıralama sinyali değildir.

Buradan çıkan ayrım şudur: DESIGN.md ve linter katmanı üretim kalitesini ölçülebilir kılar; sayfanın cevap motorlarında alınabilir olması ise içeriğin kendisiyle ilgilidir. İkisini tek bir vaatte birleştirmek yanlış olur. Ölçüm de buna göre ikiye ayrılır. Tasarım tarafında: linter ihlal sayısı, ajanın ilk denemede geçme oranı, token dışı değer kullanımı. Yayın tarafında: sayfanın sunucudan tam HTML olarak gelip gelmediği, bot ziyaret sayısı ve kaç sorunun bir başlıkla karşılığının bulunduğu. Dört tasarım metriği haftalık, üç yayın metriği aylık okunur.

Hata Desenleri: Makine Okunabilirliği Adına Yapılan Üç Yanlış

Tasarım dosyasını SEO aracı sanmak. Depoda duran bir tasarım belgesi arama motorlarının gördüğü bir varlık değildir; onu görünürlük kaldıracı gibi sunmak ölçülemeyen bir vaattir. Doğru çerçeve, bu belgenin ajan üretim kalitesini artırdığı, kalitenin de dolaylı olarak sayfanın işine yaradığıdır.

Kuralı yazıp mekanik kontrol koymamak. Yalnız yazılmış kural, ajanın uymayı unutabileceği bir öneridir. Kuralın değeri, ihlalin otomatik yakalanmasıyla ortaya çıkar; kontrolsüz belge birkaç sürüm sonra gerçekle uyumunu kaybeder.

İnsan onayını mekanik kontrolle karıştırmak. Linter renk, boşluk ve yarıçap gibi ölçülebilir şeyleri denetler; arayüzün amaca hizmet edip etmediğine karar veremez. Mekanik kontrol insan kapısını ucuzlatır, yerine geçmez. Bu ayrımın otomasyon tarafındaki karşılığı otonom ajanlarda insan onayı yazısındaki onay kapısı tartışmasıdır.

Hangi Kural Nereye Yazılır?

Makine okunabilirliği çalışmasının en pratik çıktısı, her kuralın hangi katmana ait olduğunu gösteren bir ayrımdır. Aynı kuralı iki katmana birden yazmak, ikisinin zamanla çelişmesine yol açar.

Kural türüYaşadığı yerDenetleyen
Renk, boşluk, yarıçap değeriTasarım token dosyasıLinter
Bileşen kullanım kısıtıTasarım belgesi kısıt bölümüLinter + kod incelemesi
İçerik yapısı ve başlık düzeniSayfa içeriğinin kendisiİçerik kalite kapısı
Erişilebilirlik gereksinimiBileşen tanımıOtomatik test
Estetik ve ton kararıYazılı ilkeİnsan

Tablonun son satırı kasıtlıdır: her kuralın makineye devredilmesi hedef değildir. Ölçülebilir olanı otomatik denetlemek, yargı gerektireni insanda bırakmak; bu ayrım netleştiğinde ajanla çalışmak hız kazandırır. Ayrım bulanık kaldığında ise iki taraf da birbirini bekler ve süreç, elle yapılan hâlinden yavaşlar.

Bu çalışmanın sınırını da yazmak gerekir: makine okunabilir bir tasarım sistemi, arkasında iyi bir tasarım kararı yoksa yalnızca tutarlı biçimde vasat arayüzler üretir. Tutarlılık kaliteyi çoğaltır; yerine geçmez.

Uygulamaya geçmek isteyen bir ekip için sıra şudur: önce mevcut arayüzde fiilen kullanılan renk, boşluk ve yarıçap değerleri sayılır - çoğu projede bu sayı beklenenin iki katı çıkar ve çalışmanın gerçek kapsamını buradaki fazlalık belirler. Ardından bu değerler adlandırılmış token'lara indirgenir ve hangi bileşenin hangi token'ı kullanacağı yazılır. Üçüncü adımda kısıtlar - bir sayfada kaç birincil eylem olabileceği, hangi bileşenin hangi bağlamda kullanılamayacağı - ölçülebilir cümlelere çevrilir. Dördüncü adımda mekanik denetim devreye alınır ve ilk hafta yalnız uyarı üretir; ihlaller kapandıkça denetim engelleyici hâle getirilir. Beşinci adımda ajan üretimi bu kurallara bağlanır ve ilk denemede geçme oranı ölçülmeye başlanır. Bu oran zamanla artmıyorsa sorun ajanın kendisinde değil, kuralların ölçülebilir yazılmamış olmasındadır; kuralı düzeltmek her zaman modeli değiştirmekten ucuzdur.

Son bir uyarı, bu çalışmanın ömrüyle ilgilidir. Tasarım belgesi kod tabanının yanında yaşamıyorsa, birkaç sürüm içinde gerçekle uyumunu kaybeder ve ajan artık var olmayan bir sistemi referans alır. Belgeyi arayüzle aynı depoda tutmak, değişikliği aynı incelemeden geçirmek ve mekanik denetimi sürekli çalıştırmak; bu üçü olmadan makine okunabilirliği bir kerelik bir tazeleme çalışması olarak kalır ve altı ay sonra yeniden yazılması gerekir. Kalıcı olan tek şey, kuralın yaşadığı yerin arayüzle aynı hızda güncellenmesidir; belge geride kaldığı anda ajan da geride kalır.

🚀 Bu konuda profesyonel destek mi arıyorsunuz?

SEO, AEO ve GEO Optimizasyonu hizmetimizi inceleyin.

Çözümü İncele →

Sıkça Sorulan Sorular

DESIGN.md dosyası arama motoru görünürlüğünü artırır mı?

Doğrudan artırmaz. Depoda duran bir tasarım belgesi arama motorlarının gördüğü bir varlık değildir; kod ajanlarının arayüz üretirken uyacağı kuralları taşır. Görünürlüğü belirleyen şey üretilen sayfanın kendisidir: indekslenebilirliği, snippet uygunluğu ve içeriğin soruyu gerçekten yanıtlaması. Tasarım belgesinin katkısı dolaylıdır ve üretim kalitesi üzerinden gelir.

Yapay zekâ cevap motorlarında görünmek için özel bir işaretleme gerekiyor mu?

Google'ın arama dokümantasyonuna göre gerekmiyor. Belge, AI Overviews veya AI Mode içinde görünmek için ek bir gereklilik ya da özel optimizasyon bulunmadığını; yeni makine-okunur dosyalar, yapay zekâ metin dosyaları veya özel bir schema.org işaretlemesi eklemenin gerekmediğini açıkça yazar. Ön koşul sayfanın indekslenmiş ve snippet ile gösterilmeye uygun olmasıdır.

Tasarım kurallarını yazmak tek başına yeterli mi?

Yeterli değildir. Yalnızca yazılmış kural, ajanın uymayı unutabileceği bir öneridir; değeri ihlalin mekanik olarak yakalanmasıyla ortaya çıkar. Linter renk, boşluk ve yarıçap gibi ölçülebilir kısıtları denetler ve ajana anında geri bildirim verir. Kontrolsüz bir belge birkaç sürüm sonra gerçekle uyumunu kaybeder.

Linter varsa insan incelemesine gerek kalır mı?

Kalır. Mekanik kontrol ölçülebilir kuralları denetler; arayüzün amaca hizmet edip etmediğine, tonun doğru olup olmadığına karar veremez. Doğru kurgu, mekanik kontrollerin insan kapısını ucuzlatması ama yerine geçmemesidir: ölçülebilir olan otomatik denetlenir, yargı gerektiren kısım insana kalır.

Makine okunabilirliğinin başarısı nasıl ölçülür?

Ölçüm ikiye ayrılır. Tasarım tarafında linter ihlal sayısı, ajanın ilk denemede geçme oranı ve token dışı değer kullanımı haftalık izlenir. Yayın tarafında ise sayfanın sunucudan tam HTML olarak gelip gelmediği, cevap motoru botlarının ziyaret sayısı ve kaç sorunun bir başlıkla karşılığı olduğu aylık okunur. İki grubu tek bir metrikte birleştirmek yanıltıcı olur.