Yönetici panelinde okunaklı kalan veritabanı adlandırma kuralları

İsimler, bir yönetici panelinin temiz mi dağınık mı hissettireceğini belirler

Çoğu yönetici paneli veri modelinizden üretilir. Tablo ve alan adları menü öğeleri, sayfa başlıkları, sütun başlıkları, filtre etiketleri ve hatta insanların arama kutusuna yazdığı kelimeler olur.

İsimler net olduğunda, bir yönetici bir listeyi saniyeler içinde tarayıp anlayabilir. İsimler belirsizse, durur, tahmin eder, bir kaydı açar, geri döner ve tekrar dener. Bu tereddüt birikir. "Doğru müşteriyi nasıl bulurum?" destek sorularına ve kimsenin okumak istemediği eğitim dokümanlarına dönüşür.

Geliştiriciler genelde şeyleri inşa ederken ve hata ayıklarken anlaşılır kılmak için adlandırır. Operatörler ise işi yaparken anlaşılır isimler ister. Bir geliştirici acct, addr1 veya stat ile idare edebilir çünkü ne anlama geldiğini hatırlar. Bir operatör ise çözmeden "Hesap", "Adres satırı 1" ve "Durum" ister.

Bir yönetici ekranında "okunaklı" genellikle şunu ifade eder:

• Bir tabloyu tarayıp her sütunu bir satırı açmadan anlayabilirsiniz.
• Günlük işte kullandığınız kelimelerle arama ve filtreleme yapabilirsiniz.
• Tarihlerin gerçekten tarih, durumların tutarlı olduğu gibi sürpriz olmadan sıralayıp karşılaştırabilirsiniz.

Ekranları modelden üreten bir platform kullanıyorsanız (örneğin AppMaster’ın Data Designer ve yönetici tarzı görünümleri), adlandırma UI tasarımının bir parçası olur. İyi isimler, etiketleri ve düzenleri cilalamaya başlamadan önce size ilk andan itibaren temiz varsayılan ekranlar verir.

Tüm ekibinizin takip edebileceği basit bir adlandırma tabanı

Oluşturulan yönetici ekranlarının ilk günden temiz görünmesini istiyorsanız, ilk tablo eklenmeden önce bir taban üzerinde anlaşın. Çoğu adlandırma problemi teknik değil, tutarlılık problemidir.

