Yeniden kullanılabilir UI bileşenleri: isimlendirme, varyantlar ve düzen kuralları

Görsel düzenleyicilerde ekran tutarlılığı neden bozulur

Görsel düzenleyiciler ekranları hızlı yayınlamayı kolaylaştırır. Bu hız, UI'nın görünüm ve davranışındaki yavaş sürüklenmeyi de gizleyebilir. Birden çok kişi aynı anda çalışırken, küçük seçimler üst üste biner: biri 12px dolgu ekler, başka biri 16px kullanır ve üçüncüsü eski bir düğmeyi farklı bir ekrandan kopyalar.

Belirtileri genellikle erken fark edersiniz: neredeyse aynı bileşenler, ekranlar arasında değişen boşluklar ve aynı eylem için biraz farklı kelimeler (Kaydet, Gönder, Onayla). Durumlar da genelde farklılaşır. Bir form net bir yükleniyor durumu gösterir, diğeri göstermez. Hata mesajları değişir ve "hızlı düzeltmeler" bir sayfada görünür ama paylaşılan paterne geri gelmez.

İşte UI borcu böyle başlar. Her tutarsızlık küçük hissettirir ama zamanla ürünün güvenilirliğini azaltır. Ayrıca ekipleri yavaşlatır çünkü insanlar “doğru” sürümü aramak, ekranları karşılaştırmak ve incelemede küçük farkları düzeltmekle daha fazla zaman harcar.

Görsel bir oluşturucudaki bir bileşen kütüphanesi, herkesin yeniden oluşturmak yerine çektiği paylaşılan yapı taşları setidir (düğmeler, alanlar, kartlar, başlıklar, boş durumlar). AppMaster gibi bir platformda bu genellikle görsel UI oluşturucular içinde yeniden kullanılabilir UI parçaları oluşturmak, sonra bunların nasıl isimlendirileceği, yapılandırılacağı ve yerleştirileceği konusunda anlaşmak anlamına gelir; böylece farklı kişiler inşa etse bile ekranlar tutarlı kalır.

Amaç yaratıcılığı ortadan kaldırmak değil. Günlük parçaları öngörülebilir kılmak, seçimlerin kasıtlı olmasını sağlar. Sürüklenmeyi önleyen dört kaldıraç: net isimlendirme, mantıklı varyantlar, temel düzen kuralları (boşluk, hizalama, ızgaralar) ve kütüphaneyi uygulama büyüdükçe sağlıklı tutan takım alışkanlıklarıdır.

Hangi öğe yeniden kullanılabilir bileşen olmalı (hangisi olmamalı)

Her hoş görünen öğe bileşen olmaya layık değildir. Her şeyi bileşen haline getirirseniz, insanlar kütüphanede vakit kaybeder ve olmaması gereken seçenekleri kurcalar.

İyi bir yeniden kullanılabilir bileşen, birçok ekranda göreceğiniz veya her seferinde aynı görünmesi ve davranması gereken bir şeydir. Kullanıcıların hemen tanıdığı kalıpları düşünün: birincil düğme, yardım metni olan bir metin girişi, kaydı önizleyen bir kart.

Küçük bir başlangıç seti genellikle çoğu ekranı kapsar: düğmeler, girişler, kartlar, sayfa başlıkları ve bir iki modal türü (onay ve form).

Pratik bir çıkarım kuralı kararları basit tutar: aynı UI'ı 2–3 kez kullanıyorsanız veya markanız için kritikse ve aynı olması gerekiyorsa çıkarın. Bir kez görünüyorsa, yerel tutun.

Ne tek seferlik kalmalı? Tek bir ekrana bağlı, çok özel düzenler; her gün değiştirdiğiniz deneysel bölümler; ve büyük ölçüde içerik olan şeyler. Örneğin özel metin ve illüstrasyon içeren tek seferlik bir onboarding afişi genelde bileşenleştirmeye değmez.

