No-code UI oluşturucularında tasarım tokenları ekiplerin renkleri, yazı tiplerini, boşlukları ve varyantları bir kez tanımlayıp tahmine gerek kalmadan tutarlı UI göndermesini sağlar.
Tutarsız UI nadiren bir “tasarım sorunu” olarak başlar. Zaman sorunu olarak başlar. Birine şimdi bir butona ihtiyacı vardır, bu yüzden başka bir sayfadan kopyalar ve yakın görünene kadar değiştirir.
İşte küçük farklılıkların sızdığı yer: neredeyse aynı iki mavi, köşe yarıçapının 6'dan 8'e değişmesi, başlığın “biraz kalın” olması ve padding'in ekranı yapan kişiye bağlı olarak değişmesi. No-code oluşturucularda küçük tek seferlik düzenlemeler yapmak daha kolaydır çünkü kontroller hemen oradadır ve değişiklikler zararsız hissettirir.
Ürün büyüdükçe kayma hızlanır. Daha fazla sayfa daha fazla tekrar eden desen demektir. Daha fazla oluşturucu daha fazla kişisel zevk demektir. Daha fazla ekip arkadaşı daha fazla izole “hızlı düzeltme” demektir. Bir kişi müşteri portalını, bir başkası admin panelini yapıyorsa aynı markanın iki farklı yorumu ortaya çıkar.
Günlük işte “göze göre” seçimler görünür: bir rengi “doğru görünene kadar” seçmek, ekran “çok sıkışık” hissettiği için boşluğu birkaç piksel kaydırmak, var olan bir butonu kullanmak yerine yeni bir buton stili oluşturmak, varsayılan biraz küçük geldiği için yazı boyutlarını karıştırmak veya bir ekranı düzeltip geri kalanları kontrol etmemek.
Maliyet daha sonra ortaya çıkar. İncelemeler yavaşlar çünkü geri bildirim öznel hale gelir ("diğer sayfa gibi hissettirsin"). Yeniden işler birikir çünkü değişiklikleri her yerde uygulamak zordur. Web ve mobil ayrışır çünkü farklı kişiler benzer ama aynı olmayan seçimler yapar.
Tasarım tokenları bu durumu, “yeterince yakın” kararları paylaşılan değerlere dönüştürerek çözer. Takım ve uygulama büyüse bile UI tutarlı kalır.
Tasarım tokenları UI'nız hakkında isimlendirilmiş kararlardır. “Bu maviyi kullan” veya “butonlar ferah olsun” demek yerine, bu seçimlere herkesin yeniden kullanabileceği net isimler verirsiniz.
Bir token ham değer değildir. Ham değer 16px, #2563EB veya 600 (font ağırlığı) olabilir. Token ise o değerin ürününüzde ne anlama geldiğini açıklayan etikettir, örneğin space-4, color-primary veya font-weight-semibold.
Bu kayma göze göre seçim problemini durdurur. İnsanlar duygulara göre değer seçtiğinde, yavaş yavaş beş farklı mavi, üç biraz farklı başlık ve ekran ekran değişen boşluklar toplarsınız.
Tokenlar tek bir gerçek kaynağı olarak en iyi şekilde çalışır. Her ekran ve bileşen aynı isim setine refere ederse, görünümü düzinelerce ekranı aramak yerine birkaç token değerini güncelleyerek tüm uygulamada değiştirebilirsiniz.
Tokenlar ayrıca tasarım ile uygulamayı birbirine bağlar. Tasarımcılar token adlarını spesifikasyonlarda kullanır, oluşturucular ise aynı adları no-code UI oluşturucuda kullanır; böylece tasarım teslimat sırasında korunur.
Çoğu token seti birkaç kategoriye girer: renk rolleri (primary, background, text, danger), tipografi (font aile, boyutlar, ağırlıklar, satır yüksekliği), boşluk adımları (padding, margin, gap), şekil ve derinlik (radius, border genişlikleri, gölgeler) ve bazen hareket (süreler ve easing).
Çoğu takımın büyük bir token kitaplığına ihtiyacı yoktur. Çoğu ekranı kapsayan, insanların değerleri tahmin etmeyi bırakmasını sağlayan küçük, net bir sete ihtiyaçları vardır. Bu, no-code araçlarda “sadece bu sefer” düzenlemelerin hızlıca yayılabildiği yerlerde daha da önemlidir.
Pratik bir başlangıç seti beş grubu kapsar:
Kütüphaneyi akıllı tutmanın bir kuralı: bir değer üç veya daha fazla yerde görünüyorsa, onu token yapın. Bir yerde görünüyorsa, yeni norm haline gelmeden önce şüpheli muamelesi yapın.
İyi token isimleri tartışmaları başlamadan önce engeller. İnsanlar bir tokeni aramadan tahmin edebiliyorsa, onu yeniden kullanırlar. Edemezlerse yeni bir tane oluştururlar ve temanız bölünür.
Bir değerin UI'da ne iş yaptığını anlatan isimleri tercih edin, nasıl göründüğünü değil. text-primary herkesin ne zaman kullanacağını söyler. blue-600 sadece bir boya kutusudur.
Kullanışlı bir desen iki katmanlıdır:
color-blue-600, space-16, font-14 gibi ham yapı taşlarıtext-primary, bg-surface, border-muted gibi UI rolleriNo-code UI oluşturucuda anlamsal tokenlar, tasarımcı olmayanların doğru değeri göze göre seçmeden hızlıca seçmesine yardımcı olur.
Çoğu token kütüphanesi dağılır çünkü “yeni” varsayılan olur. “Yeniden kullan”ı varsayılan yapın.
Kuralları basit tutun:
Sonra adlandırmayı standardize edin. Bir yazım stili seçin (kebab-case iyi işler), sabit önekler kullanın (text-, bg-, border-, icon-, space-) ve sayı skalalarını tutarlı tutun (space-4, space-8, space-12, space-16).
Mevcut UI'nızı kanıt olarak kullanın. Yeni bir şey yaratmadan önce kısa bir envanter yapın: ekran görüntüleri toplayın, stilleri inceleyin ve üretimde gerçekte gördüğünüz her renk değeri, yazı boyutu ve boşluk değerini (tek seferlik olanlar dahil) not edin.
Sonra kasıtlı olarak çoğaltmaları azaltın. Genellikle aynı griyi beş slightly farklı hex değeriyle veya 14, 15 ve 16 arasında atlayan boşluklarla bulursunuz. Saklayacağınız bir değeri seçin, sonra eski değerleri ona eşleyin. İşte tokenların pratik olduğu yer: zevk üzerine tartışmayı bırakıp küçük bir ortak tercih setinde anlaşmaya başlarsınız.
İyi bir ilk sürüm tek geçişte inşa edilebilir:
Her token için bir cümle rehberi ekleyin: nerede kullanılacağı ve nerede kullanılmayacağı. Örnek: “text-muted yardımcı metin içindir, ana butonlar için değil.”
Son olarak sahipliği kararlaştırın. Değişiklikleri onaylayacak bir kişi (veya küçük bir grup) atamak yardımcı olur; basit bir kural: “Yeni bir token yalnızca mevcut bir token uymuyorsa eklenir.” Bu, ürün büyürken sistemi stabil tutar.
Her ekranın devralacağı varsayılanlarla başlayın: temel bir metin stili (font, boyut, satır yüksekliği, renk), başlık stilleri (H1-H3) ve sayfaların rastgele hissetmemesi için küçük bir yerleşim boşluğu kuralı.
Sonra tokenları aracınızın tema ayarlarına eşleyin: tema değişkenleri, global stiller, stil ön ayarları veya tasarım sistemi ayarları ne ad veriyorsa. Amaç “Primary” veya “Space/16” seçildiğinde bir tokenın seçilmesidir, tek seferlik bir değer değil.
Yeniden kullanılabilir stilleri günlük kullandığınız desenlere odaklayın. Başlangıç seti olarak bir kart stili (arkaplan, border, radius, padding, gölge), bir form alanı stili (label, input, yardımcı metin), buton stilleri ve tablo satırı yoğunluğu ile hover durumları iyi bir başlangıçtır.
Durumlar (states) tutarsızlığın sızdığı yerdir, bu yüzden bunları erken tanımlayın. Her interaktif bileşenin hover, focus, disabled ve error için token tabanlı değerleri olmalı. Focus her yerde aynı ring rengi ve kalınlığını kullanmalı. Error aynı border ve metin renk eşlemesini kullanmalı.
Son olarak paylaşımı planlayın. Workspace'iniz şablonlar veya yeniden kullanılabilir modülleri destekliyorsa, tokenları ve temel stilleri bir “başlangıç uygulaması”na koyun; yeni projeler buradan kopyalansın. Böylece yeni ekranlar varsayılan olarak tutarlı başlar.
Varyantlar bir UI sisteminin ya sakin ve öngörülebilir olmasını sağlar ya da tek seferlik tweaks yığınına dönüşmesine izin verir. Varyantlar renk, tipografi ve boşluk için tokenlara ince bir katmanla eşlendiğinde en iyi çalışır.
Her yerde kullandığınız küçük bir ana bileşen setiyle başlayın: butonlar, inputlar, rozetler (badges), uyarılar ve kartlar. Her birine iki seçim boyutu verin: boyut ve amaç. Boyut mekanik olmalı (tipografi ve boşluk). Amaç anlam taşımalı (anlamsal renkler).
Boyut varyantları yalnızca token tabanlı birkaç özelliği değiştirdiğinde tutarlı kalır: yazı boyutu, padding ve border radius. Amaç varyantları öncelikle renk rollerini (arkaplan, metin, border) değiştirmeli ve asla boşluğu gizlice değiştirmemelidir.
Çoğu ürünü kapsayan bir set:
Durum kurallarını sadece butonlar için değil tüm bileşenlere uygulayın. Örneğin: focus her zaman görünür bir ring gösterir, hover tutarlı bir şekilde kontrastı artırır ve disabled aynı opaklığı kullanır ve tıklamaları engeller.
Yalnızca tekrar eden bir anlamı temsil ettiğinde yeni bir varyant ekleyin (ör. “danger”). Eğer tek seferlik düzenleme ise, genellikle yeni bir bileşen veya bir sarmalayıcı (wrapper) olmalı, herkesin daha sonra yanlış kullanacağı bir varyant değil.
Ürün web ve mobilde yayınlandığında “aynı marka” her zaman “aynı pikseller” anlamına gelmez. Hedef, platformlar farklı varsayılanlara sahip olsa bile ekranların bir aile gibi hissetmesi.
Paylaşılabilir tokenlarla başlayın: renk rolleri (background, surface, text, primary, danger), tipografi ölçeği (boyutlar ve ağırlıklar) ve boşluk tokenları (4, 8, 12, 16, 24). Bunlar tahmini ortadan kaldırır ve güncellemeleri öngörülebilir kılar.
Sonra gerçek farklılıklara izin verin. Mobil daha büyük dokunma hedeflerine ve genellikle biraz daha fazla boşluğa ihtiyaç duyar. Web daha yoğun tablolar, yan çubuklar ve çok sütunlu düzenlere ihtiyaç duyar. Fontlar da farklı olabilir: webde marka fontunu kullanırken iOS/Android'de okunabilirlik ve performans için platform varsayılanlarını tercih edebilirsiniz.
Pratik yaklaşım iki katmanlıdır: anlamı tanımlayan global tokenlar ve o anlamın nasıl render edileceğini tanımlayan platform tokenları.
color.text, color.primary, space.md, radius.sm, type.bodytype.family.web, control.height.web, space.tableRowtype.family.mobile, control.height.mobile, space.touchBileşen isimlerini tutarlı tutun (Button/Primary); boyutlar farklı olsa bile. Yayın öncesi her iki tema için de kontrast kontrolleri yapılmasını zorunlu kılın.
Tokenlar ancak stabil ve anlaşılır kaldıklarında işe yarar. Hafif bir yönetim olmadan ekipler gizlice “bir mavi daha” veya “bir padding daha” ekler ve tekrar göze göre ayarlamaya dönersiniz.
Süreci küçük ama gerçek tutun:
Kullanımdan kaldırmalarla birlikte basit bir değişiklik günlüğü tutun. Eski bir token değiştiriliyorsa yerine ne kullanılacağı söylenmeli, bir süre çalışır durumda bırakılmalı ve yeni ekranların onu kullanmaması için açıkça işaretlenmelidir.
Temizlik işi işin bir parçasıdır. Ayda bir, kullanılmayan tokenları ve bileşen varyantlarını kaldırın veya en azından işaretleyin.
Tasarımcı olmayanlar teoriden çok örneğe ihtiyaç duyar.
Yapılacak: boşluk merdivenini gapler için kullanın ve ana eylem için Primary Button varyantını kullanın.
Yapılmayacak: padding'i “13px çünkü göze iyi geliyor” şeklinde ayarlamak veya bir ekranı eşleştirmek için yeni bir buton stili oluşturmak.
Token çalışmasını ürün öncelikleriyle ilişkilendirin: yeni özellikler, yeniden markalaşma ve erişilebilirlik düzeltmeleri token güncellemelerini yönlendirmeli, kişisel tercihler değil.
Tokenların faydasını yitirmesinin en hızlı yolu onları bir atık alanı gibi görmektir. İyi niyetle başlarsınız, sonra bir kaç hızlı düzeltme birikir ve ekip tekrar göze göre seçim yapmaya döner.
Erken çok fazla token oluşturmak yaygın bir tuzaktır. Her ekran kendi renk veya boşluk tokenını alırsa, bir sistem kurmuyor; istisnaların envanterini çıkarıyorsunuz demektir. Yeni bir token yalnızca en az iki yerde kullanılacağını gösterebildiğinizde ekleyin.
Sessiz bir problem de ham değerlerin bileşenlere sızmasına izin vermektir. Birisi buton padding'ini “sadece bu sefer” diye 14px olarak ayarlar veya bir kartta hex rengi doğrudan kullanır. Haftalar sonra kimse neden farklı olduğunu hatırlamaz. Alışkanlık haline getirin: görünür ve tekrar edilebilir ise token olmalı.
Ayrıca token türlerini karıştırmamaya dikkat edin. Temel tokenlar (ör. gray-900, space-4) ham değerleri tanımlar. Anlamsal tokenlar (ör. text-primary, surface-muted) anlamı tanımlar. Bir bileşen temel token kullanıp başka biri aynı rol için anlamsal token kullanmaya başlayınca sorun başlar.
Durumlar da son aşamada ağrı kaynağıdır. Takımlar genellikle normal stilleri tanımlar, sonra focus, hover, disabled ve error'ı yayına çok yakın bir zamanda yamalar. Bu yüzden tutarsız focus ring'leri ve üç farklı “error” kırmızısı ortaya çıkar.
Büyümeden önce kısa bir tuzak kontrolü yapın:
UI'nızı daha fazla ekrana, takıma veya ürüne yaymadan önce temelinizin kopyalandığında tahmine gerek kalmayacak kadar açık olup olmadığını kontrol edin.
Küçük bir ekip aynı anda iki uygulama geliştiriyor: müşteri portalı ve dahili admin paneli. Farklı kişiler farklı ekranlara dokunuyor ve no-code UI oluşturucuda hızlıca inşa ediyorlar. Birkaç hafta sonra UI "tuhaf" hissetmeye başlıyor, ama kimse tek bir problemi adlandıramıyor.
Tokenlar olmadan inceleme yorumları birikir: butonlar neredeyse aynı ama değil, boşluk ekran ekran değişiyor, form alanları eşleşmiyor ve portal istemeden "dostça" hissederken admin paneli kazara "katı" hissediyor.
İşlerini küçük, pratik bir token seti getirerek çözüyorlar. Anlamsal renkler (Primary, Success, Danger, TextMuted), bir boşluk skalası (4, 8, 12, 16, 24) ve tek bir radius ile tutarlı durumlara sahip buton varyantları (Primary, Secondary, Ghost) tanımlıyorlar.
Artık katkıda bulunanlar rastgele hex değerleri ve yazı boyutları seçmeyi bırakıyor. Tokenları ve varyantları seçiyorlar, böylece her yeni sayfa aynı kararları miras alıyor.
İnşa etme hızlanıyor çünkü seçimler zaten yapılmış. İncelemeler küçük görsel noktalardan ziyade gerçek UX sorunlarına kayıyor. “Bu butonu primary varyanta yap” demek, "Butonu biraz daha mavi ve biraz daha uzun yapabilir misin?" taleplerinin yerini alıyor.
Sonra küçük bir yeniden markalaşma oluyor: ana renk değişiyor ve yazı ölçeği sıkılaştırılıyor. Tokenlar sayesinde ekip birkaç değeri bir kez güncelliyor ve hem portal hem admin panel birlikte yenileniyor.
Sık görülen ve belirgin kayma olan bir akışı seçin: onboarding, bir ayar sayfası veya basit bir form gibi. Tek bir akışı dönüştürmek fikri kanıtlamanın ve göze göre ayarlamayı durdurmanın en hızlı yoludur.
Küçük, güvenli bir token setiyle başlayın: primary/background/text/border/danger, kısa bir yazı ölçeği, bir boşluk merdiveni ve 2-3 radius ile gölge seviyesi. Sonra yalnızca token kullanan küçük bir bileşen seti oluşturun: bir buton, bir input, bir kart, bir uyarı. Varyantları yalnızca gerçek bir ihtiyacı çözdüklerinde ekleyin.
Takımla kısa bir değerlendirme yapın: bir “önce” ekranı (tutarsız padding ve fontlar içeren) ve tokenlar ve varyantlarla oluşturulmuş bir “sonra” ekranı gösterin. Birkaç kural üzerinde anlaşın (ör. “hard-coded renk yok” ve “boşluk token olmalı”) ve en önemli tutarsızlıkları önce düzeltin.
Yaygınlaştırma için önce yeni ekranları dönüştürün, sonra dokunduğunuz eski ekranları geriye doğru güncelleyin. Destek yeni bir yönetici filtresi istediğinde, o paneli token tabanlı bileşenlerle yeniden inşa edin ve yalnızca düzenlediğiniz yerleri değiştirin.
Eğer AppMaster'da backend, web ve mobil ile tam ürünler inşa ediyorsanız, tokenları ve yeniden kullanılabilir UI stillerini erken belirlemek yeni ekranların aynı kararları miras almasını sağlar. Böylece görsel tutarlılık ve uygulama mantığı tekrarlayan temizlik olmadan birlikte ilerleyebilir.
Bir tasarımcımız olduğu halde neden UI tutarsızlığı devam ediyor?UI sapması genellikle küçük "sadece bu sefer" düzenlemelerle başlar: bir bileşeni kopyalamak, padding'i değiştirmek veya rengi göze göre seçmek. Zamanla bu küçük farklılıklar sayfalara ve ekip üyelerine yayılır; incelemeler paylaşılan kurallara göre hızlı kontroller yerine öznel tartışmalara dönüşür.
Tasarım tokenı tam olarak nedir (teori olmadan)?Tasarım tokenları, insanların ham değerleri tahmin etmek yerine yeniden kullanması için isimlendirilmiş UI kararlarıdır. Değer 16px veya #2563EB olabilir, ama token adı amacını açıklar; örneğin space-16 veya color-primary gibi, böylece herkes aynı seçimi her seferinde kullanır.
Gerçek bir ürün için hangi token kategorilerini önce tanımlamalıyız?Önce renk rolleri, tipografi, boşluk ve küçük bir köşe ve gölge seti ile başlayın. Bu, çoğu ekranı kapsar ve en yaygın "göze göre ayarlama" sorunlarını durdurur; aynı zamanda token setini insanların gerçekten kullanacağı kadar küçük tutar.
Yeni bir token ne zaman eklemeliyiz yoksa tek seferlik bir stil olarak mı bırakmalıyız?Pratik bir varsayılan: bir değer iki veya daha fazla yerde göründüğünde veya hover, focus, disabled ya da error gibi gerçek bir durumu desteklediğinde token oluşturun. Gerçekten tek seferlik bir değerse, bileşenin yerelinde tutun ki yanlışlıkla global standart olmasın.
Token isimleri anlamsal (`text-primary`) mı yoksa ham (`blue-600`) mı olmalı?Anlamsal isimler, tokenın ne için olduğunu anlatır (text-primary, bg-surface) ve insanların paleti ezberlemeden doğru seçimi yapmasını sağlar. blue-600 gibi ham isimler temel yapı taşları olarak uygundur, ama bileşenlerde bunlara dayanmak renklerin uygulama genelinde kötü kullanılmasını kolaylaştırır.
Tutarsız bir UI'dan tokenları kırmadan nasıl oluştururuz?Var olan yaygın olmayan UI'dan token oluşturmak için yayınladığınızı denetleyin: üretimde gerçekte gördüğünüz renkleri, yazı boyutlarını ve boşluk değerlerini toplayın, sonra yakın değerleri kasıtlı olarak birleştirin. Küçük, temiz bir set elde ettikten sonra eski değerleri en yakın tokene eşleyin ki yeni ekranlar tokenları yeniden kullansın.
No-code UI oluşturucuda tokenları pratikte nasıl uygularız?Öncelikle global varsayılanları ayarlayın, sonra tokenları aracınızın tema değişkenlerine veya global stillerine eşleyin ki bileşenler isimlere referans versin, hex kodlarına ya da piksel değerlerine değil. Ardından günlük kullandığınız bileşenler için küçük yeniden kullanılabilir stiller oluşturun ve hover, focus, disabled ve error durumlarının da token kullanmasını sağlayın.
Buton ve input gibi bileşen varyantlarını kaos yaratmadan nasıl oluştururuz?Varyantları basit ve öngörülebilir tutun: yalnızca boyut (size) ve amaç (intent) olsun. Boyut token tabanlı birkaç özelliği değiştirir (yazı boyutu, padding), amaç ise anlamsal renk rollerini değiştirir; böylece bir “danger” buton gizlice boşluk veya tipografiyi değiştirmez.
Aynı markayı zorlamadan web ve mobil temaları nasıl hizalayabiliriz?Anlamsal tokenları platformlar arasında paylaşın ki anlam aynı kalsın; sonra dokunma hedefleri ve yoğunluk gibi farkları işlemek için platforma özel tokenlara izin verin. Amaç “aynı aile, aynı piksel değil”dir: web ve mobil tutarlı hissetmeli ama kendi kısıtlarına saygı göstermeli.
Tokenları zaman içinde temiz tutmak için nasıl yönetim yapmalıyız?Açık bir sahiplik atayın ve değişiklikler için küçük bir inceleme akışı kullanın ki yeni tokenlar hızlı çözümler olarak eklenmesin. Düzenli güncelleme ritmi ve eski tokenları kademeli olarak kullanımdan kaldırma, sistemin daha fazla kişi ekran oluşturdukça stabil kalmasını sağlar; bu AppMaster projelerinde hızlı katkıda bulunan ekipler için özellikle önemlidir.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
