Buton Hiyerarşisi: Tasarım Sistemleri Ne Öneriyor?

Bir sayfada üç tane primary buton yan yana duruyorsa, kullanıcıya üç ayrı "asıl işlem" sunuyorsun demektir. Kullanıcı hangisine basacağını düşünmek zorunda kalır, çünkü arayüz ona bir sonraki adımı söylemiyor.

Buton hiyerarşisi tam olarak bunu çözer: butonları görsel ağırlıklarına göre sıralayıp kullanıcıya hangi işlemin asıl, hangisinin yan işlem olduğunu gösterir. Bu yazıda Apple, Google, IBM, GitHub, Microsoft, Adobe, Atlassian, Shopify ve GOV.UK'nin tasarım sistemlerinin bu konuda ne önerdiğini bir araya getirdim. Amaç tek bir "doğru" sistem seçmek değil; kaynakların nerede birleştiğini, nerede ayrıldığını görüp ana fikri yakalamak.

Ağırlık Seviyeleri

Her sistem seviyelere farklı isim veriyor, ama hepsi aynı fikri anlatıyor: bir butonun ne kadar dikkat çektiği, işlemin ne kadar önemli olduğunu söyler.

default
secondary
outline
ghost
link
destructive

shadcn/ui'daki buton varyantları: ilk beşi en çok dikkat çekenden en aza, destructive ise silme gibi geri alınamayan işlemler için.

Sistem	Güçlüden zayıfa
Google · Material 3¹	Filled, tonal, elevated, outlined, text
IBM · Carbon²	Primary, secondary, tertiary, ghost
Atlassian³	Primary, default, subtle
Shopify · Polaris⁴	Primary, secondary, tertiary
GitHub · Primer⁵	Primary, secondary (en sık kullanılan)
Apple HIG⁶	Prominent stil ve primary rolü, diğerleri normal

Ağırlık renk, dolgu ve kenarlıkla kurulur. Dolgulu bir buton en çok dikkati çeker, yalnızca kenarlığı olan buton daha az, sadece metinden oluşan buton en az. Apple burada önemli bir ayrıntı ekliyor: tercih edilen seçeneği boyutla değil, stille ayır. Aynı gruptaki butonlar aynı boyutta olmalı; farkı stil göstermeli.⁶

Bir de çoğu kişinin gözden kaçırdığı şey var: Primer'a göre butonların çoğu secondary olmalı.⁵ Primary bir istisnadır, varsayılan değil.

Kaynakların Birleştiği Kural: Tek Primary

Hemen her kaynak aynı şeyi söylüyor: bir alanda tek bir asıl işlem olur. Farklı olan, "alan"ın ne kadar büyük olduğu.

Sistem	Kural
IBM · Carbon²	Ekranda tek primary; uygulama başlığı, modal ve yan panel bu sayıya girmez
GitHub · Primer⁵	Mümkünse sayfada tek primary
Atlassian³	Her alanda tek primary
Microsoft · Fluent 2⁷	Her düzende tek primary
GOV.UK⁸	Sayfanın ana çağrısı için tek buton
Shopify · Polaris⁴	Primary az kullanılır
Apple HIG⁶	Bir görünümde en fazla bir iki öne çıkan buton
Adobe · Spectrum⁹	Bir görünümde en fazla 3 accent buton

Apple ve Spectrum'un daha esnek olması kuralı bozmuyor; ikisi de sınırı hiyerarşiyi korumak için koyuyor. Apple gerekçeyi açıkça söylüyor: öne çıkan buton sayısı arttıkça kullanıcı seçim yapmak için daha çok düşünür.⁶

Fluent burada akılda kalacak bir şey söylüyor: ikiden fazla buton eşit önemdeyse, hiçbirini primary yapma; hepsini nötr bırak.⁷ Primary, "bu daha önemli" demenin yoludur. Daha önemli bir işlem yoksa, primary de olmaz.

GOV.UK ise sorunun kökünü gösteriyor: bir sayfada çok fazla çağrı varsa, çözüm daha fazla buton stili değil; sayfayı sadeleştirmek ya da bölmek.⁸

Secondary Neyin Yeridir?

Secondary'yi "ikinci önemli buton" diye düşünmek yaygın, ama Carbon daha net bir tanım veriyor: secondary, primary'nin karşıtı olan işlemdir. İptal, Geri, Vazgeç. Bu yüzden Carbon'a göre secondary tek başına kullanılmaz ve olumlu bir işlem için kullanılmaz.² Atlassian da İptal gibi yan işlemler için primary'nin yanına sade (subtle) bir buton öneriyor.³

Önemsiz ama bağımsız işlemler, örneğin bir sayfa başlığındaki "Dışa aktar", daha zayıf seviyelere gider: Carbon'da tertiary ya da ghost,² Material'de text butonu.¹

Kaynakların Ayrıldığı Yer: Sıra

Asıl tartışma primary butonun nerede durduğu. Aşağıda aynı iki işlemi, her sistemin kendi kuralıyla, bir sayfada ve bir dialog'da görebilirsin. Bir sistemin bir bağlam için kural koymadığı yerde demo bunu söylüyor; boşlukları tahminle doldurmadım.

Sayfada

Bu sistem bu bağlam için bir sıra tanımlamıyor.

—

Dialog'da

İptalKaydet

Primary, diğer butonun sağında

