AI ile üretilen ekranların boşluk, tipografi ve formlarını eşleştirmek için React uygulamalarında tasarım tokenları ve bileşen kuralları kullanarak nasıl prompt yazılacağını öğrenin.
UI tutarsızlığı genellikle tıklarken tuhaf gelen küçük detaylarda ortaya çıkar. Bir sayfada bol padding varken diğerinde sıkışık hissedersiniz. Başlıklar boyut atlar, butonlar şekil ve renk değiştirir, aynı input ekranlara göre farklı davranır.
Çoğunlukla sürüklenme birkaç temel karardan kaynaklanır:
Bu, ekranlar ayrı promptlarla üretildiğinde yaygındır. Her prompt aslında yeni bir başlangıçtır, bu yüzden model eksik kararları tahmin ederek doldurur. “Modern stil kullan” gibisinden bir talimat bile yüzlerce küçük seçimi bırakır: 8px mi 12px mi boşluk, 14px mi 16px mi gövde metni, hatalar ne zaman gösterilecek, birincil buton nasıl görünecek.
İki ya da üç sayfayı manuel temizleyebilirsiniz ama bu ölçeklenmez. Bir kerelik CSS düzeltmelerini takip edersiniz, stilleri dosyalar arasında kopyalarsınız ve formları tekrar düzeltirsiniz. Kurallar kafanızdadır, projede değil.
Bugün bir giriş ekranı, yarın profil ekranı ürettiğinizi düşünün. Biri hataları sadece submit’te gösterirken diğeri blur’da gösteriyorsa kullanıcı fark eder. Birincil buton yüksekliği ekranlar arasında değişiyorsa uygulama yamalı gibi hissedilir.
Her ekran aynı paylaşılan sistemi (tasarım tokenları + küçük bir bileşen ve form kuralı seti) takip ettiğinde tutarlılık varsayılan olur.
Tasarım tokenları, UI genelinde tekrar kullandığınız basit isimlendirilmiş değerlerdir. Her ekranda “rahat padding” demek yerine space-4 gibi bir token kullanırsınız. “Hafif yuvarlak” yerine radius-md kullanırsınız. İsim sabit kalır, daha sonra hangi değere denk geldiğini değiştirebilirsiniz.
Tokenlar, her ekranın paylaşmasını istediğiniz karar kümesidir. Tat ve tahmin gereksizliğini ortadan kaldırırlar; işte üretim veya yeni sayfa oluştururken sürüklenmeye neden olan tam da budur.
Tipik tokenlar boşluk, tipografi, renk, şekil ve az miktarda yükseltiyi kapsar. Pratik kazanç: bir başlık her zaman aynı boyutu kullanır, bir kart her zaman aynı padding’e sahiptir ve birincil buton aynı renk ve radius’u korur.
Ürünün genel hissini etkileyen şeyleri tokenleyin: boşluk ölçeği, font boyutları ve satır yükseklikleri, çekirdek renkler (metin, arka plan, birincil, tehlike, border) ve küçük bir border radius seti.
İçerik odaklı seçimleri esnek bırakın: metin uzunluğu, hangi ikonun kullanılacağı veya bir bölümün iki mü yoksa üç kart gerektirip gerektirmediği gibi.
Ekranları (Koder.ai gibi araçlarla dahil) üretirken, baştan küçük bir token seti vermek tahmin miktarını azaltır ve çıktıyı belirgin şekilde daha tutarlı kılar.
Bir token seti, izin verilen değerlerin kısa bir menüsüdür. Küçük olması daha iyidir çünkü rastgele seçimlere yer bırakmaz, ancak ekranları bozan temel unsurları kapsamalıdır.
Boşlukla başlayın. Bir ölçek seçin ve padding, gap ve layout’ta her yerde kullanın. 4, 8, 12, 16, 24, 32 gibi bir set çoğu UI için yeterlidir. Tasarım 10px veya 18px gerektiriyorsa, yeni sayı eklemek yerine en yakın tokene yuvarlayın.
Sonra tipografi varsayılanlarını tanımlayın ki başlıklar ve gövde metni sürüklenmeyi bıraksın. Büyük bir tip sistemi gerekmez; tekrarlanabilir net adımlar gerekir.
Kompakt ve kullanılabilir bir set örneği:
Erişilebilirlik de sistemin parçası olmalı. Klavye kullanıcıları için tutarlı focus outline stili (renk, kalınlık, offset) tanımlayın. Mobil için minimum dokunma hedefi (örneğin 44x44) belirleyin. Kontrastı öngörülebilir tutmak için metin renklerini küçük, güvenilir bir sette sınırlayın.
Butonlar bazen sıkışık görünüyorsa, genellikle bir ekranda padding 10, diğerinde 12 kullanılmıştır. Tokenlarla şu diyebilirsiniz: “Butonlar paddingY=8, paddingX=16, radius=12, focus outline token, min height 44.” Bu sayılar sabitlendiğinde, üretici doğaçlama yapmayı bırakır.
Tokenlar sayıları verir. Bileşen kuralları alışkanlıkları belirler.
Küçük bir temel bileşen seti seçin ve bunları ekranlar için tek yapı taşları olarak kabul edin. Sıkıcı ve yeniden kullanılabilir tutun: Button, Input, Select, Checkbox, Card. TextArea ve Modal ekleyebilirsiniz, ama onların da aynı sistem (etiketler, boşluk, durumlar) ile gitmesi gerekir.
Sonra varyantları sınırlayın ve ne zaman izin verildiğini tanımlayın. Örneğin: Button’ın primary, secondary ve danger varyantları vardır. Primary genelde ekrandaki ana aksiyon içindir (genelde bir tane). Secondary iptal veya düşük öncelikli aksiyon içindir. Danger yalnızca silme gibi yıkıcı aksiyonlar içindir. Varyant gerekçelendirilemiyorsa, varsayılan olarak secondary kullanın.
Boşluk kuralları ince sürüklenmeyi önler. Bileşen içinde varsayılanları tanımlayın: Button padding, Input yüksekliği, label–alan arası boşluk, üst üste yığılan alanlar arasındaki standart gap. Birkaç layout kuralı da ekleyin: Kartların sabit iç padding’i ve tutarlı başlık/gövde boşluğu; Modalların aynı genişlik adımlarını ve footer hizalamasını kullanması.
Son olarak, durumları tartışmaz hale getirin çünkü UI’lar genellikle buradan rastgeleleşir:
“Create project” gibi form ağırlıklı bir ekran üretilirken, bu kurallar karışık buton boyutlarını, kaydıran etiket pozisyonlarını veya sadece bir sayfada görünen “özel” bir kartı engeller.
Görsel olarak stabil olunsa bile, “tuhaf hissetme” şikayetlerinin çoğu form davranışlarından gelir. Her ekran etiketleri, hataları ve odaklanmayı farklı ele alırsa, kullanıcı bunu tutarsızlık olarak yaşar.
Bir form deseni seçin ve her yerde kullanın: etiket, opsiyonel/gerekli işareti, yardımcı metin, sonra hata metni. Yazımı da tutarlı tutun (örneğin, cümle biçiminde etiketler, kısa yardımcı metin ve hatalar fiil ile başlayan cümleler).
Çoğu sürüklenmeyi önleyen kurallar:
Boyutlandırmayı ve yerleşimi kilitleyin ki ekranlar farklı “nefeslemesin”. Tek bir input yüksekliği, tek bir buton yüksekliği ve varsayılan alan genişliği tanımlayın. Masaüstünde alanları tutarlı bir ızgaraya hizalayın ve etiketleri inputların üstünde yığın. Mobilde alanları tam genişlik yapın ve gerçekten gerekli olmadıkça iki sütunlu formlardan kaçının.
Basit bir örnek: “Create project” ekranı Name, Region ve Description içerebilir. Region select bile olsa, onu diğer alanlar gibi ele alın: aynı yükseklik, aynı etiket pozisyonu, aynı hata satırı. Kullanıcı Name ile gönderirse ve boşsa, odak Name’e gider, hata altında görünür ve yerleşim sabit kalır.
Ekranları Koder.ai’de üretiyorsanız, bu form kurallarını prompt’unuza bir kez koyun ve özellikler boyunca yeniden kullanın, böylece her yeni form aynı davranışı gösterir ve tekrar düzeltme gerekmez.
Prompt’unuzu küçük bir UI sözleşmesi gibi ele alın. Kısa, spesifik ve yeniden kullanılabilir tutun ki her yeni ekran aynı boşluk, tipografi, bileşenler ve davranışlara otursun.
Pratik bir desen, isteğinizin başına kompakt bir UI spesifikasyonu yapıştırmak, sonra ekranı düz dille tarif etmektir.
UI SPEC (apply to every screen)
Tokens:
- Spacing: 4, 8, 12, 16, 24, 32
- Radius: 8
- Typography: H1 24/32, H2 18/26, Body 14/20
- Colors: text, muted, bg, primary, danger (no custom hex)
Components (must use): PageShell, Section, Card, Button, Input, Select, TextArea, FormRow, HelperText, Toast
Layout rules:
- Page padding: 24 desktop, 16 mobile
- Section spacing: 24
- Card padding: 16
- Grid: 12 cols desktop, 4 cols mobile, gap 16
Do:
- Reuse components and tokens only
- Keep labels above inputs, helper text below
Do not:
- Invent new spacing values, font sizes, or one-off CSS
- Mix different button heights or input styles
If a new component is needed:
- Extend an existing component pattern and document it in the output
- Do not create new visual styles outside tokens
Spec’in ardından, sürüklenmeyi erken yakalayacak birkaç kabul kontrolü ekleyin:
Sohbet tabanlı bir üreteç kullanıyorsanız, bu spec’i istekler boyunca sabit tutun. Her seferinde değiştirmek amaca zarar verir.
Herhangi bir şey üretmeden önce UI kontratını yazın: küçük bir token seti (boşluk, tipografi, renkler, radius, gölgeler) ve kısa bir bileşen envanteri (Button, Input, Select, Card, Modal, Table, Toast). Bir token veya bileşen eksikse, model bir tane icat eder ve UI sürüklenir.
Sonra kuralları test eden bir referans ekran oluşturun. Form ağırlıklı bir sayfa iyi bir temel çünkü başlıklar, yardımcı metin, doğrulama hataları, birincil ve ikincil butonlar ve bir başarı toast’u içerir. O ekranı baseline olarak kabul edin.
Bundan sonra yeni ekranları tanımladıklarınızı birleştirerek oluşturun. “Taze stil” istemekten kaçının. Aynı Card’ı, aynı boşluk ölçeğini, aynı tipografi adımlarını ve aynı alan desenini isteyin.
Basit bir iş akışı:
Eğer “Search users” ekranı referanstan daha sıkı boşluk içeriyorsa, tek seferlik margin’leri değiştirmek yerine spacing tokenlarını veya Card padding kuralını bir kere güncelleyin ve yeniden üretin.
Koder.ai kullanıyorsanız, snapshot ve rollback burada yardımcı olur: bir baseline kilitleyin, güvenle deney yapın ve bir değişiklik sürüklenme başlattığında hızlıca geri dönün.
Tutarlılığı kaybetmenin en hızlı yolu token ve kuralları öneri gibi görmektir. Küçük istisnalar yeni ekranlarda çoğalır.
Yaygın tuzaklardan biri boşluk ölçeğini proje ortasında değiştirmektir. Erken ekranlar 8, 16, 24 kullanıyorsa yeni ekran 10 ve 18 ekliyorsa “çünkü daha iyi görünüyor” diye, artık sürüklenmeye izin verilmiştir ve eski ekranlar güncellenmez.
Başka bir sürüklenme kaynağı, jeneratörün yeni bileşen stilleri icat etmesine izin vermektir. “Sadece bu buton varyantları var” demezseniz, yeni bir radius veya farklı input padding’i oluşturabilir.
Durumlar sık sık gözden kaçan bir alandır. Loading, empty ve error durumları genelde farklı boşluk ve davranışlar yaratır. Bunları sonradan eklemeye çalışırsanız, genelde diğerleriyle eşleşmeyen acele kalmış desenler elde edersiniz.
Ayrıca yanlış türde belirsizlikten kaçının: “modern, yumuşak gölgeler kullan” belirsizdir; oysa “hataları alanın altında göster”, “devre dışı butonlar focus stillerini korusun” ve “Enter sadece son alanda submit etsin” gibi davranış kuralları somut ve tekrarlanabilirdir.
Kısa bir guardrail bloğunu prompt’lara yapıştırmak isterseniz, kısa tutun:
Üretilen bir ekranı merge etmeden önce iki dakikalık bir tarama yapın.
Boşluktan başlayın. 13px gibi rastgele değerler veya “sığdırmak için” eklenmiş tek seferlik margin’ler arayın. Token kullanıyorsanız, her gap onaylı settendir; gutterlar, kart padding’i ve form alanları arasındaki boşluk dahil.
Sonra tipografiyi tip ölçeğiyle karşılaştırın. Başlıklar öngörülebilir şekilde adım atmalı. Benzer bölümlerde gövde metni boyutu değişmemeli. Satır yüksekliği de önemlidir, özellikle ayarlar gibi yoğun ekranlarda.
Butonları tarayın. Varyantlar ve boyutlar kurallara uygun olmalı: ana aksiyon için primary, daha az önemli için secondary, silme gibi için danger. Buton yüksekliği, ikon yerleşimi ve etiket stili eşleşmeli.
Formlar için tutarlılık çoğunlukla yapıyla ilgilidir. Etiketler tek yerde kalmalı, gerekli göstergeler tek kurala uymalı, yardımcı metin ve hatalar yarışmamalı, hatalar tutarlı bir yerde görünmeli.
Kısa kontrol listesi:
Son olarak hızlıca mobil testi yapın. Genişliği daraltın ve düzenin yeni font boyutları veya boşluklar icat etmeden uyum sağladığını doğrulayın.
Basit bir onboarding akışı hayal edin: üç ekran (Profile, Preferences, Confirm) ve sonra bir Settings sayfası. Her ekranın ayrı üretimlerde bile aynı tasarımcıdan çıkmış gibi görünmesini istiyorsunuz.
Her şeyi üretmeden önce küçük bir token seti ve birkaç bileşen kuralı verin:
TOKENS
- spacing: xs=4, sm=8, md=12, lg=16, xl=24
- radius: sm=8, md=12
- type: body=14/20, title=20/28, label=12/16
- layout: pageMax=960, sectionGap=24, fieldGap=12
COMPONENT RULES
- Page: max width=pageMax, padding=xl, sectionGap between blocks
- Card: padding=lg, radius=md
- Field: label above, helper below, fieldGap between fields
- Button row: primary on right, gap=sm
- Errors: shown under field, same copy style, no alerts
Şimdi “Profile” ve “Preferences” ayrı ayrı üretin. Çünkü her iki ekran da Page, Card, Field ve Button row kullanmalı, aynı marginler, etiket boşlukları ve buton yerleşimleriyle gelir. Confirm adımı daha fazla salt okunur metin içerse bile uyum sağlar.
Form davranışı sürüklenmenin sık giriş noktısıdır, bu yüzden bunu bir kez tanımlayıp yeniden kullanın: geçerli olana kadar submit devre dışı, inline hatalar sadece blur veya submit sonrası, Enter sadece son adımda submit eder ve Back butonu girilmiş değerleri temizlemez.
Yeni bir UI öğesine ihtiyaç duyduğunuzda, modele doğaçlama yaptırmayın. Bir kural ekleyin, sonra yeniden üretim yapın:
Tokenları ve kuralları kullanılabilir bir spec’e çevirin. Çok uzun olursa yapıştırılmaz ve uygulanmaz.
Pratik bir spec genellikle şunları içerir: token tablosu (boşluk, tipografi, radii, renkler), kısa bir bileşen kural seti (butonlar, inputlar, kartlar, başlıklar), form davranışı kuralları (doğrulama zamanlaması, hatalar, devre dışı/loading), yerleşim varsayılanları (sayfa paddingi, max genişlik, bölüm boşluğu) ve kısa bir “asla yapma” listesi (rastgele marginler, ad-hoc font boyutları).
Sonra bir alışkanlık edinin: spec’i önce güncelleyin, tek tek pikselleri değil.
Koder.ai (koder.ai) kullanıyorsanız, planning mode spec’i üretmeden önce yinelemek için iyi bir yerdir. Alternatifler denemek istediğinizde, snapshots ve rollback kararlı bir baseline kaybı olmadan keşfetmenize izin verir.
Çünkü her ekran isteği yeni bir başlangıç gibidir. Paylaşılan bir sistem sağlamazsanız, jeneratör eksik detayları tahmin ederek doldurur—boşluklar, yazı boyutları, buton dolguları, gölgeler ve form davranışları—ve küçük farklar sayfalar arasında birikir.
Design tokenları, boşluk, yazı boyutları, renkler ve radius gibi şeyler için isimlendirilmiş, tekrar kullanılabilir değerlerdir.
“Rahat dolgu” demek yerine space-md gibi bir token kullanırsınız. İsim sabit kalır ve her ekran aynı kararı tekrar kullanır, böylece UI sürüklenmeyi bırakır.
Küçük başlayın ve görünür sürüklenmeye neden olanları kapsayın:
Her isteğin üstüne küçük bir UI spec bloğu koyun ve bunu bir kontrat gibi kullanın:
Sonra ekranı açıklayın. Anahtar nokta: spec’i ekranlar boyunca değiştirmemek.
Tokenlar sayıları belirler; bileşen kuralları alışkanlıkları belirler. Yararlı kurallar şunlardır:
Varsayılan kural: bir varyant gerekçelendirilemiyorsa, standart olanı kullanın.
Bir desen seçin ve her yerde kullanın:
Bu, bir ekranın blur’da, diğerinin yalnızca submit’te doğrulama yapması gibi tutarsızlıkları önler.
Standardize etmeniz gereken durumlar:
Belirlemezseniz, her ekran kendi desenini icat etme eğiliminde olur.
Stili icat etmesine izin vermeyin. Yeni bileşeni mevcut bir desenin belgelendirilmiş uzantısı olarak ekleyin:
Tokenlarla tarif edilemiyorsa, muhtemelen çok özelleşmiş demektir ve sürüklenmeye yol açar.
Sistemi zorlayan bir “referans” ekran oluşturun (form ağırlıklı bir sayfa iyi bir stres testi olur), sonra aynı spec’i her yeni ekranda kullanın.
Koder.ai’de planning mode, spec’i üretmeden önce yinelemek için kullanışlıdır; snapshots ve rollback ise deney yaparken sabit bir temel korumanıza yardımcı olur.
Kabul etmeden önce hızlı bir tarama yapın:
Bir şey yanlışsa, spec/tokenları güncelleyin ve yeniden üretin—tek seferlik margin’leri yama yapmayın.
Yeni bir değere ihtiyaç duyarsanız, 10px ya da 18px gibi değerler icat etmek yerine en yakın tokene yuvarlayın.