Her bileşeni odaklı tutun. Bir bileşen tek bir işi yapmalı. İzinler, fatura durumu ve yönetici eylemlerini de yöneten bir “Kullanıcı Kartı” yeniden kullanılmayı zorlaştırır. Daha temiz yaklaşım, görüntü odaklı bir “Kullanıcı Kartı” artı ayrı eylem düğmeleri ve durum etiketleridır.

Yorgunken bile okunabilir kalan isimlendirme kuralları

Bir ekip hızlı gönderim yaptığında, isimler ilk bozulan şeydir. Biri “Button2” kopyalar, diğeri “CTA Button” oluşturur, üçüncüsü “BlueButton” kullanır. Bir hafta sonra kimse hangisinin yeniden kullanılacağını bilmez, bu yüzden yenisini yaparlar. Kütüphane böylece neredeyse kopya bir yığını olur.

Yorgun olsanız bile tutarlı kalmanıza yardım edecek basit bir desen: Bileşen - Parça - Durum. Çoğu bileşen hepsine ihtiyaç duymaz, ama sıra aynı kalır.

İnsanların gerçekten kullandığı kelimeleri kullanın. Takımınız “Müşteri kartı” diyorsa, ona “CRM Kartı” demeyin. Ürün ona “Plan” diyorsa “SubscriptionBox” demeyin. Düz ve anlaşılır dil aranabilirlik kazandırır.

Bir kural çok karışıklığı önler: aynı katmanda "neye benzediği" ile "ne işe yaradığı"nı karıştırmayın. Bir yaklaşımı seçin. Amaç bazlı isimlendiriyorsanız renk kelimelerinden kaçının. Görsellik bazlı isimlendiriyorsanız iş anlamından kaçının. Amaç bazlı isimlendirme genelde daha iyi ölçeklenir.

Kolay taranabilir bileşen listesi örnekleri:

• Düğme - Birincil
• Düğme - İkincil - Devre Dışı
• Girdi - Etiketli
• Kart - Kompakt
• Modal - SilmeyiOnayla

Formatlamaya bir kez karar verin ve yazın: Başlık Harfleri mi yoksa cümle biçimi mi, tire çevresinde boşluklar, ve kısaltmalardan kaçının (evrensel değillerse). Görsel düzenleyicilerde birçok kişi katkıda bulunduğunda, bu küçük seçimler liste büyüdükçe kütüphaneyi okunabilir tutar.

Varyantlar: kaos yaratmadan seçim sunmanın yolu

Varyantlar, bir ekip tek bir bileşeni birçok yerde yeniden kullanabilsin diye kopya oluşturmadan yol verir. İş, hangi farklılıkların önemli olduğuna baştan karar vermekte ve diğer her şeyi kilitlemekte.

Gerçek ihtiyaçları karşılayan birkaç varyant boyutuyla başlayın. Birçok bileşen için üç boyut yeter: boyut (S/M/L), amaç (primary/secondary/danger) ve durum (default/hover/active). Yeni bir seçenek bu boyutlara uymuyorsa, onu yeni bir bileşen olarak değerlendirin, “bir varyant daha” olarak değil.

Varsayılanlar insanların düşündüğünden daha önemlidir. Birisi bileşeni sürükleyip hiçbir şeyi değiştirmediğinde yeni ekranlar doğru görünmelidir. Güvenli varsayılanlar belirleyin (örneğin boyut=M, amaç=primary, durum=default) böylece hız rastgele stil farklılıklarına dönüşmez.

Varyantı olan her bileşen için yazılı ve uygulanan kurallar koyun:

• Desteklenen boyutlar ve izin verilen değerler (kısa tutun)
• Varsayılan değerler
• Varyantlar arasında hiçbir zaman değişmeyenler (padding, yazı tipi, köşe yarıçapı, simge boşluğu)
• Devre dışı ve yükleniyor gibi gerekli durumlar, artı hata durumu mümkünse
• Yeni bir varyant eklemek yerine yeni bir bileşen oluşturulması gereken durumlar