Uyarılarda en olası seçilecek buton sonda, İptal başta durur. İptal hiçbir zaman varsayılan buton yapılmaz.

Kaynak: Apple HIG

Görüldüğü gibi dialog'larda çoğunluk primary'yi sağa koyuyor: Apple,¹⁰ Material,¹¹ Carbon,² Primer,¹² Atlassian¹³ ve Spectrum.¹⁴ Windows ise tersini yapıyor; Tamam, İptal'in solunda.¹⁵ Sayfa içinde ise Carbon, Fluent, GOV.UK ve Spectrum primary'yi sola, içeriğin hizasına koyuyor.

Bu ayrılığın arkasında iki farklı mantık var:

Okuma sırası: Sola hizalı bir formda göz soldan başlar, bu yüzden asıl işlem ilk sırada durur. Spectrum bunu açıkça kural yapıyor: sıra metin hizasını izler; sola hizalı düzende en önemli buton solda, sağa ya da ortaya hizalıda en sağda.¹⁴
Akışın sonu: Dialog ve sihirbazlarda kullanıcı "ileri" gider, ileri de sağdadır. Bu yüzden onaylayan buton sona konur.

NN/g bu tartışmaya iyi bir nokta koyuyor: Tamam ile İptal'in sırası, kullanılabilirliği nadiren etkileyen küçük bir ayrıntı. Masaüstünde platformun kuralına uy, web'de kullanıcılarının en çok kullandığı platformunkine. Asıl hata, aynı ürünün farklı ekranlarında farklı sıra kullanmak.¹⁵

Yıkıcı İşlemler

Silme gibi geri alınamayan işlemler ayrı bir dikkat istiyor ve kaynaklar burada birbirini tamamlıyor:

Apple: Yıkıcı bir işleme, en olası seçim olsa bile primary rolü verme. İnsanlar öne çıkan butona bazen okumadan basar.⁶
GOV.UK: Uyarı butonunu yalnızca ciddi ve kolayca geri alınamayan işlemler için kullan. İlk adımda normal bir buton, son onayda uyarı butonu olsun. Tehlikeyi yalnızca kırmızıyla anlatma; butonun metni sonucu açıkça söylesin.⁸
Carbon: Akışın zorunlu ya da ana adımı olan yıkıcı işlem primary danger stilini alır; birkaç seçenekten biri olan ise tertiary ya da ghost danger stilini.²
Shopify · Polaris: Kritik tonu yalnızca geri alınması zor ya da imkânsız yıkıcı işlemler için kullan.⁴

Adam Silver da sık yapılan bir hatayı düzeltiyor: onay adımına götüren bir "Kaldır" linkinin bulunması zor olmamalı; asıl işlemin yanlışlıkla tetiklenmesi zor olmalı. Linki sayfanın dibine saklamak kullanıcıyı korumaz, sadece işini zorlaştırır. Koruma onay adımından gelir.¹⁶

Etiketler

Kaynakların hepsi butonun ne yaptığını söyleyen bir etiket istiyor. "Tamam" yerine işlemin kendisi:

Apple: Bir fiille başla, örneğin "Sepete Ekle".⁶
GOV.UK: "Kaydet ve devam et", "Taslak olarak kaydet" gibi işlemi anlatan fiiller.⁸
Carbon: Fiil ve isim; İptal ya da Sil gibi yaygın işlemler tek kelime kalabilir.²
Fluent: Dialog butonları başlıkla eşleşsin: "Bu dosya silinsin mi?" başlığının butonu "Sil" olur.⁷

Pasif Butonlar

GOV.UK disabled butonları kullanmamayı öneriyor: kontrastları düşük ve kullanıcıyı şaşırtıyorlar.⁸ Primer ise ara bir yol sunuyor: soluk görünen ama tıklanınca neden çalışmadığını anlatan "inactive" bir buton.⁵ İkisinin ortak noktası, kullanıcıyı açıklamasız bir duvarla bırakmamak.

Ana Fikir

Bütün bu kuralları tek bir soruya indirebiliriz: bu ekranda kullanıcının yapmasını en çok istediğim şey ne?

Cevap tek bir işlemse, o primary olur.
Diğer işlemler onun karşıtıysa (İptal, Geri) secondary olur.
Bağımsız ve önemsizse tertiary, ghost ya da metin butonu olur.
Cevap "ikisi de eşit"se, ikisi de nötr kalır.
İşlem yıkıcıysa primary olmaz, onay adımıyla korunur.
Sıra için platformun ve ürünün kendi kuralı seçilir, sonra her yerde aynı tutulur.

Hiyerarşi bir stil kararı değil, bir öncelik kararı. Butonun rengi bu kararın sonucu.

Özet

Buton hiyerarşisi, kullanıcıya bir sonraki adımı söyler.
Neredeyse bütün sistemler bir alanda tek primary öneriyor; Apple bir iki, Spectrum üç accent butona izin veriyor.
Secondary, primary'nin karşıtı olan işlemdir; tek başına kullanılmaz.
Eşit önemdeki işlemler nötr kalır.
Primary'nin solda mı sağda mı durduğu sistemden sisteme değişir; önemli olan tutarlılık.
Yıkıcı işlemler primary olmaz ve bir onay adımıyla korunur.
Etiket, butonun ne yaptığını söyleyen bir fiildir.