İsimlendirme Nasıl Yapılır? Kod, Tasarım ve Ürün İçin Pratik Kurallar

İyi bir isim, ekibin de kullanıcının da aynı şekilde anladığı ve kullandığı isimdir. Temel isimlendirme kuralları üçe iner: her isim aynı mantıkla kurulur, görünüşe değil işleve dayanır ve kısa ama anlamlı kalır.

Smashing Magazine’den Vitaly Friedman, 6 Ekim 2026’da yayımlanan “A Practical Guide To Naming Things” yazısında isimlendirme için başvurulacak araçları ve rehberleri derledi. Bu yazı o derlemeyi Türkçe çalışan ekipler için düzenliyor. Kod, tasarım dosyası, token ve yeni özellik isimlerini ayrı ayrı ele alıyoruz.

İsimlendirme neden bu kadar önemli?

Friedman’ın tespiti basit: tasarımcı, geliştirici, ürün yöneticisi ve kullanıcı aynı şeye farklı kelimelerle seslenir. Her grup kendi “diyalektini” konuşunca ekip zaman kaybeder. Friedman bir adım daha ileri gidiyor: Bir özelliğin az kullanılması, özelliğin değil isminin sorunu olabilir (Smashing Magazine).

Erin Gannon da Google’daki çalışmalarına dayanarak ismin kullanıcının bir özellikle ilk karşılaşması olduğunu hatırlatıyor. Ona göre öğrenilmiş bir ismi sonradan değiştirmek kullanım ve memnuniyet metriklerini etkileyebilir. Gannon, Google Cloud’da bir bileşeni adlandırırken aynı kelimenin (“service”) birden fazla anlama gelmesinin kullanıcıyı hataya sürükleyebildiğini araştırmada gördüklerini anlatıyor (UX Collective). Bilgi mimarisinde etiketlerin neden bu kadar belirleyici olduğunu bilgi mimarisi yazımızda da tartışmıştık.

İYİ İSİM

Ayırt edici

Benzer adlı başka bir kavramla karışmaz.

İYİ İSİM

Açıklayıcı

Ne işe yaradığını ya da ne yaptığını ele verir.

İYİ İSİM

Uyumlu

Sektör terimleriyle ve ürünün geri kalanıyla aynı dili konuşur.

İYİ İSİM

Kalıcı

Ürün büyüdüğünde de doğru kalır; sonradan değiştirmek gerekmez.

KAÇIN

Belirsiz

Yeterince açıklayıcı değil, birden çok şey anlamına gelebilir.

KAÇIN

Çelişkili

Kelimenin günlük ya da yerleşik anlamıyla çatışır.

KAÇIN

Uzun

2–3 kelimeyi aşan isimler söylemesi ve yazması zor.

KAÇIN

Kısaltılmış

Tanımlanmamış kısaltmalar yanlış anlaşılmaya açık.

Koddaki isimler: değişken, fonksiyon ve CSS sınıfı

Kodda isimlendirmenin en yaygın başvuru kaynaklarından biri GitHub’daki naming-cheatsheet. Temel ilkesi S-I-D: isimler kısa (Short), sezgisel (Intuitive) ve açıklayıcı (Descriptive) olmalı. Yani a yerine postCount.

• Tek bir yazım biçimi seçin: pageCount ya da page_count; ikisi birden değil.
• Kısaltmayın: onItmClk değil, onItemClick.
• Bağlamı tekrarlamayın: MenuItem içinde handleMenuItemClick değil, handleClick.
• Beklenen sonucu yansıtın: Ters mantık kuran isEnabled yerine isDisabled = itemCount <= 3.
• Tekil ve çoğulu ayırın: Tek değer için friend, liste için friends.

Fonksiyon isimleri için A/HC/LC kalıbı

Aynı kaynak fonksiyon isimleri için şu kalıbı öneriyor: önek? + eylem (A) + yüksek bağlam (HC) + düşük bağlam?. Kelime sırası anlamı değiştirir. shouldUpdateComponent “bileşeni güncelleyeceksin” demektir. shouldComponentUpdate ise “bileşen kendini güncelleyecek” anlamına gelir.

getUserMessages      // get + User + Messages
handleClickOutside   // handle + Click + Outside
isDisabled           // is: durum (boolean)
hasProducts          // has: bir değere sahip olma
shouldUpdateUrl      // should: koşul + eylem
minPosts, maxPosts   // sınırlar
prevPosts, nextPosts // önceki / sonraki durum

get

Veriye eriş

getFruitCount — değeri hemen döndürür.

set

Değer ata

setFruits(5) — yeni değeri bildirir.

reset