Örnek: müşteri portalında bir “Gönder” düğmeniz var. Bir kişi “Geniş Gönder Düğmesi” yapar, diğeri “Yuvarlak Gönder Düğmesi” yaparsa, sürüklenme hızlıca ortaya çıkar. Kurallarla tek bir Düğme bileşenini tutarsınız. Boyut ve amacı izin verirsiniz, özel padding ve köşe yarıçapını yasaklarsınız ve “Yükleniyor”u bir kez tanımlarsınız (bir gösterge göster, tıklamaları kilitle) böylece her yerde aynı davranır.

Birisi “sadece bir stil daha” dediğinde, hangi kullanıcı problemini çözdüğünü sorun. Cevap net değilse, muhtemelen kaosun maskesidir.

Düzen kuralları: herkesin uyması gereken boşluk, hizalama ve ızgaralar

Düzen kuralları belirsizse, her ekran yavaşça tek seferlik bir haline gelir. Bileşenleri tutarlı tutmanın en hızlı yolu boşluk ve hizalamayı sıkıcı hale getirmektir: birkaç izin verilen seçenek, her seferinde aynı şekilde kullanılır.

Bir boşluk skalasıyla başlayın ve diğer her şeyi yasaklayın. Küçük bir set seçin (örneğin 4, 8, 12, 16, 24) ve bunu bir klavye gibi düşünün: birçok şarkı çalabilirsiniz ama sadece o tuşlarla. Birisi “18px” istiyorsa genelde bileşen veya ızgara doğru değildir.

Boşluğun ne anlama geldiğini açıkça belirtin:

• Padding bir bileşenin içindedir ve ekranlar boyunca tutarlı kalır.
• Gap bir konteyner içindeki öğeler arasındadır (form satırları, araç çubuğu öğeleri).
• Margin bir bileşenin dışındadır ve seyrek kullanılmalıdır.
• İkili yığılmış margin yerine gap tercih edin ki iç içe geçmiş bileşenlerde boşluk iki kat olmasın.

Hizalama kuralları sonsuz "biraz oynat" düzenlemelerini ortadan kaldırır. Basit bir varsayılan iyi çalışır: metni sola hizalayın, etiketler ve girdileri aynı dikey çizgide hizalayın ve birincil eylemleri tutarlı tutun (örneğin bir modalde alt-sağda ve form altbilgisinde sağa hizalı). Metin ağırlıklı satırlar için baseline hizalamayı kullanın. Sadece simge içeren satırlar için ortalanmış hizalamayı saklayın.

Izgaralar karmaşık olmak zorunda değil, ama var olmaları gerekir. Sütunları ve gasketleri (gutters) kararlaştırın ve daha küçük ekranlarda ne olacağını tanımlayın (temel olarak “masaüstünde 12 sütun, mobilde tek sütun” bile yardımcı olur). Konteyner genişliklerini ve kırılma noktalarını bir kez belirleyin, sonra ekranları o sınırlar içinde oluşturun.

Dikkat edilmesi gereken yaygın tuzaklar: her biri padding ekleyen iç içe konteynerler, tutarsız sayfa kenar boşlukları, sabit genişliklerle duyarlı sütunların karışması ve sadece bir ekranı düzelten "sihirli sayılar".

Stil tokenları: fontlar, renkler ve erişilebilirlik temelleri

Stil tokenları herkesin kullandığı ortak seçimlerdir. Tokenlar net olduğunda, farklı kişiler ekranlar inşa etse bile yeniden kullanılabilir UI bileşenleri tutarlı kalır.

