Tasarım sistemin Markdown'a sığıyorsa

Vercel'in kurucusu Guillermo Rauch'a göre sıradaki tasarım sistemin bir komponent kütüphanesi değil, bir Markdown dosyası.

Rauch tezini tek cümleyle attı: "Your next design system is… Markdown." Arkasındaki fikir şu — AI üretiminin bugünkü en zor problemi slop, yani teknik olarak doğru ama kimliksiz, özensiz çıktı. Rauch'a göre bunun çözümü daha iyi bir bileşen değil, yazılı bir zevk kaydı: DESIGN.md. Tasarım kararlarını, gerekçeleri ve sınırları tek bir düz metin dosyasında topluyorsun; o dosyayı hem modele hem ekibe okutuyorsun. Zevk, ilk kez organizasyon ölçeğinde kopyalanabilir hale geliyor.

Rauch'un tezi: DESIGN.md hem slop sorununun cevabı hem de zevki organizasyon ölçeğine yaymanın yolu.

Neden Markdown? Çünkü üretimi yapan artık çoğu zaman bir ajan ve ajanın en iyi okuduğu şey düz metin. Komponent kütüphanesi sonucu taşıyor: buton böyle görünür. Yazılı kural seti gerekçeyi taşıyor: buton neden böyle görünür, hangi durumda başka türlü görünür. AI bir ekranı saniyeler içinde üretebildiğinde kıt olan şey sonuç değil; tekrar edilebilir olan tek şey gerekçe.

Karşı cephe: sistem dosya değil, çalışan altyapı

Tasarım sistemleri dünyasının cevabı gecikmedi. İtiraza göre slop'u çözen şey bir metin dosyası değil, gerçekten çalışan bir tasarım sistemi: token'lar, bileşenler, kod seviyesinde zorlanan tutarlılık. DESIGN.md prototip araçlarına yardım eder; üretim ortamında işi bileşen taşır.

Karşı cephenin özü: dosya niyeti anlatır, tutarlılığı üretimde bileşen zorlar.

Tartışma büyüdükçe görünen üç şey

Birincisi: tez havada kalmadı, dosya ortada. Vercel kendi zevk kaydını vercel.com/design.md adresinde herkese açık yayımlıyor ve içi renk paleti listesi değil. İçinde bir karar hiyerarşisi var — gerçekler çerçeveden, çerçeve okunabilirlikten, okunabilirlik markadan önce gelir — ve yirmiye yakın "yapma" maddesi: dekoratif gradyan yok, cam efekti yok, ortalanmış hero altına kart grid'i yok, tekrarlanan metrik kutuları yok. Yanında ajanın kullanacağı herkese açık bir CSS API'si duruyor; çıktı bir eval harness'ından geçiyor, üretimdeki geri bildirim dosyaya geri besleniyor. Yani Vercel'in evinde DESIGN.md tam da tezin tarif ettiği şey: kural listesi değil, işletilen bir zevk kaydı. Bu döngünün adı tanıdık gelebilir — harness katmanını ürün tarafı için ayrıca yazdık.

İkincisi daha ilginç: format bir haftada meta oldu. Refero Styles, Linear'dan Notion'a 2.000'den fazla ürünün tasarım dilini hazır DESIGN.md dosyalarına çevirip yayımladı; kopyala, projene at, "bu stilde yap" de. Buradaki ironiyi kaçırma — slop'u çözmek için önerilen format, kopyala-yapıştır kütüphanesine dönüştü. Herkes Linear'ın dosyasını yapıştırırsa çıktı yine slop; sadece daha şık bir slop. Dosyanın değeri formatında değil, içindeki gerekçenin sana ait olmasında.

Üçüncüsü: asıl zor sorular Rauch'un altındaki cevaplarda soruldu. Bir cevap (@RasmusAW) itirazı tek cümleye indirdi: dosya kuralları tutabilir ama o kuralları üreten tartışmayı tutamaz — zevk, bir sonraki ekip stylesheet'i değil kararı devraldığında ölçeklenir. Bir diğeri (@RealRossMc) yönetişimi sordu: dosyayı kim değiştirir? Kötü bir çıktı kanıttır, otomatik olarak yeni kural değil; karar katmanı yoksa sistem ya aynı dersi sonsuza kadar tekrar öğrenir ya da bir ekibin geçici çözümü herkese standart olur. Üçüncüsü (@trydotworks) teknik tarafı hatırlattı: Markdown'daki kuralı zorlayan bir mekanizma yok — drift'i ne engelleyecek?

Bir de eğilmemiz gereken üçüncü bir okuma var. UX Collective, 2027'ye kadar UX işinin sabit arayüz üretmekten otonom sistemlerin davranışını, sınırlarını ve kontrol mekanizmalarını tanımlamaya kayacağını yazdı. Balsa UI agent-native bir komponent kütüphanesi çıkardı — bileşenin kendisi de ajana göre yeniden tasarlanıyor. Fikrin kökü de yeni değil: Rauch 2015'te Pure UI'ı yazarken de aynı şeyi savunuyordu — durumları tarif et, render'ı başkası yapsın. On yıl sonra spec Markdown, render eden bir ajan.

Üçüncü okuma: bu, on yıllık bir fikrin ajan çağına çevirisi — durumları tarif et, render'ı başkası yapsın.

Soru "dosya mı kütüphane mi" değil

İki cephe de yarı haklı. Komponent kütüphanesi ölmüyor; üretim ortamında tutarlılığı hâlâ o zorluyor. Ama Rauch'un işaret ettiği boşluk gerçek: kütüphanen gerekçeni taşımıyor. Ekibinden ayrılan kıdemli tasarımcıyla birlikte giden şey bileşenler değil, hangi durumda hangi kararın verileceği bilgisi. Ve cevaplardaki yönetişim sorusu bizim de sorumuz: dosya, kararların çıktısıdır — dosyayı kimin, neye dayanarak değiştireceği belli değilse yazılı zevk de drift eder. Asıl soru şu: gerekçen yazılı mı, yoksa birinin aklında mı?

İşin ölçüsü "ne çizdim"den "neyi tekrar edilebilir hale getirdim"e kayıyor.

Tasarımcının çıktısı ekrandan kural setine kayarsa, portfolyo da performans değerlendirmesi de aynı yöne kayar. Ekran güzel olabilir; senden sonra da güzel ekran üretilebiliyorsa sistem kurmuşsun demektir.

Senin tasarım sisteminde gerekçe nerede duruyor — Figma dosyasında mı, birinin aklında mı, yazılı bir yerde mi? Biz gerekçesini yazamayan sistemin AI çağında sistem sayılmayacağını düşünüyoruz. 🧱