Başa döndür

resetFruits — ilk değere geri alır.

add / remove

Koleksiyona ekle, çıkar

removeFilter — öğe listeden çıkar ama yok olmaz.

create / delete

Oluştur, tamamen sil

deletePost — kayıt tamamen silinir.

compose

Var olandan üret

composePageUrl — mevcut veriden yenisini kurar.

handle

Olaya yanıt ver

handleLinkClick — genellikle bir callback.

CSS sınıfı ya da değişken için kelime bulamıyorsanız Paul Robert Lloyd’un Classnames sitesi işe yarar. Eylem, benzerlik, sıra, gruplama gibi başlıkların yanında doğa, mimari, müzik, moda ve yayıncılık temalı kelime listeleri sunuyor.

Tasarım dosyasındaki isimler: katman, bileşen, renk ve boyut

Javier Cuello’nun goodpractices.design rehberi tasarım dosyaları için en net kuralları veriyor. Ona göre iyi bir isim mantıklı bir yapıya sahip, kısa ama anlamlı, ekipteki herkesin bildiği ve kabul ettiği bir isimdir. En önemlisi de zamanla değişebilecek görsel özelliklere bağlı değildir.

• Katmanı sonraya bırakmayın: “Copy 23” adında bir grup, adını hemen vermemenin işaretidir.
• İçeriği değil işlevi adlandırın: Bir grubun içindeki katmanların adı, içerik değişse de aynı kalmalı.
• Gerekirse sonek ekleyin: Yan yana duran aynı tür katmanları ayırmak için.

Bileşen isimleri genelden özele dizilir

1 · BİLEŞEN

Button

En genel katman: neyin bileşeni olduğu.

2 · İŞLEV / HİYERARŞİ

Secondary

Arayüzdeki rolü; görünüşü değil.

3 · VARYANT

Compact

Aynı rolün farklı biçimi.

4 · DURUM

Enabled

O anki etkileşim hâli.

Boyut ve renk isimleri

• Boyutta kıyafet ölçeği: xs, sm, md, lg, xl, 2xl. Cuello, büyüdükçe okunabilirliği koruduğu için xxl yerine 2xl‘yi tercih ediyor.
• Hayvan ölçeği yok: Fare, tavşan, köpek, at, fil, balina gibi benzetmelerde sıra belirsiz ve ölçek büyütmek zor.
• Rengi tonuyla adlandırmayın: “Sarı” yerine işlevi: Primary (buton ve link gibi etkileşimli öğeler), Secondary (Primary’ye tamamlayıcı karşıtlık), Highlight (dikkat çekilmesi gereken öğe).
• Paleti konuma göre numaralayın: Ana ton Primary / 00, koyu ve açık adımlar Primary / Dark / 10, Primary / Light / 20 gibi.

Bir rengin “adı” gerçekten gerekiyorsa (örneğin bir marka kılavuzu ya da renk seçici için), David Aerne’nin color-names deposu açık kaynak bir renk adı sözlüğü sunuyor. Friedman 30.355 isimden söz ediyor; deponun README dosyası bugün 31.942 benzersiz isim gösteriyor. Aynı ekipten Color Parrot da verdiğiniz renge bir isim öneriyor. Palet adımlarını numaralarken ton farklarının algıda eşit dağılmasına dikkat edin; OKLCH’de lightness tuzağı yazımız bunu anlatıyor.

Design token ve değişken isimleri

Token isimleri tek bir marka temasının ötesine geçince zorlaşır. Friedman iki örnek öne çıkarıyor. İlki Intuit: Mailchimp, QuickBooks ve TurboTax’ın çatı şirketi, çok farklı ürünlere hizmet edebilecek esnek bir token taksonomisi kurdu. Nate Baldwin’in vaka çalışması eski sistemin sorunlarını, yeni sistemin ölçütlerini ve nasıl kurulduğunu anlatıyor.

İkincisi Vodafone UK. Ekibin Figma Community’de paylaştığı Variables Taxonomy Map, çok markalı ve çok temalı bir sistemi dört koleksiyona ayırıyor. Bu koleksiyonlar marka ve temel değerlerden (primitive) başlayıp anlamsal katmandan geçerek sayfalara kadar iniyor. Hedef, bir token’ın nerede kullanıldığını ve neyi temsil ettiğini yalnızca adından anlamak.

Kendi yapınızı kurmak için Romina Kavčič’in ücretsiz Design Token Naming Guide + Builder aracı bileşen, kategori, durum ve rol adımlarıyla bir isim şeması oluşturmanıza yardım ediyor. Tasarım sistemlerinin yapay zeka araçlarıyla nasıl konuştuğunu merak ediyorsanız 20 tasarım sistemini karşılaştırdığımız yazıya bakabilirsiniz. Orada da tutarlı isimlendirme önemli bir ölçüt.