Tipografiyle başlayın ve tek bir doğru kaynağı belirleyin. Yazı boyutu, ağırlık ve satır yüksekliği için küçük bir ölçek seçin ve bundan sonra sabit kalın. Çoğu ekip yalnızca birkaç adıma ihtiyaç duyar (örneğin: body, small, caption, title ve page heading). Bu seçimleri tek bir yerde tutun ki yeni metinler aynı varsayılanlardan başlasın.

Renkler anlamlarına göre adlandırıldığında en iyi şekilde çalışır. “Primary” ana eylemi belirtir. “Success” "başarılı"yı, “warning” "kontrol et"i belirtir. Takımınız zaten paletlere göre düşünmüyorsa “blue-500” gibi adlardan kaçının.

İleride sorunları önleyen erişilebilirlik temelleri:

• Metin arka planına karşı yeterli kontrast olmasını sağlayın.
• Dokunma hedeflerini parmaklar için yeterince büyük yapın, fare göstergesi için değil.
• Hata mesajlarını ne olduğunu ve ne yapılması gerektiğini söyleyecek şekilde yazın.
• Durumu iletmek için yalnızca renge dayanmayın.

Tokenlar bileşen varyantlarına doğrudan bağlanmalıdır. Bir Düğme varyantı gibi Primary, Secondary veya Danger onaylı tokenları (renk, kenarlık, metin stili) değiştirmeli, yeni tek seferlik stiller getirmemelidir.

Token listesini insanların gerçekten kullanacağı kadar kısa tutun. İyi bir test: biri doğru tokenı 5 saniyede seçebiliyor mu? Seçemiyorsa, birleştirin veya silin.

Basit bir başlangıç seti tipografi (text.body, text.small, text.title), renk (color.primary, color.success, color.warning, color.danger), boşluk (space.8, space.16, space.24), radius (radius.sm, radius.md) ve odak (focus.ring) içerebilir.

Adım adım: bir görsel düzenleyicide bileşen kütüphanesi kurma

Bir bileşen kütüphanesi "tasarım mükemmelliği"nden çok günlük mikro-kararları ortadan kaldırmakla ilgilidir. Herkes aynı yapı taşlarını seçtiğinde, farklı kişiler inşa etse bile ekranlar tutarlı kalır.

Pratik 5 adımlık yayılım

1. Zaten neye sahip olduğunuzu denetleyin. 5–10 gerçek ekran seçin ve sık tekrar eden kopyaları not alın: düğmeler, metin girişleri, bölüm başlıkları, kartlar ve boş durumlar.

2. Standartlaştırmak için küçük ilk dalgayı seçin. Her yerde görünen ve en çok uyumsuzluk yaratan ilk 10 parçaya odaklanın. Birçok ekip için bu düğmeler, girdiler, açılır listeler, modal diyaloglar, tablo başlıkları ve kartlardır.

3. İnşa etmeden önce kuralları yazın. Kısa tutun: bileşen adı, ne zaman kullanıldığı, izin verilen varyantlar ve etrafındaki düzen kuralları (boşluk, hizalama, genişlik).

4. Bir kez yeniden inşa edin, sonra kademeli olarak değiştirin. Yeni bileşenleri görsel düzenleyicide oluşturun ve üzerinde anlaştığınız varyantları kilitleyin. Eski kopyaları ekran ekran değiştirin. Her şeyi tek bir sprintte yeniden düzenlemeye çalışmayın.

5. Hafif bir inceleme kapısı ekleyin. Yeni bileşenleri ve varyantları kontrol eden bir kişi (haftalık dönen) olsun. Amaç polislik değil; kazara fork oluşmasını engellemek.

"Yeterince iyi" neye benzer

Bir tasarımcı veya PM "Standart kartı kompakt başlıkla kullan" dediğinde ve iki inşa edici aynı sonucu ürettiğinde işe yaradığını anlarsınız. Kazanç: daha az tek seferlik seçim, daha az ince farklılık ve daha hızlı ekran oluşturma.