Bir tanımlayıcı stil seçin ve karıştırmayın. Veritabanları için snake_case genelde okumak ve aramak için en kolay olandır. Eğer stack’iniz camelCase bekliyorsa, her yerde ona bağlı kalın (tablolar, sütunlar, yabancı anahtarlar, enum'lar). Proje ortasında stil değiştirmek etiketlerin ve filtrelerin rastgele hissetmesine neden olur.

Çoğu ekip için işe yarayan bir taban:

• Tam kelimeler kullanın: customer_id, cust_id değil; description, desc değil.
• Nesneler için net isimler, eylemler için net fiiller kullanın: invoice, payment, refund_requested.
• Tutarlı zaman damgası isimleri kullanın: created_at, updated_at, deleted_at.
• data, info, value veya type gibi belirsiz kelimelerden kaçının; bağlam ekleyin (shipping_address, payout_method gibi).
• Tekil vs çoğul kullanımında tutarlı olun (birçok ekip tablolar için çoğul customers, sütunlar için tekil customer_id kullanır).

Küçük bir sözlük yazın ve görünür tutun. Erken karar verin: customer mı, client mı, account mı yoksa user mı demek istiyorsunuz; sonra tek bir terime bağlı kalın. "order" vs "purchase" veya "ticket" vs "case" için de aynı şeyi yapın.

Hızlı bir kontrol: iki kişi account_status gibi bir sütuna bakıp ne anlama geldiği konusunda soru sormadan anlaşabiliyorsa, taban işe yarıyor demektir. Anlaşamıyorlarsa, ekranlar ve filtreler kurmadan önce yeniden adlandırın.

Menü ve listelere düzgün eşleyen tablo adlandırma kuralları

Çoğu yönetici paneli tablo adlarını menü öğelerine, liste başlıklarına ve breadcrumb'lara dönüştürür. Şemanız sadece mühendislere ait değildir; UI’nızın ilk taslağıdır.

Varlık tabloları için bir stil seçin ve ona bağlı kalın: tekil (user, invoice, ticket) veya çoğul (users, invoices, tickets). Tekil formlarda daha iyi okunabilir ("Edit Ticket"), çoğul menülerde daha iyi görünebilir ("Tickets"). Her ikisi de uygundur. İkisinin karıştırılması gezinmeyi tutarsız hissettirir.

Tabloları ne oldukları için adlandırın, ne yaptıkları için değil. Bir tablo işaret edilebilecek bir şeyi temsil etmelidir. payment bir şeydir; processing bir eylemdir. Sonradan refunds, retries ve settlements eklerseniz, "processing" tablo adı yanıltıcı olur.

Menüleri ve listeleri temiz tutacak kurallar:

• Somut isimler kullanın (customer, subscription, invoice, ticket_message).
• Kalıcı veri için kova tablolarından kaçının (settings, misc, temp, data). Bunları gerçek varlıklara bölün (notification_setting, tax_rate, feature_flag).
• Kısaltmalar yerine alt çizgiyle kısa, okunaklı birleşik isimleri tercih edin (purchase_order, support_ticket).
• Çakışmayı önlediğinde modül öneki ekleyin (örneğin billing_invoice vs invoice). Önek kullanırsanız modül boyunca tutarlı uygulayın.

AppMaster kullanarak doğrudan şemadan ekranlar üretiyorsanız, isimlendirilmiş sabit isimli varlık tabloları genelde az sonradan düzenleme gerektiren temiz bir varsayılan menü ve liste görünümü üretir.

Join tabloları ve tanımlayıcılar: çoktan-çoğa okunaklı tutma

Çoktan-çoğa ilişkiler yönetici panellerinin genelde karışık görünmeye başladığı yerdir. Eğer ilişki tablosu ve anahtarları iyi adlandırılmışsa, oluşturulan ekranlar elle temizleme gerektirmeden okunaklı kalır.

Sıkıcı bir kuralla başlayın ve bozmayın: her tablonun birincil anahtarı id olmalıdır. Bir tabloda user_id birincil anahtar, diğerinde id olmasın. Üniform tanımlayıcılar ilişkileri öngörülebilir kılar ve oluşturulan formlar ile referans alanlarının tutarlı kalmasına yardımcı olur.

Saf join tabloları için her iki varlığın adını kullanarak tek bir desen ve sıralama ile adlandırın. Yaygın seçenekler alfabetik sıradır (product_tag) veya "ana şey önce" (user_role). Bir sıralama seçin ve her yerde uygulayın.

links veya mappings gibi belirsiz isimlerden kaçının; tablo gerçekten nesneler arası genel bağlantılar tutmuyorsa. Çoğu yönetici panelinde açıklık zekâdan üstündür.

Join tablo gerçek bir varlık olduğunda

İlişkinin ekstra alanları varsa, onu kendi modeli gibi ele alın ve insanların anlayacağı bir isim verin: membership, assignment, subscription. Örneğin, bir kullanıcının rolünün starts_at, ends_at ve granted_by gibi alanları varsa, user_role kabul edilebilir, ancak UI’de membership daha anlamlı olabilir.

Ekranları profesyonel tutacak basit kurallar:

• Her tabloda birincil anahtar olarak id kullanın.
• Join tablolarını tutarlı bir sırayla her iki varlığın adıyla adlandırın (user_role).
• user_id ve role_id gibi net yabancı anahtarlar kullanın.
• Gerçek hayata uyan benzersizlik kuralları ekleyin (örneğin bir user_id başına bir role_id).
• Geçmişe izin veriyorsanız, benzersizlik kuralını "aktif" kayıtlara göre yapın (örneğin ended_at null iken benzersiz).

Bu seçimler veri büyüdükçe dayanır ve AppMaster’ın Data Designer ile iyi çalışır; ekranlar doğrudan modelden üretilebilir.

Alan adlandırma desenleri: temiz sütunlar ve filtreler üretme

Alan isimleri sadece geliştiricilere yardımcı olmaz. Kullanıcıların gördüğü sütun başlıklarını, filtre etiketlerini ve form alanlarını belirler.

Öngörülebilir sonekler tahmin gereksiz kılar:

• Yabancı anahtarlar için _id kullanın: customer_id, assigned_agent_id.
• Zaman damgaları için _at kullanın: created_at, paid_at, closed_at.
• Sayaçlar için _count kullanın: login_count, attachment_count.

Booleanlar düz cümle gibi okunmalı. is_ ve has_ tercih edin ki onay kutuları bir bakışta anlamsız olmasın: is_active, has_paid, is_verified. is_not_approved gibi çift olumsuzlardan kaçının. Bir "değil" durumu gerekiyorsa, pozitif modeli kurun ve mantığı kodda tersine çevirin.

Para alanları yönetici ızgaralarında karışıklık kaynağıdır. Bir yaklaşım seçin ve tutarlı kullanın: küçük birimleri (kuruş gibi) integer olarak saklayın ya da sabit hassasiyetli decimal kullanın. Alan adını öyle seçin ki kimse tahmin etmek zorunda kalmasın. Örneğin total_amount_cents + currency_code, veya total_amount + currency_code. price, amount ve totalı karıştırmayın, ancak farklı kavramları temsil ediyorlarsa ayrı tutun.

Metin alanları amaca göre spesifik olmalı, sadece türü değil. description müşteri görebilir. internal_comment gizlidir. notes genel amaçlıdır ve dikkatli kullanılmalıdır. Birden fazla not varsa, kime ait olduklarını belirtin: customer_note, agent_note.

İletişim alanları literal olmalı çünkü genelde hızlı filtrelemelerde kullanılır: website_url, contact_email, billing_email. AppMaster tarafından üretilen yönetici ekranlarında bu tür isimler genelde temiz varsayılan etiketlere dönüşür.

İlişkiler ve yabancı anahtarlar: veri modelini açıklayan isimler

İyi ilişkiler düz İngilizce gibi okunur. Bir yönetici paneli veritabanından oluşturulduğunda, yabancı anahtar isimleri sütun başlıkları, filtreler ve form etiketleri olur.

Bir kuralı tutun: yabancı anahtar sütunu referans verilen tablo adı artı _id olmalıdır. Eğer customer.id varsa customer_id kullanın. order.id için order_id. Bu tutarlılık bir sütunun nereye işaret ettiğini açıkça gösterir.

Kendi kendine ilişkiler ekstra açıklık gerektirir çünkü sonra kolayca yanlış okunur. related_id gibi genel isimlerden kaçının. Yönü ve anlamı açıklayan isimler kullanın: ağaç yapıları için parent_id, organizasyon şemaları için manager_id, birleştirme için merged_into_id gibi.

Bir ilişki join tablo içeriyorsa, cümle gibi okunacak şekilde adlandırın. Örneğin, rol "assignee" ise ticket_assignee.user_id, ticket_user.user_id yerine daha açık olur.

Çoğu problemi önleyecek pratik kontroller:

• owner_idyi farklı anlamlarda tablolar arasında tekrar kullanmayın. created_by_user_id, account_manager_user_id veya billing_contact_id gibi tercih edin.
• Aynı tabloya birden fazla ilişki varsa rolü dahil edin: requested_by_user_id ve approved_by_user_id.
• Tek bir soft delete işaretçisi seçin ve ona bağlı kalın. deleted_at yaygındır ve filtrelerle iyi çalışır.

Daha sonra AppMaster ile ekran oluşturursanız, bu isimler her yerde görünür; küçük bir özen UI temizliğini büyük oranda azaltır.

Enum'lar ve durum alanları: zamanla anlaşılır kalma

Yönetici paneli veritabanınızdan üretiliyorsa, ekranları dağıtan en hızlı yol anlamı küçük bayraklara yaymaktır. Kayıtların ana yaşam döngüsü için bir açık durum enum'ı tercih edin; ekstra bayrakları sadece gerçekten ayrı davranışlar için tutun.

Kullanışlı bir kural: kullanıcılar "Bu öğe yolculuğunun neresinde?" diye soruyorsa, bu bir durumdur. "Gizlemeli miyiz?" veya "Kilidi açık mı?" gibi sorular ayrı boolean alanlarıdır.

Bir durum beş boolean'dan iyidir

is_new, is_in_progress, is_done, is_cancelled yerine tek bir ticket_status kullanın. Liste sütunlarında, filtrelerde ve toplu aksiyonlarda daha iyi okunur. Ayrıca done + in_progress gibi imkansız kombinasyonların oluşmasını engeller.

Enum değerlerini sabit tutun. UI metni değişebilir ama saklanan değerler değişmemeli. waiting_for_review yerine pending saklayın gibi. Daha sonra daha dostça etiketler gösterirsiniz ama veri göçü gerektirmez.

Detay gerektiğinde, statüyü fazla yüklemeyin; ikinci bir alan ekleyin. Örnek: payment_status yaşam döngüsünü tutar, ek detay için failure_reason (metin) eklenebilir.

Enum'ları alana göre adlandırın (filtrelerin anlamlı olması için)

Birden fazla modelde aynı "status" olduğunda ekranların okunaklı kalması için domain öneki kullanın:

• payment_status (sipariş ödeme)
• ticket_priority (destek önceliği)
• user_role (erişim seviyesi)
• invoice_status (fatura yaşam döngüsü)
• delivery_status (teslimat yaşam döngüsü)

Yaşam döngüsü ile operasyonel bayrakları ayırın. Örneğin: status iş akışındaki yeri tanımlar, is_archived ise günlük listelerden gizlenmesini belirtir.

Her enum değeri için takım notlarında bir cümleyle anlam yazın. Gelecekte cancelled ile voided arasındaki farkı unutursunuz. AppMaster kullanıyorsanız bu kısa tanımlar oluşturulan açılır menülerin ve filtrelerin web ve mobil arasında tutarlı kalmasına da yardımcı olur.

Kenar durumlar: tarihler, denetim alanları ve type sütunları

Adlandırma rehberleri genelde tablolar ve temel alanları kapsar, ama yönetici panelleri kenar durumlarda karışır. Tarihler, denetim alanları ve type sütunları kafa karıştıran ekranlara yol açar.

Tarih ve zaman damgaları için isim, olayın hikayesini anlatmalı: planlanan mı, gerçek mi, hatırlatma mı? Basit bir desen fiil anlamı ile net sonek kullanmaktır. Örneğin due_at (planlanan son tarih) ve completed_at (gerçek bitiş) anlaşılır sütunlar ve filtreler olur. Gerçekte scheduled_at ve finished_at gibi daha açıklayıcı isimler gerekebilir.

Opsiyonel ilişkiler başka bir tuzaktır. Table başına yeni desenler icat etmeyin. İlişki adı sabit kalsın ve "opsiyonel" null izin vererek ifade edilsin. manager_id opsiyonel olsa da yine manager_id olmalıdır.

Adresler kodda güzel görünebilir ama ızgaralarda çirkefleşir. Numaralandırılmış satırlar sadece ekip herkesin ne anladığı üzerinde anlaştıysa iyidir. Açık tutun:

• address_line1, address_line2, city, region, postal_code, country_code
• address1, address2 gibi isimlerden kaçının (daha zor okunur, çoğaltılması kolaydır)

Denetim alanları kasıtlı olarak sıradan olmalı:

• created_at, updated_at
• created_by_id, updated_by_id (gerçekten kullanıcı takibi lazım ise)

type ile dikkatli olun. Genelde çok geniştir ve zamanla eskir. type yerine anlamı yazın: payment_method, ticket_channel, customer_tier. Şema tabanlı yönetici ekranlarında (AppMaster dahil) bu tek seçim, net bir filtre ile kafa karışıklığı arasındaki farkı yaratır.

Örnek: yönetici ekranlarında iyi görünen bir destek bileti modeli adlandırma

Küçük, gerçekçi bir destek kurulumunda: müşteriler yazıyor, personel yanıtlıyor ve biletler etiketlenebiliyor. Adlandırma kuralları, otomatik oluşturulan menülerin, liste ekranlarının ve filtrelerin sezgisel görünmesini sağlar.

Kenar çubuğunda isimleri isim olarak okunacak tablo adlarıyla başlayın:

• customer
• ticket
• ticket_message
• ticket_tag
• ticket_tag_link

Çoğu yönetici panelinde bunlar "Tickets" ve "Ticket Messages" gibi etiketlere dönüşür ve join tablosu arka planda kalır.

Ticket liste ekranı için, net sütun başlıkları ve filtreler olacak alan isimleri seçin:

• subject, status, priority
• assigned_to_id (personel kullanıcıya işaret eder)
• last_message_at (en güncele göre sıralama için)
• created_at (standart ve öngörülebilir)

Enum'lar çoğunlukla okunabilirliği bozduğu yerlerdir, bu yüzden seti sabit ve sade tutun:

• ticket_status: new, open, pending_customer, resolved, closed
• ticket_priority: low, normal, high, urgent

Sürekli karışıklığı önleyecek bir seçim: "customer"ı aşırı yüklemeyin. Destekte talep eden her zaman müşteri olmayabilir (bir iş arkadaş sizin adınıza gönderebilir). Gönderen kişiyi saklıyorsanız ona requester_id deyin ve biletin konusu olan hesabı ayrıca customer_id olarak saklayın. Bu ayrım formların ve filtrelerin baştan itibaren doğru olmasını sağlar.

Adım adım: ekranları oluşturmadan önce yeni bir modeli nasıl adlandırırsınız

Ekranların okunaklı kalmasının en kolay yolu, henüz basit dille düşünürken isimlendirmektir, zaten inşa ederken değil.

Her özellik için tekrarlanabilir bir süreç

1. Mini bir sözlükle başlayın (5–10 terim). Teknik olmayan bir meslektaşın bir toplantıda kullanacağı kelimeleri yazın, sonra her kavram için bir tercih kelime seçin (örneğin "customer" vs "client").

2. Beklediğiniz ekranları taslaklayın: liste, detay, oluştur, düzenle. Liste görünümü için hangi 5–8 sütunun anında açık olması gerektiğine karar verin. Bir alan adı başlık olarak tuhaf görünüyorsa, muhtemelen düzeltilmeli.

3. Tabloları ve ilişkileri taslaklayın, sonra alanları sonek kurallarına göre adlandırın (*_id, *_at, is_*, *_count). Daha sonra yönetici ekranları ürettiğinizde (AppMaster dahil), bu desenler temiz etiketler ve öngörülebilir filtreler üretme eğilimindedir.

Taşınmadan önce stilleri karıştırmadığınızdan emin olun (customer_id bir tabloda, clientId diğerinde). Tutarlılık zekâdan daha önemlidir.

4. Enum'ları erken tanımlayın, ilk UI oluşmadan önce. Her değer için bir cümlelik anlam yazın, sanki destek personeline açıklıyormuşsunuz gibi. Değişime dayanabilecek değerleri tercih edin: pending, active, archived gibi.

5. Bir "sütun başlığı okuma" testi yapın. Kendinizi yönetici kullanıcıymış gibi düşünün ve tabloyu tarayın.

• "Created At", "Updated At", "Status", "Assigned To", "Total Amount" eğitimsiz olarak anlamlı mı olurdu?
• Herhangi bir alan iç kod gibi mi geliyor (tmp_flag, x_type, data1)?
• Birimler açık mı? (amount_cents vs amount, duration_seconds vs duration)?

Eğer bir şey yüksek sesle okununca belirsiz geliyorsa, şimdi yeniden adlandırın. Sonradan yeniden adlandırmak mümkün olsa da genelde raporlar, filtreler ve alışkanlıklara sızar.

Yönetici panellerini kullanışsız yapan yaygın adlandırma hataları

Şema karışıksa, ekranlar da dağınık görünür; en güzel UI bile bunu düzeltemez. Adlandırma kuralları daha çok "stil" değil, günlük kullanılabilirlikle ilgilidir.

İlk tuzak karışık kelime hazinesidir. Bir tabloda client, diğerinde customer yazıyorsa menüler, filtreler ve arama sonuçları farklı şeyler anlatıyor gibi hissedilir. Her temel kavram için tek bir kelime seçin ve tüm yerlerde kullanın.

Başka bir sorun aşırı kısaltmadır. addr, misc veya info gibi kısaltmalar birkaç karakter kazandırır ama tablolar ve ihracatlar için çok açıklığı kaybettirir.

Üçüncü hata UI akışını veritabanına gömmektir. new_customer_wizard_step gibi bir alan lansman sırasında mantıklı olabilir, sonra akış değiştiğinde kafa karıştırıcı olur. İş gerçeğini saklayın (onboarding_status) ve UI’nın insanları nasıl yönlendireceğine izin verin.

Ayrıca boolean aşırı yüklemesine dikkat edin. is_new, is_open, is_closed eklerseniz sonunda çakışmalar ve belirsiz filtreler olur. Ana durum için küçük, iyi adlandırılmış bir set içeren tek bir durum alanı tercih edin.

Çirkin yönetici ekranlarına yol açan kırmızı bayraklar:

• Aynı şey için iki farklı ad (client_id bir yerde, customer_id diğer yerde)
• Karışık veriler tutan catch-all sütunlar (notes, misc, extra)
• Kampanya ömrünü geçen zaman bağımlı isimler (summer_campaign_*)
• Tek bir durumu betimlemeye çalışan birden fazla boolean
• Düzgün göç planı olmadan yapılan yeniden adlandırmalar

Yeniden adlandırma sadece bul-ve-değiştir değildir. customer_phoneu phone_numbera değiştiriyorsanız göç planlayın, oluşturulan ekranları güncelleyin ve diğer sistemler API’yı okuyorsa geriye dönük uyumluluğu koruyun. AppMaster’da temiz isimler hemen karşılık bulur çünkü listeler, formlar ve filtreler modelinizden etiketleri miras alır.

Yönetici panelini yayımlamadan önce hızlı kontrol listesi

Şemayı "tamam" ilan etmeden önce, yönetici panelinde her gün yaşayacak birinin bakış açısından bir tur yapın.

• Tablolar gerçek şeyler gibi mi sesleniyor? Bir meslektaş tablonun neyi temsil ettiğini (ticket, customer, invoice) tahmin etmeden söyleyebilmeli.
• Ana alanlar öngörülebilir sonekleri takip ediyor mu? İnsanların bir bakışta tanıyacağı desenleri kullanın: *_id referanslar için, *_at zaman damgaları için, *_amount (veya *_amount_cents) para için ve is_* doğru/yanlış için.
• Enum'lar sabit ve sade mi? pending, paid, failed gibi saklanmış değerler UI metinleri değişse bile sağlam kalır.
• Yeni bir ekip üyesi anlam çıkarabilir mi? Alanlar oluşturulan liste görünümünde yardım metni olmadan görünse, niyet açık mı olur?
• Belirsiz kelimeler kaldırıldı mı veya özelleştirildi mi? data, value, type, info gibi çöp çekmecesi isimleri status, source, category, notes veya external_reference gibi somut olanlarla değiştirin.

AppMaster’ın Data Designer ile şema tabanlı yönetici görünümleri oluşturuyorsanız, bu kontrol listesi pratiktir: temiz isimler temiz sütunlar ve filtreler getirir; kullanıcılar sisteme başladığında etiketleri yamalamaya daha az zaman harcarsınız.

Sonraki adımlar: adlandırmayı alışkanlık haline getirin ve ekranları tutarlı tutun

İyi adlandırma tek seferlik temizlik değildir. Şemanız büyüdükçe yönetici UI’nızın okunaklı kalmasını sağlayan küçük bir rutindir.

Var olan bir modülle başlayın ve kuralları sadece bir sonraki yeni tabloya uygulayın. Bu korkutucu bir yeniden yazmadan kaçınır ve gerçek bir yerde pratik yapmanızı sağlar. Bir sonraki özelliğiniz sipariş sistemine "returns" ekliyorsa, tabloyu, yabancı anahtarları ve durumları baştan kurallara göre adlandırın ve aynı yaklaşımı sonraki özelliğe tekrar kullanın.

Şema çalışması yaptığınız yerde bir sayfalık adlandırma rehberi tutun. Kısa olsun: tabloları, birincil anahtarları, yabancı anahtarları, zaman damgalarını ve durum enum'larını nasıl adlandırdığınız. Amaç hızlı kararlar, uzun tartışmalar değil.

AppMaster ile geliştiriyorsanız, bu desenleri Data Designer içinde ayarlamak işe yarar. Tablo veya alan adlarını değiştirdiğinizde uygulamayı yeniden üretin ki ekranlar, API ve mantık uyumlu kalsın, sürüklenip ayrılaşmasın.

Yayın öncesi hafif bir inceleme adımı genelde yeterlidir:

• Tablo ve alan adları menü öğeleri, sütun başlıkları ve filtreler olarak iyi okunuyor mu?
• Durumlar ve enum'lar ekstra açıklama olmadan açık mı?
• İlişkiler ve yabancı anahtarlar kendini açıklıyor mu (gizemli kısaltmalar yok mu)?
• Benzer modeller tutarlı şekilde adlandırılmış mı (aynı kelimeler, aynı sıra)?

Zamanla gerçek kazanç tutarlılıktır. Her yeni model aynı kuralları izlediğinde, yönetici panelleriniz üretilmiş olsalar bile tasarlanmış gibi görünür; çünkü etiketler ve listeler tutarlı bir ürün dili gibi okunur.