Bileşen isimleri: aynı şeye kaç farklı ad veriliyor?

Iain Bean’in The Component Gallery sitesi, gerçek tasarım sistemlerinden toplanan örneklerle 60 bileşeni listeliyor ve her birinin alternatif adlarını gösteriyor. Akordeon bunun en çarpıcı örneği. Sitede “Also known as” satırında Arrow toggle, Collapse, Collapsible, Details, Disclosure, Expandable, Expander ve hatta “ShowyHideyThing” yazıyor.

Accordion51 kayıt

Details9

Disclosure7

Collapse5

Collapsible4

Expander3

Diğer 24 farklı ad25 (her biri 1–2 kez)

Bu dağılımdan çıkan ders şu: Yeni bir bileşene ad verirken önce yerleşik adın ne olduğuna bakın. Yerleşik ad hem geliştiricinin aradığında bulacağı kelimedir hem de HTML’deki karşılığına (<details>) ya da erişilebilirlik kalıbına (“disclosure”) bağlanır. Görsel bir sözlük isteyenler için Name That UI da yaygın arayüz bileşenlerini resimleriyle eşleştiriyor.

Yeni bir özellik nasıl adlandırılır?

Friedman özellik isimleri için üç ilke koyuyor: ismi kullanıcının ihtiyacına ve sorununa dayandırın, özelliğin sağladığı sonucu sezdirin ve kullanıcının kendi dilini kullanın. Bunun için kullanıcılardan özelliği kendi sözleriyle anlatmalarını isteyip o kelimeleri benimseyin (Smashing Magazine). Erin Gannon’ın rehberi ise bunu adım adım bir sürece çeviriyor (UX Collective):

1. Riski ölçün: İki soru sorun. Kötü bir isimle kullanıcının hata yapma olasılığı ne? Hata yaparsa sonucu ne kadar ağır? Yanlış sayfaya gitmek düşük risktir, iş açısından kritik bir veritabanını silmek yüksek risk. Önce yüksek riskli isimlerle uğraşın.
2. Yeni bir isim gerçekten gerekli mi, sorun: Ad vermek bir kavramı olduğundan karmaşık gösterebilir. Gannon önce düz dil ya da sektör standardı bir terim denemeyi, adlandırmayı son çare saymayı öneriyor.
3. Ekibi kurun: PM, mühendislik, tasarım, araştırma, yazı ve pazarlamadan temsilciler. Gannon’a göre atölyeyi yaklaşık 10 kişiyle sınırlamak tartışmayı odakta tutuyor.
4. Ölçütleri baştan belirleyin: Mevcut ürünlerle ve sektör diliyle çakışmıyor mu? İşlevi anlatıyor mu? Ürün değiştikçe ölçekleniyor mu? Okuması ve söylemesi kolay mı? İsmin görüneceği tüm arayüzlerde çalışıyor mu?
5. Beyin fırtınası yapın: Bu aşamada nicelik nitelikten önemli. Sektör terimleri, ürünün farkları ve metaforlar için ayrı ayrı birkaç dakika ayırın. Sonra listeyi tartışarak ya da oylayarak 10 veya daha az isme indirin.
6. Adayları matriste puanlayın: Her ismi ölçütlere göre 10 üzerinden ya da evet/hayır/belki ile değerlendirin.
7. Tek isimle değil 2–3 adayla çıkın: Yerelleştirme ya da marka tescili engel çıkarabilir. Sevdiğiniz isim başka bir dilde çevrilemeyebilir veya istenmeyen bir anlam taşıyabilir.

Ürün ya da marka ismi arıyorsanız açık kaynak Onym rehberi beyin fırtınası yöntemlerinden isim doğrulamaya, etimolojiden ibret verici örneklere kadar kaynakları bir araya getiriyor. Arayüzdeki komut ve buton isimleri için NN/g’nin UI copy yönergeleri de tamamlayıcı: 2–4 kelimelik kısa etiketler, genel “İleri” yerine mümkünse belirli bir fiil ve onay pencerelerinde “Tamam” yerine eylemin adı (örneğin “Discard”).

Kullanıcının bir özelliği neden görmezden geldiğine farklı bir açıdan bakan kusursuz çalışan bir özellik neden saklanıyor yazımız da bu bölümle birlikte okunabilir.

Türkçe projelerde iki dil kuralı

Türkçe çalışan bir ekipte isimlendirme iki ayrı dille yapılır ve kaynaklar bu ikisini net biçimde ayırıyor:

• Kod ve tasarım dosyası İngilizce: Hem naming-cheatsheet (primerNombre değil firstName) hem goodpractices.design, özellikle dağıtık ya da uluslararası ekiplerde isimlerin İngilizce olmasını öneriyor (naming-cheatsheet, goodpractices.design).
• Arayüz ve özellik isimleri kullanıcının Türkçesiyle: Friedman’ın “kullanıcının kendi dili” ilkesi burada devreye giriyor. Kodda Disclosure diyen bir bileşen, arayüzde kullanıcının söylediği kelimeyle görünmeli.
• Çeviriyi isim seçiminin sonuna bırakmayın: Gannon’ın uyarısı tersinden de geçerli. İngilizce düşünülmüş bir özellik adı Türkçeye iyi çevrilmeyebilir. Bu yüzden “çevrilebilir mi” sorusunu ölçüt listesine baştan koyun.

Terimlerin bölünmesi yalnızca ürün içinde olmuyor; meslek adlarında bile aynı şey yaşanıyor. NN/g anketindeki “UX mi, product mı” terim kırılımı bunun iyi bir örneği.

Hangi iş için hangi kaynak?

İsimlendirdiğiniz şey	Başvuru kaynağı	Ne sunuyor
Değişken ve fonksiyon	naming-cheatsheet	S-I-D ilkesi, A/HC/LC kalıbı, fiil ve önek listesi
CSS sınıfı	Classnames	Temalara ayrılmış kelime listeleri
Renk	color-names, Color Parrot	Açık kaynak renk adı sözlüğü, renkten isim önerisi
Katman ve bileşen	goodpractices.design	Boyut, renk, katman ve bileşen için yap / yapma örnekleri
Design token	Name Design Tokens, Intuit vaka çalışması	İsim şeması oluşturucu, çok ürünlü taksonomi örneği
Değişken koleksiyonu	Vodafone UK Variables Taxonomy Map	Çok markalı sistemde dört koleksiyonlu yapı
Arayüz bileşeni	The Component Gallery, Name That UI	Gerçek sistemlerden bileşen adları ve alternatifleri
Yeni özellik	Erin Gannon, UX Collective	Risk matrisi, ölçüt listesi, atölye akışı
Ürün ve marka	Onym	Beyin fırtınası, doğrulama ve etimoloji kaynakları

Friedman’ın son önerisi pratik: İsim tartışmaları bir anda çözülmüyorsa çakışmaları bir backlog’a yazın ve sonra çözün. Doğru isim, ekibin ve kullanıcının gerçekten anlayıp kullandığı isimdir (Smashing Magazine).

Sık sorulan sorular

Değişken isimleri Türkçe mi İngilizce mi olmalı?

Yaygın kabul gören rehberler İngilizceyi öneriyor. naming-cheatsheet firstName örneğini veriyor; goodpractices.design de dağıtık ve uluslararası ekiplerde İngilizce isim kullanmayı tavsiye ediyor. Kullanıcıya görünen metinler ise kullanıcının Türkçesiyle yazılmalı.

Figma’da bileşen nasıl isimlendirilir?

Genelden özele dizilen bir kalıp kullanın: Bileşen / İşlev veya hiyerarşi / Varyant / Durum, örneğin Button / Secondary / Compact / Enabled. İsmi görsel özelliğe değil işleve bağlayın ve ekipteki herkesin bildiği tek bir kuralı izleyin.

Renkler neden “mavi” ya da “sarı” diye adlandırılmamalı?

Çünkü renk değiştiğinde isim anlamsızlaşır. goodpractices.design rengi Primary, Secondary, Highlight gibi işleviyle adlandırmayı öneriyor. Ton adları ancak işlev yetmediğinde ve “light/dark” gibi genel özelliklerden sonra kullanılmalı.

Design token isimlendirme kuralları nelerdir?

Token adı genelden özele okunmalı ve nerede kullanıldığını kendisi anlatmalı. Intuit örneğindeki color.input.background.error buna uyuyor. Vodafone UK ise sistemini dört koleksiyona ayırarak markadan sayfaya uzanan bir yapı kuruyor.

Yeni bir özelliğe isim verirken nelere dikkat edilmeli?

İsim kullanıcının sorununa dayanmalı, sağladığı sonucu sezdirmeli ve kullanıcının kendi kelimelerini kullanmalı. Erin Gannon iyi bir ismin ayırt edici, açıklayıcı, uyumlu ve kalıcı olmasını; 2–3 kelimeyi aşmamasını ve tanımlanmamış kısaltma içermemesini öneriyor.