Kütüphanenizi kasıtlı olarak küçük tutun. Birisi yeni bir varyant istiyorsa önce şu soruyu sorun: bu gerçek bir yeni ihtiyaç mı, yoksa mevcut varyant farklı içerikle bunu karşılayabilir mi?

Yavaş, tutarsız UI'ye neden olan yaygın hatalar

Çoğu tutarsızlık kötü zevkten kaynaklanmaz. Kopyalamak kolaydır, ince ayar hızlıdır ve kimse geri dönüp temizlemez. Sonuç, güncellemesi zor ama neredeyse aynı olan ekranlar setidir.

Yaygın tuzaklardan biri varyant eklemek yerine neredeyse kopyalar oluşturmaktır. Birisi "birincil düğme ama biraz daha uzun" ister ve bileşeni kopyalar. Bir hafta sonra başka biri bunu kopyalar. Şimdi üç düğme var; görünüşleri yakın ama davranışları farklı ve her değişiklik bir av peşine dönüşür.

Bir yavaşlama da aşırı yapılandırılabilir bileşendir: onlarca geçişi olan mega bileşen. Başta esnek hissi verir, sonra öngörülemez olur. İnsanlar güvenmeyi bırakır ve "sadece bu durum için" sürümleri oluşturur; amaç bozulur.

Düzen hataları da en az bunlar kadar zararlı. En büyük hata sorumlulukları karıştırmaktır: bir bileşen kendi dış marginlerini kontrol ederken ekran da boşluk ekler. Rastgele boşluklar sayfa sayfa değişir. Basit bir kural yardımcı olur: bileşenler iç dolgu tanımlar, ekranlar bileşenler arasındaki boşluğu kontrol eder.

Genelde ilk görülen problemler: isimlendirme kuralları aceleyle bozulur, durumlar (yükleniyor, boş, hata) geç eklenir, tek seferlik ince ayarlar kalıcı olur ve farklı insanlar aynı düzeni farklı yollarla çözer.

Her yeni ekran için hızlı tutarlılık kontrol listesi

Bir şey eklemeden önce 60 saniye durun ve temel kuralları kontrol edin. Bir ekran düzgün görünebilir ama sistemi sessizce bozuyor olabilir; bu küçük bozulmalar birkaç kişinin paralel çalışmasıyla hızla çoğalır.

• İsimlendirme: Her bileşen üzerinde anlaşılan desen takip ediliyor mu (örneğin Form/Input, Form/Input.HelperText, Table/RowActions). İsim birinin hızlıca arayıp yerleştirmesine yardım etmiyorsa şimdi yeniden adlandırın.
• Sahip + amaç: Her paylaşılan bileşenin bir sahibi (kişi veya ekip) ve ne zaman kullanılacağına dair bir cümle açıklaması olsun.
• Sadece onaylı boşluk ölçeği: Tüm padding, gap ve margin onaylı boşluk adımlarını kullanıyor mu? Yeni bir sayı yazıyorsanız "çünkü göze iyi geliyor" diye durmayın, en yakın adımı seçin.
• Durumlar dahil: Ana etkileşimli parçalar sadece mutlu yolu değil, yükleniyor ve hata gibi durumları da içersin. Devre dışı düğme, girdi hatası, boş liste, yeniden dene gibi.
• Yeni stil icat edilmedi: Ekranı mevcut tokenlar ve bileşenlerle kurun. Yeni bir renk, font boyutu, radius veya gölge istiyorsanız bunu bir sistem isteği olarak ele alın, ekran düzeltmesi olarak değil.

Örnek: iki kişi aynı özelliği kuruyor, kurallarla ve kuralsız şekilde

Maya ve Leon müşteri destek ekibinde. İkisine iki ekran lazım: hızlı tarama için bir bilet listesi ve bir bilet üzerinde işlem yapmak için bir detay ekranı. İşleri paylaşırlar ve görsel düzenleyicide inşa ederler.

