AI’nin tasarımdan koda nasıl düzen, hiyerarşi ve kullanıcı niyetini çıkardığını, sonra UI kodu ürettiğini öğrenin—sınırlamalar, en iyi uygulamalar ve inceleme ipuçlarıyla.
“tasarımdan koda” AI, görsel bir tasarım fikrini—genellikle bir Figma çerçevesi veya ekran görüntüsünü—çalıştırılabilir UI koduna çevirir. Amaç “kusursuz kod” değil; insanın üstünden geçip iyileştirebileceği, yapıyı, stili ve temel davranışı yakalayan kullanılabilir bir ilk taslaktır.
Temelde sistem, gözlemleyebildiği şeyleri UI’ların tipik olarak nasıl kurulduğuna eşler.
AI yaygın desenleri çıkarabilir: bir ikon sırası muhtemelen bir araç çubuğudur; üst üste gelmiş etiket + input muhtemelen bir form alanıdır; tutarlı stiller yeniden kullanılabilir bir bileşen olduğunu gösterir. Constraintler ve boşluklara dayanarak responsif davranışı da tahmin edebilir.
Ama piksellerin garantileyemediği çoğu şeyi genellikle sizin belirtmeniz gerekir: gerçek bileşen adları, tasarım tokenları (renkler/tipografi ölçekleri), durumlar (hover/disabled/error), breakpoints, veri kuralları ve gerçek etkileşimler (doğrulama, gezinme hedefleri, analitik).
Çıktıyı bir başlangıç noktası olarak değerlendirin. Yapıyı gözden geçirmek, ad-hoc stilleri tokenlarla değiştirmek, kendi bileşen kütüphanenize uyarlamak ve yinelemek gerekir. “tasarımdan koda” hızlandırma sağlar—tasarım ve mühendislik yargısını ortadan kaldıran bir otomasyon değildir.
AI bir “güzel ekran”dan ürün kurallarını çıkaramaz. Çalışmak için verdiğiniz kanıtlara dayanır—bazı girdiler pikselleri tanımlar, bazıları yapıyı tanımlar. Bu fark genelde temiz UI kodu mu yoksa kırılgan mutlak konumlandırma mı alacağınızı belirler.
Ekran görüntüsü en sınırlı girdidir: renkler ve şekiller vardır, ama bir şeyin buton mu yoksa etiket mi olduğu, neyin yeniden kullanılabilir olduğu veya düzenin nasıl uyum sağlayacağı açık değildir.
Sadece piksellerden AI, sınırları tahmin etmek zorunda kalır (bir öğe nerede bitiyor diğer hangi öğe başlıyor), metin stillerini, boşluk kurallarını ve bir “kart”ın tek bir bileşen mi yoksa birkaç ayrı parça mı olduğunu belirlemeyi tahmin eder. Ayrıca constraintleri çıkaramaz—dolayısıyla responsif davranış çoğunlukla spekülasyondur.
AI tasarım dosyasına (veya yapıyı koruyan bir ihracata) erişince kritik metadata kazanır: çerçeveler, gruplar, katman adları, Auto Layout ayarları, constraintler ve metin/stil tanımları.
Burada düzen geometri olmaktan çıkar. Örneğin, Auto Layout kullanan bir Figma çerçevesi “bu öğeleri dikey olarak 16px boşlukla yığın” gibi niyeti ekran görüntüsünden çok daha iyi iletir. Tutarlı katman adlandırma da öğeleri UI rolleriyle eşlemeye yardımcı olur (ör. “Primary Button”, “Nav Item”, “Input/Error”).
Bağlı bir tasarım sistemi tahmini azaltır. Tokenlar (renkler, boşluk, tipografi) AI’nın sabit değerler yerine ortak bir kaynağa referans veren kod üretmesini sağlar. Yayınlanmış bileşenler (butonlar, alanlar, modallar) hazır yapı taşları sunar ve yeniden kullanım sınırlarını netleştirir.
Hatta küçük sözleşmeler—variant isimlendirmeleri (Button/Primary, Button/Secondary) ve semantik tokenlar (text/primary) kullanmak yerine #111111 gibi sabit değerler—bileşen eşlemesini iyileştirir.
Speslar UI’nın arkasındaki “neden”i ekler: hover davranışı, loading ve empty durumları, doğrulama kuralları, klavye davranışı ve hata mesajlaşma.
Bunlar yoksa AI genellikle statik bir anlık görüntü üretir. Speslar varsa çıktı etkileşim kancaları, durum yönetimi ve daha gerçekçi bileşen API’ları içerebilir—takımın yayınlayabileceği ve sürdürebileceği bir şeye daha yakın.
Design-to-code araçları ekranı bir insan gibi algılamaz; her katmanı düzen kurallarıyla (satırlar, sütunlar, konteynerler, boşluklar) açıklamaya çalışır. Bu kurallar ne kadar netse, çıktı o kadar az kırılgan konumlandırmaya dayanır.
Çoğu model tekrar eden hizalamalar ve eşit aralıklar aramakla başlar. Eğer birkaç öğe aynı sol kenarı, baz hattı veya merkez hattını paylaşıyorsa, AI genellikle bunları bir sütun veya grid kanalı olarak değerlendirir. Tutarlı boşluklar (ör. 8/16/24px kalıpları) layout’un stack boşlukları, grid gutters veya tokenize boşluklarla ifade edilebileceğini gösterir.
Boşluklar hafifçe değişiyorsa (burada 15px, orada 17px) AI düzenin “manuel” olduğunu düşünerek piksel-kusursuz mesafeleri korumak için mutlak koordinatlara geri dönebilir.
AI görsel “kapsama” arar: arka planlar, kenarlıklar, gölgeler ve padding benzeri boşluklar bir konteyner olduğunu işaret eder. Arka planı ve iç padding’i olan bir kart, ebeveyn öğe ve çocukları için net bir sinyal verir.
Buradan genelde yapıyı şu temel yapılara eşler:
Tasarım dosyasında temiz gruplanma ebeveynleri kardeşlerden ayırmayı kolaylaştırır.
Tasarımda constraintler (pinleme, hug, fill) varsa AI bunları neyin esnediğini neyin sabit kaldığını belirlemek için kullanır. “Fill” elemanları tipik olarak esnek genişlikler alır (ör. flex: 1), “hug” içerik boyutlu öğelere karşılık gelir.
Model akışıyla ifade edilemeyen ilişkileri güvenli şekilde açıklayamadığında mutlak konumlandırma ortaya çıkar—genelde tutarsız boşluklar, örtüşen katmanlar veya hizalanmamış öğeler yüzünden. Bir ekran boyutunda doğru görünen bu yaklaşım, responsivlikte ve metin yeniden boyutlandırmasında bozulur.
Küçük bir boşluk ölçeği kullanmak ve net bir ızgaraya hizalanmak, AI’nın flex/grid kodu üretme olasılığını dramatik biçimde artırır. Tutarlılık yalnızca estetik değil—makine tarafından okunabilir bir desendir.
AI “anlamaz”; önem derecesini genelde onu işaret eden görsel kalıplardan çıkarır. Tasarım bu sinyalleri ne kadar net iletirse, üretilen UI niyetinize o kadar yakın olur.
Tipografi en güçlü ipuçlarından biridir. Daha büyük puntolar, daha yüksek ağırlık, güçlü kontrast rengi ve daha cömert satır yüksekliği genellikle daha yüksek öncelik gösterir.
Örneğin, 32px kalın bir başlığın üstünde 16px normal bir paragraf açık bir “başlık + gövde” desenidir. Sorun, stiller belirsizleştiğinde ortaya çıkar—ör. iki metin bloğu sadece 1–2px fark ediyorsa veya aynı ağırlık farklı renklerle kullanılmışsa. Bu durumlarda AI her ikisini de düz metin sayabilir veya yanlış başlık seviyesini seçebilir.
Hiyerarşi ayrıca mekansal ilişkilerden çıkar. Birbirine daha yakın, hizalanmış ve diğer içerikten boşlukla ayrılmış öğeler grup olarak değerlendirilir.
Ortak arka planlar (kartlar, paneller, renkli bölümler) görsel parantez gibi davranır: AI genellikle bunları section, aside veya bileşen sarmalayıcısı olarak yorumlar. Düzensiz padding veya tutarsız boşluk yanlış gruplaşmaya neden olabilir—ör. bir buton yanlış karta eklenebilir.
Tekrarlayan desenler—özdeş kartlar, liste öğeleri, satırlar veya form alanları—yeniden kullanılabilir bir bileşen olduğuna dair güçlü kanıttır. Küçük farklar (ikon boyutu, köşe yarıçapı, metin stili) AI’yı tek tek varyantlar üretmeye yöneltebilir; oysa tek bir bileşen ve varyantları daha uygundur.
Butonlar boyut, dolgu, kontrast ve konumla niyeti iletir. Dolgulu ve güçlü kontrastlı bir buton genelde birincil eylem olarak değerlendirilir; outline veya metin butonlar ikincil olur. İki eylem eşit vurguda görünüyorsa, AI hangi olanın “birincil” olduğunu yanlış tahmin edebilir.
Son olarak AI hiyerarşiyi semantike çevirmeye çalışır: başlıklar (h1–h6), gruplanmış bölümler (section) ve anlamlı kümeler (ör. “ürün detayları” vs “satın alma aksiyonları”). Net tipografik adımlar ve tutarlı gruplaşma bu çeviriyi çok daha güvenilir kılar.
Modeller niyeti, çok sayıda UI örneğinden öğrendikleri kalıplarla eşleştirerek tahmin eder: ortak şekiller, etiketler, ikonografi ve yerleşim gelenekleri.
Belirli düzenler belirli bileşenleri güçlü şekilde işaret eder. Solda logo, üstte yatay şerit ve sağda metin öğeleri bir nav bar; eşit genişlikte öğelerden oluşan bir sıra ve birinin vurgulanmış olması tabları işaret eder; resim, başlık ve kısa metin içeren tekrar eden kutular karttır; hizalanmış başlıklar ve satırlar yoğun gridler genelde tablolar olur.
Bu tahminler önemli çünkü yapı üzerinde etkisi vardır: “tab”, seçili durum ve klavye navigasyonu gerektirir; “buton sırası” ise aynı şeyi gerektirmez.
AI genellikle etkileşim ipuçlarını arar:
Bunlara dayanarak davranış atar: tıklama, menü açma, gezinme, gönderme, aç/kapa. Tasarım etkileşimli öğeleri net ayırdıkça çıktı daha doğru olur.
Tasarım birden fazla varyant gösteriyorsa—hover, seçili, disabled, hata, loading—AI bunları durumlu bileşenlere eşleyebilir. Durumlar görünür değilse AI çoğunlukla bunları atlar.
Belirsizlik sık görülür: bir kart tıklanabilir mi yoksa sadece bilgi mi veriyor? Bir chevron dekoratif mi yoksa disclosure kontrolü mü? Bu durumlarda adlandırma, notlar veya ayrı çerçevelerle etkileşimi belirtin.
AI düzenin makul bir okumasını yaptıktan sonra bir sonraki adım “göründüğü şey”i “ne olduğu”na çevirmektir: semantik HTML, yeniden kullanılabilir bileşenler ve tutarlı stil.
Çoğu araç tasarım katmanlarını ve grupları bir DOM ağacına eşler: çerçeveler konteyner olur, metin katmanları başlık/paragrafa dönüşür, tekrar eden öğeler listeler veya gridler olur.
Niyet netse AI daha iyi semantik atayabilir—ör. üst çubuk bir \u003cheader\u003e olur, logo ve linkler \u003cnav\u003e olur, tıklanabilir kart \u003ca\u003e veya \u003cbutton\u003e olur. ARIA rolleri bazen çıkarılabilir (modal için role=\"dialog\" gibi) ama desen belirsizse daha güvenli çıktı düz HTML ve erişilebilirlik inceleme TODO’ları olur.
Tek bir devasa dosya üretmemek için AI UI’yi şu parçalara ayırmaya çalışır:
Tekrar eden patternler, tutarlı padding/typografi ve gruplanmış tıklanabilir alanlar bileşen sinyalleridir. Başarısızlık modları aşırı parçalara ayırma veya her şeyi tek seferlik hardcode etme olacaktır.
Generator genelde hedef yığına veya kendi varsayılanına göre bir yaklaşım seçer:
Kaliteli çıktı tasarım tokenlarına yaslanır—renkler, boşluk, radius, gölgeler—böylece tasarım değiştiğinde kod da kolayca uyum sağlar. Kesin piksel eşleşmesi genelde tek seferlik değerler üretir ve bakım zorlaşır.
Pratik denge: hiyerarşiyi ve boşluk ritmini koruyun, sonra bunu tokenlara ve tekrar kullanılabilir bileşenlere normalize edin (ve inceleme adımında daha fazla refactor yapın).
Tasarım dosyaları genelde birkaç sabit frame boyutunda olduğu için (ör. 1440 ve 375). Kod bunu varsayamaz. Design-to-code aracı ara genişliklerde UI’nin nasıl davranacağını, ipuçları ve varsayılanlarla kararlaştırmalı.
Tasarımınız aynı ekranın birden fazla versiyonunu içeriyorsa (desktop/tablet/mobile) ve yapı tutarlıysa AI bunları hizalayıp hangi kuralların değiştiğini çıkarabilir. Varyant yoksa genelde yaygın breakpointlere döner ve çerçeveyi “temel” kabul eder; bu da garip geçişlere yol açabilir.
AI şu desenlere bakar: tekrar eden kartlar, eşit boşluk ve hizalama. Buna dayanarak 3 sütunlu bir gridin 2’ye sonra 1’e düşeceğine karar verebilir. Tasarım manuel düzeltmelere dayandıysa—görünüşte hizalanmış ama aslında tutarsız—AI bunun kasıtlı olup olmadığını anlayamaz.
Çoğu tasarım kısa, düzenli metin kullanır. Gerçek ürünler uzun metinler içerir. AI tarafından üretilen UI kodu genelde sabit genişlik/yükseklik koyar veya aşırı kestirir.
Hızlı bir kontrol:
AI tasarımdaki kırpmayı koruyabilir, ama responsif UIs kurallar ister: en-boy oranını koru, nasıl kırpılacağına karar ver, görüntünün ne zaman küçüleceğini veya yer değiştireceğini belirtin. Tasarım bunu belirtmiyorsa genellikle “fill” davranışı görülür ve önemli kısımlar kırpılabilir.
Çıktıya güvenmeden önce çok küçük genişliklerde, çok büyük monitörlerde ve ara boyutlarda önizleyin. Herhangi bir örtüşme, kırpılma veya okunamazlık varsa sorun genelde eksik düzen niyetidir—bu da tasarımda daha net constraintler eklemeniz gerektiğini gösterir.
AI pikselleri UI koduna şaşırtıcı derecede iyi çevirebilir, ama erişilebilirlik genelde “görünüş doğru” ile “herkes için çalışır” arasında fark yaratır. Birçok gereksinim statik bir çerçevede görünmez; modelin bunları doğru yapması için açık sinyaller gereklidir.
Bazı erişilebilirlik dostu seçimler görsel olarak ortaya çıkar ve AI bunları daha iyi HTML’e çevirebilir:
Görünmeyen gereksinimler şunlardır:
Bekleyin: eksik label/for bağlantıları, yanlış başlık seviyeleri, klavye desteği olmayan tıklanabilir divler, zayıf odak stilleri ve metin alternatifi olmayan ikonlar.
h1 → h2 → h3).header, nav, main, footer) ve çoğaltılmamış.alt içeriyor veya dekoratifse alt="".Modal, drawer, karmaşık formlar, özel selectler, sürükle-bırak veya çok durumlu öğeler olduğunda kısa bir spes ekleyin. Birkaç not (ör. “modalde odak tuzağı”, “Esc kapatır”, “satır içi hatalar duyurulsun”) üretilen UI kodunu ciddi şekilde iyileştirir.
AI ilk bakışta yakın görünen UI kodu üretebilir, ama küçük yorumlama hataları biriktikçe sorunlar büyür. Çoğu hata, tasarımda kuralların net kodlanmamasından kaynaklanan “makul tahminler”den gelir.
Yaygın bir şikayet uyumsuz boşluklardır: butonlar hafifçe kaymış, bölümler çok hava almış veya kartlar sıkışık görünür. Bu, benzer öğeler arasında paddingin tutarsız olduğu ya da auto-layout ile manuel düzeltmelerin karıştığı durumlarda olur. Model ya bir deseni (ör. “her yerde 16px”) uygular ya da kazara olan istisnaları korur.
Oluşan markup sıklıkla çok sayıda sarmalayıcı içerir. Her görsel grup yeni bir \u003cdiv\u003e olur. Sonuç, stil vermesi ve debug yapması zor ve bazen render performansı düşen bir yapı olur.
AI bazen çok parçacıklı (her etiket ayrı bileşen) veya çok monolitik (tüm ekran tek bileşen) sonuç verir. Sebep belirsiz sınırlar: tekrarlayan desenler özdeş değilse model ortak bir bileşen çıkarmaya güvenemez.
Metin stilleri kodda tam eşleşmeyebilir; satır yüksekliği, harf aralığı veya font fallback’leri farklılık yaratır. Bu yüzden Figma’da sığan bir başlık kodda sarma yapabilir.
Hover, focus, error, loading veya empty durumları tasarımda yoksa AI genelde bunları eklemez. Statik görüntü doğru görünse de kullanıcı etkileşimi başladığında UI başarısız olabilir.
AI kod üretecekse tasarım dosyanız katmanlar, constraintler, stiller ve bileşen örnekleriyle temiz olmalı. Yapı ne kadar temizse modelin tahmin etmesi gereken o kadar az olur (ve daha az garip div temizlemeniz gerekir).
Katman adları niyet ve bileşen eşlemesi için güçlü sinyallerdir. Aşağıdaki gibi tutarlı, açıklayıcı kalıplar kullanın:
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/Checkbox“Rectangle 12” veya “Group 5” bırakmayın—bu AI’yi generic sarmalayıcılara iter.
Manuel konumlandırma genelde koddaki mutlak koordinatlara dönüşür. Flex/grid çıktısı istiyorsanız tasarımınızın flex/grid gibi davranması gerekir:
Tasarım araçlarında iyi davranan bir yapı, üretilen UI’nin varsayılan olarak daha responsif olmasını sağlar.
Tek seferlik renkler, font boyutları ve boşluklar tek seferlik CSS üretir. Bunun yerine:
Bu tutarlılığı artırır ve ileride design system’e refactor etmeyi kolaylaştırır.
AI bulunmayanı çıkaramaz. Önemli varyantları (hover/pressed/disabled), input hata durumlarını, loading ve empty durumlarını ekleyin.
Davranış önemliyse kısa bir not bırakın: “opens modal”, “server-validated”, “shows toast on success”. Bir bileşenin yanında birkaç kelime yanlış etkileşim kodunu önleyebilir.
Ekip standardı oluşturuyorsanız bunları hafif bir kontrol listesinde toplayın ve iç dokümana referans verin.
AI tarafından üretilen UI kodu en iyi ilk taslak gibi ele alınır: saatler kazandırır ama yine de insan eliyle düzeltilmeli, sürdürülebilir hale getirilmeli ve ürün standartlarına uyumlu hale getirilmelidir.
Markup’u bir ekran okuyucu gibi okuyormuş gibi başlayın:
\u003ch1\u003e, sonra mantıklı \u003ch2\u003e/\u003ch3\u003e).\u003cul\u003e/\u003col\u003e) olduğundan emin olun, yığın \u003cdiv\u003eler olmasın.Semantik yanlışsa CSS ile düzeltmek erişilebilirlik veya kullanılabilirlik sorunlarını çözmez.
Çoğu generator piksel-kusursuzluğu korumak için mutlak konumlandırma veya derin sarmalayıcılar kullanır. Bu içerik değiştiğinde bozulur. Flex/grid kurallarını tercih edin ve gereksiz katmanları kaldırın. Eğer birçok yerde style={{ left, top, width, height }} görüyorsanız ilk önce orayı yeniden yazın.
Tekrarlayan desenleri (kartlar, input satırları, nav öğeleri) bileşene dönüştürün. Ardından sabit değerleri tokenlar ile değiştirin: boşluk, radius, tipografi ve renkler. Eğer ekibinizin mevcut token rehberi varsa ona uyun; yoksa küçük bir setle başlayıp kademeli genişletin.
Ağır test yazmanıza gerek yok:
Generatorlar niyet tahmininde bulunur. Yaptığınız düzenlemeleri (etkileşim kuralları, breakpoints, bileşen eşlemeleri) kaydedin ki bir sonraki jenerasyon veya geliştirici bunları geri almasın.
Bu, görsel bir kullanıcı arayüzünü (Figma çerçevesi, tasarım ihracı veya ekran görüntüsü) çalıştırılabilir UI koduna yapay zeka destekli bir çevirisidir. Amaç, geliştiricinin tokenlar, bileşenler ve üretim kalitesinde semantikler için yeniden düzenleyebileceği sağlam bir ilk taslaktır—düzen, stil ritmi ve temel yapı dahil.
Genellikle şu öğeleri çevirir:
Pikseller her şeyi kodlamaz. Genellikle sizden belirtmeniz veya sağlamanız gerekenler:
Bir ekran görüntüsü en zayıf girdi: renk ve geometriden başka yapı bilgisi vermez (layerlar, constraintler, bileşenler yok). Daha fazla tahmin, daha fazla mutlak konumlandırma ve daha az yeniden kullanılabilir kod beklersiniz.
Bir Figma/Sketch dosyası veya yapıyı koruyan bir ihracat ise çerçeveler, katman adları, Auto Layout, constraintler ve stiller gibi temiz sinyaller sağlar—bu da daha temiz flex/grid düzenleri ve doğru bileşen sınırları üretir.
AI, UI’yi flex/grid kurallarıyla ifade etmek için tekrar eden hizalamalar ve tutarlı boşluklar arar. Net bir boşluk ritmi (ör. 8/16/24) bulursa kararlı stack ve gridler üretebilir.
Boşluklar tutarsızsa veya öğeler hafifçe hizalanmamışsa, model genellikle mutlak koordinatlara geri döner—bu da duyarlılığı feda ederek piksel kusursuzluğunu korur.
Görsel olarak “kapsama” sinyalleri arar:
Tasarım aracında temiz gruplanmış yapı (çerçeveler, Auto Layout) ebeveyn/çocuk ilişkilerini koda taşımayı çok daha kolaylaştırır.
İlişkilerin belirsiz olduğu—örtüşmeler, tutarsız boşluklar, manuel kaydırmalar veya net olmayan gruplayanlar—durumlarda mutlak konumlandırma görünür. Bu, farklı görünüm genişliklerinde, daha uzun metinlerde veya erişilebilirlik için font ölçeklendirildiğinde bozulma riskini artırır.
Esnek çıktı istiyorsanız, tasarımın flex/grid gibi davranmasını sağlayın (Auto Layout ve constraintler kullanın).
AI hiyerarşiyi görsel ipuçlarından çıkarır:
Stiller sadece 1–2px farklıysa veya hiyerarşi adımları belirsizse, yanlış başlık seviyesini seçebilir veya başlıkları düz metin sayabilir.
Model, öğrendiği çok sayıda UI örneğiyle eşleşme yaparak niyeti tahmin eder: yaygın şekiller, etiketler, ikonlar ve yerleşim gelenekleri.
Bazı düzenler belirli bileşenleri güçlü şekilde önerir: sol tarafta logo ve sağda metin öğeleri olan üst yatay şerit genellikle bir nav çubuğudur; eşit genişlikte öğelerden oluşan bir sıra ve biri vurgulanmışsa tablara karşılık gelebilir; resim, başlık ve kısa metin içeren tekrar eden kutular kartlardır.
Bu tahminler yapının yanı sıra davranışı da etkiler: bir “tab” seçili durum ve klavye gezintisi gerektirirken, bir “buton sırası” bunu gerektirmez.
Etkileşimli olma eğilimini şu ipuçlarından arar:
Bunlardan hareketle tıklama, menü açma, gezinme, gönderme, aç/kapa gibi davranışlar atanır. Tasarım etkileşimli ile statik öğeleri net ayırdıkça çıktı daha doğru olur.
Tasarımdaki birden çok varyant—hover, aktif/seçili, disabled, hata, yükleniyor—gösteriliyorsa AI bunları durumlu bileşenlere eşleyebilir. Durumlar açık değilse çoğu zaman atlanırlar.
Belirsizlik yaygındır: bir kart tıklanabilir mi yoksa sadece bilgi mi veriyor? Bir chevron dekoratif mi yoksa disclosure kontrolü mü? Bu tür durumlarda adlandırma, açıklama veya etkileşimi gösteren ayrı çerçevelerle açıklık getirin.
AI, tasarım katmanlarını DOM ağacına çevirir: çerçeveler konteyner olur, metin katmanları başlık/gövdeye, tekrar eden öğeler listelere veya gridlere dönüşür.
Niyet belli olduğunda daha iyi semantik ekleyebilir—ör. üst çubuk bir \u003cheader\u003e olur, logo ve linkler bir \u003cnav\u003e olur, tıklanabilir kart bir \u003ca\u003e veya \u003cbutton\u003e olur. ARIA roller bazen çıkarılabilir (modal için role="dialog" gibi) ama desen net değilse güvenli olan sade HTML ve erişilebilirlik incelemesi için TODO notları olur.
Tek bir devasa dosya üretmemek için AI UI’yi şu ilkelere ayırmaya çalışır:
Tekrar, tutarlı padding/typografi ve tıklanabilir alanlar bileşen sinyalleridir. Başarısızlık modları aşırı parçalanma (çok küçük bileşenler) veya yetersiz parçalanma (her şey tek seferlik hardcode) olacaktır.
Generator, hedef yığına veya kendi varsayılanlarına göre bir stil yaklaşımı seçer:
Yüksek kaliteli çıktı, tasarım tokenlarına dayanır—renkler, boşluklar, radius, gölgeler—böylece tasarım değiştiğinde kod tutarlı kalır. Katı piksel eşleşmesi genelde tek seferlik değerler (ör. 13px boşluk, birbirine yakın griler) üretir ve bakım zorluğu yaratır.
Pratik yaklaşım: hiyerarşiyi ve boşluk ritmini koruyun, sonra bunu tokenlara ve tekrar kullanılabilir bileşenlere normalize edin (daha fazla refactor için bir sonraki adımda genişletin).
Tasarım dosyaları genellikle birkaç sabit çerçeve boyutunda (1440, 375 vb.) çizildiği için “bitmiş” görünür. Kod bunu varsayamaz. Design-to-code aracı, ara genişliklerde nasıl davranılacağını belirlemeli; bu da ipuçları ve varsayılanlara dayanır.
Eğer tasarımda aynı ekranın masaüstü/tablet/mobile versiyonları varsa ve yapı tutarlıysa AI bunları hizalayıp hangi kuralların değiştiğini çıkarabilir. Varyant yoksa genellikle yaygın breakpointlere döner ve çerçeve boyutunu “temel” kabul eder—bu da ani ve garip geçişlere yol açabilir.
AI şu desenlere bakar: tekrar eden kartlar bir grid oluşturuyorsa, eşit boşluk ve hizalama varsa bir 3 sütunlu grid 2’ye, sonra 1’e düşebilir. Tasarım manuel kaydırmalar kullanıyorsa—görünüşte hizalanmış ama gerçekte tutarsızsa—AI bunun kasıtlı mı olduğuna karar veremez ve hatalı davranışlar üretebilir.
Çoğu tasarım kısa, düzgün kopya kullanır. Gerçek ürünler öyle değil. AI tarafından üretilen UI kodu genelde sabit genişlik/yükseklikler koyar ya da aşırı kestirir.
Hızlı bir kontrol için deneyin:
Bu testler genelde nerelerin kırılacağını gösterir.
AI tasarımdaki piksel kırpmayı koruyabilir, ama responsif UI’ler kurallar gerektirir: en-boy oranını koru, nasıl kırpılacağına karar ver, ve resimlerin ne zaman küçüleceği veya yer değiştireceğini belirt. Tasarım bunu belirtmiyorsa genellikle “fill” davranışı görürsünüz ve önemli parçalar kırpılabilir.
Küçük genişliklerde, çok büyük monitörlerde ve ara boyutlarda önizleme yapmadan çıktıya güvenmeyin. Örtüşme, kırpılma veya okunamazlık varsa genelde saklanan düzen niyeti eksiktir—bu da tasarımda daha net constraintler gerektirdiğinin işaretidir.
Pikselleri UI koduna şaşırtıcı derecede iyi çevirebilir, ama erişilebilirlik genelde “görsel olarak doğru” ile “herkes için çalışır” arasında ayrım yaratır. Birçok gereksinim statik bir çerçevede görünmez; modelin bunları doğru yapması için açık sinyaller gerekir.
AI tasarımdan şu tip erişilebilirlik dostu seçimleri çıkarabilir:
Küçük yorum hatalarından kaynaklanan birçok yorumlama hatası birikince kod hızla sorunlu hale gelir. Çoğu problem, tasarım kurallarının net kodlanmamasından doğan “makul tahminler”dir.
Yaygın sorunlar:
AI kod üretecekse tasarım dosyanız katmanlar, constraintler, stiller ve bileşen örnekleriyle iyi yapılandırılmış olmalı. Yapı temiz oldukça modelin tahmin etmesi gereken az olur (ve daha az garip div temizlemeniz gerekir).
Öneriler:
Katman adları niyet ve bileşen eşlemesi için güçlü sinyallerdir. Tutarlı, açıklayıcı adlar kullanın:
AI tarafından üretilen UI kodunu bir ilk taslak olarak değerlendirin: saatler kazanabilirsiniz ama yine de insan eliyle gözden geçirilmeli, sürdürülebilir hale getirilmeli ve ürün standartlarına uydurulmalıdır.
Adımlar:
AI “hızlandırıcı” olarak kullanıldığında en verimli olur; tam otomatik pilot gibi davranmayın. En hızlı ekipler, tasarım sistemlerinin olgunluğuna ve oluşturulan ekranın risk seviyesine göre bir iş akışı seçer.
İki yaygın iş akışı:
1) Tasarım araçları içinde AI destekli (ör. Figma eklentileri): Kaynak dosyaya yakın kalmayı sağlar. Hızlı iskelet üretimi sırasında tasarımcılar iterasyon yapabilir ve adlandırmalar, bileşenler, tokenlarla dosya uyumu korunur.
2) Harici dönüştürücüler (upload/export → code): Çok sayıda dosya veya ekipler arası tekrarlı pipeline için kullanışlıdır. Toplu dönüştürmede hızlı olabilir, ama yapı temizliği ve etkileşimlerin bağlanması için genelde daha fazla temizlik gerekir.
Pratikte birçok ekip design-to-code’u geniş bir “spesifikasyondan yayına” akışına entegre eder. Örneğin, gibi platformlar niyeti implementasyona çevirme ilkesini alıp daha ileri götürür: chat ile özellik tanımı, React frontend, Go/PostgreSQL backend (ve mobil için Flutter) üretimi, planlama modu, snapshot, rollback ve kaynak kodu ihracı gibi özellikler sunar.
AI şu durumlarda parlak:
Kaçınılması veya sınırlanması gereken durumlar:
Ancak reliably çıkaramadığı noktalar:
Yaygın eksikler: bağlantısı olmayan label/for, yanlış başlık seviyeleri, klavye desteği olmayan tıklanabilir div’ler, zayıf odak stilleri, metin alternatifleri olmayan ikonlar.
Hızlı bir kontrol listesi:
h1 → h2 → h3).header, nav, main, footer) ve çoğaltılmamış.alt içeriyor veya dekoratifse alt="".Modal, drawer, karmaşık formlar, özel selectler, sürükle-bırak gibi karmaşık durumlar için kısa bir erişilebilirlik spesifikasyonu ekleyin—ör. “modalde odak tuzağı”, “Esc ile kapat”, “satır içi hataları duyur” gibi birkaç not, üretilen kodun kalitesini ciddi şekilde iyileştirir.
\u003cdiv\u003e oluyor ve basit bir kart beş katmanlı hale geliyor.Bu nedenle çıkan kodu insanın gözden geçirip düzeltmesi gerekir.
Button/Primary, Button/SecondaryCard/Product, Card/ArticleForm/Input/Text, Form/Checkbox“Rectangle 12” veya “Group 5” bırakmayın—bu AI’yi genel sarmalara iter.
Manuel konumlandırma genelde koddaki mutlak koordinatlara dönüşür. Flex/grid çıktısı istiyorsanız tasarımın flex/grid gibi davranmasını sağlayın:
Tasarım araçlarında iyi davranan bir yapı, üretilen UI’nin varsayılan olarak daha responsif olmasını sağlar.
Tek seferlik renkler, font boyutları ve boşluklar bir defaya mahsus CSS’e yol açar. Bunun yerine:
Bu tutarlılığı artırır ve ileride design system’e refactor etmeyi kolaylaştırır.
AI bulunmayanı çıkaramaz. Önemli varyantları (hover/pressed/disabled), input hata durumlarını, loading ve empty durumlarını dahil edin.
Davranış önemliyse kısaca not edin: “opens modal”, “server-validated”, “shows toast on success”. Bir bileşenin yanında birkaç kelime yanlış etkileşim kodunu önleyebilir.
Ekip akışını standartlaştırıyorsanız bu kuralları hafif bir kontrol listesinde yakalayın ve iç dokümanlara bağlayın.
\u003ch1\u003e bir tane, sonra mantıklı \u003ch2\u003e/\u003ch3\u003e)\u003cul\u003e/\u003col\u003e), \u003cdiv\u003e yığınları değilSemantik yanlışsa CSS ile düzeltmek erişilebilirlik veya kullanılabilirlik sorunlarını çözmez.
Çoğu generator, ekran görüntüsüne uymak için mutlak konumlandırma veya derin sarmalayıcılar kullanır. Bu, içerik değişince bozulur. Flex/grid kurallarını tercih edin ve her sarmalayıcının net bir amacı olana kadar gereksiz katmanları kaldırın.
Tekrarlayan desenleri bileşene dönüştürün ve tek seferlik değerleri tokenlarla değiştirin: boşluk, radius, tipografi, renkler. Varsa mevcut token rehberinize uyun; yoksa küçük bir başlangıç setiyle ilerleyin.
Ağır test takımı gerekmez:
Generatorlar niyet tahmininde bulunur. Yaptığınız düzenlemeleri, etkileşim kurallarını ve bileşen eşlemelerini kaydedin ki sonraki jenerasyonda veya başka bir geliştiricide bu kararlar geri alınmasın.
Her jenerasyonda çıktıyı inceleyip tekrar bildirim döngüsü oluşturun: ortak sorunları (isimlendirme, eksik durumlar, yanlış semantik) not edin, sonra prompt/spesifikasyon ve tasarım kurallarını güncelleyin. Birkaç turda kalite beklenenden fazla iyileşir.
Pilot çalışması yapmadan önce şu kriterlerle değerlendirin: düzen sadakati, bileşen tekrar kullanımı, responsivlik, temel erişilebilirlik ve refactor süresi. Araç/plan karşılaştırmasında fiyatlandırma kontrollerini unutmayın.