Kuralsızken, her kişi "bir kart"ı farklı yapar. Maya ince bir sınır ve gölgeyle beyaz bir kart kullanır. Leon gri bir kart, sınır yok ama ekstra padding kullanır. Bir ekranda yuvarlak bir birincil düğme varken diğerinde kare düğme ve bir metin bağlantısı vardır. Durum bir ekranda renkli bir nokta, diğerinde bir pil olarak görünür. Detay sayfasında etiketler farklı genişlikte olduğu için alanlar hizalanmaz ve form tümüyle sallantılı hisseder.

İnceleme toplantısı bir stil tartışmasına döner ve basit bir güncelleme (örneğin "Öncelik" eklemek) birçok tek seferlik düzeni değiştirmeyi gerektirir.

Kurallarla, paylaşılan yeniden kullanılabilir UI bileşenlerinden oluşan küçük bir kütüphaneyle başlarlar: yapı ve boşluk için bir TicketCard, durum stilleri ve kontrast için bir StatusBadge ve tutarlı birincil eylemler için bir ActionBar.

Şimdi liste ekranı ana alanlar için kompakt TicketCard varyantını kullanır ve önizleme satırı gösterir. Detay ekranı tam açıklama, zaman çizelgesi ve ek alanlar için detay varyantını kullanır. Yapı aynı kalır; varyant hangi alanların görüneceğini kontrol eder.

En iyi kısmı görünmeyendir: daha az inceleme yorumu, "neden farklı" sorusu ve daha hızlı sonraki güncellemeler. Takım "Kapandı"yı "Çözüldü" olarak yeniden adlandırıp rengini ayarladığında, StatusBadge'i bir kere değiştirirler ve her iki ekran da birlikte güncellenir.

Zaman içinde tutarlı tutmak (ve sonraki adımlar)

Tutarlılık tek seferlik bir kurulum değildir. Daha fazla kişi ekran inşa etmeye başladıkça, "sadece bu sayfa için" seçimleri çoğalır ve kütüphane sürüklenmeye başlar.

Basit bir değişiklik süreci takımın hızla hareket etmesini sağlar, her düğme ayarı tartışmaya dönüşmesin diye:

• Öner: ne değişiyor ve neden (yeni bileşen, yeni varyant, yeniden adlandırma, kullanımdan kaldırma)
• İnceleme: bir tasarımcı veya UI sahibi isimlendirme, boşluk kuralları ve erişilebilirlik temellerini kontrol eder
• Onay: kısa bir notla net bir evet/hayır
• Yayın: paylaşılan kütüphaneyi güncelle ve değişikliği bir yerde duyur

Kararlar için bir yer olmalı. Kısa bir "UI kuralları" dokümanı yeterlidir; içinde isimlendirme kuralları, resmi varyant listesi (ne var ne yok) ve yapılmaması gerekenler listesi (örneğin: "Farklı padding ile ikinci bir 'Birincil Düğme' oluşturmayın") bulunmalıdır.

Aylık bir temizlik zamanı planlayın. Kopyaları birleştirmek, kullanılmayan parçaları kaldırmak ve eski bileşenleri kullanım dışı ilan etmek için kullanın ki insanlar yanlış olanı almaktan vazgeçsin.

Aynı desen iki defa göründüğünde refaktör edin (örneğin iki ekip hafif farklı boş durumları oluşturdu). Gerçekten benzersiz, zaman baskılı ve tekrar etmeyecekse tek seferliği kabul edin.

AppMaster'da inşa ediyorsanız, pratik bir sonraki adım önce tek bir iş akışını standartlaştırmaktır (örneğin "Bilet oluştur" veya "Ödeme"), sonra genişletmek. UI oluşturucular aynı bileşenleri ekranlar arasında paylaşmayı kolaylaştırır ve appmaster.io, takımınızın sadece sayfa düzenleri değil tam uygulamalar destekleyen no-code yaklaşımlar için başvurabileceği bir referans noktasıdır.