Web Uygulamalarında UI/UX Mühendisliği: Kullanılabilirlik, Duyarlı Tasarım ve Güvenilir İstemci Davranışı

Yaklaşım: Bu metinde Zen, tarihsel veya dinî bir öğretinin tasarım kuralına indirgenmiş karşılığı değildir. Kavram; gereksiz kararları azaltmak, dikkati asıl görevde tutmak, biçimi işlevin önüne geçirmemek, geri bildirimi sessiz ama görünür vermek ve yalnız daha yeni göründüğü için çalışan davranışı bozmamak için kullanılan bir tasarım çerçevesidir. Değeri estetik slogandan değil; standart, ölçüm, hata maliyeti ve gerçek görev bağlamıyla sınanabilmesinden gelir.

Bir web arayüzü üzerinde çalışırken renk, boşluk ve ikonlar en görünür katmandır; fakat üretimde sorun çıkaran noktalar çoğu zaman bu katmanda değildir. Bilgi mimarisi, kullanıcının zihinsel modeli, erişilebilirlik, ağ gecikmesi, veri bütünlüğü, giriş aygıtları, yetki sınırları ve yıllar içinde oluşan kullanım alışkanlıkları aynı etkileşimin parçalarıdır. Arayüz bunlardan birini görmezden geldiğinde görsel olarak temiz, operasyonel olarak kırılgan bir sonuç ortaya çıkabilir.

UI ve UX yalnız görsel tasarım değil, insan-bilgisayar etkileşimi ile yazılım mühendisliğinin kesişimindeki bir mühendislik alanıdır. Bir ekranın iyi olması, güzel görünmesinden önce kullanıcının işini doğru, öngörülebilir, erişilebilir ve güvenli biçimde tamamlatmasıyla ilgilidir. Hız ve öğrenilebilirlik de bu bütünün parçasıdır; fakat doğruluk veya veri güvenliği pahasına elde edilen hız gerçek bir kazanım değildir.

Dört kanıt türü birbirinden ayrılır:

• Normatif gereksinim: W3C WCAG/WAI-ARIA ve HTTP gibi standartlar.
• Araştırma temelli bulgu: kullanılabilirlik araştırmaları ve hakemli çalışmalar.
• Tasarım sistemi/kalıp: GOV.UK, IBM Carbon, Apple HIG, Material gibi geniş kullanım alanına sahip sistemlerin önerileri.
• Endüstri örneği: Facebook, X, Amazon, Hepsiburada, Trendyol, Canvas, Moodle ve üniversite otomasyonlarında görülen uygulama kalıpları.

Bir şirketin veya popüler ürünün belirli bir arayüzü kullanması, o kararın her ürün için doğru olduğunu kanıtlamaz. Büyük ürünler kendi kullanıcı kitlesi, ticari modeli, deneyleri, teknik borcu ve geriye uyumluluk zorunlulukları içinde tasarlanır. Örnekler kopyalanacak şablonlar değil, incelenecek kararlar olarak görülmelidir.

Ünite 1: Temeller, Kullanılabilirlik ve Bilgi Mimarisi

UI, UX ve Kullanılabilirlik

UI ile UX aynı kavram değildir

Kullanıcı Arayüzü (User Interface, UI) kullanıcının sistemle doğrudan etkileşim kurduğu görsel ve etkileşimsel yüzeydir: düğmeler, menüler, tablolar, formlar, arama alanları, sekmeler, diyaloglar, renkler, tipografi, boşluklar, ikonlar ve durum göstergeleri.

Kullanıcı Deneyimi (User Experience, UX) bundan daha geniştir. Kullanıcının bir hedefe ulaşırken yaşadığı bütün deneyimi kapsar: aradığı işlevi bulabilmesi, ne yapacağını anlayabilmesi, işlemi ne kadar sürede tamamladığı, hata yapma olasılığı, hatadan kurtulabilmesi, sistemin verdiği geri bildirimi anlayabilmesi, bekleme süresi, güven ve kontrol hissi, erişilebilirlik ve cihazlar arasındaki tutarlılık.

Görsel açıdan etkileyici bir ekran kötü UX üretebilir. Tersine sade bir ekran, görev akışı doğruysa yüksek kullanılabilirliğe sahip olabilir.

Kullanılabilirliğin mühendislik karşılığı

Kullanılabilirliği şu eksenlerde düşünmek yararlıdır:

1. Öğrenilebilirlik: Yeni kullanıcı temel görevi ne kadar kolay öğreniyor?
2. Verimlilik: Deneyimli kullanıcı aynı görevi ne kadar az bilişsel ve fiziksel maliyetle tamamlıyor?
3. Hatırlanabilirlik: Kullanıcı bir süre ara verdikten sonra sistemi yeniden öğrenmek zorunda kalıyor mu?
4. Hata oranı ve hata şiddeti: Ne kadar sık hata yapılıyor ve sonuç ne kadar ciddi?
5. Kurtarılabilirlik: Hata geri alınabiliyor veya kolayca düzeltilebiliyor mu?
6. Memnuniyet: Kullanıcı sistemi kontrol altında hissettiği bir araç olarak mı görüyor?
7. Erişilebilirlik: Görsel, işitsel, motor veya bilişsel farklılıklara rağmen görev tamamlanabiliyor mu?

Kullanıcının zihinsel modeli

İyi arayüz, sistemin gerçek teknik mimarisini kullanıcıya öğretmek zorunda bırakmaz. Kullanıcı “hangi mikroservis çağrılıyor”, “hangi tablo güncelleniyor” veya “hangi durum makinesi çalışıyor” diye düşünmemelidir.

Kullanıcı şunu bilmelidir:

• Neredeyim?
• Burada ne yapabilirim?
• Bir sonraki adım nedir?
• Yaptığım işlem gerçekleşti mi?
• Yanlış yaptıysam nasıl geri dönerim?
• Verim kaydedildi mi?
• Sistem şu anda çalışıyor mu, bekliyor mu, hata mı verdi?

Bu soruların cevabı arayüzde görünür değilse bilişsel yük kullanıcıya taşınmış demektir.

Nielsen Kullanılabilirlik Sezgileri ve Modern Web

Nielsen Norman Group'un on kullanılabilirlik sezgisi kesin bir standart değil, çok geniş problem sınıflarında çalışan değerlendirme ilkeleridir.

1. Sistem durumunun görünürlüğü

Kullanıcı yaptığı işlemin sonucunu görebilmelidir.

• Kaydet → “Kaydediliyor…” → “Kaydedildi”.
• Filtre değişti → yükleme durumu görünür.
• Dosya yükleniyor → gerçek ilerleme biliniyorsa yüzde/ilerleme çubuğu.
• Uzun sorgu çalışıyor → arayüz donmuş gibi görünmez.
• Oturum kapanmış → kullanıcı sessizce boşa veri girmeye devam etmez.

Sessizlik, sistem durumunun en kötü geri bildirim biçimlerinden biridir.

2. Sistem ile gerçek dünya arasında uyum

Teknik terimler yalnız kullanıcı kitlesi gerçekten teknikse kullanılmalıdır. Kullanıcının iş alanındaki sözcükler, sunucu tarafı sınıf veya veri tabanı adlarından daha önemlidir.

3. Kullanıcı kontrolü ve özgürlüğü

Özellikle yanlış işlemlerde geri, iptal, geri al, değişiklikleri geri çevir ve varsayılana dön gibi güvenli kaçış yolları bulunmalıdır.

4. Tutarlılık ve standartlar

Aynı ürün içinde aynı kavram aynı adla, aynı ikonla, aynı konum mantığıyla, aynı kısayolla ve aynı durum diliyle sunulmalıdır. Web'de yerleşmiş bir davranışı değiştirmek için açık bir kazanç gerekir.

5. Hata önleme

En iyi hata mesajı, hiç oluşması gerekmeyen hatayı önleyen tasarımdır. Geçersiz tarihlerin seçilememesi, yanlış kombinasyonların engellenmesi, silme kapsamının açık gösterilmesi ve yinelenen gönderimin hem istemci hem sunucu tarafında önlenmesi buna örnektir.

6. Hatırlama yerine tanıma

Kullanıcı bir kodu veya komutu hatırlamak yerine seçenekleri görüp tanıyabilmelidir. Son kullanılanlar, otomatik tamamlama, görünür filtreler, gezinti yolu, açık sekme başlıkları ve kısayol ipuçları bilişsel maliyeti düşürür.

7. Kullanım esnekliği ve verimlilik

Yeni kullanıcı görünür kontrollerden ilerlerken deneyimli kullanıcı klavye kısayolları, toplu işlemler, kayıtlı filtreler ve hızlı arama ile aynı işi daha hızlı yapabilmelidir.

8. Estetik ve minimalist tasarım

Minimalizm “az özellik” değildir; göreve katkısı olmayan gürültünün azaltılmasıdır. Yoğun bir yönetim ekranında 30 sütun gerçekten gerekiyorsa tabloyu 5 sütuna indirmek minimalist tasarım değil, bilgi kaybıdır.

9. Hataları tanıma ve düzeltme

“İşlem başarısız” çoğu zaman yetersizdir. Hata mesajı ne olduğunu, kullanıcı ne yapabileceğini ve verisinin korunup korunmadığını açıklamalıdır.

10. Yardım ve dokümantasyon

İyi ürün mümkün olduğunca kendini açıklamalıdır; ancak karmaşık görevlerde bağlamsal yardım, alan altı açıklamalar, örnek değerler, kısayol listeleri ve süreç yardım sayfaları değerlidir.

Yerleşik Web Konvansiyonları

Konvansiyon neden değerlidir?

Kullanıcı bir web uygulamasına boş bir zihinle gelmez. Önceki ürünlerden şu beklentileri getirir:

• logo ana sayfaya götürür,
• arama büyüteçle ilişkilidir,
• profil/avatar hesap işlemlerine açılır,
• dişli ayarları çağrıştırır,
• çöp kutusu silmeyi ifade eder,
• sol ok geri dönmeyi ifade eder,
• sekmeler aynı bağlamın farklı görünümleridir,
• gezinti yolu konumu gösterir.

Bu bilgi başka ürünlerde öğrenilen davranışın yeni ürüne taşınmasını sağlar.

LTR masaüstü web için güçlü yerleşim kalıbı

┌─────────────────────────────────────────────────────────────────────────┐
│ Logo   Birincil Gezinme            Arama       Yardım  Bildirim  Profil │
└─────────────────────────────────────────────────────────────────────────┘

Buradaki bütün konumlar aynı kanıt düzeyinde değildir.

Logo/ana sayfa sol üst: Nielsen Norman Group araştırmaları ve uzun süreli web konvansiyonu tarafından güçlü biçimde desteklenir. LTR arayüzlerde sol üst yerleşim ana sayfaya dönüş ve marka tanıma açısından avantajlıdır. RTL arayüzlerde mantıksal başlangıç tarafı tersine dönebilir.

Profil/hesap sağ üst: Çok sayıda web uygulamasında yardımcı gezinmenin bitiş tarafında görülür. Bu güçlü bir endüstri konvansiyonudur; ancak logonun sol üstte olması kadar doğrudan deneysel bir zorunluluk sayılmamalıdır.

Arama: Ürünün ana görevi aramaysa görünür ve merkezi olmalıdır. Arama ikincilse üst yardımcı bölgede daha küçük yer alabilir.

İçerik sitesi ile uygulama aynı gezinme düzenini gerektirmez

İçerik ağırlıklı site:

Logo | Ana Sayfa | Makaleler | Kaynaklar | Hakkında | Arama | Profil

Yoğun iş uygulaması:

┌───────────────────────────────────────────────┐
│ Üst bar: başlık / genel arama / yardımcılar  │
├──────────────┬────────────────────────────────┤
│ Sol menü     │ Çalışma alanı                  │
│ Modül A      │ Tablo / form / detay           │
│ Modül B      │                                │
│ Modül C      │                                │
└──────────────┴────────────────────────────────┘

NN/g, masaüstünde geniş veya büyüyen bilgi mimarileri için görünür sol gezinmenin güçlü bir seçenek olduğunu belirtir. Hamburger menüyü masaüstünde varsayılan hâle getirmek keşfedilebilirliği düşürebilir.

Genel, yerel ve yardımcı gezinme

• Genel gezinme: ürünün ana bölümleri.
• Yerel gezinme: aktif bölüm içindeki alt alanlar.
• Yardımcı gezinme: hesap, yardım, bildirim, dil ve çıkış gibi ikincil fakat sık erişilen işlevler.

Bu katmanların görsel olarak aynı ağırlıkta sunulması bilgi mimarisini bulanıklaştırır.

Gezinti yolu ne zaman gerekir?

Gezinti yolu özellikle derin hiyerarşi, çok sayıda kategori veya kullanıcının dış bağlantıdan ara sayfaya gelebilmesi durumunda değerlidir.

Ana Sayfa > Yönetim > Kullanıcılar > Kullanıcı Ayrıntısı

“Üç tıklama kuralı” gerçek bir kural değildir

Bir görevin üç tıklamadan uzun sürmesinin otomatik olarak kötü UX olduğu fikrini destekleyen genel bir ampirik kural yoktur. Önemli olan bilgi kokusunun güçlü olması, kullanıcının nerede olduğunu bilmesi, adımların anlamlı olması ve yanlış yoldan kolayca dönebilmesidir.

Görsel Hiyerarşi, Düzen ve Dikkat

Bir ekran ilk birkaç saniyede şu sırayı anlatabilmelidir:

1. Bu ekran nedir?
2. Ana görev nedir?
3. Ana eylem hangisidir?
4. İkincil bilgiler nelerdir?
5. Riskli/yıkıcı eylemler hangileridir?

Hiyerarşi boyut, ağırlık, kontrast, boşluk, hizalama, renk, gruplama ve konumla kurulur.

Boşluk dekorasyon değil, bilgi mimarisidir

Boşluk ilişkili öğeleri bir araya getirir, farklı grupları ayırır ve görsel öncelik üretir. Her öğenin etrafına eşit boşluk koymak iyi tasarım değildir.

Boşluğun ölçeği ve ilişkisel anlamı

Boşluk yalnız büyük sayfa kenarları değildir. Arayüzde üç düzey birlikte çalışır:

• Makro boşluk: sayfanın veya çalışma alanının ana bölgeleri arasındaki mesafe,
• Mikro boşluk: düğme, etiket, ikon, hücre ve benzeri öğelerin kendi içindeki veya yakın çevresindeki mesafe,
• Metinsel boşluk: başlık, paragraf, satır ve liste öğeleri arasındaki dikey ve yatay ritim.

Bu ayrımın amacı yeni bir tasarım terminolojisi üretmek değil, boşluğun hangi ilişkiyi anlattığını düşünmektir. Bir başlık altındaki paragraf başlığa yakın, yeni bölüm ise önceki bölümden daha uzaksa kullanıcı içerik yapısını okumadan önce görsel olarak sezebilir.

Negatif alanın çok olması tek başına iyi tasarım değildir. Yoğun bir iş uygulamasında gereğinden büyük boşluk tarama mesafesini artırabilir, karşılaştırılması gereken verileri birbirinden koparabilir ve ekran başına düşen yararlı bilgiyi azaltabilir. Buna karşılık yetersiz boşluk da ayrı görevleri tek blok gibi gösterir.

Bu nedenle boşluk için doğru soru:

Ne kadar boşluk güzel görünür?

değil,

Hangi öğeler birlikte, hangileri ayrı algılanmalıdır?

olmalıdır.

Boşluk, renk ve çizgiyle yapılabilecek gruplamanın daha sessiz bir aracıdır. Sınır çizgisi eklemeden önce mesafenin aynı işi yapıp yapamayacağı değerlendirilmelidir.

Tutarlı boşluk ölçeği

Rastgele değerler yerine bir ölçek kullanılabilir:

4, 8, 12, 16, 24, 32, 48

Bu sayılar evrensel yasa değildir. Değerli olan tasarım belirteçleri ile tutarlılık sağlanmasıdır.

Hizalama

Özellikle form etiketleri, tablo sayıları, eylem düğmeleri, kart başlıkları ve ikon-metin çiftleri ortak eksenlerde hizalanmalıdır.

Renk tek başına anlam taşımamalıdır

[!] Hata: Kayıt kaydedilemedi
[✓] Kaydedildi

Renk, ikon ve metin birlikte çalışmalıdır.

İkonlar

İkon yalnız yaygın anlamlarda metinsiz kullanılmalıdır. Arama, kapat, geri ve oynat/duraklat gibi semboller daha güvenlidir; belirsiz işlevlerde ikon + etiket tercih edilmelidir.

Altın Oran — Tasarım İlkesi mi, Tasarım Miti mi?

Altın oran:

φ = (1 + √5) / 2 ≈ 1.618

Yaklaşık dağılım 61.8% / 38.2% olarak düşünülebilir.

Nerede kullanılabilir?

Bir kompozisyon hipotezi olarak öne çıkan bölüm/metin alanı, görsel kırpma, başlık ölçeği, kart oranları veya dekoratif yerleşimde denenebilir.

Nerede kullanılmamalıdır?

Yan menü genişliği, kırılma noktası, tablo kolonları, dokunma hedefi, form sütunları, modal iletişim kutusunun boyutu ve erişilebilir font ölçüsü gibi işlevsel kararlarda tek belirleyici olmamalıdır.

Araştırma ne diyor?

Paul van Schaik ve Jonathan Ling'in 98 katılımcılı web bilgi erişimi deneyinde ekran oranının görev performansı ve öznel sonuçlar üzerinde etkisi görülmüş, ancak Altın Oran kullanılan düzen deneyde en zayıf ekran oranı sonucunu vermiştir.

Tractinsky, David ve Krupnik'in 91 katılımcılı deneyinde altın oran hipotezi mobil cihaz biçimlerinde destek bulurken web sayfası tasarımlarında desteklenmemiştir.

Dolayısıyla:

Altın oran web UX için bilimsel olarak kanıtlanmış evrensel bir optimum değildir.

Altın oran → taslak/estetik hipotez
Kullanıcı görevi + içerik + erişilebilirlik + ölçüm → tasarım kararı

Bilgi Mimarisi ve Gezinme

Menüler kurumun iç organizasyonuna göre değil, kullanıcının hedeflerine göre gruplanmalıdır.

Belirsiz:

İşlemler
Diğer
Hizmetler
Daha Fazla

Daha açıklayıcı:

İzin Başvuruları
Ödeme Geçmişi
Erişim Yetkileri
Dışa Aktarma

Mega menu

Çok geniş içerik sitelerinde çok seviyeli üzerine gelmeyle açılan çok seviyeli zincirler yerine mega menü birden fazla kategori seviyesini aynı anda gösterebilir. Yoğun iş uygulamasında ise sol gezinme + bölüm başlığı + sekmeler çoğu zaman daha kararlıdır.

Sekme neyi temsil eder?

Sekmeler aynı bağlamdaki, birbirine yakın ve birbirini dışlayan görünümleri temsil etmelidir.

Kullanıcı
├─ Profil
├─ Yetkiler
├─ Geçmiş
└─ Oturumlar

Sekme ile “Kaydet”, “Sil” ve “Dışa Aktar” gibi eylemler karıştırılmamalıdır. Apple HIG de sekme çubuğunun eylem değil gezinme için kullanılmasını ayırır.

Fazla sekme

Çok sayıda sekme taşma, yatay kaydırma, adların kesilmesi ve aktif sekmenin görünmemesi problemlerine yol açar. Belli bir noktadan sonra yan menü, açılır seçim veya bölünmüş görünüm daha uygun olabilir.

Arama, Keşif, Filtre ve Sıralama

Olgun arama deneyimi yalnız metin kutusu değildir. Şunları içerebilir:

1. açık arama olanağını görünür kılan işaret,
2. geçmiş aramalar,
3. otomatik tamamlama,
4. yazım düzeltme,
5. eşanlam/ilişkili sorgular,
6. filtre,
7. sıralama,
8. aktif filtre özeti,
9. sonuç sayısı,
10. boş sonuç kurtarma önerileri.

Amazon'ın arama geliştirmelerinde otomatik tamamlama, yazım düzeltme ve ilişkili arama açıkça kullanılır. Hepsiburada'nın resmî 20-F açıklamalarında metin araması yanında kategori, filtre, barkod, görüntü ve konuşmadan metne gibi farklı arama yolları belirtilir.

Arama, kötü bilgi mimarisinin yerine geçmez

Arama özellikle kullanıcının adını bildiği tek bir öğeyi çok büyük bir kümeden bulması gerektiğinde güçlüdür. Buna karşılık kullanıcı hangi seçeneklerin bulunduğunu henüz bilmiyorsa görünür gezinme ve iyi gruplama, doğru arama terimini düşünmekten daha düşük başlangıç maliyeti yaratabilir.

Bu nedenle arama:

• iyi adlandırılmış gezinmenin yerine geçmemeli,
• kötü gruplanmış çok sayıda işlevi gizlemek için kullanılmamalı,
• kullanıcının ürünün neler yapabildiğini keşfetmesini engellememelidir.

Yoğun kurumsal uygulamada arama, bilgi mimarisi kurulduktan sonra hızlandırıcı olabilir. On dokuz anlaşılmaz işlem adını bırakıp yalnız bir arama kutusu eklemek karmaşıklığı çözmez; kullanıcıdan doğru iç terimi bilmesini ister.

Bilinen bir kayıt, kişi, belge veya komut çok geniş bir kümeden seçilecekse arama doğal çözümdür. Görevin ne olduğu henüz bilinmiyorsa önce anlaşılır seçeneklerin görünmesi çoğu zaman daha uygundur.

Yazdıkça arama

Her tuşta sunucu tarafı çağırmak yerine:

girdi
  ↓
bekletme (debounce)
  ↓
önceki isteği iptal et
  ↓
yeni istek
  ↓
yalnız en son isteğin sonucu arayüze uygulanır

kullanılmalıdır.

Filtreler

Filtrelerde seçili değer, aktif filtre sayısı, tek tek kaldırma, tümünü temizleme ve sonuç sayısı görünür olmalıdır. Baymard'ın e-ticaret araştırmalarındaki “uygulanan filtreleri görünür tutma” bulgusu kurumsal veri ızgaralarına aktarılırken alan bağlamıyla doğrulanmalıdır.

Sıralama

Sıralama açık yön göstermeli ve mümkünse insan dilinde ifade edilmelidir: “En yeni / En eski” gibi.

Ünite 2: Veri, Formlar, İş Akışları ve İstemci Durumu

Bir istemci iş akışı tasarlanırken önce kullanıcının gerçekleştirmek istediği işlem, giriş koşulları ve işlemin tamamlandığını gösteren durum tanımlanır. Bekleme, kısmi veri, doğrulama hatası, zaman aşımı ve yeniden deneme ayrı arayüz durumları olarak değerlendirilir. Aynı isteğin yinelenmesi çift işlem doğurabilecekse kullanıcı kontrolü ile sunucu tarafı işlem kimliği birlikte ele alınmalıdır. Arayüz, işlem gerçekten tamamlanmadan başarı bildirimi göstermemeli; hatadan sonra kullanıcının girdiği bilgiyi mümkün olduğunca korumalıdır.

Veri Tabloları ve Veri Izgarası Tasarımı

Nielsen Norman Group veri tablolarında dört temel görevi vurgular:

1. belirli ölçüte uyan kayıtları bulma,
2. kayıtları karşılaştırma,
3. tek kaydı görüntüleme/düzenleme/ekleme,
4. kayıtlar üzerinde eylem yapma.

Tablo ile ızgara aynı şey değildir

Statik veya yalnız okuma amaçlı tablolar için semantik HTML <table> çoğu zaman doğru ve erişilebilirdir. Etkileşimli veri ızgarası; klavye ile hücre gezinmesi, seçim, düzenleme ve sanallaştırma gibi uygulama davranışları içeriyorsa WAI-ARIA grid kalıbı gerekebilir.

Yaygın iş tablosu yüzeyi

Başlık                    [Ara................] [Filtre] [⋯]
Aktif filtreler: [Durum: Aktif ×] [Tarih: Bugün ×] [Temizle]

┌────┬──────────────┬─────────────┬──────────┬────────────┐
│ □  │ Kayıt        │ Tarih ↕     │ Durum    │ İşlemler   │
├────┼──────────────┼─────────────┼──────────┼────────────┤
│ □  │ ...          │ ...         │ ...      │ ⋯          │
└────┴──────────────┴─────────────┴──────────┴────────────┘

1–50 / 12.480                       [‹] [1] [2] [3] [›]

İhtiyaca göre arama, filtre, sıralama, sayfalama, sayfa boyutu, satır seçimi, çoklu seçim, toplu işlem, sütun görünürlüğü, yeniden boyutlandırma, sabitlenen başlık, ayrıntı yan paneli, dışa aktarma, kopyalama, boş/yükleme/hata durumları bulunabilir. Her tabloya bütün özellikleri eklemek doğru değildir.

IBM Carbon veri tablosu yaklaşımında araç çubuğu arama, filtreleme ve genel eylemler için ortak bölgedir. Satır seçildiğinde toplu işlemler bağlamsal olarak ortaya çıkabilir.

Mobil tablo

Duyarlı olmak tabloyu mutlaka karta dönüştürmek değildir. Önceliksiz sütunları gizlemek, ayrıntı yan paneli, kontrollü yatay kaydırma, sabitlenen ana sütunlar veya göreve özel kart görünümü değerlendirilebilir. Yoğun mühendislik/yönetim tablolarında yatay kaydırma çoğu zaman bilgiyi kaybetmekten daha doğrudur.

Sayfalama mı, sonsuz kaydırma mı?

Sonsuz kaydırma keşif ve homojen sosyal akış için güçlüdür. Sayfalama ise belirli kayda geri dönme, karşılaştırma, yönetim ve raporlama için çoğu zaman daha uygundur. NN/g de sonsuz kaydırmanın belirli bir öğeyi bulmak gibi hedefli görevlerde zayıf olabileceğini belirtir.

Sanallaştırma

100 bin satırı DOM'a koymak duyarlı tasarım değildir. Sanal kaydırma oluşturma maliyetini düşürür; ancak ekran okuyucu semantiği, tarayıcıda bulma, satır sayısı, klavye gezinme ve kaydırma konumu dikkatle ele alınmalıdır.

Form Tasarımı

Kullanıcının amacı form doldurmak değil, formun arkasındaki sonucu elde etmektir. Her alan için “Bu bilgi gerçekten şimdi gerekli mi?” sorusu sorulmalıdır.

Kaldır → Otomatikleştir → Sadeleştir

1. gereksiz alanı kaldır,
2. bilinen veriyi tekrar isteme,
3. türetilebilen veriyi otomatik getir,
4. kalan alanları sadeleştir.

Baymard'ın ödeme akışı araştırmasında da ham adım sayısından çok, kullanıcının karşılaştığı alan yükünün önemli olduğu görülür.

Etiket

Tercih:

E-posta adresi
[________________________]

Placeholder etiket yerine kullanılmamalıdır; yazmaya başlayınca kaybolur.

Zorunlu ve isteğe bağlı

Uzun formlarda hangi alanların zorunlu olduğu açık olmalıdır. Yalnız kırmızı * kullanıp anlamını açıklamamak zayıftır.

Girdi alanı semantiği

<input type="email" autocomplete="email">
<input type="tel" inputmode="tel">
<input type="date">

uygun sanal klavye ve tarayıcı davranışını destekler.

Doğrulama

İstemci doğrulaması hızlı geri bildirim içindir; sunucu doğrulaması güvenlik ve veri bütünlüğünün gerçek kaynağıdır. İstemci tarafı doğrulama bir güvenlik kontrolü değildir.

Uygun zamanlama genellikle:

• dokunulmamış alan → sessiz,
• odaktan ayrılmış/dokunulmuş alan → doğrula,
• gönderim → bütün formu doğrula.

Hata mesajından önce hata kaynağını kaldırmak

Doğrulama yalnız yanlış girdiyi yakalama işi değildir. Kullanıcının geçersiz bir durumu üretmesine neden gerek duyulduğu da sorgulanmalıdır.

Örneğin sistem yalnız son on iki döneme ait kayıtları sunabiliyorsa kullanıcıdan serbest başlangıç ve bitiş tarihi almak yerine gerçekten seçilebilen dönemleri göstermek hata uzayını küçültür. Benzer biçimde sistem mevcut sorgunun tarih aralığını zaten biliyorsa aynı tarihleri analiz ekranında tekrar sormak hem gereksiz karar hem de tutarsızlık olasılığı üretir.

Genel sıra şu olabilir:

geçersiz durumu mümkünse üretilemez yap
↓
kalan hatayı erken ve bağlam içinde göster
↓
sunucu tarafında yine doğrula
↓
kurtarma yolunu açık bırak

Her hatayı onay iletişim kutusuyla önlemeye çalışmak da çözüm değildir. Onay, yanlış yapanı durdurduğu kadar doğru yapan herkesi de kesintiye uğratır. Düşük riskli ve geri alınabilir işlemlerde iyi varsayılan, açık durum ve geri alma çoğu zaman daha düşük bilişsel maliyetlidir.

Hata özeti

Form gönderilemedi. 3 alanı düzeltin:
- Başlangıç tarihi
- E-posta
- Bölüm

Uzun formda üstte özet, alan yanında detay yararlıdır.

Form durumu

Tarayıcının geri düğmesi 15 dakikalık formu silmemelidir. Geçmiş durumu, taslak veya uygun depolama değerlendirilebilir; hassas veri için istemci depolaması ayrıca güvenlik analizi gerektirir.

Sihirbaz, Adım Göstergesi, Görev Listesi ve Aşamalı Gösterim

Sihirbaz süreç doğal olarak sıralıysa, sonraki adım önceki cevaba bağlıysa, yeni kullanıcı seçenek yoğunluğunda zorlanıyorsa veya yüksek riskli kararlar adım adım doğrulanacaksa yararlıdır.

1. Temel Bilgiler
      ↓
2. Kapsam
      ↓
3. Yetkiler
      ↓
4. Kontrol
      ↓
5. Onay

Sihirbaz ne zaman yanlıştır?

Kullanıcı aynı işi çok sık yapıyor, alanları aynı anda karşılaştırıyor veya adımlar arasında sürekli gidip geliyorsa sihirbaz uzman kullanıcıyı yavaşlatabilir.

İyi sihirbaz özellikleri

• mevcut adım görünür,
• toplam ilerleme anlaşılır,
• önceki adıma dönülebilir,
• geri dönünce veri kaybolmaz,
• kilitli adımlar yanlışlıkla aktif görünmez,
• her adım tek mantıksal konuya odaklanır,
• son adımda özet bulunur.

Cevapları gözden geçirme

GOV.UK, küçük ve orta ölçekli işlem akışlarında son onaydan hemen önce cevapların gözden geçirildiği ekranın güveni artırıp hataların düzeltilmesine yardımcı olabileceğini belirtir.

Kontrol edin

Ad Soyad       Ali Köker      [Değiştir]
Birim           ...            [Değiştir]
Yetki           ...            [Değiştir]

[Onayla ve Kaydet]

Görev listesi

Uzun, birden fazla oturumda tamamlanan süreçte lineer sihirbaz yerine:

Başvuru

[✓] Kimlik bilgileri
[✓] İletişim
[ ] Belgeler
[ ] Tercihler
[-] Son kontrol

görev listesi daha uygundur. GOV.UK, uzun ve çok parçalı işlem akışlarında bu deseni kullanır; ancak önce sürecin gerçekten sadeleştirilemeyeceğinin sorgulanmasını önerir.

Aşamalı gösterim

Temel Ayarlar
...
[ Gelişmiş seçenekleri göster ]

İleri düzey seçenekleri saklamak faydalı olabilir; ancak sık kullanılan kritik özelliği “gelişmiş” diyerek gizlemek yanlış bilgi mimarisidir.

Facebook Privacy Checkup

Meta'nın Privacy Checkup aracı gizlilik ve güvenlik ayarlarını konu-temelli rehberli akışa dönüştürmüştür. Karmaşık ayar kümelerinin tek büyük form yerine rehberli kontrol/sihirbaz kalıbıyla yönetilmesine iyi bir örnektir.

Diyalog, Yan Panel, Bağlamsal Açılır Panel ve Modal İletişim Kutusu

Modal iletişim kutusu pahalı bir etkileşimdir

Modal iletişim kutusu:

• ana akışı keser,
• odağı kendi içine taşır,
• arka planı geçici olarak kullanılamaz hâle getirir,
• kullanıcıyı karar vermeye zorlar.

Bu nedenle yalnız gerçekten geçici ve odak gerektiren işlem için kullanılmalıdır.

Modal iletişim kutusunda erişilebilirlik

WAI-ARIA modal iletişim kutusu kalıbında:

• odak açıldığında dialog içine taşınır,
• Tab dialog içinde dolaşır,
• Escape kapatır,
• kapandıktan sonra odak anlamlı biçimde tetikleyiciye döner,
• görünür bir kapat/iptal mekanizması bulunur.

Modal iletişim kutusunu yalnız görsel olarak ortalanmış bir <div> yapmak yeterli değildir; odak yönetimi davranışın parçasıdır.

Onay iletişim kutusu

Her işlem için:

Emin misiniz?

sormak zamanla refleks hâlinde onay üretir. Onay özellikle:

• geri alınamaz,
• yüksek etkili,
• nadir,
• kullanıcının yanlışlıkla tetikleyebileceği

eylemlerde kullanılmalıdır.

Mümkünse geri alınabilir işlem ve Geri Al (Undo) seçeneği daha iyi bir UX sağlayabilir.

Yan panel

Yan panel veya ayrıntı paneli şu durumlarda yararlıdır:

• kullanıcı listedeki bağlamı kaybetmeden ayrıntı görmek istiyorsa,
• hızlı düzenleme yapılacaksa,
• filtre paneli gerekiyorsa,
• kayıt detayına kısa süreli erişim isteniyorsa.

Ancak derin, çok bölümlü ve doğrulama yoğun formları dar yan panel içine sıkıştırmak kullanılabilirliği düşürür.

Bağlamsal açılır panel

Kısa bağlamsal seçimler için uygundur:

• satır işlemleri,
• hızlı filtre,
• küçük seçenek listeleri,
• ikincil açıklamalar.

Kritik bir işlev yalnız hover olayıyla erişilebilir olmamalıdır; dokunmatik ve klavye kullanıcıları düşünülmelidir.

Sistem Geri Bildirimi, Yükleme Durumları ve Algılanan Performans

Gerçek hız ve algılanan hız

Kullanıcı açısından:

Tıklama → hiçbir şey yok → 1,5 s sonra ekran değişti

ile:

Tıklama → hemen basılı/yükleniyor durumu → 1,5 s sonra sonuç

aynı sunucu tarafı süresine rağmen farklı deneyimlerdir.

web.dev’in INP belgesi, geciken görsel geri bildirimin kullanıcının aynı kontrolü tekrar tekrar etkinleştirmesine yol açabileceğini açık biçimde ele alır.

Yükleme göstergesi amaca göre seçilmelidir

İskelet ekran

• sayfanın yapısı önceden belliyse,
• içerik yükleniyorsa.

Yükleme göstergesi

• kısa,
• süresi bilinmeyen işlemde.

İlerleme çubuğu

• ilerleme gerçekten ölçülebiliyorsa.

Belirli ilerleme

• yüzde veya kalan iş güvenilir biçimde biliniyorsa.

Sahte ilerleme yüzdesi göstermek kullanıcı güvenini bozar.

İyimser arayüz

Örneğin “beğen” gibi:

• düşük riskli,
• kolay geri alınabilir

bir işlem arayüzde hemen uygulanıp sunucu tarafı sonucu sonradan doğrulanabilir.

Ancak:

• para transferi,
• yetki değişikliği,
• kritik veri silme,
• resmî kayıt oluşturma,
• güvenlik ayarı

gibi işlemlerde sunucu sonucu alınmadan “başarılı” göstermek doğru değildir.

Geçici bildirim

Geçici bildirim:

• geçici,
• düşük önem düzeyinde,
• kullanıcının ayrıca işlem yapması gerekmeyen

durumlar için uygundur.

Kritik hata yalnız birkaç saniyelik geçici bildirim ile kaybolmamalıdır.

Boş durum

Boş tablo:

Kayıt yok

yerine durumun nedenini ayırmalıdır.

Henüz kayıt oluşturulmamış.            [Yeni kayıt]

veya:

Bu filtrelerle eşleşen kayıt yok.      [Filtreleri temizle]

Bu iki durum sistem açısından aynı sonuç kümesini üretse de kullanıcı görevi açısından farklıdır.

Tekrarlı İstekleri ve Yarış Durumlarını Önleme

Bu konu UI/UX ile veri bütünlüğünün doğrudan kesişimidir. Yoğun trafikli üretim sistemlerinde küçük görünen bir çift tıklama veya geç dönen bir arama isteği, yalnız arayüz kusuru olarak kalmaz; yinelenen kayıt, eski verinin yeni sonucu ezmesi ya da operatörün yanlış kayıt üzerinde işlem yapması gibi sonuçlara dönüşebilir.

Problem 1: Çift tıklama / yinelenen gönderim

Kullanıcı “Kaydet” düğmesine iki kez basabilir:

POST /save
POST /save

İstemci tarafında düğmeyi veya işlemi geçici olarak kilitlemek yararlıdır:

if (saving) return;
saving = true;

try {
    await save();
} finally {
    saving = false;
}

Ancak bu veri bütünlüğü garantisi değildir. Kullanıcı:

• iki sekmeden,
• başka cihazdan,
• yeniden deneme yapan ara sunucu veya istemci üzerinden

aynı isteği tekrarlayabilir.

Problem 2: Arama isteği fırtınası

Her karakterde sunucu tarafı çağırmak:

a    → request 1
al   → request 2
ali  → request 3
alik → request 4

gereksiz ağ, CPU ve DB yükü üretir.

Debounce

let timer;

function scheduleSearch(value) {
    clearTimeout(timer);
    timer = setTimeout(() => search(value), 250);
}

250 ms yalnız örnektir. Gecikme kullanıcı görevi ve gerçek ölçümle seçilmelidir.

Problem 3: Eski isteğin yeni sonucu ezmesi

request("a")      yavaş
request("alik")   hızlı

"alik" sonucu gelir
"a" sonucu sonra gelir
UI yanlışlıkla eski sonuca döner

Çözüm iki katmanlı olabilir:

1. önceki isteği AbortController ile iptal etmek,
2. ayrıca generation/sequence kontrolü kullanmak.

let controller;
let generation = 0;

async function search(value) {
    controller?.abort();
    controller = new AbortController();
    const current = ++generation;

    const response = await fetch(`/search?q=${encodeURIComponent(value)}`, {
        signal: controller.signal
    });

    const data = await response.json();
    if (current !== generation) return;

    render(data);
}

Bu model yalnız yükü azaltmaz; son kullanıcı niyetinin arayüz üzerinde baskın kalmasını sağlar.

Problem 4: Değişiklik işlemini yeniden deneme

HTTP semantiğinde GET, HEAD, OPTIONS ve TRACE güvenli (safe) kabul edilir; güvenli yöntemler ile PUT ve DELETE idempotent semantiğe sahiptir. POST genel olarak idempotent varsayılmaz.

Dolayısıyla:

POST gönderildi
bağlantı koptu
işlem sunucuda gerçekleşti mi?

sorusu kritik hâle gelir.

Idempotency key

Özellikle ödeme ve sipariş API'lerinde yaygın çözüm:

POST /orders
Idempotency-Key: 550e8400-e29b-41d4-a716-446655440000

Sunucu aynı anahtarla tekrar gelen aynı mantıksal işlemi ikinci kez oluşturmamalıdır. Stripe'ın API modeli bu yaklaşımı açıkça uygular.

Doğru koruma katmanları

Arayüzde sürmekte olan işlem koruması
        ↓
debounce / cancel
        ↓
idempotency key
        ↓
iş kuralı değişmezi / işlem
        ↓
iyimser eşzamanlılık veya benzersizlik kısıtı (mümkünse)

Düğmeyi geçici olarak devre dışı bırakmak tek başına veri güvenliği değildir.

Yeniden deneme

Yeniden deneme şu koşullarda daha güvenlidir:

• idempotent/güvenli işlem,
• geçici hata,
• sınırlı deneme,
• üstel geri çekilme,
• rastgele sapma.

İdempotent olmayan POST isteğinin semantiği bilinmeden kör biçimde otomatik yeniden denenmesi yinelenen veri üretebilir. RFC 9110 bu ayrımı açıkça ortaya koyar.

URL, Gezinme Durumu ve Tarayıcı Geçmişi

Web uygulamasında görünen her durum aynı yaşam süresine sahip değildir. Arama kutusundaki geçici metin, açık panel, seçili kayıt, sayfalama, filtreler, kullanıcı taslağı ve sunucuda kalıcı olarak saklanan alan verisi aynı depolama veya gezinme mekanizmasına bağlanmamalıdır.

Pratik bir ayrım şöyledir:

geçici görünüm durumu
    -> yalnız mevcut etkileşim

gezinme durumu
    -> URL / session history ile anlamlı geri dönüş

oturum durumu
    -> aynı sekme veya oturum boyunca çalışma bağlamı

kalıcı alan durumu
    -> sunucuda doğrulanan iş verisi

Bu ayrımın UX karşılığı önemlidir. Kullanıcı bir arama sonucunda üçüncü sayfaya geçmiş, belirli bir filtreyi etkinleştirmiş ve bir kaydın ayrıntısını açmışsa tarayıcının Geri düğmesine basmak çoğu durumda onu anlamsız bir varsayılan ekrana değil, önceki anlamlı gezinme durumuna döndürmelidir.

URL paylaşılabilir durumun sözleşmesidir

URL'ye taşınması yararlı olan durum genellikle şu özellikleri taşır:

• yeniden yüklemede anlamını korur,
• yer imi yapılabilir,
• başka bir sekmede açılabilir,
• kullanıcıya veya ekip arkadaşına gönderildiğinde aynı bağlamı yeniden kurabilir,
• gizli veya hassas veri içermez.

Örneğin:

/search?q=oracle&status=open&page=3

anlamlı bir gezinme durumunu temsil edebilir. Buna karşılık parola, erişim belirteci, kişisel veri veya çok büyük geçici nesneler URL'ye taşınmamalıdır.

Her UI değişikliği de yeni geçmiş girdisi üretmemelidir. Kullanıcının anlamsal olarak "yeni bir yere" geçtiği durumlarda pushState, mevcut gezinme durumunun aynı adres üzerinde düzeltilmesinde replaceState benzeri davranış daha uygundur. Buradaki karar API isminden önce kullanıcı zihinsel modeline dayanır:

yeni anlamlı adım     -> geçmişte yeni giriş
aynı adımın düzeltmesi -> mevcut girişi güncelle

WHATWG HTML standardındaki oturum geçmişi (session history) modeli, Geri/İleri gezinmesini ve klasik History API durumunu tarayıcı davranışının parçası olarak tanımlar. Uygulamanın kendi iç yönlendirmesi bu sözleşmeyle çatışmamalıdır.

Yenileme, derin bağlantı ve doğrudan açılış

SPA içinde yalnız istemci belleğinde bulunan bir yönlendirme durumu veya seçim, sayfa yenilendiğinde kayboluyorsa teknik olarak çalışan ama kırılgan bir bilgi mimarisi oluşur. Kritik bir görünüm doğrudan URL ile açılabiliyorsa sunucu ve istemci bu adresi birlikte anlamlandırabilmelidir.

aynı URL
  |
  +--> normal tıklama
  +--> yeni sekmede açma
  +--> yenileme
  +--> yer imi
  +--> doğrudan adres çubuğu

Bu yolların hepsinin birebir aynı piksel durumunu üretmesi gerekmez; fakat aynı kullanıcı görevini güvenli biçimde yeniden kurmalıdır.

Kaydırma ve odak geri yükleme aynı şey değildir

Tarayıcı oturum geçmişi için kaydırma geri yükleme davranışı sunar. Uygulamanın bunu elle yönetmesi gerektiğinde iki ayrı soru sorulmalıdır:

• kullanıcı hangi içerik konumuna dönmeli?
• klavye/yardımcı teknoloji odağı hangi anlamlı elemana dönmeli?

Sadece scrollTop saklamak erişilebilir gezinme sağlamaz. Yeni bir görünüm açıldığında odağın anlamlı başlığa veya içerik başlangıcına taşınması; önceki görünüme dönüldüğünde ise kullanıcının bağlamının gereksiz biçimde sıfırlanmaması gerekir.

URL arayüz durumunun tamamı değildir

Her durumu URL'ye kodlamak da hatadır. Açık tooltip, hover, bir metin alanındaki henüz kaydedilmemiş birkaç karakter veya anlık sürükleme konumu URL sözleşmesinin parçası olmak zorunda değildir. Amaç, kullanıcının tekrar kurmak isteyeceği gezinme bağlamını adreslenebilir tutmaktır.

Dağıtık İstemci Durumu, Veri Tazeliği ve Çevrimdışı Davranış

Modern web uygulamasında "ekrandaki veri" tek bir durum değildir. Aynı anda birden fazla gerçeklik katmanı bulunabilir:

sunucudaki doğrulanmış durum
        |
        +--> istemci önbelleği
        |       |
        |       +--> ekranda gösterilen sürüm
        |
        +--> arka planda gelen yeni sürüm

kullanıcının kaydedilmemiş taslağı

ağda bekleyen / sonucu bilinmeyen değişiklik

Bu katmanlar ayrılmadığında kullanıcı eski veriyi güncel, gönderilmemiş değişikliği kaydedilmiş veya başarısız senkronizasyonu başarılı sanabilir.

Veri tazeliği görünür bir UX özelliğidir

Kritik karar ekranında "sonuç geldi" bilgisi tek başına yeterli olmayabilir. Gerektiğinde şu bilgiler görünür olmalıdır:

• veri hangi zamana ait?
• son başarıyla ne zaman yenilendi?
• arka planda yenileme sürüyor mu?
• görünüm tam mı, kısmi mı?
• kullanıcı şu anda önbellekteki eski sürüme mi bakıyor?

Burada amaç her satıra zaman damgası doldurmak değil, kararı değiştirebilecek tazelik farkını görünür kılmaktır.

Çevrimdışı, yavaş ve kopuk bağlantı aynı durum değildir

"Ağ yok" tek hata sınıfı değildir:

bağlı ve güncel
bağlı ama yavaş
bağlantı koptu, yerel veri var
bağlantı koptu, gerekli veri yok
yeniden bağlandı, senkronizasyon bekliyor
senkronizasyon çakıştı

Service Worker ve Cache API gibi web platformu mekanizmaları çevrimdışı yetenek sağlayabilir; fakat yalnız teknik olarak cache kullanmak doğru UX üretmez. Kullanıcı hangi verinin çevrimdışı erişilebilir olduğunu ve hangi işlemin sunucuya ulaşmadığını anlayabilmelidir.

Örneğin bir değişiklik çevrimdışıyken kuyruğa alınabiliyorsa arayüz "Kaydedildi" yerine semantiği doğru bir durum göstermelidir:

Yerel olarak kaydedildi · bağlantı gelince gönderilecek

Sunucu onayı geldikten sonra kalıcı başarı gösterilir. Eylem çevrimdışıyken güvenli biçimde kuyruğa alınamıyorsa kontrolün bunu açıkça söylemesi, yanlış başarı üretmesinden daha doğrudur.

Yeniden bağlanma sessiz veri ezme fırsatı değildir

Kullanıcı çevrimdışıyken taslak değiştirmiş, aynı kayıt başka bir yerde güncellenmiş olabilir. Yeniden bağlantıda sırf yerel sürüm daha sonra gönderildi diye sunucu durumunu ezmek güvenilir bir senkronizasyon stratejisi değildir.

Daha güvenli model:

yerel taban sürüm
      +
yerel değişiklik
      +
sunucudaki güncel sürüm
      |
      v
karşılaştır / birleştir / kullanıcıya çakışmayı göster

Otomatik birleştirme yalnız alanların bağımsızlığı ve iş kuralı bunu gerçekten güvenli kılıyorsa yapılmalıdır.

Çok Sekmeli ve Çok Kullanıcılı Durum

Aynı kullanıcı uygulamayı iki sekmede açabilir; iki kullanıcı aynı kaydı eşzamanlı değiştirebilir. Bu iki problem benzer görünse de farklı katmanlardadır.

sessionStorage ve localStorage aynı davranışı vermez

WHATWG HTML standardı sessionStorage alanını sekme/üst düzey gezinme bağlamına bağlı çalışma durumu için, localStorage alanını ise aynı kaynak kökeni (origin) altında daha kalıcı ve pencereler arasında paylaşılan durum için tanımlar. localStorage paylaşılıyor diye atomik işlem veya kilitleme garantisi verdiği varsayılmamalıdır.

Bu nedenle:

• benzersiz sayaç,
• sıra numarası,
• kilit,
• para/işlem durumu,
• güvenlik kararı

gibi veri bütünlüğü gerektiren değerler tarayıcı depolamasındaki oku-değiştir-yaz akışına emanet edilmemelidir.

Aynı kaynak kökenindeki sekmeler arasında arayüz olayı iletmek için storage olayı veya uygun olduğunda BroadcastChannel kullanılabilir. Örneğin bir sekmede oturum kapatıldıysa diğer açık sekmelerin bunu fark edip yetkili ekranı göstermeye devam etmemesi gerekir.

Sunucu tarafı eşzamanlılık UI sözleşmesine yansır

İki istemci aynı kaydı şu sırayla değiştirebilir:

A sürüm 7'yi okur
B sürüm 7'yi okur
A değiştirir -> sürüm 8
B eski sürüm üzerinden değiştirir

B'nin yazması kontrolsüz kabul edilirse A'nın değişikliği kaybolabilir. RFC 9110 koşullu isteklerin If-Match gibi önkoşullarla durum değiştiren isteklerde kayıp güncelleme (lost update) problemini önlemek için kullanılabileceğini açıkça tanımlar.

UI açısından önemli olan HTTP başlığının kendisinden çok çatışmanın doğru temsilidir. Sunucu değişikliği reddettiğinde kullanıcıya yalnız:

Kaydetme başarısız.

demek yeterli değildir. Mümkünse şu ayrım görünür olmalıdır:

Bu kayıt siz düzenlerken değiştirildi.
[Sunucudaki sürümü incele]
[Benim değişikliklerimi karşılaştır]
[İptal]

Kullanıcının taslağı hata nedeniyle silinmemelidir. "Son yazan kazanır" bazı düşük riskli ayarlar için kabul edilebilir olabilir; fakat veri kaybı maliyetinin yüksek olduğu iş akışlarında bilinçli bir ürün kararı olmadan varsayılan hâle getirilmemelidir.

Bildirim ve Dikkat Mimarisi

Bildirim tasarımı tek bir toast bileşeni seçmek değildir. Mesajın önemi, yaşam süresi, eylem gerektirip gerektirmediği ve bağlamdan ayrıldığında anlamını koruyup korumadığı belirleyicidir.

alan hatası          -> alanın yanında
form özeti           -> form bağlamında kalıcı
başarı bilgisi       -> kısa ve düşük kesintili
sistem uyarısı       -> görünür ve gerektiğinde kalıcı
arka plan olayı      -> yalnız kullanıcının kararını etkiliyorsa yükselt

Aynı olay tekrar tekrar oluşuyorsa bildirim fırtınası üretmek yerine birleştirme, sayaç veya durum yüzeyi düşünülebilir. Kullanıcının göremeden kaybolacağı kritik mesaj için otomatik kapanan geçici yüzey kullanılmamalıdır.

Bildirim sayısı arttıkça "daha şeffaf sistem" oluşmaz. Dikkat de sınırlı bir kaynaktır. Tasarımın görevi teknik olayları kullanıcıya aynen dökmek değil, bir sonraki kararı değiştiren durumları doğru önem düzeyinde görünür kılmaktır.

Semantik Platform Bileşenleri ve Yerleşik Davranıştan Yararlanmak

Bir arayüz mühendisliği problemi her zaman yeni bir JavaScript bileşeni yazmayı gerektirmez. HTML platformu; bağlantı, form alanı, düğme, ayrıntı/açılır bölüm ve diyalog gibi birçok etkileşim için klavye davranışı, odak yönetimi, semantik rol ve yardımcı teknoloji entegrasyonu açısından güçlü bir başlangıç noktası sunar. Bu nedenle tasarım kararında ilk soru yalnız “nasıl görünmeli?” değil, “bu davranış için tarayıcıda zaten uygun bir semantik ilkel var mı?” olmalıdır.

Bu yaklaşım üç avantaj sağlar:

• temel etkileşim JavaScript yüklenmeden veya gelişmiş katman başarısız olduğunda da daha dayanıklı kalır;
• klavye ve yardımcı teknoloji davranışının önemli bir bölümü özel bileşen kodundan önce gelir;
• istemci kodu, yerleşik davranışı yeniden üretmek yerine ürünün gerçekten özel gereksinimlerine ayrılabilir.

Örneğin yalnız görünüş için div üzerine tıklama olayı bağlamak, gerçek bir button öğesinin odak, klavye ve disabled semantiğini yeniden üretme yükü doğurur. Benzer biçimde açılır açıklama için details/summary, gerçek modal gereksinimi için uygun olduğunda dialog, form girdisi için doğru input türü ve otomatik tamamlama semantiği özel kod miktarını azaltabilir.

Buradaki kural “native her zaman daha iyidir” değildir. Ürünün davranış modeli, erişilebilirlik testleri veya tarayıcı desteği özel bileşen gerektiriyorsa özel uygulama yapılabilir. Ancak özel uygulama bilinçli bir sapma olmalı; platformun zaten sağladığı semantiği fark etmeden yeniden yazmanın sonucu olmamalıdır.

Girdi türü kullanıcı deneyimini etkiler

Doğru form türü yalnız veri doğrulama konusu değildir. Uygun type, autocomplete, required, min, max, step ve benzeri semantik özellikler; dokunmatik cihazdaki yazılım klavyesini, tarayıcı yardımını, otomatik doldurmayı ve hata geri bildirimini etkileyebilir. Bu nedenle istemci doğrulaması ile form semantiği birbirinden ayrı düşünülmemelidir.

Bir form alanı için şu sıra yararlıdır:

1. Veri gerçekten hangi türdedir?
2. Platformda bu türü anlatan yerleşik bir kontrol var mı?
3. Kullanıcıya hangi giriş kolaylıkları sağlanabilir?
4. Sunucu tarafındaki doğrulama hangi kuralları kesin olarak uygulayacaktır?
5. Yerleşik davranış yeterli değilse hangi kısmı progressive enhancement ile geliştirmek gerekir?

Bu sıra, görsel olarak özel ama semantik olarak zayıf formların önüne geçer.

Eski ağ yanıtının yeni kullanıcı seçimini ezmesini önlemek. Kullanıcı önce A kaydını, hemen ardından B kaydını açtığında A isteğinin ağdan daha geç dönmesi mümkündür. Yanıtlar geliş sırasına göre doğrudan ekrana yazılırsa kullanıcı B kaydını seçmişken eski A içeriği gösterilebilir. Bunun önüne geçmek için her yeni seçimde artan bir istek sürüm numarası oluşturulur; yanıt işlendiğinde yalnız güncel sürümle eşleşiyorsa görünür duruma uygulanır. Örneğin A isteği 7, B isteği 8 sürümünü aldıysa önce gelen B yanıtı uygulanır, daha sonra gelen A yanıtı görünür durumu değiştirmez. Önceki isteği iptal etmek kaynak kullanımını azaltabilir; fakat iptalin yarış altında kesinleşeceği varsayılmamalıdır. Yükleniyor göstergesi ve hata mesajı da aynı sürüm denetimine tabi olmalıdır. Böylece ağ gecikmesi, kullanıcının son niyetine aykırı bir arayüz durumuna dönüşmez.

Ünite 3: Duyarlı Tasarım, Erişilebilirlik, Performans ve Güvenlik

Duyarlı bir arayüzün doğrulanması yalnız birkaç ekran genişliğinde görünüş kontrolüyle sınırlı değildir. Önce içerik büyümesi, uzun çeviriler, klavye kullanımı, yakınlaştırma ve odak sırası gibi değişken koşullar belirlenir. Bileşenler en dar kullanım senaryosundan başlayarak taşma, gizlenen kontrol ve odak kaybı açısından değerlendirilir. Performans incelemesinde etkileşime yanıt verme süresi ile yalnız sayfanın ilk kez çizilmesi birbirinden ayrılmalıdır.

Duyarlı ve Uyarlanabilir Tasarım

Duyarlı tasarımın hedefi

Duyarlı tasarım:

aynı masaüstü ekranını küçültmek

anlamına gelmez.

Hedef:

aynı kullanıcı görevini farklı görüntüleme alanı ve giriş yeteneklerinde sürdürülebilir biçimde gerçekleştirmek.

Görüntü alanı

Mobil web için temel:

<meta name="viewport" content="width=device-width, initial-scale=1">

Kırılma noktası cihaz adı değildir

Yanlış düşünce:

iPhone kırılma noktası
iPad kırılma noktası
Dizüstü bilgisayar kırılma noktası

Daha iyi soru:

İçerik hangi genişlikte bozuluyor?

Kırılma noktası içerik tarafından belirlenmelidir.

Mobil öncelikli ve masaüstü

Mobil öncelikli CSS yararlı bir mühendislik tekniğidir; fakat masaüstünü dev bir telefon görünümüne çevirmek doğru değildir. Geniş ekranda:

• karşılaştırma alanı,
• çok sütunlu veri,
• kalıcı navigasyon,
• eş zamanlı detay paneli

gibi avantajlar kullanılabilir.

NN/g de mobil tasarım desenlerinin masaüstüne mekanik biçimde büyütülmesinin gereksiz boşluk ve dağınık bilgi yoğunluğu üretebileceğini vurgular.

Container query

Görüntü alanı her bileşen için yeterli sinyal değildir.

Aynı kart:

• tam sayfada 800 px,
• yan menü içinde 300 px

olabilir.

.card-container {
    container-type: inline-size;
}

@container (min-width: 40rem) {
    .card {
        grid-template-columns: 1fr 1fr;
    }
}

Böylece bileşen cihaz genişliğine değil, kendi kullanılabilir alanına tepki verir.

clamp()

Akışkan tipografi veya boşluk:

h1 {
    font-size: clamp(1.75rem, 1rem + 2vw, 3rem);
}

ile tanımlanabilir.

Yalnız vw kullanmak büyük ve küçük ekranlarda aşırı değerler üretebilir; minimum ve maksimum sınırlar önemlidir.

Giriş yeteneği

Yalnız ekran genişliğine bakmak yeterli değildir.

@media (pointer: coarse) { ... }
@media (hover: none) { ... }
@media (prefers-reduced-motion: reduce) { ... }

Dokunmatik laptop, kalem, dokunmatik yüzey ve telefon aynı etkileşim kabiliyetine sahip değildir.

Ekran boyutu giriş yöntemi değildir

Duyarlı tasarımda görüntü alanı genişliği yerleşim için yararlı bir sinyaldir; fakat kullanıcının hangi giriş aygıtına sahip olduğunu güvenilir biçimde açıklamaz. Geniş ekranlı bir cihaz dokunmatik olabilir; küçük bir cihaz fiziksel klavye veya kalemle kullanılabilir; aynı sistem aynı anda dokunma, fare, dokunmatik yüzey ve klavye kabul edebilir.

Bu nedenle aşağıdaki eşleştirmeler tasarım kuralı olarak kullanılmamalıdır:

dar ekran   = dokunma
büyük ekran = fare
masaüstü    = hassas işaretçi
mobil       = yalnız parmak

Yerleşim ve giriş yeteneği ayrı sorulardır:

Yerleşim sorusu: Ne kadar alan var?
Giriş sorusu:    Kullanıcı bu yüzeyle nasıl etkileşebilir?
Görev sorusu:    Hangi yöntemle güvenli ve verimli çalışabilir?

Bir kırılma noktası yalnız alanın yeniden düzenlenmesini belirlemelidir. Etkileşim davranışını değiştirirken giriş yeteneği ayrıca değerlendirilmelidir.

Çoklu giriş kipleri

Tek bir cihaz için tek bir “doğru” giriş yöntemi varsaymak giderek daha az güvenlidir. Özellikle hibrit bilgisayarlarda kullanıcı aynı görev içinde yöntem değiştirebilir:

klavyeyle arama
→ dokunmayla sekme değiştir
→ dokunmatik yüzeyle ayrıntı seç
→ klavyeyle düzenlemeye devam et

Arayüz bu geçişi bir kip değişikliği gibi kullanıcıya yüklememelidir. Aynı temel görev:

• klavyeyle,
• hassas işaretçiyle,
• kaba işaretçiyle,
• destekleniyorsa kalemle

tamamlanabilmelidir.

CSS giriş yeteneği sorguları yararlı sinyaller sağlar; ancak bunlar kullanıcı davranışını kesin olarak bildiren profil bilgileri değildir. Arayüzü “dokunmatik cihaz” veya “masaüstü cihaz” diye sınıflandırmak yerine gereken yeteneği sorgulamak daha dayanıklıdır.

Üzerine gelme bir geliştirmedir, temel yol değildir

hover kısa önizleme, açıklama veya hızlandırıcı için yararlı olabilir. Fakat bir işlev yalnız üzerine gelmeyle keşfedilebiliyorsa dokunma, klavye ve bazı yardımcı teknoloji yollarında kaybolabilir.

Daha güvenli model:

Temel işlev      → tıklama/dokunma + klavye ile erişilebilir
Ek hızlı bilgi   → hover destekleniyorsa gösterilebilir

Üzerine gelme davranışı, var olan erişilebilir yolu hızlandırmalı; o yolun yerine geçmemelidir.

Duyarlı tasarımın fiziksel sınırı

CSS pikseli yerleşim için güçlü bir soyutlamadır, fakat fiziksel temasın kendisi piksel cinsinden gerçekleşmez. Ekran yoğunluğu, görüntüleme uzaklığı, cihazın elde veya sabit yüzeyde kullanılması ve komşu kontrollerin aralığı aynı sayısal boyutun pratik kullanılabilirliğini değiştirebilir.

Bu nedenle tek bir tarihsel piksel değerini bütün dokunmatik yüzeyler için evrensel fiziksel yasa gibi uygulamak yerine iki katman birlikte korunmalıdır:

1. WCAG gibi güncel normatif erişilebilirlik gereksinimleri karşılanır.
2. Gerçek cihaz ve görev bağlamında yanlış dokunma, erişim, örtülme ve hata maliyeti ayrıca ölçülür.

Standart asgari sınırı tanımlar; saha doğrulaması bağlamı doğrular.

Yeniden akış (Reflow)

WCAG 2.2 Yeniden Akış (Reflow) kriteri, belirli istisnalar dışında içerik ve işlev kaybı olmadan 320 CSS px genişliğe karşılık gelen dar görünümde iki boyutlu kaydırma gerektirmeyen düzeni hedefler.

Gerçek veri tabloları, haritalar ve karmaşık diyagramlar gibi iki boyutlu düzenin anlam için gerekli olduğu içerikler ayrıca değerlendirilir.

Duyarlı önceliklendirme

Masaüstü:

[Başlık] [Arama................] [Filtre] [Dışa Aktar] [Yeni]

Mobil:

[Başlık]                         [⋯]
[Arama.............................]
[Filtre 3]

İşlev kaybolmaz; yerleşim ve öncelik değişir.

Farklı çözünürlük test matrisi

Aşağıdaki değerler standart kırılma noktası değil, pratik test matrisidir:

• Sınıf: Çok dar telefon; Örnek CSS görüntü alanı: 320 × 568
• Sınıf: Telefon; Örnek CSS görüntü alanı: 360 × 800
• Sınıf: Modern telefon; Örnek CSS görüntü alanı: 390 × 844
• Sınıf: Büyük telefon; Örnek CSS görüntü alanı: 412 × 915
• Sınıf: Küçük tablet; Örnek CSS görüntü alanı: 768 × 1024
• Sınıf: Tablet/yatay; Örnek CSS görüntü alanı: 1024 × 768
• Sınıf: Küçük laptop; Örnek CSS görüntü alanı: 1366 × 768
• Sınıf: Laptop; Örnek CSS görüntü alanı: 1440 × 900
• Sınıf: Masaüstü; Örnek CSS görüntü alanı: 1920 × 1080
• Sınıf: Geniş ekran; Örnek CSS görüntü alanı: 2560 × 1440

Bunlara ayrıca:

• %200 tarayıcı yakınlaştırması,
• büyük sistem fontu,
• yatay görünüm,
• dokunmatik giriş,
• klavye-only,
• koyu tema,
• azaltılmış hareket

testleri eklenmelidir.

4K ekran

4K monitörde bütün içeriği ekranın tamamına yaymak zorunlu değildir.

Uzun metin:

okunabilir metin kolonu

şeklinde kontrollü maksimum satır uzunluğunda kalabilir.

Veri ızgarası, zaman çizelgesi veya grafik çalışma alanı ise geniş alanı anlamlı biçimde kullanabilir.

Duyarlı tasarım her bileşeni width: 100% yapmak değildir.

Mobil Gezinme ve Ekran Alanı

Alt gezinme

Material 3 NavigationBar küçük ekranlarda üç ila beş ana hedef bölüm için tasarlanmıştır. Apple da sekme çubuğunu uygulamanın üst seviye bölümleri arasında geçiş için konumlandırır.

Uygun:

[Anasayfa] [Arama] [Görevler] [Bildirim] [Profil]

Uygun değil:

[Kaydet] [Sil] [Dışa Aktar] [Yenile]

Çünkü bunlar hedef bölüm değil eylemdir.

Mobilde daha az görünürlük, daha az işlev demek değildir

1. ikincil görev taşma menüsünde,
2. az kullanılan gelişmiş ayarlar yan panel/alt sayfa.

Sidebar → gezinme bar dönüşümü

Geniş görünümde yan menü, dar görünümde daha kompakt üst/bottom gezinme kullanılabilir.

Masaüstü: kalıcı sol gezinme şeridi
Tablet: daraltılabilir yan şerit
Telefon: 3–5 birincil hedef için alt gezinme + Daha Fazla

Ancak bilgi mimarisi beşten çok eşit ağırlıklı üst seviye alan içeriyorsa bunları bottom gezinme içine zorla sıkıştırmak doğru değildir.

Erişilebilirlik — WCAG 2.2 ve Klavye

WCAG hedefi

W3C yeni projelerde WCAG 2.2'nin kullanılmasını önerir. Kurumsal web uygulamalarında WCAG 2.2 AA güçlü bir asgari hedef olarak değerlendirilebilir.

Klavye erişimi

Her önemli işlev gerektiği ölçüde:

• Tab,
• Shift+Tab,
• Enter,
• Space,
• ok tuşları,
• Escape

ile kullanılabilmelidir.

Odak görünür olmalıdır

:focus-visible {
    outline: 2px solid currentColor;
    outline-offset: 2px;
}

Odağı yalnız estetik gerekçeyle kaldırmak ciddi kullanılabilirlik problemidir.

WCAG 2.2 ayrıca odaklanan bileşenin sabitlenen/sabit katmanlar tarafından tamamen gizlenmemesini ele alır.

Hedef boyutu

WCAG 2.2 Target Size (Minimum) kriterinde AA seviyesinde hedeflerin genel olarak en az 24 × 24 CSS px olması veya kriterdeki boşluk/istisna koşullarından birini karşılaması beklenir.

Bu erişilebilirlik tabanıdır. Mobilde operasyonel olarak daha büyük hedefler çoğu zaman daha güvenlidir.

Tab kalıp

WAI-ARIA sekme kalıbında:

• Tab tablist'e girer,
• Left/Right Arrow sekmeler arasında dolaşabilir,
• automatic activation yalnız panel değişimi gecikmesizse uygundur,
• aksi durumda Enter/Space ile manual activation daha iyi olabilir.

Bu ayrım performans ile erişilebilirliğin doğrudan kesiştiği bir noktadır.

Izgara klavye modeli

ARIA ızgara kullanılıyorsa:

• Arrow keys hücreler arasında,
• Home/End satır içinde,
• Ctrl+Home/Ctrl+End bütün ızgara içinde

benzeri uygulama-seviyesi klavye davranışları gerekebilir.

Semantik HTML tablosunu gereksiz yere ARIA grid'ine çevirmek ek sorumluluk üretir.

Azaltılmış hareket

@media (prefers-reduced-motion: reduce) {
    *, *::before, *::after {
        animation-duration: 0.01ms;
        animation-iteration-count: 1;
        transition-duration: 0.01ms;
    }
}

Bu örnek uygulamaya göre daha kontrollü hâle getirilebilir.

X'in erişilebilirlik seçeneklerinde de:

• hareketi azaltma,
• otomatik oynatmayı kapatma,
• font boyutu,
• yüksek kontrast,
• koyu/loş tema,
• klavye kısayolları

gibi tercihler bulunur.

Ekran okuyucu ve erişilebilir ad

Kötü:

<button><i class="fa fa-trash"></i></button>

Daha iyi:

<button aria-label="Kaydı sil">
    <i aria-hidden="true" class="fa fa-trash"></i>
</button>

Canlı bildirimler

Dinamik durum:

<div role="status" aria-live="polite">
    Kaydedildi
</div>

Kritik hata:

<div role="alert">
    Kayıt kaydedilemedi.
</div>

olarak sunulabilir. Ancak gereksiz aria-live kullanımı ekran okuyucu deneyimini gürültülü hâle getirir.

Performans Bir UX Özelliğidir

Çekirdek Web Vitals

Google'ın güncel Çekirdek Web Vitals eşikleri, sayfa yüklerinin 75. persentilinde:

• LCP ≤ 2,5 s
• INP ≤ 200 ms
• CLS ≤ 0,1

olduğunda “good” değerlendirmesine karşılık gelir.

Bunlar özellikle genel web sayfaları için alan metriği hedefleridir; kritik kurum içi uygulamanın kendi uçtan uca SLA'sının yerine geçmez.

INP ve tekrar tıklama

Düşük yanıt verebilirlik:

Click
(geri bildirim yok)
Click
Click
...
event queue catches up

üretebilir.

Bu yalnız “yavaş hissetme” değildir; aynı olayın birden çok tetiklenmesi işlevsel hataya dönüşebilir.

CLS

Sayfa yüklendikten sonra üstte banner eklenip içerik aşağı kayarsa:

• kullanıcı yanlış butona basabilir,
• okuma konumu bozulabilir.

Alan önceden rezerve edilmeli veya öngörülebilir yerleşim kullanılmalıdır.

Gecikmeli yükleme

Gecikmeli yükleme:

• görünür olmayan ağır görseller,
• uzak sekmeler,
• büyük modüller

için yararlı olabilir.

Ancak ana ekranın ilk etkileşimi için gerekli JavaScript'i aşırı parçalamak ilk görev süresini uzatabilir. Amaç “daha az ilk bayt” değil, kritik kullanıcı yolunu daha erken kullanılabilir hâle getirmektir.

Güvenlik, Gizlilik ve Veri Bütünlüğü UX'in Parçasıdır

UI gizlemek yetkilendirme değildir

if (!admin) hideDeleteButton();

yalnız UX'tir.

Sunucu tarafı ayrıca:

authenticate
    ↓
eylemi yetkilendir
    ↓
authorize resource scope
    ↓
validate invariant
    ↓
mutate
    ↓
denetim izi

yapmalıdır.

Yetkisiz veriyi istemciye gönderip gizlemek yanlıştır

Kötü:

Sunucu → bütün kayıtlar
İstemci → yetkisiz kayıtları CSS ile sakla

Doğru:

Sunucu → yalnız yetkili kayıtlar

Yıkıcı eylem

Silme düğmesinde:

• nesne adı,
• kapsam,
• geri alınabilirlik

açık olmalıdır.

“2026 Ağustos Raporu” kalıcı olarak silinecek.
Bu işlem geri alınamaz.

[İptal] [Raporu Sil]

Kaydedilmemiş değişiklik içeren form

Kullanıcı değişiklik yaptıysa:

• sekme kapama,
• kayıt değiştirme,
• sayfa değiştirme

sırasında kayıp riski yönetilmelidir.

Ancak her gezinmede onay göstermek de yorucudur. Uyarı yalnız gerçek kaydedilmemiş değişiklik durumu varsa tetiklenmelidir.

Otomatik kaydetme

Otomatik kaydetme uygunsa:

Değiştirildi → Kaydediliyor → Kaydedildi 09:41

durumu görünür olmalıdır.

Birden çok kullanıcının aynı kaydı düzenlediği sistemlerde otomatik kaydetme:

• sürüm numarası,
• iyimser eşzamanlılık,
• çakışma yönetimi

olmadan veri kaybı üretebilir.

Oturum zaman aşımı

Uzun formun sonunda “oturum süresi doldu” deyip bütün girdiyi kaybetmek ciddi UX ve veri kaybı problemidir.

Güvenlik politikasını bozmadan:

• zaman aşımı öncesi uyarı,
• yeniden doğrulama,
• hassas olmayan taslağın korunması

değerlendirilebilir.

Cihaz Değil Yetenek: Media, Container ve Girdi Özellikleri

Duyarlı tasarımın olgun yaklaşımı cihaz modelini tahmin etmekten uzaklaşır. “Tablet”, “telefon” veya “masaüstü” adları tek başına güvenilir tasarım girdileri değildir; aynı ekran boyutu farklı pencere genişliklerinde, farklı pointer türleriyle ve farklı giriş aygıtlarıyla kullanılabilir.

Bu nedenle üç ayrı soru birbirinden ayrılmalıdır:

• Viewport ne kadar alan sağlıyor? Sayfanın genel kompozisyonu için önemlidir.
• Bileşenin kendi kapsayıcısında ne kadar alanı var? Yeniden kullanılabilir bileşenin gerçek çalışma koşulunu belirler.
• Kullanıcının hangi etkileşim yetenekleri var? İnce pointer, kaba pointer, hover, klavye veya kalem gibi yetenekler hedef boyutu ve etkileşim biçimini etkiler.

Media query bu sorulardan ilkine ve bazı kullanıcı/etkileşim tercihlerine cevap verebilir. Container query ise bir bileşenin tüm ekran yerine yerleştirildiği bağlamı dikkate almasını sağlar. Bu fark, aynı bileşen ana içerikte genişken yan panelde dar olabildiğinde özellikle değerlidir.

pointer ile any-pointer, hover ile any-hover

Bir sistem aynı anda dokunmatik ekran, touchpad, mouse ve kalem barındırabilir. Bu nedenle birincil işaretleme aygıtının niteliği ile sistemde mevcut herhangi bir aygıtın niteliği aynı şey değildir. Arayüzün yalnız pointer: fine gördüğü için dokunmayı yok sayması veya yalnız genişliğe bakarak hover varsayması kırılgan bir yaklaşımdır.

Pratik karar:

viewport/container -> kompozisyon
pointer/hover       -> etkileşim ergonomisi
kullanıcı tercihi   -> hareket/renk gibi sunum davranışı

Bunlar birbirinin yerine kullanılmamalıdır.

Container-relative ölçüler

Container sorguları yalnız “dar/geniş bileşen” eşikleri değildir. cqi, cqw, cqb, cqh, cqmin ve cqmax gibi container-relative birimler, ölçünün viewport yerine bileşenin bulunduğu alanla ilişkilendirilmesini sağlar. Ancak bu birimler de ergonomik alt sınırları ortadan kaldırmaz. Bir buton veya yazı alanı kapsayıcı küçüldükçe sınırsız biçimde küçülmemelidir.

Bu nedenle akışkan ölçü şu düşünceyle kurulmalıdır:

ergonomik alt sınır
        <=
uyarlanabilir değer
        <=
makul üst sınır

min(), max() ve clamp() bu sınırlandırmayı ifade etmek için yararlıdır; fakat sayı seçimi gerçek içerik, zoom, dil ve giriş yöntemiyle test edilmelidir.

Responsive Görseller: Yalnız CSS Boyutlandırması Değildir

Bir resmi max-width: 100% ile taşmayı önleyecek şekilde küçültmek responsive davranışın yalnız bir parçasıdır. Kullanıcıya gereğinden büyük bir dosya göndermek, küçük ekranda yalnız CSS ile küçültülmüş olsa bile ağ, bellek ve decode maliyeti üretir.

Responsive görsel stratejisinde iki problem ayrılır:

• Resolution switching: aynı görselin uygun çözünürlükteki kaynağını seçmek.
• Art direction: kompozisyonun farklı ekran koşullarında gerçekten farklı kırpım veya görsel gerektirmesi.

srcset, sizes ve gerektiğinde picture bu problemlere tarayıcı düzeyinde araç sağlar. Dosya formatı seçimi de performansın parçasıdır; ancak format kararı fallback ve üretim zinciriyle birlikte ele alınmalıdır.

Buradaki UX ilkesi basittir: görsel kalite ile aktarım maliyetini birlikte optimize etmek. En yüksek çözünürlüklü dosyayı her kullanıcıya göndermek kalite garantisi değil, çoğu durumda gereksiz maliyettir.

Ünite 4: Ürün Kalıpları, Tasarım Sistemleri ve UX Ölçümü

Büyük Ölçekli Ürünlerden Çıkarılabilecek Desenler

Büyük ürünleri incelerken piksel düzenini kopyalamak yerine hangi problemi hangi davranışla çözdüklerine bakmak daha değerlidir. Aynı arayüz kararı başka bir kullanıcı kitlesinde, başka bir gelir modelinde veya kritik bir kurum içi sistemde ters sonuç verebilir. Bu nedenle aşağıdaki örnekleri hazır reçeteler değil, sınanabilir tasarım kararları olarak okuyorum.

Facebook / Meta

Meta, Facebook ayarlar arayüzünü yeniden düzenlerken ayarları daha geniş kategoriler altında topladığını, ilişkili seçenekleri birbirine yaklaştırdığını, ayarlar aramasını geliştirdiğini ve Privacy Checkup'a daha görünür erişim verdiğini açıklamıştır. Buradaki önemli nokta belirli menü biçimi değil, karmaşıklığın tek bir gezinme tekniğine yüklenmemesidir. Bilgi mimarisi, arama ve konu temelli rehberli denetim birlikte kullanıldığında kullanıcı uzun bir ayar ağacını ezberlemek zorunda kalmaz.

Privacy Checkup'ın ayrıca başka bir değeri vardır: yüksek etkili gizlilik ve güvenlik kararlarını tek büyük formda üst üste yığmak yerine, anlamlı konulara bölünmüş bir gözden geçirme akışına dönüştürür. Aynı yaklaşım kritik kurumsal ayarlarda da düşünülebilir; fakat hangi adımların gerçekten rehberlik gerektirdiği görev ölçümüyle belirlenmelidir.

X

X'in yayımladığı erişilebilirlik seçenekleri arasında klavye kısayolları, yüksek karşıtlık, hareketi azaltma, otomatik oynatmayı denetleme, yazı boyutu, koyu/loş temalar, alternatif metin ve altyazı gibi tercihler bulunur. Bu örnek, duyarlı tasarımın yalnız ekran genişliğine cevap vermek olmadığını hatırlatır. Kullanıcının hareket, görme, giriş aygıtı ve içerik tüketme tercihleri de arayüzün uyum sağlaması gereken değişkenlerdir.

Amazon

Amazon'ın 2024 ana sayfa geliştirmelerinde kişiselleştirilmiş devam noktaları, ilişkili ürün grupları, yatay keşif, “Buy Again” gibi tekrarlı işi kısaltan girişler ve farklı tasarım varyasyonlarının ölçülerek kademeli biçimde yaygınlaştırılması öne çıkar. Arama deneyimi de otomatik tamamlama, yazım düzeltme, ilişkili sorgular, görüntü ve metinle arama gibi birden çok bulma yolunu birlikte kullanır.

Buradan çıkarılabilecek genel ilke, kullanıcının her oturumda aynı bağlamı baştan kurmaya zorlanmamasıdır. “Son kullanılan”, “yeniden yap” veya “kaldığın yerden devam et” türü yollar doğru görevlerde büyük zaman kazandırabilir. Yoğun iş uygulamalarında da benzer kazancı sık görüyorum: yeni özellik eklemekten önce kullanıcının tekrar tekrar kurduğu bağlamı korumak çoğu zaman daha etkilidir.

Hepsiburada

Hepsiburada'nın SEC'e sunduğu yıllık raporlar; kategori ve alt kategori gezinmesi, metin araması, kategori içi ayrıntılı arama, barkod, görüntü ve konuşmadan metne gibi farklı ürün bulma yollarını birlikte tanımlar. 2025 raporunda trafiğin yaklaşık %90'ının mobil kanallardan geldiği de belirtilir.

Bu oran yalnız Hepsiburada'nın kendi platformuna aittir ve Türkiye'deki bütün web uygulamalarına genellenemez. Yine de tüketici ürünlerinde mobil görünümü masaüstünün eksiltilmiş sürümü olarak ele almanın ne kadar riskli olabileceğini gösteren somut bir kullanım bağlamı sağlar.

Trendyol

Trendyol Tech'in ana sayfa mimarisi yazısında sayfanın farklı türde, kişiselleştirilebilen, kullanıcı grubuna göre seçilebilen, A/B testine girebilen ve gerektiğinde varsayılan içeriğe düşebilen bileşenlerden kurulduğu görülür. Buradaki mimari fikir, büyük bir ana sayfayı tek parça olarak değil, bağımsız sıralanabilen ve ölçülebilen içerik birimleri olarak modellemektir.

Bunu kurumsal işlem ekranına doğrudan taşımak doğru değildir. Operatörün her gün aynı yerde aradığı bir kontrolü dinamik olarak başka yere taşımak kas hafızasını bozar. Gösterge panelinin kişiselleştirilmesi ile yüksek sıklıkta kullanılan işlem arayüzünün yerleşim kararlılığı aynı problem değildir.

Canvas ve Moodle

Canvas Student mobil uygulamasında Dashboard, Calendar, To Do, Notifications ve Inbox gibi öğrencinin sürekli döndüğü üst düzey bölümler alt gezinmede görünür tutulur. Moodle 5.2 gösterge paneli ise Course overview, Timeline ve Calendar gibi ilerleme ve yaklaşan işleri gösteren bölümleri aynı merkezde bir araya getirir; gösterge paneli blokları özelleştirilebilir.

Bu iki örneği birlikte okuduğumda eğitim sisteminin ana ekranı için basit bir ölçüt çıkıyor: ekran kurumun kendisini anlatmaktan önce kullanıcının “şimdi ne yapmam gerekiyor?” sorusuna cevap verebilmelidir. Ders listesi önemlidir, fakat yaklaşan görev, takvim, bildirim ve iletişim çoğu zaman aynı derecede operasyonel değere sahiptir.

İstanbul Üniversitesi AKSİS ve Sakarya Üniversitesi SABİS

İstanbul Üniversitesi'nin resmî AKSİS kullanım kılavuzunda belge talebi Belge Talepleri → Yeni Talep biçiminde görev odaklı bir girişle başlar ve ardından mevcut talepler tablo üzerinden izlenir. Buradaki değer güncel görsel stil değil, mevcut işlemler ile yeni işlem başlatmanın birbirinden açıkça ayrılmasıdır.

Sakarya Üniversitesi'nin resmî SABİS kılavuzlarında ise sistem; öğrenci bilgi sistemi, posta, eğitim bilgi sistemi, kütüphane ve başka kurumsal uygulamalara bir merkez görevi görür. Öğrenci bilgi sistemi içinde ders, transkript ve başvuru gibi görevler daha sonra kendi yerel gezinmesiyle ayrılır. Çok modüllü otomasyonlarda önce çalışma alanını, sonra o alan içindeki görevi seçtiren bu iki katmanlı model anlaşılır olabilir.

Bu üniversite kılavuzlarını güncel UX standardı olarak değil, gerçek kurum görevlerinin nasıl bölündüğünü gösteren saha örnekleri olarak kullanmak gerekir.

Gösterge paneli Tasarımı

Gösterge paneli rapor çöplüğü değildir

Gösterge paneli şu sorulara cevap vermelidir:

• Şu anda ne önemli?
• Ne bekliyor?
• Ne değişti?
• Ne yapmalıyım?
• Hangi alan riskli?

Kart kullanımında anlam

Kötü:

[ 125 ]
[ 98 ]
[ 72 ]
[ 41 ]

Sayıların anlamı ve eylemi yoktur.

Daha iyi:

Bekleyen Başvurular      125
Dünden +18
En eskisi: 3 gün
[İncele]

Kart bir düşünceyi taşımalıdır

Kart, yalnız köşeleri yuvarlatılmış bir dikdörtgen değildir. Bağımsız bir içerik veya görev birimini sınırlandırdığı, kendi içinde anlaşılır olduğu ve çoğunlukla bir baskın eylem taşıdığı zaman yararlıdır.

Kart kullanımı şu durumlarda anlamlı olabilir:

• birbirinden bağımsız öğeler aynı koleksiyonda gösteriliyorsa,
• öğelerin farklı ekran genişliklerinde yeniden dizilmesi gerekiyorsa,
• her öğenin kısa özet + belirgin eylem yapısı varsa.

Buna karşılık aynı anda karşılaştırılması gereken sıkı ilişkili değerleri ayrı kartlara bölmek göz hareketini ve boşluk maliyetini artırır. Tablo, hizalı liste veya tek bir yoğun bilgi yüzeyi daha doğru olabilir.

Kart sayısı arttıkça kartın sınırı da bilgi olmaktan çıkıp görsel gürültüye dönüşebilir. Bu nedenle “bir veri = bir kart” yaklaşımı yerine “bir anlamlı birim = bir yüzey” yaklaşımı tercih edilmelidir.

Gösterge paneli kişiselleştirme

Moodle gibi platformlarda kullanıcıların gösterge paneli bloklarını düzenleyebilmesi mümkündür.

Kurumsal sistemde kişiselleştirme:

• kullanıcının rolü,
• görev frekansı,
• ekran alanı

açısından faydalı olabilir.

Ancak güvenlik gereği görünmesi zorunlu kritik uyarılar kullanıcı tarafından tamamen kaldırılamamalıdır.

Klavye-Öncelikli ve Yoğun İş Uygulamaları

Tüketici web sitesi ile operatör uygulamasının UX hedefi aynı değildir. Saatler boyunca aynı kayıt akışı üzerinde çalışan deneyimli bir kullanıcı için birkaç yüz milisaniyelik gecikme, her kayıtta yeniden konumlanan odak veya kaybolan seçim, tek başına küçük görünse bile vardiya boyunca biriken gerçek bir üretkenlik ve hata maliyetidir.

Deneyimli kullanıcının saatlerce kullandığı sistemde:

• fare hareket mesafesi,
• bağlam değiştirme,
• modal iletişim kutusu açıp kapama,
• tab sırası,
• seçimin korunması,
• kaydırma konumu

önemlidir.

Kısayollar

İyi kısayol:

• görevle ilişkili,
• çakışmasız,
• keşfedilebilir,
• geri alınabilir,
• girdi alanında yanlışlıkla tetiklenmeyen

olmalıdır.

Örnek:

Enter       → seçili kayıtta ana işlem
Esc         → bağlamsal paneli kapat
Ctrl+S      → kaydet
F1 / ?      → kısayol yardımı

Tarayıcı veya işletim sistemi kısayollarını gereksiz yere ele geçirmekten kaçınılmalıdır.

Gezinen tabindex / composite bileşen

Tablo, tablist ve araç çubuğu gibi yoğun bileşik bileşenlerde her alt kontrolü ayrı Tab durağı yapmak yüzlerce sekme durağı üretebilir.

WAI-ARIA kalıpları uygun bileşenlerde:

• bir kez bileşene Tab,
• içeride ok tuşları

yaklaşımını kullanabilir.

Seçim korunması

Kullanıcı listede satır 700'de çalışırken:

• ayrıntıyı kaydetme,
• yan panel açma,
• kısa yenileme

sonrasında ilk satıra atılmamalıdır.

Korunabilecek durum:

• seçili kayıt,
• kaydırma konumu,
• etkin sekme,
• filtre,
• sıralama,
• sütun genişlikleri.

Duyarlı Form ve Tablo Birlikte Tasarlama

Masaüstü formu

Ad                [____________________]
Soyad             [____________________]
E-posta           [____________________]

                         [İptal] [Kaydet]

İki sütun ne zaman?

Yalnız ilişkili ve kısa alanlar:

Başlangıç [____]   Bitiş [____]
İl        [____]   İlçe  [____]

Uzun formu yalnız boşluğu doldurmak için iki sütuna bölmek göz taramasını zorlaştırabilir.

Mobil

Ad
[____________________]

Soyad
[____________________]

E-posta
[____________________]

[Kaydet]

Sabitlenen eylem çubuğu

Uzun mobil formda önemli birincil eylem altta sabitlenebilir.

Dikkat:

• içerik altında kalmamalı,
• sanal klavye ile çakışmamalı,
• odağı örtmemeli,
• güvenli alan payı dikkate alınmalıdır.

Tasarım Karşıt Kalıpları

1. Her şeyi hamburger menüye saklamak

Masaüstünde yeterli alan varken ana gezinmeyi gizlemek keşfedilebilirliği düşürebilir.

2. Placeholder-only form

Kullanıcı yazmaya başladığında etiket kaybolur.

3. Yalnız ikonlu belirsiz eylem

Kullanıcı anlamı tahmin etmeye zorlanır.

4. Yalnız imleç üzerine gelince görünen kritik işlev

Dokunmatik ve klavye kullanıcısı işlevi göremeyebilir.

5. Yalnız renkle gösterilen durum

Renk körlüğü, düşük kontrast veya ekran koşullarında anlam kaybolabilir.

6. Her şeyi modal iletişim kutusuna dönüştürmek

Kullanıcı bağlamı sürekli kesilir.

7. Sonsuz kaydırmalı yönetim ekranı

Kayıt konumu, karşılaştırma ve geri dönüş zorlaşır.

8. Her ekranı karta çevirmek

Yoğun karşılaştırma gerektiren veri görsel olarak şişer.

9. Devre dışı gönderim düğmesi + açıklama yok

Düğme pasiftir ama kullanıcı nedenini anlayamaz.

10. Yinelenen gönderimi yalnız düğmeyi devre dışı bırakarak çözmek

Sunucu yinelenen isteğe hâlâ açık olabilir.

11. Filtre uygulandı ama görünmüyor

Kullanıcı verinin “eksik” olduğunu sanabilir.

12. İskelet ekranın sonsuza kadar kalması

Sunucu tarafı hatası yükleme görünümü içinde gizlenir.

13. Kaydırma konumunu sürekli sıfırlamak

Yoğun iş uygulamasında ciddi verim kaybı yaratır.

14. Masaüstünü büyütülmüş mobil görünüm yapmak

Geniş ekranda aşırı boşluk ve gereksiz kaydırma üretebilir.

15. “Altın oran = doğru UX”

Araştırma bunu desteklemez.

16. “3 tıklama = sınır”

Genel bir ampirik kural değildir.

17. Başarılı şirketi kör kopyalamak

NN/g'nin vurguladığı gibi büyük ve başarılı bir ürün belirli tasarım kusurlarını marka gücü, alışkanlık, trafik veya başka avantajlar sayesinde tolere edebilir. Aynı desen daha küçük veya farklı görevli bir üründe ciddi kayıp üretebilir.

UI Durum Modeli

Her veri bileşeni yalnız “veri var/veri yok” değildir.

Asgari durum makinesi:

BEKLEME
  ↓
YÜKLENİYOR
  ├── BAŞARILI + VERİ
  ├── BAŞARILI + BOŞ
  └── HATA

Değişiklik işlemi:

TEMİZ
  ↓ düzenleme
DEĞİŞTİRİLDİ
  ↓ kaydetme
KAYDEDİLİYOR
  ├── KAYDEDİLDİ
  ├── ÇAKIŞMA
  └── HATA

Bu durumların her birinin UI karşılığı tasarlanmalıdır.

Neden önemlidir?

Aksi durumda:

• boş veri ile hata aynı görünür,
• yükleme bittiği anlaşılmaz,
• kullanıcı kaydedilmediği hâlde sayfadan çıkar,
• çakışma sıradan hata olarak gösterilir,
• yinelenen gönderim tetiklenebilir.

Sürümlü analitik sonuç ve eski bağlam

Analitik ekranlarda "eski veri" yalnız önbellekte kalmış bir satır değildir. Bir bulgu, seçim veya bağlamsal eylem belirli bir veri anlık görüntüsüne ait olabilir. Veri kapsamı değiştiğinde aynı sıra numarası veya aynı görünen kart artık başka bir nesneyi temsil edebilir.

Bu nedenle yapılandırılmış sonuçlar veri sürümüyle ilişkilendirilebilir:

sonuç
├─ veri sürümü
├─ kapsam
├─ bulgular
└─ seçimler

Yeni sürüm geldiğinde eski sonuç bütünüyle silinmek zorunda değildir; karşılaştırma veya kullanıcı hafızası için görünür kalabilir. Ancak eski sonuca bağlı eylem güncel veri üzerinde sessizce çalıştırılmamalıdır. Arayüz eski kapsamı işaretleyebilir ve kullanıcıdan yeni sonuç üzerinde yeniden seçim yapmasını isteyebilir.

Aynı kural clarification ve takip komutları için de geçerlidir. "İkincisini aç", "bunu göster" veya "biraz aç" gibi ifadeler ancak referans verilen bulgu hâlâ güncel veri sürümüne aitse güvenle çözülebilir.

Bu, yalnız state-management ayrıntısı değildir. Sürümlü sonuç ve stale-reference koruması, yoğun analitik arayüzlerde yanlış nesne üzerinde eylem yapılmasını önleyen bir UX güvenlik mekanizmasıdır.

Form ve İşlem Durumları İçin Güvenilir Kalıp

Örnek kayıt düzenleme akışı:

GET kayıt + sürüm
        ↓
formu oluştur
        ↓
kullanıcı düzenler
        ↓
DEĞİŞTİRİLDİ
        ↓
Kaydet tetiklenir
        ↓
yinelenen gönderimi engelle
        ↓
PUT/PATCH + beklenen sürüm
        ↓
sunucu kimlik doğrulama + kapsam + sürüm denetimi yapar
        ├─ uygun     → KAYDEDİLDİ
        ├─ çakışma   → ÇAKIŞMA arayüzü
        └─ hata      → HATA + girilen veriyi koru

Arayüzün görevi yalnız istek atmak değildir; sunucu tarafı durumunu doğru temsil etmektir.

Tasarım Sistemleri

Tasarım sistemi bileşen kitaplığı değildir

Olgun tasarım sistemi:

• tasarım belirteci,
• bileşen,
• kalıp,
• içerik kılavuzu,
• erişilebilirlik davranışı,
• etkileşim durumu,
• duyarlı davranış,
• kod standardı

içerir.

Tasarım belirteci

:root {
    --space-xs: .25rem;
    --space-sm: .5rem;
    --space-md: 1rem;
    --space-lg: 1.5rem;

    --radius-sm: .25rem;
    --radius-md: .5rem;
}

Tasarım belirteci kullanmak görsel değişikliklerin bütün üründe kontrollü yapılmasını sağlar.

Bileşen durumu

Bir düğme yalnız varsayılan durumdan ibaret değildir:

varsayılan
üzerine gelme
odak
etkin
devre dışı
yükleniyor

Girdi:

boş
dolu
odak
geçersiz
devre dışı
salt okunur

Her durum tasarım sözleşmesinin parçasıdır.

Kalıp seviyesi

“Form” tek bir bileşen değildir; kalıptır.

“kullanıcı seçici”, “toplu düzenleme”, “filtre çubuğu”, “sihirbaz”, “komut paleti” gibi yapılar birden çok bileşenin davranış sözleşmesini içerir.

Kullanıcı Alışkanlıkları ve Kas Hafızası

Yoğun kullanılan uygulamada kullanıcı yalnız görmez; hareket dizisi öğrenir. Üretimde uzun süre değişmeden kalan klavye akışlarının zamanla neredeyse düşünmeden uygulanan bir çalışma ritmine dönüştüğünü görmek mümkündür.

Örneğin:

Enter → kayıt aç
Right → sonraki kayıt
Ctrl+S → kaydet

uzun süre kullanıldığında kas hafızasına dönüşür.

Neden küçük değişiklik büyük olabilir?

Bir düğmeyi:

sağ alt → sol üst

taşımak teknik açıdan basitken operasyonel olarak yüzlerce günlük işlemi etkileyebilir.

Bu nedenle üretimde kendini kanıtlamış yoğun sistemde:

yeni özellik eklemek ile mevcut davranışı değiştirmek aynı risk sınıfında değildir.

UX regresyon testi

Yalnız ekran görüntüsü testi yeterli değildir.

Görev senaryosu:

1. Arama yap
2. 17. kaydı seç
3. Klavyeyle 3 kayıt ilerle
4. Detayı değiştir
5. Kaydet
6. Önceki liste konumuna dön

gibi uçtan uca davranışlar doğrulanmalıdır.

Rol ve Kullanıcı Profili Bazlı UX

Aynı sistemde:

• yeni kullanıcı,
• uzman operatör,
• yönetici,
• yalnız okuyucu,
• mobil kullanıcı

aynı ihtiyaçlara sahip değildir.

Aşamalı uzmanlaşma

Yeni kullanıcı:

[Açıklamalı Yeni Kayıt]

Uzman:

Ctrl+N

ile aynı görevi yapabilir.

Uzman kullanıcı görüşü nasıl yorumlanmalıdır?

Uzman kullanıcıların talepleri değerlidir; ancak uzman davranışı otomatik olarak bütün kullanıcıların davranışı değildir. Uzman kişi sistemin terimlerini bilir, kısayollar geliştirmiştir ve seyrek kullanılan ince ayarlara daha fazla değer verebilir.

Bu ayrım iki farklı yanlış sonuca götürmemelidir:

• “Uzman istedi, herkesin ana ekranına ekleyelim.”
• “Genel kullanıcı zorlanır, uzman işlevini kaldıralım.”

Hedef kitle gerçekten uzman operatörlerden oluşuyorsa onların hız, klavye, toplu işlem ve bilgi yoğunluğu ihtiyacı birincil gereksinimdir. Karma kullanıcı kitlesinde ise temel yol görünür ve anlaşılır tutulurken hassas ayarlar, gelişmiş filtreler veya kısayollar ikinci katmanda sunulabilir.

Amaç uzmanlığı cezalandırmadan başlangıç maliyetini düşük tutmaktır.

Rol duyarlı arayüz

Yetkisi olmayan eylem:

• gösterilmeyebilir,
• devre dışı + neden açıklamasıyla sunulabilir

ürün ihtiyacına göre.

Ancak sunucu tarafında yetkilendirme zorunludur.

Riskli yönetici eylemleri

Yönetici ekranında eylem yoğunluğu yüksek olabilir; yıkıcı eylemler:

• görsel olarak ayrılmalı,
• yanlışlıkla birincil eylemin hemen yanına konmamalı,
• kapsam açık gösterilmeli.

Eğitim Platformları İçin UX İlkeleri

LMS ve öğrenci otomasyonunda kullanıcı genellikle “içeriği keşfetmek” yerine belirli görevleri zamanında tamamlamak ister.

Ana sorular:

• Bugün ne yapmalıyım?
• Hangi dersim var?
• Son teslim tarihi ne?
• Notum açıklandı mı?
• Hangi başvurum bekliyor?
• Belgem hazır mı?

Gösterge paneli

İyi akademik gösterge paneli:

Bugün
- 10:00 Ders
- 16:00 Ödev teslimi

Yaklaşan
- Cuma sınavı
- Başvuru son tarihi

Derslerim
- ...

Bildirimler
- ...

Akademik yoğunluk

Öğrenci bilgi sistemlerinde bazı ekranlar doğal olarak veri yoğundur:

• transkript,
• ders seçimi,
• sınav programı,
• ders planı.

Bunları büyük kartlara çevirmek yerine:

• tablo,
• grup başlığı,
• sabitlenen sütun,
• toplamlar,
• açıklayıcı durum

daha verimli olabilir.

İşlem geçmişi

Başvuru/evrak gibi süreçlerde:

Talep Tarihi
Belge Türü
Durum
Son İşlem
İndir / Detay

gibi izlenebilir tablo kullanıcıya güven verir.

UI/UX Ölçümü

“Tasarım güzel görünüyor” ölçüm değildir.

Kullanım kolaylığını ölçülebilir gereksinime dönüştürmek

“Kullanımı kolay” ifadesi tasarım niyetini anlatabilir; ancak tek başına doğrulanabilir bir gereksinim değildir. Kullanılabilirliği mühendislik konusu hâline getirmek için en az şu beş öğe açık olmalıdır:

• kullanıcı grubu: görevi kimin yaptığı,
• görev: hangi sonucun tamamlanacağı,
• kullanım bağlamı: cihaz, çevre, yetki, veri yoğunluğu ve benzeri koşullar,
• ölçüt: neyin gözleneceği,
• karar eşiği: sonucun hangi düzeyde kabul edileceği.

ISO 9241 ailesinde kullanılan kullanılabilirlik çerçevesi; belirli kullanıcıların belirli hedeflere, belirli bir kullanım bağlamında etkililik, verimlilik ve memnuniyet ile ulaşmasını esas alır. Bunlar aynı şey değildir:

• Etkililik, hedefin doğru ve eksiksiz tamamlanıp tamamlanmadığıyla ilgilidir.
• Verimlilik, elde edilen sonuca karşılık harcanan zaman ve çaba gibi kaynakları ele alır.
• Memnuniyet, kullanıcının etkileşime ilişkin algısını ve değerlendirmesini kapsar.

Bu ayrım, “hızlıysa kullanılabilirdir” veya “kullanıcı beğendiyse sorun yoktur” gibi tek boyutlu sonuçları engeller. Bir kullanıcı görevi başarıyla tamamlayabilir ancak gereksiz yere uzun sürede bitirebilir; başka bir akış hızlı olabilir fakat kritik hata üretme riski taşıyabilir.

Ölçülebilir bir kabul tanımı şu biçimde kurulabilir:

Kullanıcı grubu : tanımlı rol / deneyim düzeyi
Görev           : açık başlangıç ve bitiş koşulu
Etkililik       : başarı, eksiksizlik, kritik hata
Verimlilik      : görev süresi, gereksiz adım, yardım gereksinimi
Memnuniyet      : önceden seçilmiş öznel ölçüm
Karar eşiği     : ürünün riskine göre testten önce belirlenmiş hedef

Buradaki eşikler evrensel sayılar değildir. Kritik bir iş uygulaması ile düşük riskli içerik sitesinin hata toleransı aynı olamaz. Önemli olan, hedefi sonuç görüldükten sonra değiştirmek yerine testten önce tanımlamaktır.

Geliştirme amaçlı değerlendirme ile sonuç değerlendirmesini ayırmak

Kullanılabilirlik çalışmasının amacı ölçüm yöntemini belirler. Geliştirme amaçlı değerlendirme (formative evaluation) arayüzde neyin bozuk olduğunu bulup düzeltmeye odaklanır. Sorunun türü, sıklığı, şiddeti, hangi görevde ortaya çıktığı ve kullanıcıyı nasıl etkilediği burada sayısal verilerle birlikte yorumlanabilir.

Sonuç değerlendirmesi (summative evaluation) ise daha çok “hedeflenen kullanılabilirlik düzeyine ulaşıldı mı?” sorusuna cevap verir. İki yaygın düzen vardır:

• referans değere göre değerlendirme: bir sürümün önceden belirlenmiş hedeflerle karşılaştırılması,
• karşılaştırmalı değerlendirme: iki tasarımın, iki sürümün veya iki yöntemin aynı görevler üzerinden karşılaştırılması.

Karşılaştırmada aynı katılımcıların bütün tasarımları denemesi ile farklı katılımcı gruplarının kullanılması farklı deney düzenleridir. Hangi düzen seçilirse seçilsin sıra etkisi, öğrenme etkisi ve katılımcı profili sonuçla birlikte düşünülmelidir.

Katılımcı sayısı ile temsil gücü de aynı kavram değildir. Çok sayıda fakat yanlış kullanıcı profilinden toplanan veri, hedef kullanıcıyı temsil eden daha küçük bir çalışmadan otomatik olarak daha güvenilir değildir. Örneklem büyüklüğü belirsizliği etkiler; temsil gücü ise örneklemin hangi kullanıcı evrenini yansıttığıyla ilgilidir.

Davranış ölçümü ile algı ölçümünü ayırmak

Kullanıcının ne yaptığı ile yaptığı iş hakkında ne düşündüğü birlikte değerlendirilebilir; ancak birbirinin yerine kullanılmamalıdır.

Davranış
- görevi tamamladı mı?
- ne kadar sürdü?
- kaç hata yaptı?
- yardım aldı mı?

Algı
- arayüzü ne kadar kolay buldu?
- kontrol hissi nasıldı?
- etkileşimden ne kadar memnun kaldı?

Sistem Kullanılabilirlik Ölçeği (System Usability Scale, SUS) gibi standartlaştırılmış anketler algılanan kullanılabilirlik için yararlı olabilir. Buna karşılık tek bir anket puanı görev başarısını veya hata güvenliğini kanıtlamaz. Puanın anlamı da mümkün olduğunda uygun bir referans dağılımı, önceki sürüm veya hedef değer ile birlikte yorumlanmalıdır.

Standardın kapsamını doğru okumak

ISO 9241-940:2017, genel web arayüzleri için yazılmış bir standart değildir; dokunsal ve haptik etkileşimlerin değerlendirilmesine odaklanır ve standart klavye/fare gibi bazı giriş aygıtlarını kendi kapsamı dışında bırakır. Bu nedenle haptik aygıta özgü hükümleri web ekranlarına doğrudan normatif kural olarak taşımak doğru olmaz.

Bununla birlikte standardın kullandığı değerlendirme ayrımları önemli bir yöntem dersidir: temsilî kullanıcı ve görevlerle test, uzman incelemesi, performans verisi, kullanıcı bildirimi, etkililik, verimlilik ve memnuniyet aynı değerlendirme planının farklı parçalarıdır. ISO 9241-940 cihaz-özel bir standarddır; genel web kullanılabilirliğine ilişkin hükümler doğrudan bu standardın kapsamından türetilmemelidir.

Görev metrikleri

• görev tamamlama oranı,
• görev süresi,
• hata oranı,
• kurtarma süresi,
• terk oranı.

Etkileşim metrikleri

• arama success,
• sıfır sonuçlu sorgu,
• filtre kullanımı,
• yinelenen tıklama,
• öfke tıklaması,
• geri izleme,
• doğrulama hatası,
• geri alma kullanımı.

Performans

• LCP,
• INP,
• CLS,
• API gecikmesi,
• oluşturma gecikmesi.

Uzman uygulamada ek metrikler

• yalnız klavye completion,
• işlem başına fare tıklaması,
• kayıt başına süre,
• yanlış kayıt üzerinde işlem oranı,
• context switch sayısı.

Belirsizliği görünür kılmak

Kullanılabilirlik ölçümünde gözlenen değer, kullanıcı evreninin kendisi değil örneklemden elde edilen bir tahmindir. Örneğin görev tamamlama oranı:

gözlenen başarı = başarılı görev sayısı / toplam deneme

gibi hesaplanabilir; fakat rapor yalnız bu noktadaki oranla bitmemelidir. Özellikle küçük örneklemlerde aynı gözlenen oran geniş bir belirsizlik aralığına karşılık gelebilir. Bu nedenle başarı oranları uygun bir binom güven aralığıyla, görev süresi gibi sürekli ölçümler ise dağılıma uygun özet ve güven aralığıyla birlikte yorumlanmalıdır.

Görev süresi verileri uç değerler ve sağa çarpıklık içerebilir. Bu nedenle yalnız aritmetik ortalamaya bakmak yerine medyan, dağılım ve seçilen istatistiksel yöntemin varsayımları da dikkate alınmalıdır. Ölçümün amacı sahte hassasiyet üretmek değil, kararın ne kadar belirsizlik taşıdığını görünür kılmaktır.

tek sayı              -> eksik bağlam
nokta tahmini + aralık -> değer + belirsizlik

GOMS ile görev yolunu modellemek

Card, Moran ve Newell'in GOMS yaklaşımı, özellikle deneyimli kullanıcının rutin görevini yalnız ekran görüntüsü olarak değil, hedef ve yöntem yapısı olarak incelemeye imkân verir. GOMS adı dört bileşenden gelir:

• Hedefler (Goals): kullanıcının ulaşmak istediği sonuçlar,
• İşlemler (Operators): yöntemi oluşturan temel fiziksel veya bilişsel adımlar,
• Yöntemler (Methods): aynı hedefe ulaşmak için kullanılabilecek yordamlar,
• Seçim kuralları (Selection Rules): birden fazla yöntem varsa hangisinin hangi koşulda seçileceği.

Örneğin yoğun bir kayıt ekranında aynı hedef için iki yol bulunabilir:

Hedef: belirli kaydı bul ve aç

Yöntem A
Ctrl+K -> kimliği yaz -> Enter

Yöntem B
filtre panelini aç -> alanı seç -> değeri yaz -> uygula -> satırı aç

Seçim kuralı
kimlik biliniyorsa A
kimlik bilinmiyorsa B

Bu model “kaç tıklama var?” sorusundan daha güçlüdür. Çünkü kullanıcının alternatif yolu ne zaman seçtiğini, görevin hangi alt hedeflere ayrıldığını ve optimizasyonun hangi adıma uygulanması gerektiğini görünür hâle getirir.

GOMS'un sınırı da önemlidir. Klasik model en iyi, öğrenilmiş ve büyük ölçüde hatasız rutin davranışta çalışır. Acemi kullanıcının keşif süreci, ciddi hata sonrası problem çözme, beklenmeyen kesintiler veya karmaşık hata kurtarma davranışı aynı doğrulukla açıklanamaz. Bu nedenle GOMS kullanıcı testinin yerine değil, görev analizi ile kullanıcı testi arasındaki mühendislik aracına yerleştirilmelidir.

Tuş Vuruşu Düzeyi Modeli ile etkileşim maliyetini tahmin etmek

Tuş Vuruşu Düzeyi Modeli (Keystroke-Level Model, KLM), GOMS ailesinin uzman kullanıcının iyi öğrenilmiş bir yöntemi uygulama süresini tahmin etmeye yönelik daha düşük seviyeli modelidir. Web uygulamasında yararlı olabilecek temel işlem türleri şöyle düşünülebilir:

• K: tuş veya düğme etkinleştirme,
• P: işaretçiyle hedefe yönelme,
• H: elin klavye, fare veya başka giriş aygıtı arasında taşınması,
• M: sonraki fiziksel eylem için zihinsel hazırlık,
• R: sistem yanıtını bekleme,
• D: gerektiğinde çizme veya sürekli işaretçi hareketi.

Sembolik toplam:

T_tahmin = nK*tK + nP*tP + nH*tH + nM*tM + sum(tR) + sum(tD)

şeklinde kurulabilir. Burada asıl değer tarihsel deneylerden alınmış sabit süreleri modern sisteme körlemesine taşımak değildir. Kullanıcı grubu, giriş aygıtı ve uygulama gecikmesi farklıysa süreler ölçülmeli veya yerel veriye göre kalibre edilmelidir.

Bu ayrıştırma iki önemli tasarım hatasını önler.

Birincisi, tıklama sayısı görev maliyeti değildir. Daha az tıklama, daha fazla işaretleme, zihinsel hazırlık veya aygıt değiştirme gerektiriyorsa gerçekten daha hızlı olmayabilir.

İkincisi, sistem gecikmesi R ile görev süresinin içindedir. İki adımlı fakat her adımda yavaş sunucu turu yapan bir yol, dört yerel etkileşimli yoldan daha pahalı olabilir. Böylece istemci tasarımı ile sunucu gecikmesi aynı kullanıcı görevinin bütçesinde buluşur.

İki alternatif akış sayısal sabit verilmeden bile karşılaştırılabilir:

Akış A = M + P + K + R + M + P + K
Akış B = M + K + K + R

Gerçek karar için ilgili işlem süreleri ölçülür; ardından tahmin kullanıcı testiyle doğrulanır. Model, tasarım seçeneğini üretim öncesinde elemek veya neden yavaş olduğunu açıklamak için yararlıdır; gerçek kullanıcı verisinin yerine geçmez.

Kullanılabilirlik testi

Az sayıda kullanıcıyla yapılan test bütün kullanıcı evrenini kanıtlamaz; küçük testler yine de erken ve ciddi kusurları yakalayabilir.

Daha güçlü süreç:

heuristic review
      ↓
prototype test
      ↓
görev temelli kullanılabilirlik testi
      ↓
üretim telemetrisi
      ↓
saha geri bildirimi
      ↓
iteration

Ünite 5: Kabul Ölçütleri, Kontrol Listeleri ve Sadelik

Duyarlı Tasarım ve Erişilebilirlik Kabul Matrisi

Bir ekran “duyarlı” diye yalnız Chrome DevTools'ta telefon ön ayarıyla doğrulanmamalıdır.

Görsel

• 320 CSS px'de ana görev tamamlanıyor mu?
• %200 yakınlaştırmada içerik kayboluyor mu?
• metin kesiliyor mu?
• araç çubuğu üst üste biniyor mu?
• sabitlenen başlık odağı kapatıyor mu?
• yatay görünüm çalışıyor mu?

Klavye

• Tab sırası mantıklı mı?
• odak görünür mü?
• modal iletişim kutusunda odak tuzağı doğru mu?
• Escape çalışıyor mu?
• tablist arrow gezinme doğru mu?

Dokunmatik

• hedefler yeterli mi?
• yalnız üzerine gelmeyle işlev var mı?
• yanlış dokunma riski yüksek mi?
• yalnız bir hedefin boyutu değil, komşu hedeflerle aralığı da güvenli mi?
• parmak hedefi örttüğünde seçimin gerçekleştiği yine anlaşılabiliyor mu?
• sık kullanılan eylemler farklı tutuş ve yönelimlerde erişilebilir mi?
• kritik veya geri alınması zor eylemler yanlış dokunmaya karşı yeterince ayrıştırılmış mı?
• dokunma ile seçilen kontrolün durumu temas sonrasında görünür kalıyor mu?
• uzun basma, sürükleme veya çoklu dokunma temel işlevin tek erişim yolu mu?
• aynı görev fare/dokunmatik yüzey ve klavyeyle de tamamlanabiliyor mu?
• işletim sistemi veya tarayıcı kenar hareketleriyle uygulama hareketleri çakışıyor mu?
• ekran yönü değiştiğinde hedeflerin sırası ve anlamı korunuyor mu?
• sabit terminal veya stand kullanımı, elde kullanılan tablet varsayımlarıyla yanlışlıkla aynı mı ele alınıyor?

Ekran okuyucu

• heading yapısı doğru mu?
• form etiketleri bağlı mı?
• table üst çubuk ilişkileri doğru mu?
• durum değişiklikleri gerektiğinde duyuruluyor mu?

Performans ve ağ

• yüksek gecikme simülasyonunda yükleme durum var mı?
• istek gereksiz tekrarlanıyor mu?
• eski istek yeni sonucu eziyor mu?
• yinelenen gönderim yinelenen değişiklik işlemi üretebilir mi?

Bir Web Uygulaması İçin Önerilen Temel Yerleşim

Masaüstünde yoğun iş uygulaması

┌──────────────────────────────────────────────────────────────────────┐
│ Logo / Ürün        Genel Arama             ?   🔔   Kullanıcı ▾   │
├───────────────┬──────────────────────────────────────────────────────┤
│ Birincil menü │ Gezinti yolu / Konum                                 │
│               │ Sayfa Başlığı                  Birincil Eylem       │
│ Gösterge Paneli │                                                      │
│ Kayıtlar      │ Arama / Filtre / Araç Çubuğu                           │
│ Raporlar      │                                                      │
│ Yönetim       │ Ana çalışma alanı                                   │
│               │                                                      │
│               │                                                      │
└───────────────┴──────────────────────────────────────────────────────┘

Mobil

┌───────────────────────────┐
│ ←  Sayfa Başlığı      ⋯   │
├───────────────────────────┤
│ [ Arama.................] │
│ [Filtre 2]                │
│                           │
│ Ana içerik                │
│                           │
├───────────────────────────┤
│ Ana  Kayıt  Görev  Profil │
└───────────────────────────┘

Bu şema ürün gereksinimi değil, yerleşik konvansiyonlardan türetilmiş başlangıç noktasıdır.

Bir Veri Tablosu İçin Kontrol Listesi

Yapı

• [ ] Tablo başlığı görevi açıklıyor.
• [ ] Toplam/sonuç kapsamı görünür.
• [ ] Arama gerekiyorsa görünür.
• [ ] Aktif filtreler görünür.
• [ ] Sıralama yönü görünür.
• [ ] Kolon adları belirsiz değil.
• [ ] Sayısal değerler karşılaştırılabilir hizalı.
• [ ] Tarih formatı tutarlı.
• [ ] Durum yalnız renkle anlatılmıyor.
• [ ] Boş/yükleme/hata birbirinden ayrı.

Etkileşim

• [ ] Satır seçimi görünür.
• [ ] Çoklu seçim varsa kapsam net.
• [ ] Toplu işlem yalnız seçim varken görünür/aktif.
• [ ] Yıkıcı eylem ayrılmış.
• [ ] Sayfalama/kaydırma modeli göreve uygun.
• [ ] Yenileme seçimi gereksiz yere sıfırlamıyor.
• [ ] Klavye davranışı tanımlı.

Duyarlı

• [ ] En önemli kolonlar dar ekranda kalıyor.
• [ ] Yatay kaydırma varsa kullanıcı bunu anlayabiliyor.
• [ ] Satır eylemleri erişilebilir.
• [ ] Üst çubuk ve ilk sütun sabitlenmişse ise çakışma yok.
• [ ] %200 yakınlaştırma test edildi.

Bir Form İçin Kontrol Listesi

• [ ] Her alan gerçekten gerekli.
• [ ] Bilinen veri tekrar sorulmuyor.
• [ ] Etiket kalıcı.
• [ ] Placeholder yalnız örnek/ipucu.
• [ ] Zorunlu/isteğe bağlı alanlar anlaşılır.
• [ ] Alan sırası doğal.
• [ ] Girdi türü uygun.
• [ ] Otomatik tamamlama düşünülmüş.
• [ ] Yardım metni hata oluşmadan önce mevcut.
• [ ] İstemci ve sunucu doğrulaması ayrılmış.
• [ ] Hata mesajı neyin nasıl düzeltileceğini söylüyor.
• [ ] Hata olduğunda girilmiş veriler kaybolmuyor.
• [ ] Gönderim yinelenen isteğe karşı korunuyor.
• [ ] Sunucu tarafındaki değişiklik işlemi yinelenen isteğe karşı korunuyor.
• [ ] Başarılı sonuç görünür.
• [ ] Kaydedilmemiş değişikliklerin kaybı değerlendirildi.
• [ ] Klavye-only çalışıyor.
• [ ] Mobil klavye içeriği kapatmıyor.

Sihirbaz İçin Kontrol Listesi

• [ ] Gerçekten çok adımlı görev var.
• [ ] Tek forma sığdırmak daha iyi değil.
• [ ] Adım başlıkları anlamlı.
• [ ] İlerleme görünür.
• [ ] Geri adımı veri kaybetmiyor.
• [ ] Atla seçeneği yalnız gerçekten isteğe bağlı adımda.
• [ ] Kullanıcı kilitli adımın neden kilitli olduğunu anlıyor.
• [ ] Son gözden geçirme adımı var.
• [ ] Değişikliğin ne zaman gerçekleştiği açık.
• [ ] Uzun süreçte devam etme/taslak davranışı düşünülmüş.
• [ ] Uzman kullanıcı gereksiz yere yavaşlatılmıyor.

Uygulama Üst Çubuğu İçin Kontrol Listesi

• [ ] LTR web arayüzünde marka/ana sayfa bağlantısı başlangıç tarafında ve ana sayfaya dönüyor.
• [ ] Birincil gezinme görünür veya göreve uygun yan menüde.
• [ ] Yardımcı eylemler birincil gezinme ile karışmıyor.
• [ ] Hesap/profil tutarlı bir yardımcı alanın bitiş tarafında.
• [ ] Arama ürün için kritikse görünür.
• [ ] Yardım erişilebilir.
• [ ] Bildirim rozeti yalnız anlamlı olayda kullanılıyor.
• [ ] Mobilde kritik hedef bölüm kaybolmuyor.
• [ ] Üst çubuk ekranın aşırı bölümünü kaplamıyor.
• [ ] Odak sabitlenen başlık altında gizlenmiyor.

Tasarım Kararlarında Kanıt Hiyerarşisi

Bir kararı değerlendirirken şu sıra yararlıdır:

1. Veri bütünlüğü / güvenlik
2. Normatif erişilebilirlik
3. Görev doğruluğu
4. Gerçek kullanıcı araştırması
5. Ürün telemetrisi
6. Yerleşik platform konvansiyonu
7. Tasarım sistemi
8. Estetik tercih
9. Trend

Örneğin:

“Altın oran daha güzel.”

ile:

“320 CSS px yeniden akışta işlem tamamlanamıyor.”

aynı ağırlıkta değildir.

Benzer biçimde:

“Bu araç çubuğu daha modern görünüyor.”

argümanı:

“Deneyimli kullanıcı aynı görevi artık 4 yerine 11 etkileşimde tamamlıyor.”

sonucunu geçersiz kılamaz.

Büyük Ölçekli Sistemlerden Alınması Gereken Asıl Ders

Facebook, X, Amazon, Trendyol, Hepsiburada, Canvas veya Moodle'ın değeri belirli bir piksel yerleşiminde değildir.

Asıl tekrar eden ilkeler:

1. Bilgi mimarisini kullanıcı görevlerine göre kur.
2. Sık kullanılan yolu kısalt.
3. Kullanıcının kaldığı yerden devam etmesini sağla.
4. Aramayı gerçek bir keşif sistemi olarak ele al.
5. Masaüstünde ve mobilde aynı görevi, ortama uygun farklı yerleşimlerle destekle.
6. Kullanıcının sistem durumunu görmesini sağla.
7. Erişilebilirliği bileşen sonrası eklenen katman yapma.
8. Geri dönüşü olmayan işlemlerde güvenlik ve veri bütünlüğünü UX'in önüne koy.
9. Yoğun kullanıcıların kas hafızasını koru.
10. Yeni deseni görev testi veya ölçüm olmadan yalnız moda olduğu için uygulama.
11. İşlevi gizlemek ile sadeleştirmeyi karıştırma.
12. Gerçek kullanımı ölç.

Zen Yaklaşımı — Sadelik Boşluk Değil, Gereksiz Yükün Yokluğudur

Zen yaklaşımını web arayüzüne uygularken ilk hata, sadeliği yalnız beyaz alan ve az sayıda bileşenle eşitlemektir. Karmaşık bir iş uygulaması yüzlerce gerçek iş kuralını, kayıt tipini veya eylemi barındırabilir. Bunları görsel olarak ortadan kaldırmak sistemi sadeleştirmez; yalnız karmaşıklığı kullanıcıdan saklar ve çoğu zaman yanlış yere taşır.

Simple and Usable, Designing Interfaces, The Design of Everyday Things ve Don't Make Me Think aynı tasarım ilkesine farklı açılardan yaklaşır: arayüzün amacı kendisini sergilemek değil, kullanıcının amacına ulaşmasını kolaylaştırmaktır.

Zen ekseninde iyi arayüz şu soruyu tekrar tekrar sorar:

Kullanıcının gerçekten yapmak istediği iş nedir ve bu ekran o işin önünde hangi gereksiz yükleri oluşturuyor?

Bu yükler yalnız görsel değildir:

• gereksiz karar,
• tekrar girilen veri,
• anlamsız onay,
• kaybolan seçim,
• her seferinde yeniden açılan filtre,
• beklerken hiçbir geri bildirim verilmemesi,
• kullanıcının hatırlamak zorunda bırakıldığı kod,
• sürekli değişen düğme konumu,
• aynı işi iki farklı ekranda iki farklı biçimde yapma,
• gereksiz ağ isteği,
• yanlış hata mesajı,
• geri alınamayan küçük işlem,
• yalnız sistemin iç mimarisini yansıtan menü.

Sadelik ile eksiltme aynı şey değildir

Sadeleştirme için dört farklı müdahale sınıfı düşünülebilir:

1. Kaldır: Gerçek göreve katkısı olmayan işlevi veya bilgiyi çıkar.
2. Düzenle: Gerekli karmaşıklığı anlaşılır gruplara ayır.
3. Gizle: Seyrek kullanılan fakat gerekli özellikleri doğru ipuçlarıyla ikinci katmana taşı.
4. Yer değiştir: Bir işi daha uygun cihaz, zaman, katman veya otomasyon üzerine taşı.

Bu dört strateji Simple and Usable içinde açık biçimde ayrıştırılır. Kritik nokta, “gizle” seçeneğinin “kaldır” ile karıştırılmamasıdır.

Sadelik bir estetik değil, karmaşıklık yönetimidir

Sadelik düşüncesi farklı tasarım geleneklerinde benzer bir noktaya ulaşır. Dieter Rams'ın ilkeleri ürünün anlaşılır, kullanışlı, gösterişsiz, dürüst ve ayrıntıda tutarlı olmasına vurgu yapar. Bunlar erişilebilirlik standardı veya deneysel yasa değildir; tasarım kararını sorgulamak için kullanılan tarihsel ölçütlerdir.

John Maeda sadeliği yalnız özellik eksiltme olarak ele almaz. Azaltma kadar düzenleme, zaman, öğrenme, bağlam ve basitleştirilemeyen durumların kabulü de önemlidir. Bu yaklaşım, “daha az öğe = daha iyi arayüz” eşitliğinin neden yetersiz olduğunu açıklar.

Giles Colborne'un kaldırma, düzenleme, gizleme ve yer değiştirme stratejileri bu düşünceyi arayüz kararına dönüştürür. Norman'ın kavramsal model ve sistem imgesi yaklaşımı ise sınırı gösterir: karmaşıklık gizlenirken sistemin nasıl davranacağını anlamak için gerekli ipuçları da kaybolursa görünüş sadeleşir, deneyim karmaşıklaşır.

Bu nedenle sadelik dört farklı karmaşıklık türü üzerinden düşünülebilir:

1. Gereksiz karmaşıklık: Gerçek göreve katkısı yoktur; kaldırılmalıdır.
2. Sunumsal karmaşıklık: Bilgi gereklidir fakat aynı anda görünmesi gerekmez; düzenlenebilir veya gerektiğinde gösterilebilir.
3. Teknik karmaşıklık: Kullanıcının görevi değildir; uygun katmanda sistem tarafından üstlenilmelidir.
4. Alan karmaşıklığı: İşin doğasında vardır; yokmuş gibi davranmak yerine doğru kavramsal modelle anlaşılır biçimde temsil edilmelidir.

Örneğin veritabanı yeniden deneme stratejisini kullanıcıya seçtirmek teknik karmaşıklığı yanlış katmana taşır. Buna karşılık adli bir kaydın farklı kaynaklardan gelen çelişkili zaman bilgisini tek değere indirgemek alan karmaşıklığını tehlikeli biçimde yok edebilir.

Minimalizm bu nedenle boş ekran üretmek değil, karmaşıklığı doğru yerde tutmak işidir.

Sessiz arayüz

Sessiz arayüz hiçbir şey söylemeyen arayüz değildir. Tam tersine yalnız gerektiği kadar konuşur.

Örnek:

Kaydediliyor…
Kaydedildi

yeterliyken:

BAŞARILI!
İŞLEMİNİZ BAŞARIYLA GERÇEKLEŞTİRİLMİŞTİR!!!
[OK]

gereksiz dikkat tüketir.

Ama kritik bir kayıt gerçekten kaydedilemediyse yalnız küçük ve kaybolan bir geçici bildirim göstermek de aşırı sessizliktir.

Az bileşen ≠ sade sistem
Az karar + açık bağlam + kararlı davranış + düşük hata maliyeti = sade deneyim

Ünite 6: İnsan Faktörleri, Bilişsel Yük ve Etkileşim Psikolojisi

Kullanıcının Hedefi — Arayüz Amaç Değil, Araçtır

Designing Interfaces kullanıcının arayüzü kullanma nedenini, arayüz tasarımının başlangıç noktası olarak ele alır. Kullanıcı bir butona basmak, tablo görmek veya form doldurmak istemez. Kullanıcı:

• bir kaydı bulmak,
• bir işi tamamlamak,
• bir şeyi karşılaştırmak,
• bir sonuç üretmek,
• bir durumu doğrulamak,
• bir başvuruyu sonuçlandırmak

ister.

“Neden?” sorusunu sürdürmek

Bir özellik talebi:

Buraya hızlı filtre ekleyelim.

şeklinde geldiğinde gerçek ihtiyaç şu olabilir:

Neden hızlı filtre?
→ Çünkü kullanıcı her sabah aynı üç kapsamı seçiyor.

Neden her sabah seçiyor?
→ Çünkü ekran son çalışma bağlamını korumuyor.

Gerçek problem:
→ Filtre eksikliği değil, tekrar eden bağlam kaybı.

İlk talebi doğrudan uygulamak yerine kök görevi anlamak daha sade çözüm üretebilir.

Araştırma pazarlama araştırması değildir

Kullanıcıya:

Bu özelliği ister misiniz?

diye sormak tek başına yeterli değildir.

Daha değerli sorular:

• Bu işi bugün nasıl yapıyorsunuz?
• En sık nerede duruyorsunuz?
• Hangi bilgiyi başka yerden kopyalıyorsunuz?
• Hangi adımı atlamaktan korkuyorsunuz?
• Hangi işlemi tekrar tekrar yapıyorsunuz?
• Hangi ekranda geri dönmek zorunda kalıyorsunuz?
• Hangi hata sizi en fazla uğraştırıyor?

Doğrudan gözlem

Özellikle uzman operatör sistemlerinde kullanıcı davranışı, beyan edilenden farklı olabilir.

Kullanıcı:

Mouse kullanıyorum.

diyebilir; fakat gözlemde:

Enter → Right → Right → Ctrl+S → Down

gibi bir kas hafızası akışı görülebilir.

Bu davranış üretimde yıllarca oluşmuşsa, görsel olarak “modernleştirmek” adına değiştirmek ciddi UX regresyonu yaratabilir.

Tasarımın merkezi ekran değil, görevdir. Bir bileşen ancak görevi ilerlettiği ölçüde değerlidir.

Problem tanımını erken dondurmamak

İnsan merkezli tasarımda ilk özellik talebi her zaman gerçek problem tanımı değildir. Kullanıcılar yaşadıkları güçlüğü doğru fark etmeyebilir veya çözümü kendi mevcut çalışma biçimlerine göre tarif edebilir.

Bu nedenle erken aşamada:

1. görevi gözle,
2. sürtünmenin nerede oluştuğunu belirle,
3. birden fazla küçük çözüm dene,
4. davranışı gözlemle,
5. problem tanımını gerektiğinde düzelt.

Bu çevrim, “kullanıcı ne istediğini bilmiyor” varsayımına dayanmaz. Tam tersine kullanıcı iş alanını bilir; tasarım ekibinin görevi beyan edilen çözüm ile gerçek görev arasındaki farkı anlamaktır.

Özellikle uzun yaşayan üretim sistemlerinde doğrudan yeniden tasarım yerine küçük, geri alınabilir ve ölçülebilir değişiklikler daha güvenlidir. Görsel olarak daha yeni görünen ilk çözüm, görev akışını gerçekten iyileştiren çözüm olmayabilir.

Güvenli Keşif — Kullanıcı Denemekten Korkmamalıdır

Designing Interfaces içindeki Güvenli Keşif (Safe Exploration) deseni, kullanıcının arayüzü öğrenebilmesi için deneme maliyetinin düşük olması gerektiğini vurgular.

Kullanıcı:

• yanlış sekmeye girebilmeli,
• filtre deneyebilmeli,
• görünümü değiştirebilmeli,
• geçici seçim yapabilmeli,
• mümkünse işlemi geri alabilmeli

ve bunların çoğunda veri kaybı yaşamamalıdır.

Güvenli keşfin ön koşulları

1. Sistem durumu görünürdür.
2. Geri dönüş yolu vardır.
3. Destructive eylem normal gezinmeden ayrılır.
4. Geçici seçim ile kalıcı değişiklik işlemi birbirinden anlaşılırdır.
5. Kullanıcının form verisi gereksiz yere silinmez.
6. Undo mümkün değilse sonuç önceden açıkça belirtilir.

Önizleme

Yüksek etkili işlemde doğrudan değişiklik işlemi yerine:

Kapsamı seç
   ↓
Önizleme
   ↓
Etkilenecek 37 kayıt
   ↓
Onay
   ↓
Değişiklik

deseni güvenliği artırabilir.

Bu yaklaşım her küçük işleme onay eklemek değildir. Ama kapsamı önceden görmek, özellikle toplu işlemlerde kullanıcının zihinsel modelini sistemin gerçek etkisiyle hizalar.

Undo ile onay arasındaki fark

Onay kullanıcıdan geleceği tahmin etmesini ister.

Undo ise kullanıcıya gerçekleşen sonucu görüp geri dönme imkânı verir.

Geri alınabilir düşük riskli işlemde:

Arşivlendi. [Geri Al]

çoğu zaman:

Arşivlemek istediğinizden emin misiniz?

sorusundan daha akıcıdır.

Güvenli keşif ve güvenlik

Yetki, para, resmî veri, kalıcı silme veya adli kayıt gibi alanlarda “deneme serbestliği” veri güvenliğinin önüne geçemez. Burada güvenli keşif, işlemi kolay geri alma değil; işlemin kapsamını açıkça anlama ve yanlış eylemi başlamadan önleme şeklinde uygulanabilir.

Kullanıcıya hareket alanı verin; fakat uçurumun kenarına görünmez bir yol çizmeyin.

Satisficing, Uzmanlaşma ve “Yeterince İyi” Yol

İnsanlar çoğu arayüzde teorik olarak en iyi yolu aramaz. İşlerini tamamlayacak ilk yeterli yolu bulur ve tekrar kullanır. Bu davranış satisficing olarak ele alınır.

Yapay Zekâ Arayüzlerinde Kullanılabilirlik ve İnsan Denetimi

Yapay zekâ kullanan bir arayüzde temel UI/UX ilkeleri değişmez; ancak sistemin çıktısı deterministik bir iş kuralı yerine olasılıksal veya üretken olduğunda yeni bir durum ortaya çıkar. Kullanıcı yalnız arayüzü değil, çıktının belirsizliğini ve sistemin kontrol sınırını da anlamak zorundadır.

İlk ilke model çıktısı ile sistem gerçeğini ayırmaktır. Bir öneri, özet veya sınıflandırma kullanıcıya kesin kayıt gibi sunulmamalıdır. Arayüz; çıktının model tarafından üretildiğini, düzenlenebilir olup olmadığını ve hangi eylemin gerçek sisteme yazılacağını açık hale getirmelidir. Özellikle yüksek etkili işlemlerde “gösterilen bilgi” ile “uygulanmış işlem” görsel ve etkileşimsel olarak ayrılmalıdır.

Belirsizlik göstermek de yalnız yüzde yazmak değildir. Bir modelin 0.82 skoru gerçek dünya olasılığı gibi yorumlanamaz; model kalibre edilmemiş olabilir. Kullanıcı için daha yararlı tasarım bazen güven aralığı yerine alternatifleri, dayanak veriyi veya “insan incelemesi gerekli” durumunu göstermektir. UX katmanı model metriğini anlamını aşacak biçimde kesinlik göstergesine çevirmemelidir.

AI işlemleri gecikmeli olabilir. Kullanıcı beklerken sistemin durumu görünür olmalı; aynı işlemi tekrar tekrar başlatmaya zorlayan belirsiz yükleme davranışı yinelenen işlem üretebilir. İptal, yeniden deneme ve zaman aşımı politikaları arayüz davranışının parçasıdır. Akışlı çıktı (streaming) kullanılıyorsa “ilk belirteç (token) hızlı geldi” ile “iş tamamlandı” durumları ayrılmalıdır.

Üretken sistemlerde düzenleme akışı önemlidir:

öneri
↓
insan incelemesi
↓
düzeltme
↓
onay
↓
kalıcı işlem

Bu zincirde geri alma ve köken bilgisi özellikle değerlidir. Kullanıcı hangi kısmın sistem tarafından üretildiğini ve hangi kısmın insan tarafından değiştirildiğini gerektiğinde ayırt edebilmelidir. Her üründe ayrıntılı denetim arayüzü gerekmez; fakat kritik kararın kaynağı belirsiz olmamalıdır.

Model hatası için de sade bir geri dönüş tasarlanmalıdır. “Bir şeyler ters gitti” mesajı, kullanıcının ne yapacağını bilmiyorsa yetersizdir. Model kullanılamadığında görev model olmadan sürdürülebiliyorsa klasik iş akışı erişilebilir kalmalıdır. AI özelliğinin hata vermesi bütün ürünün kullanılamaz hale gelmesine yol açmamalıdır.

Otomasyon yanlılığı (automation bias) başka bir tasarım riskidir. Sistem çıktısını yüksek görsel vurgu, önceden seçilmiş seçenek veya tek öneri biçiminde sunmak kullanıcının gereğinden fazla güvenmesine neden olabilir. Buna karşılık sürekli uyarı göstermek de alarm yorgunluğu yaratır. Doğru arayüz, insanın gerçekten karar vermesi gereken noktayı korur.

Yapay zekâ arayüzü için özel bir estetik gerekmez. Asıl gereksinim durum, kaynak, belirsizlik, kontrol ve geri dönüşün görünür olmasıdır. Böylece AI, arayüze eklenmiş ayrı bir gösteri unsuru değil; mevcut görev akışında sınırları anlaşılır bir araç olarak kalır.

Sonuç

Bir işlev:

• daha kısa,
• daha hızlı,
• daha güçlü

olsa bile kullanıcı onu keşfetmeyebilir.

Çünkü mevcut yol:

çalışıyor
öğrenilmiş
risksiz

olarak algılanır.

Yeni kullanıcı ile uzman kullanıcı aynı değildir

Yeni kullanıcı için:

• açık etiket,
• açıklama,
• yönlendirme,
• sihirbaz,
• görünür birincil eylem

değerli olabilir.

Uzman kullanıcı için:

• klavye kısayolu,
• toplu işlem,
• hızlı filtre,
• son kullanılan,
• kaydedilmiş görünüm,
• doğrudan gezinme

daha değerlidir.

Aynı ürün iki seviyeyi birlikte destekleyebilir:

Yeni kullanıcı:
[Görünür Kaydet düğmesi]

Uzman:
Ctrl+S

Aşamalı uzmanlaşma

Arayüz başlangıçta öğrenilebilir kalırken kullanıcı zamanla daha hızlı yollar keşfedebilmelidir.

Bu nedenle “kolay” ile “hızlı” birbirine karşıt olmak zorunda değildir.

Satisficing ve değişiklik riski

Kullanıcı yıllardır belirli bir yolu kullanıyorsa:

A → B → C

yeni tasarım:

A → X → C

bir tıklama azaltsa bile öğrenilmiş davranışı kırabilir.

Kazanç ölçülmeden yalnız teorik adım sayısına bakmak yeterli değildir.

Kullanıcıya en kısa yolu zorla öğretmeyin. Bildiği yolu güvenli bırakın; daha iyi yolu keşfedilebilir kılın.

Ertelenmiş Seçimler ve Aşamalı Gösterim

İnsanların her kararı işin başında vermesi gerekmez. Designing Interfaces içindeki Ertelenmiş Seçimler ve Aşamalı Gösterim desenleri, gereksiz erken kararların ertelenmesini destekler.

Erken karar yükü

Kötü başlangıç ekranı:

Çıktı biçimi
Kodlama
İleri seçenek
Sıkıştırma
Önbellek
Sıralama
Görünüm
Tema
Detay seviyesi
...
[Başla]

Kullanıcı daha ne yapacağını görmeden teknik seçeneklere zorlanır.

Daha iyi:

Ne yapmak istiyorsunuz?
[Dosyayı Aç]

Gerekirse sonra:

[Gelişmiş seçenekler]

Aşamalı gösterimin üç koşulu

Bir özelliği gizlemek için:

1. Seyrek kullanılıyor olmalıdır.
2. Ana görevi engellememelidir.
3. Kullanıcı gerektiğinde onu bulabilmelidir.

“Bulunabilirlik” yoksa aşamalı gösterim değil, özellik kaybı oluşur.

Aşamalı açımlama

Sihirbaz içinde bilgiler yalnız ilgili aşamada gösterilebilir.

1. Kapsam
2. Parametreler
3. Kontrol
4. Onay

Burada kullanıcı aynı anda bütün seçenekleri görmek zorunda değildir.

Gelişmiş ayarların tehlikesi

Kullanıcının her gün kullandığı ayarı:

Gelişmiş > Diğer > Daha Fazla > Seçenekler

altına taşımak sadelik değildir.

Sıklık ve görev önemi birlikte değerlendirilmelidir.

Doğru anda gereken kadar bilgi. Ne erken, ne geç.

Alışkanlık, Mekânsal Hafıza ve Kararlı Yerleşim

Designing Interfaces alışkanlık (alışkanlık geliştirme) ve mekânsal hafızayı (mekânsal hafıza) arayüz tasarımında önemli davranış kalıpları olarak ele alır.

Kullanıcı zamanla yalnız ikonun anlamını değil, konumunu da öğrenir. Bu nedenle çalışan bir operasyon ekranında birkaç piksellik kozmetik düzenleme ile iş akışını değiştiren mekânsal müdahaleyi aynı risk sınıfında görmemek gerekir.

Örneğin:

Sol üst → ana gezinme
Sağ üst → hesap/yardımcı işlevler
Tablonun sağ uç sütunu → satır işlemleri
Alt sağ → birincil form eylemi

gibi yerleşimler kas hafızası üretir.

Yer değiştirmenin gizli maliyeti

Bir butonu yalnız görsel gerekçeyle taşımak:

• fare hareket mesafesi süresini,
• göz taramasını,
• hata oranını,
• alışkanlık kırılmasını

etkileyebilir.

Dinamik yerleşim riski

Kullanıcı tam tıklayacakken yeni içerik girip düğmeyi kaydırıyorsa yalnız CLS problemi değil, motor hafıza problemi oluşur.

Kayıt seçiminde süreklilik

Yoğun ızgara uygulamasında:

satır 812 seçili
→ detay aç
→ kaydet
→ ızgara yenilenir
→ satır 1'e dön

davranışı kullanıcı bağlamını yok eder.

Mümkün olduğunda:

• selected key,
• kaydırma konumu,
• etkin sekme,
• odak,
• filtre,
• sıralama

korunmalıdır.

Değişiklik sırasında süreklilik

Akış İçinde Değişiklik yaklaşımı, kullanıcının görevin ortasında fikir değiştirebileceğini veya bağlam değiştirebileceğini kabul eder.

Arayüz:

• geri dönmeye,
• alanı değiştirmeye,
• filtreyi revize etmeye,
• başka kayda bakıp geri gelmeye

dayanıklı olmalıdır.

Kararlılık görünmez bir kullanılabilirlik özelliğidir. Kullanıcı bir şeyi öğrendiyse, değişiklik için gerçek gerekçe olmalıdır.

Dikkat, Çalışma Belleği ve Bilişsel Bütçe

100 Things Every Designer Needs to Know About People, Design for How People Think ve Laws of UX kaynakları, tasarımın yalnız gözle değil sınırlı dikkat ve bellek kaynaklarıyla kullanıldığını vurgular.

Kullanıcı her şeyi görmez

Ekranda bulunan bir şeyin görülmesi garanti değildir.

Özellikle:

• reklam benzeri sağ kolon,
• yoğun araç çubuğu içindeki küçük ikon,
• renk olarak arka plana karışan durum,
• fold altındaki kritik bilgi

gözden kaçabilir.

Çalışma belleği dışarı taşınmalıdır

Kullanıcıya:

Önceki sayfadaki kodu hatırla
→ bu sayfaya yaz

demek yerine:

Seçili kayıt: 10428 — ...

bağlamı ekranda tutmak daha güvenlidir.

Gruplama

Uzun bilgi dizileri anlamlı gruplara ayrılmalıdır.

Kötü:

30 alan tek form

Daha iyi:

Kimlik
İletişim
Yetki
Geçerlilik

Ancak yalnız görsel kart eklemek gerçek gruplama değildir. Gruplar kullanıcı zihnindeki anlamla uyumlu olmalıdır.

Hick ilkesi

Seçenek sayısı ve seçim karmaşıklığı arttıkça karar süresi de artabilir. Bu durum:

• menü,
• kategori,
• filtre,
• başlangıç eylemleri

için önemlidir.

Çözüm her zaman seçenek azaltmak değildir. İyi gruplama ve arama, geniş seçenek uzayını yönetebilir.

Miller sayısı yanlış kullanılmamalıdır

“İnsan yalnız 7 ± 2 öğe hatırlar, menüde en fazla 7 seçenek olmalı” şeklindeki mekanik yorum güvenilir bir UI kuralı değildir.

Menü tasarımında:

• tanıma,
• kategorileştirme,
• görsel tarama

çalışma belleği ezber görevinden farklıdır.

Kullanıcının belleğini veri deposu, dikkatini sınırsız işlemci gibi kullanmayın.

Eylem Olanağı, İşaretleyici, Eşleme, Kısıt ve Kavramsal Model

Don Norman'ın tasarım yaklaşımı, arayüzde yalnız kontrolün bulunmasını değil, nasıl kullanılacağının anlaşılmasını ele alır.

Eylem olanağı (affordance)

Bir nesnenin mümkün kıldığı etkileşimdir.

İşaretleyici (signifier)

Kullanıcıya bu etkileşimin mümkün olduğunu anlatan işarettir.

Web'de:

• border,
• underline,
• düğme biçimi,
• üzerine gelme/odak durumu,
• etiket,
• icon

işaretleyici görevi görebilir.

Görünür olmayan tıklanabilir alan

Metin sıradan paragraf gibi görünürken tıklanabiliyorsa teknik olarak tıklama işleyicisi vardır; fakat yeterli işaretleyici yoktur.

Eşleme

Kontrol ile sonuç arasındaki ilişki doğal olmalıdır.

Örnek ses kanalı:

Sol kanal kontrolü → sol kanal
Sağ kanal kontrolü → sağ kanal

yer değiştirilmişse kullanıcı zihinsel dönüşüm yapmak zorunda kalır.

Kısıtlar

Yanlış eylemi yalnız hata mesajıyla yakalamak yerine sistemin izin verdiği hareket alanını sınırlamak daha güvenlidir.

Örnek:

Bitiş tarihi < başlangıç tarihi

durumunda yalnız gönderim sonrası hata vermek yerine geçersiz seçenekleri önlemek düşünülebilir.

Kavramsal model

Kullanıcının sistemin nasıl çalıştığına ilişkin zihinsel modeli teknik gerçeklikle tamamen aynı olmak zorunda değildir; fakat davranışı öngörmeye yeterli olmalıdır.

Örneğin “Taslak”:

Taslak → yalnız bana ait geçici çalışma
Yayınla → başkaları görür

şeklinde net bir kavramsal model sunmalıdır.

Doğru tasarım, kullanım kılavuzunu nesnenin davranışına mümkün olduğunca gömer.

Sistem imgesi

Kullanıcı tasarımcının zihnindeki mimariyi doğrudan göremez. Sistem hakkında modelini; ekranda gördüğü denetimler, adlar, durum göstergeleri, geri bildirimler, yardım metinleri, önceki deneyimleri ve uygulamanın davranışı üzerinden kurar. Bu bütün sistem imgesi olarak düşünülebilir.

Sistem imgesi ile gerçek davranış çelişirse arayüz teknik olarak doğru çalışsa bile kullanıcı yanlış sonuca varabilir. Örneğin:

[Kaydet]

düğmesine basıldıktan sonra durum görünmüyor, sayfa kapanınca verinin saklanıp saklanmadığı anlaşılmıyorsa sistem kullanıcının doğru kavramsal modeli kurmasına yardım etmiyordur.

Aynı kavramın farklı ekranlarda farklı adla kullanılması, bir yerde anında uygulanan seçimin başka yerde ayrıca “Kaydet” istemesi veya görünür durum ile sunucu durumunun ayrışması sistem imgesini bozar.

İyi sistem imgesi iç mimariyi açığa çıkarmak zorunda değildir. Kullanıcının görevi öngörebilmesi için doğru sonuç, doğru kapsam ve doğru durum görünür olmalıdır.

Zihindeki bilgi ve dünyadaki bilgi

Kullanıcının her şeyi hatırlaması gerekmez. Bilginin bir bölümü arayüz üzerinde, yani kullanıcının önünde tutulabilir:

• seçili filtreler,
• etkin kapsam,
• mevcut tarih aralığı,
• hangi kaydın açık olduğu,
• işlemin kaydedilip kaydedilmediği,
• kullanılabilir kısayollar,
• bir sonraki olası eylem.

Bu yaklaşım çalışma belleğini serbest bırakır ve özellikle kesintili iş akışlarında hata olasılığını düşürür.

Örnek:

Sorgu ölçütleri
→ sonuç kümesi
→ analiz

Analiz, sorgu tarih aralığını zaten taşıyorsa kullanıcıya aynı tarih aralığını yeniden sordurmak bilgi toplamak değil, sistemin bildiği bilgiyi kullanıcıya tekrar ezberletmektir.

Bilinen bağlamın görünür ve kararlı tutulması, yardım metnini artırmadan arayüzün kendi kendini açıklamasını sağlar.

Dokunma Ergonomisi ve Fiziksel Etkileşim

Dokunmatik arayüz, görsel bir yüzey olmasının yanında fiziksel bir kontrol yüzeyidir. Fare işaretçisi birkaç piksel kaplarken parmak hedefin bir bölümünü ve çevresini örter; kol, el ve cihazın ağırlığı da etkileşimin maliyetine katılır. Bu nedenle dokunma tasarımı yalnız düğmeleri büyütme problemi değildir.

Tutuş ve duruş sabit değildir

Bir kullanıcının cihazı nasıl tuttuğu yalnız cihaz modeline bağlı değildir. Aynı kişi:

• ayakta,
• otururken,
• masada,
• tek elle,
• iki elle,
• cihazı bir yüzeye dayayarak

farklı tutuşlara geçebilir. Ekran yönü değişebilir; destekleyen el ile işlem yapan el yer değiştirebilir. Bu nedenle belirli bir “başparmak bölgesi”ni bütün kullanıcılar ve bütün oturumlar için değişmez gerçek kabul etmek kırılgan bir yaklaşımdır.

Daha güvenli tasarım sorusu şudur:

Bu görevin sık kullanılan kontrolleri, desteklenen tutuşların makul bölümünde gereksiz fiziksel zorlanma oluşturmadan kullanılabiliyor mu?

Yerleşim kararı tek bir ergonomi şemasına değil; görev sıklığına, cihaz biçimine, yönelime ve gerçek kullanım gözlemine dayanmalıdır.

Temas alanı ve örtülme

Parmak ekrana tek bir matematiksel nokta olarak değmez. Sensör, belirli bir temas alanından konum üretir. Arayüz açısından daha önemli sonuç ise geometrik doğruluktan çok örtülmedir: kullanıcı dokunduğu hedefin kendisini ve yakınındaki geri bildirimi geçici olarak göremeyebilir.

Bu durum üç tasarım sonucuna yol açar:

1. Kontrol yalnız temas anındaki küçük renk değişimine güvenmemelidir.
2. Etiket veya kritik durum bilgisi tamamen parmağın altında kalmamalıdır.
3. Seçim sonucu, temas bittikten sonra da anlaşılır bir durum olarak kalmalıdır.

Örneğin yalnız ikonun içindeki ince bir ton değişimi yerine seçim durumunu satır, kenarlık, metin veya kalıcı durum göstergesiyle desteklemek daha güvenlidir. Görsel geri bildirim, kullanıcının onu gerçekten görebileceği yerde ve sürede bulunmalıdır.

Dokunma doğruluğu yalnız hedef boyutu değildir

Bir kontrolün kullanılabilirliği şu değişkenlerin bileşimidir:

hedef boyutu
+ komşu hedeflerle aralık
+ ekrandaki konum
+ kullanım sıklığı
+ temas sırasında örtülme
+ kullanıcının hareket kabiliyeti
+ yanlış seçimin maliyeti

Bu nedenle “bütün düğmeler aynı ölçüde olmalıdır” yaklaşımı her zaman doğru değildir. Küçük ve sıkışık iki kontrol, tek başına yeterli görünen iki hedeften daha fazla yanlış dokunma üretebilir. Tersine geniş yüzeyde daha büyük hedefler, özellikle yüksek etkili veya sık kullanılan eylemlerde hata toleransını artırabilir.

Normatif erişilebilirlik ölçütleri asgari kabul sınırını verir. Ergonomi incelemesi bu sınırın üzerinde, gerçek görev için gerekli güven payını belirler.

Fiziksel maliyet ve eylem sıklığı

Fareyle uzun mesafe hareket ettirmek ile büyük bir dokunmatik yüzeyde kolu tekrar tekrar taşımak aynı motor maliyete sahip değildir. Büyük ekranlarda sık kullanılan kontrollerin dağınık yerleşimi, işlem sayısı değişmese bile fiziksel yükü artırabilir.

Bu nedenle yüksek frekanslı işlerde:

• tekrar eden eylemleri gereksiz mesafelere dağıtmamak,
• aynı görev ailesini tutarlı bölgelerde toplamak,
• bir işlemi tamamlamak için gereken temas sayısını azaltmak,
• klavye veya hassas işaretçi kullanan uzman kullanıcıların hızlandırıcı yollarını korumak

gerekir.

Amaç her şeyi tek köşeye yığmak değildir. Amaç, motor maliyeti görev önemiyle birlikte değerlendirmektir.

Riskli eylemler kolay erişim ile yanlış etkinleştirme arasında dengelenmelidir

Sık kullanılan birincil eylemin erişilebilir olması gerekir. Fakat kalıcı silme, geri alınamaz gönderim veya geniş kapsamlı değişiklik gibi işlemlerde yalnız hız için en yoğun temas bölgesine başka kontrollerle bitişik bir eylem koymak risklidir.

Burada üç mekanizma birlikte düşünülebilir:

mekânsal ayrım
+ açık eylem etiketi
+ işlemin etkisine uygun geri alma / onay / önizleme

Onay iletişim kutusu, kötü hedef yerleşiminin yerine geçen bir güvenlik ağı değildir. Önce yanlış etkinleştirme olasılığı azaltılmalıdır.

Dokunma ve görünürlük aynı anda tasarlanmalıdır

Kullanıcı yalnız ulaşabildiği kontrole değil, görebildiği ve anlamlandırabildiği kontrole güvenli biçimde dokunabilir. Bu nedenle ikon, etiket, kontrast, hedef boyutu ve geri bildirim birbirinden bağımsız kalite başlıkları değildir.

Bir kontrol:

• fiziksel olarak kolay dokunuluyor,
• fakat dekoratif öğe gibi görünüyorsa keşfedilemez;
• görünür,
• fakat hedefi çok sıkışıksa hata üretir;
• doğru hedefe sahip,
• fakat dokununca geri bildirim parmağın altında kayboluyorsa belirsizlik üretir.

Eylem olanağı, işaretleyici ve geri bildirim dokunmatik yüzeyde aynı fiziksel olayın üç farklı katmanıdır.

Sabit dokunmatik yüzey, elde kullanılan tablet değildir

Tablet bir standa sabitlendiğinde ekran boyutu değişmeyebilir, ancak ergonomi değişir. Kullanıcı cihazı hareket ettiremez; kolunu yüzeye taşır. Büyük veya dikey sabit ekranlarda tekrar eden üst bölge erişimi omuz ve kol yorgunluğu oluşturabilir.

Bu nedenle sabit dokunmatik terminal, kontrol paneli veya standa sabit tablet için:

• uzun süreli kol hareketi,
• erişim yüksekliği,
• kullanıcı boyu ve hareket kabiliyeti,
• ekran açısı,
• çevresel yansıma,
• sıradaki kullanıcının mahremiyeti

gibi etkenler ayrıca değerlendirilmelidir.

Aynı HTML ve aynı çözünürlük, aynı insan faktörleri problemi anlamına gelmez.

Etkileşim Bir Konuşmadır — Eylem öncesi yönlendirme ve Geri bildirim

Designing Interfaces etkileşimi kullanıcı ile sistem arasında bir konuşma gibi ele alır. Strategic Writing for UX ise bu konuşmanın sözcüklerini sistematik bir tasarım problemi olarak işler.

Eylem öncesi yönlendirme

Eylemden önce:

Bunu yaparsanız ne olacak?

sorusunu cevaplar.

[24 kaydı dışa aktar]

[Tamam] düğmesinden daha fazla eylem öncesi yönlendirme sağlar.

Geri bildirim

Eylemden sonra:

Ne oldu?

sorusunu cevaplar.

24 kayıt dışa aktarıldı.

İyi kontrol metni

Düğme:

[Gönder]

yerine bağlama göre:

[Başvuruyu Gönder]
[Raporu Oluştur]
[Değişiklikleri Kaydet]

daha açık olabilir.

Sistem konuşmasının ritmi

Her küçük durum için kullanıcıya modal iletişim kutusu açmak, konuşmada sürekli karşı tarafın sözünü kesmek gibidir.

Daha doğal ritim:

• küçük durum → satır içi/durum alanı,
• önemli fakat geçici → bildirim,
• kullanıcı eylemi gerekiyorsa → görünür kalıcı ileti,
• kritik karar → modal iletişim kutusu/ayrı adım.

Arayüz az konuşmalı; fakat konuştuğunda belirsiz konuşmamalıdır.

İnsan Hatasını Tasarlamak — Eylem sürçmesi, Kavramsal hata ve Kurtarma

Don Norman insan hatasını kullanıcıya ait tekil kusur olarak değil, insan ile sistem arasındaki tasarım probleminin parçası olarak inceler.

Eylem sürçmesi

Kullanıcının amacı doğrudur, uygulaması yanlıştır.

Örnek:

• yanlış satırdaki sil düğmesine tıklamak,
• komşu menü öğesine dokunmak,
• Ctrl+Enter yerine Enter basmak.

Kavramsal hata

Kullanıcının zihinsel modeli veya kararı yanlıştır.

Örnek:

• “Arşivle”yi “sil” sanmak,
• tarih filtresinin kapsamını yanlış anlamak,
• “pasif” kaydın görünmeyeceğini varsaymak.

Farklı hata, farklı çözüm

Eylem sürçmesi için:

• daha büyük hedef,
• yıkıcı eylem separation,
• geri alma,
• doğru odak,
• kararlı yerleşim

yararlı olabilir.

Kavramsal hata için:

• daha iyi etiket,
• kapsam açıklaması,
• önizleme,
• kavramsal model,
• yardım

gerekebilir.

Kip hataları ve görünür durum

Aynı eylem farklı kiplerde farklı sonuç üretiyorsa kullanıcı hangi kipte olduğunu sürekli bilmek zorundadır. Kip sayısı gereksiz yere arttıkça doğru eylemin yanlış bağlamda uygulanma riski büyür.

Kip kaçınılmazsa:

• etkin kip belirgin olmalı,
• kip değişimi sessiz gerçekleşmemeli,
• aynı kontrolün anlamı beklenmedik biçimde değişmemeli,
• riskli kipler normal çalışma görünümünden ayırt edilebilmelidir.

Örneğin aynı Delete tuşunun bir ekranda yalnız seçimi kaldırıp başka bir görünümde kalıcı kayıt silmesi, görünür bağlam yeterince güçlü değilse tehlikelidir.

“Daha dikkatli olun” bir tasarım önlemi değildir

Deneyimli kullanıcıların birçok eylemi bilinçli olarak tek tek düşünmeden yapması normaldir. Bu yüzden güvenliği yalnız kullanıcının her seferinde tam dikkat göstereceği varsayımına bağlamak zayıftır.

Benzer kontrolleri ayırmak, yıkıcı eylemi sık kullanılan eylemden uzaklaştırmak, kapsamı eylemden önce görünür kılmak ve işlemden sonra belirgin geri bildirim vermek daha güvenilir savunmalardır.

Tutarlılık ve sınır kontrolleri

Sistem yalnız sözdizimsel olarak geçerli girdiyi değil, bağlam içinde olağandışı değeri de değerlendirebilir.

Örnekler:

• normalden birkaç büyüklük mertebesi yüksek parasal tutar,
• seçili sorgu aralığının tamamen dışında tarih,
• binlerce kaydı etkileyen toplu silme,
• kullanıcının yetki kapsamını aşan seçim.

Bu tür kontroller otomatik olarak işlemi reddetmek zorunda değildir. Risk düzeyine göre kullanıcıya kapsamı yeniden göstermek, ek doğrulama istemek veya sunucu tarafında işlemi engellemek gerekebilir.

Hedef, kullanıcıyı sürekli uyarmak değil; makul olmayan durumu sessizce kabul etmemektir.

Zorlayıcı işlev

Bazı kritik işlemler yanlış sırayı fiziksel olarak engellemelidir.

Örnek:

Yetki kapsamı doğrulanmadan değişiklik API’si çalışmaz.

arayüzde düğmeyi gizlemek zorlayıcı işlev değildir; güvenlik sunucu tarafındaki değişmez olmalıdır.

Onay yorgunluğu

Her şey için onay gösterilirse kullanıcı metni okumadan onaylamayı öğrenir.

Onay yalnız:

• yüksek etki,
• düşük sıklık,
• geri alınamazlık,
• kapsam belirsizliği

gibi durumlarda anlamlıdır.

“Hata yapmayın” tasarım değildir. Hata yolunu daraltın, hatayı görünür kılın, mümkünse zararı geri alınabilir yapın.

UX Psikolojisi “Kanunları” Nasıl Kullanılmalıdır?

Laws of UX psikoloji bulgularını tasarımcı için erişilebilir başlıklar hâline getirir. Bunlar matematiksel fizik kanunları gibi bağlamdan bağımsız emirler değildir.

Jakob İlkesi

Kullanıcı zamanının çoğunu başka ürünlerde geçirir. Bu nedenle mevcut web konvansiyonları yeni üründeki beklentiyi etkiler.

Sonuç:

Standart davranışı bozmak için ölçülebilir gerekçe gerekir.

Fitts İlkesi

Hedefe ulaşma süresi hedefin:

• uzaklığı,
• büyüklüğü

ile ilişkilidir.

Sık kullanılan eylem küçük ve uzak olmamalıdır.

Hick İlkesi

Karar uzayı karmaşıklaştıkça seçim süresi artabilir.

Çözüm:

• gruplama,
• varsayılan,
• arama,
• aşamalı gösterim.

Postel yaklaşımı

Girdi kabulünde tolerans yararlı olabilir; ancak güvenlik ve veri semantiğinde sınırsız tolerans yanlış sonuç üretebilir.

Form örneği:

(555) 123-45-67
5551234567
555 123 45 67

aynı telefon semantiğine normalize edilebilir.

Ama:

geçersiz tarih
yetkisiz kapsam

“tolerans” adına kabul edilmemelidir.

Tepe–Son

Kullanıcının deneyim değerlendirmesi yalnız ortalama ana değil, güçlü anlara ve sona duyarlı olabilir.

Bu nedenle:

• son onay,
• başarı ekranı,
• hata kurtarma,
• işlem kapanışı

önemlidir.

Estetik–Kullanılabilirlik Etkisi

Estetik arayüz ilk algıda daha kullanılabilir hissedilebilir. Bu, gerçek kullanılabilirlik kusurunu ortadan kaldırmaz.

Von Restorff

Ayrışan öğe dikkat çeker.

Bu nedenle yalnız gerçek birincil veya kritik öğe ayrıştırılmalıdır. Her şeyi vurgulamak, hiçbir şeyi vurgulamamaktır.

Tesler — karmaşıklığın korunumu

Bazı iş karmaşıklıkları yok edilemez; yalnız:

• kullanıcı,
• UI,
• sunucu tarafı,
• süreç

arasında taşınabilir.

Mümkün olan karmaşıklığı sistem üstlenmelidir; fakat sistem doğruluğu garanti edemiyorsa sahte otomasyon yapılmamalıdır.

Doherty eşiği

Hızlı geri bildirim kullanıcının akışını korur. Buradan çıkarım:

• ağır işlem hızlı olmak zorunda olmayabilir,
• fakat ilk geri bildirim hızlı olmalıdır.

Psikoloji kuralını dekoratif bir “yasa” etiketiyle değil, tasarım hipotezi olarak kullanın; gerçek görevle doğrulayın.

Sadeleştirmenin Dört Stratejisi — Kaldır, Düzenle, Gizle, Yer Değiştir

Simple and Usable içinde öne çıkan uygulanabilir çerçevelerden biri, karmaşıklığı dört ayrı stratejiyle ele almaktır.

1. Kaldır

Kaldırılabilecekler:

• kullanılmayan özellik,
• yinelenen kontrol,
• anlamsız açıklama,
• sistemin bildiği veriyi tekrar isteyen alan,
• hiçbir karar üretmeyen gösterge paneli metriği.

Ancak “az görünsün” diye kritik bilgi kaldırılmaz.

2. Düzenle

Karmaşıklık gerçekse iyi organizasyon gerekir:

• chunk,
• bölüm,
• hiyerarşi,
• sık kullanılanı öne alma,
• kullanıcı davranışına göre sıralama,
• tutarlı ızgara.

3. Gizle

Seyrek ama gerekli özellik:

Gelişmiş

katmanına taşınabilir.

Gizledikten sonra:

• işaret,
• ipucu,
• arama,
• doğru etiket

ile bulunabilirlik korunmalıdır.

4. Yer değiştir

Karmaşıklık başka katmana taşınabilir.

Örnek:

Kullanıcı her seferinde tarih formatı seçmesin
→ yerel ayar/sistem tercihini uygulasın.

veya:

Mobilde uzun ayar yerine masaüstünde detaylı yönetim

Ancak “kullanıcıya bırakmak” da bir displacement türüdür ve bazen kötü karardır. Sistem güvenli varsayım yapabiliyorsa kullanıcıyı gereksiz karara zorlamamalıdır.

Akıllı varsayılanlar

İyi varsayılan:

• en olası,
• güvenli,
• geri alınabilir,
• bağlama uygun

olmalıdır.

Riskli varsayılan:

Tüm kayıtları sil

olamaz.

Sadelik önce kesmek, sonra saklamak değildir. Önce görevi anlayın; karmaşıklığın hangi kısmının gerçekten var olması gerektiğini belirleyin.

Ünite 7: Form, İçerik, Prototipleme ve Güven

Form Bir Soru Listesi Değil, Kontrollü Bir Konuşmadır

Designing UX: Forms form deneyimini yalnız etiket yerleşimi olarak değil, kullanıcının soruyu anlaması, yanıtı bulması, cevabın uygunluğunu değerlendirmesi ve fiziksel olarak girmesi zinciri şeklinde ele alır.

Her sorunun maliyeti vardır

Bir alanı forma eklemek:

• okuma,
• anlama,
• hatırlama,
• karar,
• veri girişi,
• doğrulama

maliyeti üretir.

Bu nedenle:

“Bu alan sunucu tarafında var” formda bulunması için yeterli gerekçe değildir.

Soru dili

Kullanıcıya kurumun veri modelini değil, gerçek dünyadaki anlamı sorulmalıdır.

Kötü:

STAT_CD

Daha iyi:

Kayıt durumu

Bilinen cevabı tekrar sormamak

Sistem:

• kullanıcı kimliğini,
• rolü,
• önceki tercihi,
• bağlamı

güvenle biliyorsa tekrar istememelidir.

Smart prefill

Önceden doldurma:

• doğru olma olasılığı yüksekse,
• kullanıcı düzeltebiliyorsa,
• veri gizliliği uygun ise

faydalıdır.

Yanlış prefill, boş alandan daha tehlikeli olabilir; kullanıcı otomatik değeri fark etmeden gönderebilir.

Format toleransı

İnsanların doğal olarak farklı yazdığı veriler mümkünse normalize edilmelidir.

Ancak normalleştirme anlam kaybı üretmemelidir.

Review

Kritik formda son adım:

Girdi → Kontrol → Onay

özellikle çok alanlı değişiklik işleminde hata önleme sağlar.

Her soru kullanıcıdan alınan küçük bir borçtur. Gereksiz soru sormayın.

Karmaşık Veri ve Eylemler — “Göster” ile “Yaptır”ı Ayırmak

Designing Interfaces listeler, karmaşık veri, eylemler ve komutlar için ayrı kalıp aileleri tanımlar. Bu ayrım yoğun web uygulamalarında önemlidir.

Veri gösterme görevleri

Kullanıcı:

• bulur,
• karşılaştırır,
• sıralar,
• filtreler,
• detay açar.

Eylem görevleri

Kullanıcı:

• değiştirir,
• kaydeder,
• toplu işlem yapar,
• geri alır,
• dışa aktarır.

Bu iki görev aynı araç çubuğu içinde kontrolsüz karışırsa işlem riski artar.

Seçim modeli

Tabloda:

satırı tıklamak = yalnız seçmek

mi,

satırı tıklamak = detayı açmak

mı olduğu tutarlı olmalıdır.

Çift tıklama gibi masaüstü geçmişinden gelen davranışlar web/dokunmatik ortamında dikkatle kullanılmalıdır.

Cancelability

Uzun işlem:

Rapor hazırlanıyor...
[İptal]

şeklinde iptal edilebiliyorsa kullanıcı kontrolü artar.

Ancak “İptal” düğmesi yalnız arayüzdeki yükleme göstergesini kapatıp sunucu tarafı işini sürdürüyorsa semantik olarak yanlıştır.

Komut geçmişi ve geri alma

Uzman araçlarında geçmiş eylemler görünür tutulabiliyorsa:

• denetlenebilirlik,
• geri dönüş,
• öğrenilebilirlik

artar.

Veriyi görmek ile veriyi değiştirmek aynı görsel ağırlığa sahip olmamalıdır.

Arayüz Metni Tasarımı — Kelime de Bileşendir

Strategic Writing for UX, arayüz metnini sonradan doldurulan bir boşluk değil, deneyimin işlevsel parçası olarak ele alır.

Başlık

Başlık kullanıcıya konumu ve görevi söyler.

Belirsiz:

İşlemler

Daha iyi:

Kullanıcı Yetkileri

Düğme

Düğme metni sonucu açıklamalıdır.

[OK]

yerine:

[Değişiklikleri Kaydet]

Boş durum

Boşluk yalnız “veri yok” demez; ne yapılabileceğini de anlatabilir.

Henüz kayıt yok.
[Yeni kayıt oluştur]

veya:

Bu filtrelerle eşleşen kayıt bulunamadı.
[Filtreleri temizle]

Hata

İyi hata üç şeyi mümkünse açıklar:

1. Ne oldu?
2. Kullanıcı ne yapabilir?
3. Veri kayboldu mu?

Notification

Bildirim:

• olayın ne olduğunu,
• neden önemli olduğunu,
• gerekiyorsa sonraki eylemi

anlatmalıdır.

Üslup ve ton

Aynı ürün:

• başarı,
• kritik hata,
• ilk kullanım,
• güvenlik uyarısı

durumlarında aynı duygusal tona sahip olmak zorunda değildir.

Kritik hata:

“Oops! Bir şeyler ters gitti :)”

gibi aşırı neşeli olmamalıdır.

Kısalık

Kısa metin hedef değil, sonucu net ifade eden en kısa yeterli metin hedeftir.

Kullanıcının yolunu açmayan kelimeyi kaldırın; yol ayrımında gereken kelimeyi esirgemeyin.

İleri Veri Girişi: Tarih, Zaman, Dosya ve Toplu Veri

Form mühendisliği metin alanı, seçim kutusu ve Kaydet düğmesinden ibaret değildir. Tarih-zaman, dosya, yapıştırma ve toplu veri akışlarında doğrulama ile kullanıcı zihinsel modeli daha kolay ayrışır.

Tarih, saat ve zaman dilimi üç farklı kavramdır

Bir iş alanında şu değerler aynı şey değildir:

2026-09-28               -> takvim tarihi
14:30                    -> yerel saat
2026-09-28T14:30+03:00   -> ofsetli an
Europe/Istanbul          -> zaman dilimi kural kümesi

"Tarih" isteyen form gereksiz saat toplamamalıdır. Belirli bir küresel an gereken sistemde ise yalnız 28.09.2026 14:30 metni çoğu zaman yetersizdir; hangi zaman diliminde yorumlandığı bilinmelidir.

Kullanıcıdan serbest biçimli tarih metni almak yerine iş kuralına uygun olduğunda yapılandırılmış kontrol kullanmak hata alanını küçültebilir. Buna karşılık doğum tarihi gibi kullanıcının bildiği sabit bir tarihi takvimde onlarca ay geri gezdirerek seçmeye zorlamak da kötü bir kontrol eşleşmesidir. Kontrol veri türüne kadar değil, göreve kadar uygun olmalıdır.

Yerelleştirilmiş gösterim ile sunucu tarafı saklama biçimi ayrılmalıdır. Kullanıcı 28.09.2026 görebilir; veri katmanı bunun için farklı ve kesin bir temsil kullanabilir. Arayüzde gösterilen biçimi veri tabanı biçimi sanmak i18n ve doğrulama hatası üretir.

Dosya yükleme bir durum makinesidir

Dosya seçmek yalnız <input type="file"> göstermek değildir. Kullanıcı açısından akış:

seçilmedi
 -> seçildi
 -> istemci ön kontrolü
 -> gönderiliyor
 -> sunucu doğruluyor
 -> tamamlandı

ve hata dallarını içerir.

Boyut sınırı, kabul edilen tür, çoklu dosya desteği ve yükleme sonrası ne olacağı seçimden önce anlaşılabilir olmalıdır. Gönderim uzun sürüyorsa gerçek ilerleme biliniyorsa ilerleme gösterilebilir; işlem iptal edilebiliyorsa iptal hem istemci isteğini hem mümkün olduğu ölçüde sunucu tarafı işi anlamlı biçimde sonlandırmalıdır.

Dosya uzantısı veya istemci MIME değeri güvenlik doğrulamasının yerine geçmez. UI yalnız kullanıcıya erken geri bildirim verir; sunucu yine gerçek içerik ve iş kuralını doğrular.

Yapıştırma ve toplu giriş ayrı etkileşim yollarıdır

Uzman kullanıcı yüzlerce değeri tek tek forma girmek yerine panodan yapıştırmak veya dosyadan içe aktarmak isteyebilir. Böyle bir akış yalnız "çok satırlı textarea" olarak ele alınmamalıdır.

Güvenilir toplu girişte şu ayrım görünür olmalıdır:

alınan satır
 -> ayrıştırıldı
 -> doğrulandı
 -> kabul edilecek
 -> reddedilecek / düzeltilecek

Kullanıcıya yalnız "3 hata var" demek yerine hangi satırın neden reddedildiği gösterilebilmelidir. İçe aktarma ön izlemesi, yanlış ayırıcı veya kolon eşlemesi yüzünden yüzlerce kaydın hatalı oluşturulmasını engelleyebilir.

Panodan gelen içeriğin biçimi güvenilir kabul edilmemelidir. Görünmeyen karakterler, yerel sayı biçimleri, satır sonu farklılıkları ve beklenmeyen sütunlar ayrıştırma mantığını etkileyebilir.

Formun bildiği veriyi tekrar istemeyin

WCAG 2.2 Redundant Entry ölçütü aynı süreçte daha önce girilmiş bilginin gereksiz yeniden girişini azaltmayı hedefler. Bu yalnız erişilebilirlik kuralı değil, iyi form mimarisidir.

sistem zaten biliyor
      |
      +--> güvenli biçimde otomatik doldur
      +--> kullanıcıya seçtir
      +--> artık geçersizse yeniden iste

Güvenlik nedeniyle yeniden doğrulama gereken bilgi bu kuralın farklı bir problemidir; kullanım kolaylığı adına güvenlik kontrolü kaldırılmaz.

Terminoloji Yönetişimi ve İçerik Tutarlılığı

Arayüz metni yalnız tek tek iyi cümlelerden oluşmaz. Uzun yaşayan uygulamalarda aynı kavramın farklı modüllerde farklı adlarla görünmesi bilişsel maliyet yaratır.

aynı kavram
 -> "Kayıt"
 -> "Öğe"
 -> "Nesne"
 -> "Sonuç"

Bu sözcükler gerçekten farklı şeyleri anlatmıyorsa kullanıcı her ekran değişiminde yeni bir sınıflandırma yapmak zorunda kalır.

Bu nedenle ürün sözlüğünde en azından şu tür kavramlar sabitlenebilir:

• alan terimleri,
• eylem fiilleri,
• durum adları,
• hata ve başarı terminolojisi,
• yetki ve gizlilik dili,
• tarih/süre/ölçü birimi gösterimleri.

Tutarlılık mekanik tekdüzelik değildir. Aynı fiil farklı bağlamda farklı sonuç üretiyorsa daha açıklayıcı metin gerekir. Ama aynı işlev için gereksiz eşanlamlı çeşitliliği tasarım zenginliği değil, terminoloji borcudur.

Prototipleme — Tasarımı Tartışmadan Önce Davranışı Görünür Kılmak

Designing UX: Prototyping ve Figma odaklı kaynaklar, prototipi yalnız görsel arayüz maketi olarak değil, hipotez test aracı olarak ele alır.

Aslına uygunluk düzeyi amaca göre seçilir

Düşük aslına uygunluk düzeyi:

• bilgi mimarisi,
• görev akışı,
• fikir karşılaştırma

için yeterli olabilir.

Yüksek aslına uygunluk düzeyi:

• gerçek gezinme,
• mikro-etkileşim,
• duyarlı davranış,
• usability testing

için gerekebilir.

Kod prototipi ne zaman?

Şunlar önemliyse:

• gerçek klavye davranışı,
• kaydırma,
• sanallaştırılmış ızgara,
• audio/video,
• performance,
• API durum,
• dokunmatik

statik tasarım aracı gerçeği temsil etmeyebilir.

Prototip üretim değildir

Prototipte çalışan:

sahte veri + tek kullanıcı + sıfır gecikme

deseni üretimde:

yüksek gecikme + yetki + eşzamanlılık + yinelenen veri + hata

ile aynı değildir.

Test senaryosu

“Bu tasarımı beğendiniz mi?” yerine:

Son üç aya ait tamamlanmamış başvuruyu bulun ve ayrıntısını açın.

gibi görev verilmelidir.

Tasarım tartışmasını görüş yarışından davranış gözlemine taşıyın.

Duygusal Tasarım, Güven ve Algılanan Kalite

Don Norman'ın Emotional Design yaklaşımı, işlevsel doğruluğun yanında duygusal tepkinin de deneyimi etkilediğini ele alır.

Üç farklı seviye üzerinden düşünmek

Basitleştirilmiş biçimde:

• ilk algı: görünüm, düzen, hissiyat,
• kullanım: kontrol, performans, anlaşılabilirlik,
• yansıtma: ürünün kullanıcı için anlamı ve güveni.

Estetik hatayı gizlememelidir

Güzel arayüz:

• ilk güveni,
• kullanım isteğini,
• algılanan kolaylığı

artırabilir.

Ancak:

• veri kaybı,
• yetkisiz görünürlük,
• yavaş işlem,
• belirsiz durum

estetik ile telafi edilemez.

Güven tasarımı

Kurumsal sistemde güven:

• tutarlı davranış,
• doğru sonuç,
• açık denetim izi,
• görünür kayıt zamanı,
• geri dönüş,
• tahmin edilebilir hata

ile oluşur.

Sakinlik yalnız renk paleti değildir. Sistemin sözünü tutması en güçlü sakinlik kaynağıdır.

Tragic Design — Kötü UX'in Bedeli Bazen Rahatsızlık Değildir

Tragic Design, tasarım hatalarının yalnız dönüşüm kaybı veya kullanıcı memnuniyetsizliği üretmediğini; bazı bağlamlarda ciddi zararlar doğurabileceğini merkeze alır.

Yüksek riskli ürün

• sağlık,
• kamu güvenliği,
• finans,
• ulaşım,
• endüstriyel kontrol,
• yetkilendirme,
• kritik altyapı

gibi alanlarda UX kararı güvenlik kararı olabilir.

Tehlikeli sadeleştirme

Örneğin kullanıcıya “temiz görünüm” sunmak için kritik durumu gizlemek, estetik kazanç karşılığında operasyonel risk yaratabilir.

Karanlık kalıp

Kullanıcıyı:

• yanlışlıkla onaya,
• üyelikten çıkamamaya,
• gizlilik seçeneğini bulamamaya,
• gereksiz paylaşmaya

yönelten desenler kullanılabilirlik değil manipülasyondur.

Hata bütçesi

Yüksek riskli işlem için kabul edilebilir hata olasılığı, sosyal medya beğeni butonuyla aynı değildir.

İnsan faktörü

Kritik sistemde “kullanıcı dikkat etmeliydi” savunması zayıftır. Yüksek sıklıkta aynı görevi yapan bir operatörün hata olasılığı sıfırlanamaz; tasarımın görevi bu olasılığı ve hatanın etkisini sistematik biçimde azaltmaktır. Arayüz:

• yanlış seçimi mümkün olduğunca azaltmalı,
• durumu görünür kılmalı,
• kritik sonucu açık anlatmalı,
• mümkünse ikinci güvenlik katmanı sağlamalıdır.

Sadelik uğruna gerçeği saklamayın. Kritik bilgi sessiz olabilir; görünmez olamaz.

Ünite 8: Görsel Sistem Mühendisliği ve Tutarlılık

Tasarım Sistemleri — Tutarlılığın Altyapısı

Designing Interfaces, Figma kaynakları ve Practical UI Patterns for Design Systems gibi eserlerden çıkan ortak sonuç: tasarım sistemi yalnız bileşen deposu değildir.

Dört katman

Token
  ↓
Primitive
  ↓
Bileşen
  ↓
Kalıp

Örneğin:

space-md
  ↓
düğme iç boşluğu
  ↓
Düğme
  ↓
Form Kaydetme kalıbı

Davranış sözleşmesi

Bir bileşen yalnız CSS değildir.

Düğme:

• odak,
• yükleme,
• devre dışı,
• klavye,
• erişilebilir ad,
• yinelenen gönderim koruması

davranışlarını da içerir.

Kalıp sözleşmesi

Modal iletişim kutusu:

• odağın içeri alınması,
• odak tuzağı,
• Escape,
• kapatma düğmesi,
• odağın geri döndürülmesi,
• arka plan katmanı

gibi davranışları standardize eder.

Tutarlılık ve ürün hızı

Standart bileşen:

• her ekranda yeniden karar vermeyi,
• erişilebilirlik hatasını,
• küçük davranış farklılıklarını

azaltabilir.

Tasarım sistemi dogma değildir

Her gerçek iş problemi mevcut bileşene zorlanmamalıdır.

Yeni kalıp gerekiyorsa:

sorun → kanıt → kalıp → belgeleme

süreci izlenebilir.

Aynı problemi her ekranda yeniden çözmek gürültüdür. İyi sistem, tekrar eden kararları sessizce ortadan kaldırır.

Görsel Sistem Mühendisliği — Estetik Kararı Tekrarlanabilir Kurala Dönüştürmek

Bir arayüzün aynı ürüne ait görünmesi yalnız aynı logoyu veya marka rengini kullanmasıyla sağlanmaz. Tutarlılık; renk, tipografi, boşluk, kontrol yüksekliği, köşe yarıçapı, kenarlık, yüzey, ikon, hareket ve durum davranışlarının aynı karar sisteminden türemesiyle oluşur.

Bu nedenle görsel tasarımı iki uçtan biri olarak görmek yanıltıcıdır:

özgür estetik tercih
veya
katı piksel standardı

Olgun yaklaşım bunların arasındadır:

ham değer
   ↓
tasarım belirteci
   ↓
semantik rol
   ↓
bileşen
   ↓
kalıp
   ↓
sayfa şablonu

Örneğin #d32f2f yalnız bir renktir. color-danger-foreground ise bir niyeti ifade eder. Aynı semantik rol açık ve koyu temada farklı ham renklere eşlenebilir; bileşen kodu değişmeden kalır.

Evrensel standart ile tasarım sistemi tercihini ayırmak

UI ölçülerinde tek bir sektör standardı yoktur. Farklı olgun sistemler farklı ölçekler kullanır. Fluent 2, aralıklandırmada 4 px tabanlı bir ölçek kullanırken Atlassian 8 px tabanlı sistem kurar. USWDS 8 px tabanlı bir sistem kullanır fakat küçük ara değerleri de destekler. GOV.UK ise kendi aralıklandırma ölçeğini tanımlar.

Buradan çıkarılacak sonuç “hangisi doğru?” değildir. Doğru soru şudur:

Aynı ürün içinde keyfî değer üretmeden, görev ve erişilebilirlik gereksinimlerini karşılayan sınırlı bir ölçek kullanıyor muyuz?

Normatif gereksinim farklıdır. WCAG kontrast, yeniden akış, hedef boyutu ve metin aralığı gibi alanlarda sınanabilir erişilebilirlik koşulları tanımlar. Bunlar marka veya tasarım sistemi tercihiyle aynı kanıt düzeyinde değildir.

İlkel, semantik ve bileşen belirteçleri

Üç katman yararlıdır:

İlkel:      blue-600, space-4, radius-2
Semantik:   action-primary, surface-muted, gap-form
Bileşen:    button-primary-bg, dialog-padding

İlkel belirteç tasarımın ham sözlüğüdür. Semantik belirteç rolü açıklar. Bileşen belirteci ise gerektiğinde yalnız ilgili bileşenin davranışını ayarlamayı sağlar.

Her CSS değerini belirtece çevirmek de doğru değildir. Tek seferlik gerçek bir istisna ile sistemik karar ayrılmalıdır. Ama aynı 13px, 17px, #737373 veya border-radius: 7px farklı ekranlarda tekrar ediyorsa artık tesadüfi stil değil, belgelenmemiş tasarım kararı vardır.

Sayfa şablonu da tasarım sisteminin parçasıdır

Tasarım sistemi yalnız düğme ve giriş alanlarından oluşmaz. Büyük uygulamalarda tekrar eden sayfa anatomileri de standardize edilebilir:

Liste sayfası
Başlık → genel eylemler → arama/filtre → veri alanı → sayfalama/durum

Ayrıntı sayfası
Başlık → kimlik/durum → birincil eylemler → içerik bölümleri → geçmiş

Form sayfası
Başlık → bağlam → alan grupları → hata özeti → eylemler

Sihirbaz
İlerleme → adım başlığı → adım içeriği → geri/ileri → durum koruma

Bu tür şablonlar farklı modüllerin birbirine benzemesini sağlamaktan daha fazlasını yapar: kullanıcının yeni ekranda nereden başlayacağını tahmin etme maliyetini düşürür.

Renk Sistemi — Paletten Semantiğe

Renk, arayüzde marka kimliği kadar durum, hiyerarşi ve etkileşim anlamı taşır. Bu nedenle “güzel renk paleti” ile “çalışan UI renk sistemi” aynı şey değildir.

Rengin üç farklı görevi

Bir ürün içinde renkleri en az üç sınıfta düşünmek yararlıdır:

• nötr renkler: yüzey, metin, kenarlık ve ayrım için,
• marka/eylem renkleri: birincil eylem ve ürün kimliği için,
• durum renkleri: başarı, uyarı, hata, bilgi gibi semantik durumlar için.

Bu roller karıştığında anlam bulanıklaşır. Örneğin kırmızı hem marka ana rengi, hem seçili sekme, hem hata, hem grafik serisi olarak kullanılırsa kullanıcı kırmızının ne anlattığını bağlamdan çözmek zorunda kalır.

Ham renk yerine semantik renk

red-600                → ham renk
error-foreground       → semantik rol
error-surface          → semantik rol
error-border           → semantik rol

Aynı hata durumu tek bir kırmızı değerle çözülmez. Metnin, arka planın, ikonun, kenarlığın ve etkileşim durumlarının ayrı kontrast ilişkileri vardır.

Renk armonisi ve UI

Grafik tasarımda tamamlayıcı, analog, üçlü ve benzeri renk ilişkileri kompozisyon üretmek için yararlıdır. Ancak işlem ağırlıklı bir UI'da renk armonisi işlevsel semantiğin önüne geçmemelidir.

Marka paleti geniş olabilir; ürün yüzeyi çoğu zaman daha dar bir işlevsel paletle daha tutarlı çalışır. Nötr tonlar çalışma alanını kurarken doygun renkler dikkat gerektiren az sayıdaki noktaya ayrılabilir.

“60/30/10” gibi oranlar bazı tasarım sistemlerinde kompozisyon rehberi olarak kullanılır; erişilebilirlik standardı veya evrensel UI yasası değildir.

Kontrast yalnız metin problemi değildir

WCAG 2.2 kapsamında normal metin için genel eşik 4.5:1, büyük metin için 3:1'dir. Anlam taşıyan UI bileşeni sınırları ve grafiksel nesneler için de ilgili kontrast gereksinimleri değerlendirilmelidir.

Ancak kontrastı yalnız oran hesabına indirgemek yeterli değildir. Şunlar da önemlidir:

• ince font ağırlığı,
• düşük kaliteli ekran,
• parlak ortam,
• koyu temada halelenme,
• renk körlüğü,
• forced-colors / yüksek kontrast modu,
• küçük ikon ve sınırlar.

Durum rengi tek kanal değildir

kırmızı alan

yerine:

[!] Kayıt kaydedilemedi

kullanmak gerekir. Renk, ikon, metin ve gerektiğinde yapı birlikte anlam taşır.

Koyu tema renkleri ters çevirmek değildir

Koyu tema için #fff ↔ #000 dönüşümü yapmak yüzey hiyerarşisini ve kontrastı bozabilir. Koyu temada:

• yüzey katmanları ayrı nötr tonlarla kurulmalı,
• gölgelerin görünürlüğü azalacağı için elevation yüzey rengiyle de ifade edilebilmeli,
• çok doygun renklerin parlama etkisi kontrol edilmeli,
• durum renkleri ayrı doğrulanmalı,
• ikon ve görsellerin tema davranışı test edilmelidir.

Açık, koyu ve yüksek kontrast temaları aynı semantik token katmanından beslenirse bileşenler tema bilgisini kendi içinde yeniden icat etmez.

Veri renkleri UI durum renklerinden ayrılmalıdır

Grafiklerdeki kategorik renk paleti ile success/warning/error renkleri aynı sözlük değildir. Bir çubuk yalnız üçüncü seri olduğu için hata kırmızısı kullanıyorsa, kullanıcı grafik verisini durum semantiğiyle karıştırabilir.

Veri görselleştirmesinde paletler kullanım amacına göre ayrılmalıdır:

• kategorik,
• sıralı,
• iki uçlu / diverging,
• durum temelli.

Tipografi — Okunabilirlik, Ölçek ve Ritm

Tipografi yalnız font ailesi seçmek değildir. Yazı boyutu, ağırlık, satır yüksekliği, satır uzunluğu, harf aralığı, paragraf boşluğu ve sayı gösterimi birlikte bir okuma sistemi oluşturur.

Tek bir “standart font boyutu” yoktur

Web için 16 px sık kullanılan bir başlangıç noktasıdır; fakat bütün UI metinlerinin zorunlu ölçüsü değildir. Olgun tasarım sistemlerinde farklı bağlamlara göre farklı gövde ve etiket boyutları vardır. Önemli olan:

• metnin gerçek kullanım bağlamında okunabilir olması,
• tarayıcı büyütmesine dayanması,
• hiyerarşinin sınırlı ve tutarlı bir ölçekten gelmesi,
• küçük metnin ikincil bilgide dikkatle kullanılmasıdır.

rem gibi göreli birimler kullanıcının kök yazı boyutu tercihiyle daha iyi bütünleşebilir. Ancak yalnız birimi değiştirmek erişilebilir tipografi garantisi değildir.

Tipografik roller

Örnek bir semantik ölçek:

display
heading-xl
heading-lg
heading-md
body-lg
body
body-sm
label
caption
code

Bu adlar 18px, 20px gibi ham değerlerden daha anlamlıdır. Bir başlık rolü farklı viewport veya platformda gerektiğinde farklı ölçüye eşlenebilir.

Satır yüksekliği

Satır yüksekliği font boyutundan bağımsız düşünülmemelidir. Uzun metin genellikle sıkı UI etiketi metninden daha fazla satır aralığı ister.

WCAG Text Spacing kriteri, kullanıcı metin aralıklarını belirli değerlere kadar değiştirdiğinde içerik veya işlev kaybı olmamasını ister. Bu değerler varsayılan tasarım zorunluluğu değil, arayüzün kullanıcı tarafından yapılan aralık değişikliklerine dayanıklılık ölçütüdür.

Satır uzunluğu

4K ekranda paragrafı ekran boyunca uzatmak kullanılabilir alanı değerlendirmek değildir. Uzun satır, gözün bir sonraki satırın başlangıcını bulmasını zorlaştırabilir.

İçerik sitelerinde kontrollü bir max-width ve ch temelli okuma ölçüsü kullanılabilir. GOV.UK içerik düzeninde uzun satırları sınırlamayı tercih eder. Buna karşılık veri ızgarası veya zaman çizelgesi aynı genişlik sınırlamasına tabi olmak zorunda değildir.

Ağırlık ve vurgu

Hiyerarşiyi yalnız font boyutuyla kurmak gereksiz ölçek sıçramaları üretir. Boyutla birlikte:

• ağırlık,
• renk,
• boşluk,
• konum

kullanılabilir.

Tüm başlıkların kalın, büyük ve renkli olması hiyerarşi üretmez; her şeyi aynı anda bağırır hale getirir.

Büyük harf kullanımı

Uzun metinleri veya çok sayıda kontrol etiketini tamamıyla büyük harf yapmak okunabilirliği düşürebilir. Büyük harf gereken veri alanlarında ise Türkçe locale kuralları uygulanmalıdır; i/İ ve ı/I dönüşümü sıradan İngilizce casing mantığına bırakılamaz.

Sayısal veride tipografi

Tablo ve sayaçlarda rakam genişliklerinin değişmesi sütunların görsel olarak titreşmesine neden olabilir. Uygun font destekliyorsa tabular numerals kullanımı karşılaştırmayı kolaylaştırabilir.

Kod, sicil, hash veya teknik kimlik gibi alanlarda monospace yazı yararlı olabilir; bütün arayüzü monospace yapmak değildir.

Font yükleme davranışı

Web fontu seçimi performans ve yerleşim kararlılığı problemidir. geri dönüş (Fallback) font ile hedef fontun metrik farkı CLS üretebilir. Kritik uygulamada marka fontunun yüklenmesini beklemek ana görevi geciktirmemelidir.

System font stack bazı ürünlerde performans ve platform uyumu açısından daha doğru seçim olabilir. Tasarım kimliği gerektiriyorsa font dosyası, subset, preload ve geri dönüş metrikleri birlikte değerlendirilmelidir.

Boşluk, Izgara, Yoğunluk ve Boyutlandırma

Boşluk bir “güzel görünme” ayarı değil, ilişki ve ayrım dilidir. Aynı ekran içinde rastgele 11px, 13px, 17px, 23px değerleri kullanmak zamanla görsel sürüklenme üretir.

Margin, padding ve gap aynı şey değildir

• padding, bileşenin kendi sınırı ile içeriği arasındaki mesafedir.
• margin, bileşenin dış çevresindeki ilişkidir.
• gap, bir layout içindeki kardeş öğeler arasındaki ilişkiyi ifade eder.

Flex ve Grid düzenlerinde kardeşler arası mesafe için gap, tek tek öğelere yönsel margin dağıtmaktan daha öngörülebilir olabilir.

Mikro ve makro boşluk

Aynı spacing token her ölçekte aynı görevi görmez:

mikro:     ikon ↔ etiket
bileşen:   giriş alanı iç padding'i
kalıp:     form alanları arası mesafe
sayfa:     bölüm ve panel arası mesafe

Yakın öğeler ilişkili algılanır; daha büyük boşluk yeni grup sinyali verir. Bu Gestalt yakınlık ilkesinin doğrudan UI karşılığıdır.

Grid sistemi

Grid, ekrana görünür çizgiler çizmek değildir; hizalama kararlarını sınırlayan iskelettir. Şunlar ayrı kavramlardır:

• kolon,
• gutter,
• dış margin,
• içerik container'ı,
• nested grid,
• component-level grid.

12 kolon yaygın bir seçimdir fakat standart değildir. Form, dashboard ve medya düzenleri farklı grid yapıları kullanabilir.

CSS Grid ve Flexbox görev ayrımı

Flexbox çoğunlukla tek eksenli dağıtımda; CSS Grid iki eksenli düzenlerde daha doğal çalışır. Bu mutlak bir yasa değildir ama bir layout'u zorlayarak çözmek yerine veri ve hizalama ilişkisine uygun primitive seçilmelidir.

minmax(), auto-fit, auto-fill, min-content, max-content, fit-content ve subgrid gibi araçlar sabit piksel genişliklerine bağımlılığı azaltabilir.

İçerik container'ı ve çalışma alanı

Tek bir global max-width bütün sayfalara uygulanmamalıdır.

• uzun metin → kontrollü okuma genişliği,
• form → görev için yeterli fakat gereksiz genişlemeyen alan,
• veri ızgarası → mevcut genişliği kullanabilen çalışma yüzeyi,
• grafik/zaman çizelgesi → anlamlı biçimde genişleyebilen alan.

Bu nedenle tasarım sisteminde birden fazla sayfa container rolü bulunabilir.

UI yoğunluğu

“Daha ferah” her zaman “daha kullanılabilir” değildir. Gün boyu yüzlerce kayıt işleyen deneyimli operatör için aşırı boşluk daha fazla kaydırma, göz ve fare hareketi anlamına gelir.

Yoğunluk en az üç profile ayrılabilir:

compact
comfortable
spacious / touch-oriented

Ancak yoğunluk yalnız satır yüksekliğini küçültmek değildir. Kontrol hedefi, yazı okunabilirliği, satır seçimi, klavye gezinmesi ve yanlış tıklama riski birlikte değerlendirilmelidir.

Kontrol yüksekliği

Aynı uygulamada eşdeğer düğme, input ve select'lerin rastgele farklı yüksekliklerde olması hizalamayı ve ritmi bozar. Bir kontrol ölçeği tanımlanabilir:

small
medium
large

Ham piksel değerleri tasarım sistemine bağlıdır. Dokunmatik kullanımda görsel kontrol küçük görünse bile etkileşim alanı yeterince büyük tutulmalıdır.

Köşe yarıçapı ve kenarlık

Radius görsel kimlik unsurudur fakat her bileşenin ayrı radius değeri üretmesi gerekmez. Sınırlı bir ölçek yeterlidir:

radius-sm
radius-md
radius-lg
radius-pill

pill biçimi özel semantik veya belirli bileşenler için ayrılabilir. Her kartı, input'u ve paneli aşırı yuvarlatmak bilgi hiyerarşisi üretmez.

Kenar çizgilerinde de subtle / default / strong gibi roller, rastgele gri tonlardan daha sürdürülebilirdir.

Yüzey, Elevation, İkonografi ve Hareket

Bir uygulamanın “aynı tasarım dilini” konuşması yalnız renk ve spacing ile bitmez. Katman, ikon ve hareket davranışı da ortak sözlüğe bağlanmalıdır.

Yüzey ve elevation

Her paneli gölgeyle karta dönüştürmek görsel hiyerarşi üretmez. Yüzeyler şu araçlarla ayrılabilir:

• arka plan tonu,
• kenarlık,
• boşluk,
• elevation/gölge.

Elevation, özellikle üstte duran veya geçici katmanı anlatmak için yararlıdır:

base
raised
sticky
popover/dropdown
modal
notification

Bu roller görsel elevation ile CSS z-index değerinin birebir aynı kavram olduğu anlamına gelmez.

Z-index sistemi

z-index: 99999 kısa vadeli çözüm, uzun vadeli stacking-context borcudur. Katmanlar sınırlı token setiyle tanımlanmalıdır. Modalın tooltip altında kalması veya dropdown'ın sticky header tarafından kesilmesi gibi sorunlar çoğu zaman plansız katman sisteminden çıkar.

Koyu temada elevation

Gölge koyu arka planda görünmeyebilir. Bu nedenle Atlassian gibi sistemler koyu temada yüzey rengini de yükseklik sinyali olarak kullanır. Tema değişince gölgeyi yalnız tersine çevirmek yeterli değildir.

İkon ailesi

Aynı arayüzde farklı kaynaklardan alınmış stroke, fill, perspektif ve optik ağırlığı farklı ikonları karıştırmak küçük ama sürekli bir tutarsızlık üretir.

İkon sistemi için:

• ortak grid,
• sınırlı boyut ölçeği,
• benzer stroke/fill dili,
• baseline ilişkisi,
• erişilebilir ad,
• ikon+metin aralığı

tanımlanabilir.

Metinsiz ikon yalnız anlamı gerçekten yerleşikse güvenlidir. Özel kurum işlevlerinde ikon yanında etiket daha güçlüdür.

Matematiksel ve optik hizalama

Bir üçgen oynat ikonunu kutunun geometrik merkezine koymak görsel olarak sola kaymış görünebilir. Daire, chevron ve asimetrik glyph'lerde optik düzeltme gerekebilir.

Bu, keyfî piksel ayarının meşrulaştırılması değildir. İstisna gerekiyorsa bileşen düzeyinde belgelenmiş ve tekrarlanabilir olmalıdır.

Hareket sistemi

Animation süre ve easing değerleri de token olabilir. Ama asıl soru “hangi easing modern görünüyor?” değildir:

Hareket hangi durum değişimini açıklıyor?

İyi hareket:

• kaynağın hedefe dönüşümünü anlatır,
• açılan katmanın nereden geldiğini gösterir,
• durum geçişini görünür kılar,
• kullanıcının dikkatini gerekli yere taşır.

Gereksiz hareket ise gecikme hissi ve dikkat bölünmesi üretir.

prefers-reduced-motion yalnız animasyonu tamamen kapatmak olarak düşünülmemelidir. Anlam taşıyan geri bildirim korunurken hareket yoğunluğu azaltılabilir.

Modüller Arası Görsel ve Davranışsal Tutarlılık

Büyük uygulamalarda en sık görülen tasarım borçlarından biri, her modülün zamanla kendi küçük tasarım sistemini üretmesidir.

Bir modülde:

Kaydet = mavi, sağ alt, Ctrl+S

başka modülde:

Kaydet = yeşil, üst toolbar, kısayol yok

olduğunda sorun yalnız estetik değildir. Kullanıcı her modülde aynı kavramı yeniden öğrenir.

Tutarlılık katmanları

Aynı ürün ailesinde şu katmanlar ayrı ayrı denetlenmelidir:

1. terminoloji,
2. renk ve tipografi,
3. spacing ve component anatomy,
4. eylem hiyerarşisi,
5. hata/yükleme/başarı geri bildirimi,
6. klavye davranışı,
7. modal/yan panel kalıpları,
8. responsive dönüşüm,
9. boş/okuma/yükleme durumları.

Görsel olarak aynı iki bileşenin farklı davranması, farklı görünen ama aynı davranan bileşenden daha tehlikeli olabilir; çünkü kullanıcı yanlış bir beklenti geliştirir.

Bileşen anatomisi

Örneğin standart bir form alanı yalnız <input> değildir:

label
optional/required state
control
helper text
validation message
loading/read-only/disabled state

Bu anatomiyi her modül yeniden kurarsa hata gösterimi ve spacing zamanla ayrışır.

Eylem hiyerarşisi

Birincil, ikincil, üçüncül ve yıkıcı eylemler tüm uygulamada aynı görsel dil ve benzer konum mantığıyla sunulmalıdır.

Her ekranda üç tane “primary” düğme varsa primary kavramı anlamını kaybeder.

Yıkıcı eylem yalnız kırmızı renkten ibaret değildir. Etiket, kapsam, konum ve onay/geri-alma modeli birlikte çalışır.

Tasarım sürüklenmesi

Design drift şu belirtilerle görülebilir:

• aynı butonun beş padding varyantı,
• aynı panelin dört radius değeri,
• benzer hata için üç farklı kırmızı,
• aynı toolbar'ın farklı yükseklikleri,
• aynı loading durumu için farklı spinner kalıpları.

Bunlar tek tek küçük görünür; toplamda ürünün öğrenilebilirliğini ve bakım maliyetini artırır.

Tutarlılık dogma değildir

Farklı görev gerçekten farklı bir bileşen gerektiriyorsa mevcut kalıba zorlanmamalıdır. Ancak farkın gerekçesi “bu ekranı başka ekip yaptı” olmamalıdır.

Yeni varyant için yararlı süreç:

mevcut kalıp yetmiyor
      ↓
görev farkını tanımla
      ↓
erişilebilirlik/davranış sınırını belirle
      ↓
yeni varyantı üret
      ↓
belgele ve ortaklaştır

Tasarım Tokenlarını CSS Custom Properties ile Uygulamak

Tasarım tokenı kavramı soyut bir tasarım sistemi öğesi olarak kalmamalıdır. Web uygulamasında CSS custom properties, semantik kararları çalışma zamanında kullanılabilen bir sözleşmeye dönüştürmek için doğal bir araçtır.

Katmanlı düşünmek yararlıdır:

ilkel değer
   ↓
semantik token
   ↓
bileşen tokenı
   ↓
bağlama duyarlı override

Örneğin doğrudan her bileşene 12px, 14px, 36px yazmak yerine; boşluk, kontrol yüksekliği, yüzey, kenarlık ve tipografi kararları semantik değişkenlerle ifade edilebilir. Böylece dark/light tema, rahat/kompakt yoğunluk, coarse/fine pointer ve dar/geniş container gibi durumlar bileşen kodunu çoğaltmadan yönetilebilir.

Ancak tokenlaştırma da amaç değildir. Her tekil piksel değeri için değişken üretmek okunabilirliği azaltabilir. Token, birden fazla tüketicisi olan veya sistem düzeyinde anlam taşıyan karar için değerlidir.

calc(), min(), max() ve clamp() ile sınırlı akışkanlık

Akışkan değerler responsive tasarımda yararlıdır; fakat sınırsız ölçekleme ergonomiyi bozabilir. Büyük ekranda kontrollerin küçülmesi veya küçük ekranda metnin okunamaz hale gelmesi, “responsive” olmanın göstergesi değildir.

Bu nedenle tipografi, boşluk ve kontrol boyutlarında şu model tercih edilmelidir:

minimum okunabilir/kullanılabilir sınır
        +
bağlama göre akışkanlık
        +
maksimum görsel denge sınırı

Bu yaklaşım özellikle uzun ömürlü iş uygulamalarında önemlidir; çünkü ekran büyüdükçe asıl kazanç kontrol küçültmek değil, daha fazla yararlı çalışma alanı sunmaktır.

Font Yükleme, Layout Stabilitesi ve Değişken Fontlar

Tipografi yalnız font ailesi ve puntodan ibaret değildir. Web fontunun geç yüklenmesi metin ölçülerini değiştirebilir, layout kaymasına yol açabilir ve kullanıcıya önce boş veya farklı fontlu bir yüzey gösterebilir. Bu nedenle font seçimi aynı zamanda performans ve layout stabilitesi kararıdır.

font-display, uygun fallback font zinciri, gerekirse font-size-adjust/size-adjust gibi araçlar ve gereksiz font varyantlarını taşımamak algılanan kaliteyi etkiler. Variable fontlar çok sayıda ağırlık veya ekseni tek bir font kaynağında sunabilir; fakat dosya boyutu, kullanılan eksenler ve gerçek ihtiyaç birlikte değerlendirilmelidir.

Tablolar ve sayısal paneller için font-variant-numeric gibi özellikler de salt estetik değildir. Hizalı/tabular rakamlar, değişen sayıların sütun içinde daha kararlı okunmasına yardımcı olabilir.

Modern Renk ve SVG: Gelişmişlikten Önce Dayanıklılık

OKLab/OKLCH, geniş gamut renkler, color-mix() veya relative color gibi yeni renk araçları daha öngörülebilir tema ve ton üretimine imkân verebilir. Bununla birlikte temel görev veya kontrast gereksinimi yalnız yeni bir renk özelliğinin desteğine bağlanmamalıdır. Yeni renk yetenekleri, geçerli fallback renklerin üzerine eklenen geliştirme katmanı olarak düşünülmelidir.

SVG için de benzer ilke geçerlidir. SVG; keskin ölçeklenebilir ikonlar, tema uyumu ve tekrar kullanılabilir semboller için güçlüdür. Fakat erişilebilir adlandırma, title/açıklama gereksinimi, dekoratif öğelerin yardımcı teknolojiden gizlenmesi ve dış kaynağın güvenilir biçimde yüklenmesi görsel kaliteden ayrı ele alınmalıdır. Optimize edilmiş bir SVG yalnız daha küçük dosya değil, daha temiz ve sürdürülebilir bir ikon altyapısı anlamına gelir.

Ünite 9: İleri İş Akışları, Veri Görselleştirme ve Cihaz Sürekliliği

İleri Düzey Sihirbaz Tasarımı — Akıştan Durum Makinesine

Önceki sihirbaz bölümünde ne zaman lineer akışın yararlı olduğunu ele aldım. Daha karmaşık uygulamada sihirbaz artık yalnız ekranları sıraya dizme problemi değildir; bir durum makinesidir.

Wizard ile stepper aynı şey değildir

Wizard  = iş akışı ve geçiş kuralları
Stepper = ilerlemenin görsel temsili

Stepper olmadan wizard olabilir. Stepper da yalnız bilgi gösterebilir ve doğrudan gezinme sağlamayabilir.

USWDS adım göstergesi, ileri/geri gezinmenin ayrı kontrollerle sunulmasını ve her adımın ayrıca açık bir başlığa sahip olmasını önerir.

Durum modeli

Bir adım için yalnız active=true/false yetersizdir. Daha gerçekçi durumlar:

not-started
current
valid
complete
error
skipped
locked
stale

Her ürün bunların tümüne ihtiyaç duymaz; ancak kullanılan durumlar açık tanımlanmalıdır.

Önceki adım değişirse ne olur?

Örneğin:

1. Birim seçildi
2. Yetkiler seçildi
3. Onay hazırlandı

kullanıcı 1. adıma dönüp birimi değiştirirse 2. ve 3. adımın verisi hâlâ geçerli olmayabilir.

Bu durumda sistem:

• sonraki adımları geçersiz kılabilir,
• etkilenen alanları yeniden doğrulayabilir,
• kullanıcıya neyin sıfırlandığını açıklayabilir.

Sessizce eski yetkileri yeni birime taşımak veri bütünlüğü hatasıdır.

Lineer ve lineer olmayan akış

Lineer wizard:

1 → 2 → 3 → 4

Lineer olmayan süreç:

A, B, C görevlerini istenen sırada tamamla

İkinci durumda stepper yerine görev listesi daha doğru olabilir. Dinamik olarak değişen, kullanıcının istediği sırayla tamamladığı veya günler içinde sürdürülen süreçleri lineer wizard'a zorlamak ilerleme göstergesini yanıltıcı hale getirir.

Dallanma

Bazı cevaplar sonraki adımları değiştirebilir:

A seçildi → 2, 3, 5
B seçildi → 2, 4, 5

Toplam adım sayısını baştan “5 adım” diye göstermek bu durumda yanlış olabilir. İlerleme metni gerçek akış modeliyle tutarlı olmalıdır.

Kaydet ve devam et

Uzun süreçlerde geçici taslak sunucu tarafında saklanabilir. Bu özellik:

• oturum zaman aşımına,
• tarayıcı kapanmasına,
• cihaz değişimine

dayanıklılık sağlar.

Ancak taslak kaydı erişim kontrolü, hassas veri ve sürümleme gerektirir. Local storage'a formun tamamını bırakmak otomatik olarak doğru çözüm değildir.

Adım doğrulaması

Her adımın sonunda yalnız istemci doğrulaması değil, o adımın sunucu tarafı iş kuralları da doğrulanabilir. Son ekranda ilk kez bütün doğrulamayı yapmak kullanıcıyı sürecin sonundan başına geri yollar.

Buna karşılık sonraki adıma etkisi olmayan pahalı doğrulamayı her küçük değişiklikte tekrar çalıştırmak da gereksiz gecikme üretebilir.

Erişilebilir ilerleme

İlerleme yalnız görsel çizgi veya numaralı daire olmamalıdır. Mevcut adım ve toplam adım metin olarak anlaşılabilmeli; sayfa başlığı ve ana başlık da kullanıcının konumunu desteklemelidir.

Tamamlanan adıma tıklanabiliyorsa bunun bağlantı olduğu klavye ve ekran okuyucu tarafından da anlaşılmalıdır.

Mobil wizard

Uzun yatay stepper dar ekranda sıkıştırılmamalıdır. Alternatifler:

Adım 3 / 7
Yetkiler

veya kısa dikey/özet progress gösterimidir.

İş akışı aynı kalır; ilerleme temsilinin yoğunluğu ortama göre değişir.

Responsive Tasarımda Gerçek Ölçek — Genişlikten Fazlası

Responsive tasarımın önceki bölümünde viewport, container query ve reflow ele alındı. Üretim kabulünde bunlara yükseklik, zoom, sistem ölçekleme, locale ve giriş aygıtı da eklenmelidir.

CSS pixel ile fiziksel pixel aynı değildir

Bir 1920 × 1080 ekranın CSS viewport'u işletim sistemi ölçeklemesi ve tarayıcı zoom'una göre farklı olabilir. Bu nedenle test matrisi yalnız fiziksel çözünürlüğe göre kurulamaz.

Özellikle Windows ortamında %125, %150, %200 display scaling; tarayıcı zoom'u ile birlikte beklenmeyen dar CSS viewport üretebilir.

Yükseklik kırılmaları

Responsive tasarım genellikle genişlik üzerinden konuşulur. Oysa 1366 × 768 gibi yaygın bir laptopta:

• kalıcı üst bar,
• ikinci toolbar,
• breadcrumb,
• sabit alt eylem alanı

birlikte içeriğin dikey çalışma alanını ciddi biçimde azaltabilir.

Modal ve wizard ekranları kısa viewport yüksekliğinde ayrıca test edilmelidir.

Ultrawide ve 4K

Geniş ekran iki farklı fırsat sunar:

1. içeriği daha büyük göstermek,
2. aynı anda daha fazla ilişkili bağlam göstermek.

İş uygulamalarında ikincisi çoğu zaman daha değerlidir. Örneğin:

liste | ayrıntı | ilişkili bağlam

şeklinde split view kullanılabilir.

Ancak kullanıcının gözünü ekranın iki ucu arasında sürekli dolaştıran kontrol yerleşimi Fitts ve motor maliyetini artırabilir. Geniş alan kullanılmalı, fakat eylemler bağlamından koparılmamalıdır.

İçerik yeniden akışı ile işlev yeniden düzenleme

Dar ekrana geçişte yalnız kolonların alta düşmesi yeterli değildir. Component anatomy değişebilir:

masaüstü toolbar  → ana eylem + overflow
kalıcı sidebar    → drawer / daha kompakt navigation
çok sütunlu form  → tek sütun
ayrıntı paneli    → ayrı ekran
uzun tab listesi  → kontrollü scroll / alternatif seçici

Bu dönüşüm sırasında işlev kaybolmamalıdır.

Logical properties

margin-left ve padding-right gibi fiziksel yönlere bağlı CSS yerine uygun yerlerde:

margin-inline-start
padding-inline-end
inset-block-start

kullanmak LTR/RTL uyumunu kolaylaştırır.

Dil genişlemesi

Türkçe ve İngilizce aynı label uzunluğunu üretmez. Almanca gibi başka diller daha da uzun olabilir. Sabit genişlikte buton ve sekme tasarlamak localization'da kırılabilir.

Truncation kullanılıyorsa kullanıcı tam metne erişebilmelidir; kritik form etiketi sırf sığmadığı için ... ile anlamsız hale getirilmemelidir.

Safe area ve PWA

Tam ekran mobil/PWA yüzeylerinde çentik, sistem gesture alanı ve browser chrome dikkate alınabilir. env(safe-area-inset-*) gibi değişkenler gerektiğinde kullanılabilir.

Scroll mimarisi

Bir sayfada üç ayrı nested scroll bölgesi oluşturmak klavye, mouse wheel ve touch kullanıcıları için odak kaybı yaratabilir. Varsayılan olarak tek ana scroll yüzeyi daha öngörülebilirdir.

Nested scroll gerçekten gerekiyorsa:

• odak davranışı,
• scroll sınırı,
• sticky header,
• yatay scroll,
• scroll position restoration

test edilmelidir.

Veri Görselleştirme ve Gösterge Panelinde Grafik Tasarımı

Bir grafik dekorasyon değil, nicel bir iddiadır. Yanlış eksen veya yanlış renk, görsel estetikten daha ciddi biçimde yanlış anlam üretir.

Grafik türünü veri ilişkisi belirler

Genel eşleşmeler:

kategori karşılaştırma   → bar
zaman içindeki değişim   → line
parça-bütün              → sınırlı kategoride pie/donut düşünülebilir
iki sayısal değişken     → scatter
sıralı yoğunluk          → heatmap gibi uygun matris gösterimleri

Her veri setini donut chart'a çevirmek görsel çeşitlilik sağlar ama karşılaştırma doğruluğunu düşürebilir.

Eksen ve başlangıç noktası

Bar chart uzunluğu niceliği temsil ettiği için sıfırdan başlamayan eksen farkı abartabilir. Line chart'ta sıfır başlangıcı her zaman zorunlu değildir; değişimin ölçeği ve yorum bağlamı açık olmalıdır.

Dual-axis grafikler iki seriyi aynı şekil üzerinde ilişkilendiriyor gibi gösterebilir. Ölçek seçimi korelasyon izlenimini manipüle edebileceği için dikkatle kullanılmalıdır.

Veri-ink ve gürültü

Grid çizgileri, gölgeler, 3D efekt, yoğun gradient ve dekoratif çerçeveler veriyi okumaya katkı sağlamıyorsa azaltılabilir.

Zen yaklaşımı burada şu soruya dönüşür:

Bu piksel veriyi anlamaya yardım ediyor mu?

Renk seçimi

Kategorik palette kategoriler birbirinden ayırt edilebilir; sıralı palette büyüklük tonu veya açıklıkla ifade edilir; diverging palette merkez değerin iki yönü ayrılır.

Kırmızı-yeşil ayrımına tek başına güvenmek renk görme farklılıklarında sorun yaratabilir. Şekil, pattern, label veya doğrudan değer gerektiğinde ek kanal olarak kullanılmalıdır.

Tooltip tek bilgi kanalı değildir

Hover gerektiren tooltip:

• touch ekran,
• klavye,
• ekran okuyucu,
• çıktı/print

bağlamlarında yetersiz olabilir. Kritik değerler yalnız hover içinde saklanmamalıdır.

Grafik erişilebilirliği

Grafik için kısa açıklama, veri özeti veya uygun durumda tablo alternatifi sağlanabilir. Ekran okuyucuya yüzlerce SVG path okutmak tek başına erişilebilir veri görselleştirme değildir.

Gösterge panelinde sayı kartı

KPI kartı yalnız büyük sayı göstermemelidir. Anlam için bağlam gerekebilir:

Bekleyen kayıt: 125
Düne göre: +18
En eski kayıt: 3 gün

Trend, hedef veya risk yoksa büyük puntolu sayı çoğu zaman boş görsel ağırlıktır.

Görsel Kalite Güvencesi ve Tasarım Borcu

Çalışan UI'ın zaman içinde bozulmaması için tasarım ilkeleri yalnız dokümanda kalmamalıdır. Bazı kararlar otomatik veya yarı otomatik doğrulanabilir.

Görsel regresyon

Aynı bileşenin şu matrislerde ekran görüntüsü karşılaştırması yapılabilir:

viewport
× tema
× durum
× locale
× yoğunluk

Ama pixel-perfect screenshot diff tek başına kalite ölçütü değildir. Font rasterizasyonu veya platform farkı false-positive üretebilir. Ama beklenmeyen layout kayması, taşma ve kaybolan bileşeni yakalamada değerlidir.

Component state matrix

Her temel bileşen için en az şu durumlar incelenebilir:

default
hover
active
focus-visible
disabled
read-only
loading
error
selected

Bileşenin bütün durumları tasarım sisteminde yoksa ürün içinde rastgele stil üretme olasılığı yükselir.

Design linting

Kod tabanında aşağıdaki örüntüler tasarım borcu sinyali olabilir:

• izin verilmeyen hard-coded renk,
• token dışında spacing,
• rastgele z-index,
• tekrar eden özel radius,
• aynı component için lokal override zinciri,
• !important birikimi.

Bunların tümünü otomatik hata yapmak doğru olmayabilir. Önce envanter çıkarmak daha güvenli bir başlangıçtır.

Kabul matrisi

Bir responsive sayfayı yalnız bir telefon emülasyonunda test etmek yeterli değildir. Daha gerçekçi kabul eksenleri:

genişlik
× yükseklik
× zoom / OS scaling
× klavye/touch/mouse
× açık/koyu/yüksek kontrast
× locale
× reduced motion

Her kombinasyonu manuel test etmek zorunda değiliz; risk ve kullanım sıklığına göre temsilci matris seçilebilir.

Tasarım borcu metriği

Görsel tutarlılık tamamen öznel değildir. Örneğin şu değerler izlenebilir:

• aynı semantik düğme için kaç farklı height/padding var,
• kaç farklı gri metin rengi kullanılıyor,
• token dışı renk sayısı,
• duplicate component sayısı,
• modül başına özel override sayısı,
• erişilebilir kontrast ihlali,
• taşma üreten viewport sayısı.

Bu ölçümler “tasarım güzel mi?” sorusunu cevaplamaz; sistemin ne kadar kontrolsüz çeşitlendiğini gösterir.

Tasarım sistemi yönetişimi

Yeni bir component veya varyant eklenirken şu sorular sorulabilir:

1. Aynı görev için mevcut component var mı?
2. Var olan component neden yetmiyor?
3. Yeni davranış erişilebilir mi?
4. Responsive ve tema durumları tanımlı mı?
5. Klavye sözleşmesi belli mi?
6. Eski varyantın migration planı var mı?

Tasarım sisteminin amacı yeni fikirleri engellemek değil, aynı problemi her ekibin yeniden ve farklı biçimde çözmesini önlemektir.

Tasarım ile kod arasındaki sapma

Figma veya başka tasarım aracındaki component ayrı, üretim component'i ayrı evrimleşirse iki source of truth oluşur. Daha sürdürülebilir model, tasarım varlıklarının gerçek kod component API'si ve token adlarıyla mümkün olduğunca aynı sözlüğü kullanmasıdır.

Son sınır

Görsel standardizasyon davranışı bozmamalıdır. Üretimde çalışan kritik bir ekranı yalnız bütün ürün “aynı görünsün” diye yeniden düzenlemek doğru değildir.

En güvenli sıra:

envanter
  ↓
ortak token
  ↓
aynı semantiğe sahip düşük riskli bileşenleri birleştir
  ↓
davranış değişikliğini ayrı değerlendir
  ↓
gerçek görevle doğrula

Böylece görsel tutarlılık, operasyonel kararlılığın rakibi değil destekçisi olur.

Dokunma Hareketleri, Doğrudan Manipülasyon ve Çakışma Yönetimi

Dokunma hareketleri ekrandaki fiziksel hareket ile dijital sonucu doğrudan ilişkilendirebildiği için güçlüdür. Kaydırma, sürükleme ve yakınlaştırma gibi davranışlar bazı görevlerde ayrı bir kontrol aramaktan daha akıcı olabilir. Bununla birlikte görünmeyen bir hareketin varlığı kullanıcı tarafından kendiliğinden bilinmez.

Keşfedilebilirlik

Görünür düğme kendi varlığını gösterir. Gizli hareket göstermez. Bu nedenle temel işlev yalnız hareketle erişiliyorsa kullanıcı özelliğin mevcut olduğunu hiç öğrenmeyebilir.

Daha dayanıklı model:

Görünür temel yol
      +
isteğe bağlı hızlı hareket

Örneğin satır eylemi görünür bir menüden erişilebilir kalırken deneyimli kullanıcı desteklenen kaydırma hareketini hızlandırıcı olarak kullanabilir. Hareket, erişilebilir yolu ortadan kaldırmamalıdır.

Karmaşık çoklu dokunma hareketleri ikincil kalmalıdır

Birden çok parmak gerektiren hareketler motor kabiliyeti, cihazın fiziksel kullanımı ve keşfedilebilirlik bakımından daha yüksek varsayım taşır. Böyle bir hareket üretkenliği artırabilir; ancak temel görevin tek yolu haline geldiğinde erişilebilirlik riski doğurur.

Basit dokunma, görünür kontrol veya klavye yolu mümkün olduğunda korunmalıdır.

İşletim sistemi ve tarayıcı önce gelir

Ekran kenarları, geri gezinme, uygulamalar arası geçiş, yakınlaştırma veya bağlamsal menü gibi bazı hareketler işletim sistemi ya da tarayıcı tarafından sahiplenilebilir. Uygulama aynı fiziksel hareketi farklı anlamda kullanırsa iki sorun oluşur:

1. Kullanıcının yerleşik beklentisi bozulur.
2. Uygulama hareketi ile sistem hareketi fiziksel olarak yarışır.

Bu nedenle özellikle kenardan başlayan hareketler ve tarayıcıda yerleşik anlamı olan hareketler tasarlanırken platform davranışı rakip değil, üst sınır olarak görülmelidir.

Hareket yoğunluğu

Aynı yüzeyde çok sayıda benzer hareket tanımlamak hata olasılığını yükseltir. Örneğin yatay kaydırma aynı anda:

• kart değiştirme,
• satır eylemi açma,
• panel kapatma,
• tarayıcı geçmişinde geri gitme

anlamlarına gelebiliyorsa kullanıcı niyetini hareket geometrisinden güvenilir biçimde ayırmak zorlaşır.

Hareket sözlüğü küçük, tutarlı ve bağlama özgü tutulmalıdır. Bir hareketin anlamı ekranın birkaç piksel sağında tamamen değişiyorsa etkileşim kırılganlaşır.

Sürükle ve bırak için alternatif yol

Sürükleme doğrudan manipülasyon hissi sağlar; ancak hassasiyet, motor beceri ve uzun hareket mesafesi gerektirebilir. Özellikle sıralama veya taşıma görevlerinde alternatif komut yolu değerlidir:

Sürükle
veya
[Taşı] → hedefi seç → [Uygula]

Bu alternatif yalnız erişilebilirlik için değil, büyük veri kümelerinde ve hassas konumlandırmada da daha güvenilir olabilir.

Hareket öğretimi bağlam içinde olmalıdır

Açılışta bütün hareketleri anlatan uzun bir tur kısa sürede unutulabilir. Hareketin gerektiği anda küçük bir işaret, ilk kullanım ipucu veya görünür alternatif kontrol daha etkilidir. Öğretim, görevden kopuk bir ezber yüküne dönüşmemelidir.

Tablet, Hibrit ve Sabit Dokunmatik Yüzeyler

“Tablet düzeni” tek başına yeterli bir etkileşim tanımı değildir. Aynı boyuta yakın ekranlar farklı fiziksel bağlamlarda kullanılabilir:

elde tablet
masaya bırakılmış tablet
kalemli tablet
klavyeli hibrit
iki-bir-arada dizüstü
sabit stand/kiosk

Tablet

Elde kullanılan tablette tutuş değişkendir. Kullanıcı ekranı döndürebilir, ellerini değiştirebilir veya cihazı bir yüzeye bırakabilir. Yerleşim yalnız tek elle kullanım şemasına göre kilitlenmemelidir.

Hibrit bilgisayar

Hibrit sistemde dokunma, klavye ve hassas işaretçi rakip değil tamamlayıcıdır. Kullanıcı metin girişinde klavyeyi, büyük hedeflerde dokunmayı, ayrıntılı seçimde dokunmatik yüzeyi seçebilir. Arayüz bunlardan birini “asıl” kabul ederek diğerlerini ikinci sınıf hale getirmemelidir.

Özellikle yoğun iş uygulamalarında:

• dokunma hedefleri yeterli olmalı,
• klavye sırası ve kısayollar korunmalı,
• üzerine gelmeye bağlı tekil işlev bulunmamalı,
• odak göstergesi dokunma tasarımı uğruna kaldırılmamalıdır.

Sabit yüzey

Sabit ekranda cihaz ele uymaz; insan cihaza yaklaşır. Bu, erişim mesafesini ve yorgunluğu değiştirir. Elde kullanılan tablet için makul olan üst köşe işlemi, dikey büyük bir ekranda tekrar edildiğinde maliyetli olabilir.

Bu nedenle cihaz sınıfından önce kullanım bağlamı sorulmalıdır:

Ekran nerede?
Kullanıcı ne kadar uzakta?
Cihaz hareket ediyor mu?
Kullanıcı ayakta mı oturuyor mu?
Görev ne kadar sürüyor?
Hangi giriş yöntemleri aynı anda mevcut?

Duyarlı tasarım alanı yönetir; ergonomik tasarım insan ile yüzey arasındaki ilişkiyi yönetir.

Cihazlar Arasında Süreklilik — Duyarlı Tasarımdan Daha Geniş Bir Problem

Duyarlı tasarım yerleşimin değişmesidir. Çoklu cihaz deneyimi ise görevin devamlılığıdır.

Simple and Usable içindeki “displace” yaklaşımı ve mobil tasarım kaynakları, bazı işlerin farklı cihazlara veya bağlamlara taşınabileceğini gösterir.

Her iş her cihazda eşit derecede uygun değildir

Telefon:

• hızlı kontrol,
• bildirim,
• kısa onay,
• barkod/kamera,
• konum

için güçlü olabilir.

Masaüstü:

• büyük veri karşılaştırma,
• çok sütunlu ızgara,
• yoğun klavye,
• uzun düzenleme

için güçlüdür.

İşlev eşdeğerliği her zaman doğru hedef değildir

“Masaüstünde 47 özellik varsa telefonda da 47 özellik aynı anda görünmeli” yaklaşımı yanlış olabilir.

Doğru hedef:

Kullanıcının mobilde gerçekten tamamlaması gereken görevler eksiksiz ve güvenli mi?

Devamlılık

Örnek:

Telefonda bildirimi gör
→ görevi kaydet
→ masaüstünde kaldığın bağlamdan devam et

Durum aktarımı

• taslak,
• son kullanılan öğe,
• kaydedilmiş arama,
• görev durumu

gibi bağlamlar cihazlar arasında güvenli biçimde korunabilir.

Hassas veri ve paylaşılan cihaz senaryolarında bu süreklilik gizlilikle birlikte değerlendirilmelidir.

Her cihazı aynı ekrana zorlamayın; aynı amacı cihazın doğasına uygun biçimde sürdürün.

Breakpoint Kullanmadan Uyarlanabilen Kompozisyon

Her responsive değişiklik için yeni bir media query eklemek zamanla kırılma noktası enflasyonu üretir. CSS Grid ve Flexbox bazı düzen problemlerini eşik yazmadan çözebilir. Özellikle repeat(), minmax(), auto-fit ve auto-fill; kart, özet paneli veya araç grubu gibi tekrar eden alanların mevcut alana göre kendini düzenlemesini sağlar.

Örnek düşünce:

.panel-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(18rem, 100%), 1fr));
}

Buradaki önemli fikir kod satırı değil, tasarımın hangi durumda eşiğe gerçekten ihtiyaç duyduğunu sorgulamaktır. İçerik doğal olarak satır kırabiliyor ve minimum kullanılabilir genişlik tanımlanabiliyorsa, sabit cihaz eşikleri yerine layout motorunun alanı paylaşmasına izin vermek daha dayanıklı olabilir.

subgrid gibi özellikler ise iç içe bileşenlerin bağımsız hizalama sistemleri üretmesi yerine üst ızgaranın hizasını paylaşmasına yardım edebilir. Bu özellikle form etiketleri, kartlar veya çok sütunlu veri özetlerinde görsel ritmi korumak için değerlidir.

Breakpoint yine gereklidir; ancak rolü “her cihaz için ayrı layout” değil, kompozisyonun gerçekten nitelik değiştirdiği anı ifade etmektir.

Gerçek Cihaz Testi: Emülasyon ile Aynı Şey Değildir

Tarayıcı geliştirici araçları viewport, DPR, ağ hızı ve bazı input koşullarını taklit etmek için çok değerlidir; ancak fiziksel cihaz doğrulamasının yerine bütünüyle geçmez. Gerçek cihaz şu farkları görünür kılabilir:

• gerçek parmak ve kalem hassasiyeti,
• yazılım klavyesinin viewport üzerindeki etkisi,
• tarayıcı chrome alanı,
• düşük güçlü cihazlarda kaydırma ve animasyon maliyeti,
• font rasterizasyonu ve fiziksel okunabilirlik,
• split-screen ve yönelim değişiminin gerçek davranışı.

Bu nedenle emülasyon hızlı regresyon matrisi, fiziksel cihaz ise ergonomi ve gerçek çevre doğrulaması olarak düşünülmelidir.

Büyük veri görsellerinde çözünürlük ve toplulaştırma

Milyonlarca gözlemi aynı piksel alanına çizmek bilgi miktarını artırmaz; çok sayıda nokta üst üste biner ve yoğun bölgeler yanlış okunabilir. İki boyutlu bölmelere ayırma, yoğunluk veya sayım temelli özetleme ve uygun örnekleme bu nedenle yalnız performans optimizasyonu değil, analitik temsil kararıdır. Bölme genişliği, renk ölçeği ve dışlanan kayıtların sayısı görüntülenen örüntüyü değiştirebilir. Grafiğin yakınlaştırma düzeyine göre ayrıntı artırılıyorsa aynı filtre altında sayı toplamlarının korunması ve etkileşimlerin sonucu sessizce yeniden tanımlamaması gerekir.

Bir kümeleme ya da sınıflandırma modelinin çıktısını görselleştirmek ile modelin veri üzerindeki davranışını açıklamak farklı görevlerdir. Kısmi bağımlılık grafiği, ilgili değişken değiştirilirken diğer değişkenlerin belirli bir dağılım üzerinde ortalanmasıyla elde edilir; güçlü korelasyonda veride karşılığı bulunmayan özellik birleşimlerini değerlendirebilir. Bireysel koşullu beklenti eğrileri örnekler arası farklılığı gösterebilir, fakat bunlar da otomatik olarak nedensel etki sunmaz. Kullanıcı grafik üzerindeki türetilmiş bulgudan değerlendirmeye giren alt kümeye ve özgün kayda geri dönebilmelidir.

Belirsizlik gösteriminde tek bir error bar yerine kuantiller veya olası sonuç gösterimleri kullanılması, özellikle asimetrik dağılımlarda daha doğru sezgi sağlayabilir. Ancak her görselin kapsadığı olasılık tanımı belirtilmelidir. Bir olasılık dağılımından üretilen örnekleri gerçek geçmiş gözlemlerle aynı gösterge diliyle sunmak, tahmin ile ölçümü karıştırır.

Ünite 10: İleri Okuma ve Sonuç

Önerilen Kitaplar

Aşağıdaki eserler etkileşim kalıpları, insan hatası, form tasarımı, bilgi mimarisi, biliş, arayüz metni, prototipleme ve kritik sistemlerde hata maliyeti gibi farklı karar katmanlarını tamamlar.

1. Designing Interfaces, 3rd Edition

Jenifer Tidwell, Charles Brewer, Aynne Valencia — O'Reilly

Kapsam:

• etkileşim kalıpları,
• bilgi mimarisi,
• gezinme,
• yerleşim,
• formlar,
• veri,
• duyarlı/mobil,
• karmaşık uygulama kalıpları.

Etkileşim kalıpları ve uygulama deseni açısından temel başvuru kaynaklarından biridir.

2. The Design of Everyday Things — Revised and Expanded Edition

Don Norman

Kapsam:

• eylem olanağı,
• işaretleyici,
• geri bildirim,
• eşleme,
• kısıtlar,
• kavramsal model,
• insan hatası,
• insan merkezli tasarım.

UI bileşeninden daha temel seviyede tasarım düşüncesi sağlar.

3. Don't Make Me Think, Revisited

Steve Krug — New Riders, 3rd edition

Web ve mobil kullanılabilirlik, taranabilirlik, gezinme ve kullanılabilirlik testi için kısa fakat güçlü bir temel kaynaktır.

4. Web Form Design: Filling in the Blanks

Luke Wroblewski

Form akışı, etiket, eylem, hata ve veri girişi problemlerine odaklanır.

5. Information Architecture, 4th Edition

Louis Rosenfeld, Peter Morville, Jorge Arango — O'Reilly

Organizasyon, etiketleme, gezinme, arama ve bulunabilirlik konularını arayüzün üst katmanında ele alır.

6. 100 Things Every Designer Needs to Know About People

Susan M. Weinschenk

Dikkat, bellek, algı, okuma, karar verme, hata ve sosyal davranışın tasarıma etkisini pratik başlıklarla ele alır. Dikkat, bellek, görünürlük ve tanıma/hatırlama ilkeleri açısından yararlı bir başvuru kaynağıdır.

7. Design for How People Think

John Whalen

Kullanıcının yalnız ne yaptığına değil, bağlam içinde nasıl düşündüğüne ve bilgiyi nasıl işlediğine odaklanır. Tasarım kararlarının kullanıcı görevi ve araştırmayla ilişkilendirilmesi açısından değerlidir.

8. Designing UX: Forms

Jessica Enders

Formu yalnız alan yerleşimi değil; soruyu anlama, cevabı bulma, uygunluğu değerlendirme ve fiziksel girdi zinciri olarak işler. Kamu, sağlık ve kurumsal form bağlamları açısından özellikle değerlidir.

9. Designing UX: Prototyping

Ben Coleman, Dan Goodwin

Düşük/yüksek aslına uygunluk düzeyi prototipler, test amacı, araç seçimi ve gerçek kullanıcıyla davranış doğrulamasını ele alır.

10. Laws of UX

Jon Yablonski — 1. ve 2. baskı notları

Jakob, Fitts, Hick, Tepe–Son, aesthetic-usability, von Restorff ve Tesler gibi ilkeleri erişilebilir biçimde toplar. Bu ilkeler “evrensel yasa” değil, görev bağlamında doğrulanması gereken tasarım hipotezleridir.

11. Simple and Usable

Giles Colborne — 2. baskı

Sadeleştirmeyi kaldırma, düzenleme, gizleme ve yer değiştirme stratejileri üzerinden ele alır. “Sadelik = daha az öğe” yanılgısını aşmak için en yararlı kaynaklardan biridir.

12. Strategic Writing for UX, 2nd Edition

Torrey Podmajersky

Başlık, etiket, düğme, bildirim, hata ve geçiş metni gibi arayüz metinlerini sistematik kalıp olarak ele alır. Kaynak paketindeki baskı 2025 güncellemesini ve LLM tabanlı deneyimlerde içerik tasarımını da kapsar.

13. Tragic Design

Jonathan Shariat, Cynthia Savard Saucier

Kötü tasarımın yalnız memnuniyetsizlik değil, gerçek zarar üretebildiği durumları ele alır. Güvenlik, hata önleme ve kritik bilginin görünürlüğü bölümlerine doğrudan katkı sağlar.

14. The Elements of User Experience

Jesse James Garrett — 2. baskı

UX’i strateji, kapsam, yapı, iskelet ve yüzey düzlemleri üzerinden katmanlandırır. Bir görsel kararın neden daha alt seviyedeki kullanıcı ihtiyacı ve kapsam kararlarından kopuk ele alınmaması gerektiğini açıklaştırır.

15. Emotional Design

Donald A. Norman

İşlevsel kullanılabilirliğin yanı sıra ürünün ilk algı, kullanım ve uzun dönem anlam katmanlarını değerlendirmeye yardımcı olur.

16. Effective UI

Jonathan Anderson, John McRee, Robb Wilson ve EffectiveUI ekibi

Kullanıcı deneyiminin yalnız ekran değil; ekip, süreç, mühendislik ve sürekli değerlendirme problemi olduğunu destekler.

17. The Psychology of Human-Computer Interaction

Stuart K. Card, Thomas P. Moran, Allen Newell — 1983; CRC Press yeniden basım 2008

Görev analizi, GOMS, Tuş Vuruşu Düzeyi Modeli ve bilişsel beceriyi mühendislik modeline dönüştürür. Özellikle klavye/fare ağırlıklı, tekrarlanan ve zaman maliyeti önemli iş akışlarında alternatif yöntemleri karşılaştırmak için güçlüdür. Eserdeki tarihsel süre sabitleri modern donanım için evrensel değerler olarak değil, modelin nasıl kurulduğunu gösteren deneysel bağlam olarak okunmalıdır.

18. Quantifying the User Experience: Practical Statistics for User Research

Jeff Sauro, James R. Lewis — Morgan Kaufmann / Elsevier, 2012

Görev tamamlama oranı, görev süresi, hata, memnuniyet, örneklem büyüklüğü, güven aralıkları, referans değerlerle karşılaştırma ve kullanıcı araştırması verisinin istatistiksel yorumlanmasını birlikte ele alır. Tasarım kararını yalnız gözleme değil, ölçümün taşıdığı belirsizliğe de bağlamak için değerlidir.

19. Designing Mobile Interfaces

Steven Hoober, Eric Berkman — O'Reilly, 2011

Mobil arayüzleri tek tek ekran örneklerinden ziyade tekrar eden etkileşim kalıpları, insan faktörleri ve cihaz kısıtları üzerinden ele alır. Tarihsel platform ayrıntıları eskimiş olabilir; kalıp, fiziksel bağlam ve kontrol seçimi arasındaki ilişki hâlâ öğreticidir.

20. Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps

Theresa Neil — O'Reilly, 2014

Gezinme, formlar, tablolar, arama, araçlar ve yardım gibi mobil arayüz problemlerini kalıp ve karşı-kalıp yaklaşımıyla sınıflandırır. Belirli ürün ekranlarını kopyalamak için değil, aynı görev problemine farklı çözümlerin nasıl karşılaştırılabileceğini görmek için değerlidir.

21. Touch Design for Mobile Interfaces

Steven Hoober — Smashing Media AG, 2021

Dokunmatik etkileşimi ekran çözünürlüğünden daha geniş bir insan faktörleri problemi olarak inceler. Temas alanı, örtülme, doğruluk, fiziksel kullanım bağlamı ve sabit varsayımların ölçümle sınanması, dokunma ergonomisinin temel boyutlarıdır.

Bu eserler farklı karar katmanlarını tamamlar: etkileşim kalıpları, insan hatası, form tasarımı, bilgi mimarisi, biliş, arayüz metni, prototipleme ve kritik sistemlerde hata maliyeti. Kaynağa dayalı bulgular ile mühendislik sentezi birbirinden ayrılmalı; bir eserde doğrulanmayan ayrıntı o eserin görüşüymüş gibi aktarılmamalıdır.

Metin editöründe mikro-istatistikler ve ilerlemeli açıklama

Bir metin editörü kullanıcıya yararlı ölçümler sunabilir; bunun için ayrı bir gösterge paneli oluşturmak gerekmez. Kelime, karakter, cümle veya okuma süresi gibi değerler yazma işinin destekleyicisidir, asıl görev değildir. Zen yaklaşımı burada hesaplanabilen her şeyi sürekli göstermemek anlamına gelir.

Örneğin not alanında tek satır:

183 kelime · 1.164 karakter

makale alanında ise:

1.428 kelime · ~6 dk

yeterli olabilir. Kullanıcı ayrıntıyı açtığında harf, boşluksuz karakter, cümle, paragraf, ortalama cümle uzunluğu ve en uzun paragraf gibi ikincil ölçüler gösterilebilir. Bu, ilerlemeli açıklamanın (progressive disclosure) küçük fakat somut bir örneğidir: bilgi kaybolmaz, yalnız ihtiyaç anına kadar görsel önceliği düşürülür.

İstemci tarafındaki hesap için ağır bir NLP katmanı gerekmez. Metin tek geçişte taranarak:

kelime
Unicode karakter
harf
boşluksuz karakter
cümle
paragraf
satır

sayıları O(n) zamanda çıkarılabilir. Aynı geçişte cümle ve paragraf başına kelime sayıları tutulursa ortalama ve en uzun değerler ikinci bir tam tarama gerektirmez.

Tarayıcı desteği varsa kelime ve cümle sınırında Intl.Segmenter kullanmak, basit boşluk bölmeden daha güvenilir bir Unicode davranışı sağlar. Desteklenmeyen ortamda yerel, Unicode-aware bir geri dönüş kullanılabilir. Karakter sayısında JavaScript string.length doğrudan kullanılmamalıdır; bu değer UTF-16 code unit sayısıdır ve bazı Unicode karakterlerini iki birim sayabilir. Kullanıcıya gösterilen karakter kavramının ne olduğu açık olmalıdır.

Her tuş vuruşunda metnin tamamını yeniden taramak kısa metinde fark edilmese de gereksiz çalışmadır. Basit çözüm:

input
  ↓
250 ms debounce
  ↓
tek O(n) tarama
  ↓
yalnız değişen DOM değerlerini güncelle

şeklindedir. Hızlı yazım sırasında bekleyen hesap iptal edilir ve son durum işlenir. Bu ölçümler save/autosave ile aynı işlem zincirine bağlanmamalıdır; istatistik hesabının gecikmesi veri kaydını geciktirmemeli, istatistik hatası dirty-state veya revision davranışını değiştirmemelidir.

Programatik .value değişiklikleri ayrıca düşünülmelidir. Sunucudan yeni içerik yükleme, revision kabulü, conflict çözümü veya büyük/küçük harf dönüşümü tarayıcıda otomatik input olayı üretmeyebilir. Bu nedenle editör içeriğini değiştiren mevcut güvenilir yollar istatistik yenilemeyi açıkça tetikleyebilir; fakat kaydetme akışının kendisi değişmez.

Seçili metin için aynı hesaplayıcı yeniden kullanılabilir:

Seçili: 86 kelime · 517 karakter

Seçim kalkınca bütün belge istatistiğine dönülür. Böylece kullanıcı kopyalayacağı veya yeniden düzenleyeceği bölümün büyüklüğünü yeni bir modal açmadan görebilir.

Tahmini okuma süresi kesin süre gibi verilmemelidir. Örneğin sabit 250 kelime/dakika kabulüyle:

reading_minutes ~= word_count / 250

hesaplanabilir ve sonuç ~6 dk biçiminde yuvarlanabilir. Saniye göstermek ölçümün sahip olmadığı bir hassasiyet izlenimi verir.

Türkçe uzun metinlerde isteğe bağlı bir yapısal ölçü Ateşman okunabilirlik formülüdür:

R = 198.825
    - 40.175 * (hece / kelime)
    - 2.610  * (kelime / cümle)

Ateşman'ın 1997 tarihli çalışması Türkçe metinlerde kelime ve cümle uzunluğunu kullanır (Türkçede Okunabilirliğin Ölçülmesi, Ankara Üniversitesi TÖMER Dil Dergisi, 58). Puan yaklaşık olarak 90-100 çok kolay, 70-89 kolay, 50-69 orta, 30-49 zor, daha düşük değerler çok zor biçiminde sınıflandırılabilir. Ancak okunabilirlik metin kalitesi değildir. Formül doğruluk, içerik değeri, uzmanlık düzeyi veya okurun metni gerçekten anlayıp anlamadığını ölçmez.

Bu nedenle bir arayüzde "Ateşman: 57,4" değerini sürekli göstermek yerine "Okunabilirlik: Orta" ifadesi yeterli olabilir; ham değer ayrıntıda kalır. Çok kısa metinde, dili güvenilir biçimde bilinmeyen içerikte veya düzgün cümle yapısının beklenmediği not alanında bu ölçümü hiç göstermemek yanlış kesinlik üretmekten daha iyidir.

En önemli mimari sınır gizliliktir. Bu ölçümler yalnız editörün mevcut değeri üzerinden istemcide hesaplanabiliyorsa sırf kelime saymak veya okunabilirlik çıkarmak için metnin sunucuya yeniden gönderilmesine gerek yoktur:

textarea value
    ↓
geçici istemci istatistiği
    ↓
kullanıcı arayüzü

Veri tabanına yazılmayan, telemetry üretmeyen ve ağ isteği oluşturmayan bu yapı hem istemciyi hem sunucuyu gereksiz işten korur. Karmaşık hesap değil, doğru sınırlandırılmış küçük bir özellik iyi UX üretir.

Sonuç

UI/UX mühendisliği tek bir tasarım formülüne indirgenemez. UI/UX kararları, birbirine rakip kısayollar arasından birini seçmekten çok, görevin ve riskin sınırlarını doğru kurma işidir.

Ne:

altın oran

ne:

3 tıklama

ne:

mobil öncelikli tasarım

ne de:

Amazon böyle yapıyor

tek başına tasarım kararı için yeterlidir.

Daha sağlam bir karar sırası şöyledir:

Kullanıcı görevi
      ↓
Bilgi mimarisi
      ↓
Yerleşik konvansiyon
      ↓
Erişilebilir semantik
      ↓
Görsel ve etkileşimsel hiyerarşi
      ↓
Güvenilir istek/durum modeli
      ↓
Duyarlı davranış
      ↓
Performans
      ↓
Gerçek kullanıcı ölçümü
      ↓
İterasyon

UI/UX mühendisliğinin temel amacı kullanıcının dikkatini tasarıma çekmek değil, işini doğru ve öngörülebilir biçimde yapabilmesini sağlamaktır.

Modern görünmek için çalışan alışkanlığı bozmak UX değildir. Aynı şekilde “kullanıcı alışmış” diyerek doğruluk, erişilebilirlik veya veri kaybı riskini sürdürmek de doğru değildir.

En güçlü arayüz, kullanıcının:

• nerede olduğunu bildiği,
• ne yapacağını gördüğü,
• sistemin ne yaptığını anladığı,
• hatadan kurtulabildiği,
• verisinin kaybolmayacağına güvendiği,
• deneyim kazandıkça daha hızlı çalışabildiği

arayüzdür.

Zen merceğiyle son denklem daha da kısaltılabilir:

Gereksizi kaldır.
Gerekliyi görünür kıl.
Karmaşıklığı doğru yerde taşı.
Kullanıcının hafızasını değil sistemi kullan.
Çalışan alışkanlığı sebepsiz bozma.
Hatayı kullanıcıya yükleme.
Geri bildirimi geciktirme.
Veri kaybını ve yetkisiz erişimi hiçbir estetik kazançla takas etme.
Ölçmeden “daha iyi” deme.

Bu yaklaşım görsel minimalizmden daha geniştir. Asıl hedef düşük bilişsel gürültü, yüksek görev doğruluğu ve kararlı davranıştır.

Kendi Kendini Açıklayan İş Uygulamaları ve Hata Sonrası Kurtarma

Kurumsal iş uygulamalarında hata mesajının görevi yalnız başarısızlığı duyurmak değildir. Kullanıcı teknik altyapının ayrıntılarını bilmeden işlemin neden tamamlanmadığını, hangi katmanda sorun bulunduğunu ve bir sonraki güvenli adımın ne olduğunu anlayabilmelidir. Bu özellik, destek ekibine bağımlılığı azaltan kendi kendine çözüm üretilebilirlik olarak düşünülebilir.

Bir hata bildirimi mümkün olduğunda şu soruları cevaplar:

Hangi işlem tamamlanmadı?
Sorun hangi kaynaktan geliyor?
Somut ve güvenli neden nedir?
Kullanıcı ne yapabilir?
Kullanıcı çözemiyorsa kim çözebilir?
Teknik inceleme gerekirse hangi referans kullanılmalıdır?

Burada hata kaynağı ile hata nedeni farklı kavramlardır. Kaynak veritabanı, dosya sistemi, dış servis, ağ, arayüz veya sunucu olabilir. Neden ise eksik veri, geçersiz girdi, zaman aşımı, çakışma, bozuk dosya ya da beklenmeyen durum olabilir. “Sunucu hatası” gibi geniş bir sınıf, daha somut ve güvenli bir kaynak biliniyorsa tercih edilmemelidir.

Kullanıcı kitlesinin teknik seviyesi de önemlidir. Genel amaçlı tüketici uygulamasında ayrıntılı teknik kavramlar gereksiz olabilir; kurum içi uzman uygulamada ise “veritabanına erişilemiyor”, “dosya okunamıyor” veya “kaynak servis eksik veri döndürdü” gibi ifadeler sorunun yerinde çözülmesini hızlandırabilir. Buna karşılık sınıf adı, SQL, tablo yapısı, dosya yolu, sunucu adresi veya stack trace göstermek kullanılabilirlik değil bilgi sızdırmadır. Bu sınır Güvenli Yazılım Mühendisliği ile UI/UX'in kesiştiği noktadır.

Hatanın çözüm sorumlusu da mesajın anlamını değiştirir. Kullanıcı tarih aralığını düzeltebiliyorsa çözüm kullanıcıdadır. Yetki yerel bir yönetici tarafından tanımlanabiliyorsa merkezi teknik desteğe yönlendirmek gereksizdir. Kaynak sistem eksik veri üretiyorsa kullanıcının aynı işlemi sürekli tekrar etmesi de çözüm değildir. İyi hata metni doğru kişiyi doğru sonraki adıma yönlendirir.

Hata sonrası bağlamın korunması en az metin kadar önemlidir. Formdaki geçerli alanları temizlemek, sihirbazı ilk adıma döndürmek, seçili kaydı kaybetmek veya sorgu ölçütlerini sıfırlamak kullanıcıyı ikinci kez cezalandırır. Güvenli varsayılan davranış, mümkün olduğunda mevcut çalışma bağlamını korumak ve düzeltme sonrasında aynı noktadan devam etmektir.

hata
  -> bağlamı koru
  -> nedeni görünür kıl
  -> düzeltilebilir alanı belirt
  -> güvenli sonraki adımı söyle
  -> aynı noktadan yeniden dene

Bütün modüllerin aynı görsel bileşeni kullanması gerekmez. Bir sihirbaz hatayı etkin adım içinde, veri ızgarası ilgili panelde, kısa süreli başarı bildirimi ise durum alanında gösterebilir. Tutarlılık burada aynı kutuyu kullanmak değil, aynı kavramın aynı dille ve aynı çözüm mantığıyla sunulmasıdır. Hata sözleşmesinin kod tarafındaki karşılığı Temiz Kod ve Bakım Mühendisliği notunda ele alınan değişim sınırlarıyla doğrudan ilişkilidir.

Kısa durum bildirimi ile eyleme dönük hata da ayrılmalıdır. “Kaydedildi” gibi bir geri bildirim geçici olabilir. Buna karşılık neden ve çözüm içeren bir hata, kullanıcı okuyup işlem yapana kadar kalıcı ve erişilebilir olmalıdır. Tablet ve dokunmatik kullanımda yalnız imleç üzerine gelince açılan açıklamalara güvenmemek de aynı ilkenin devamıdır.

Bu yaklaşımın amacı hata metnini uzatmak değildir. Amaç, destek çağrısına dönüşecek belirsizliği uygulamanın kendi içinde azaltmaktır. İyi hata deneyimi, kullanıcıya teknik ayrıntı yığını vermeden sistemi işletilebilir kılar.

Klavye odağı, durum sürekliliği ve hata sonrası toparlanma

Kullanılabilirlik yalnız ekranın ilk görünümü değildir. Kullanıcı filtre uygulamış, satır seçmiş, panel açmış ve metin yazmışken arka planda veri yenilenmesi bu bağlamı bozmamalıdır. Yenileme sonrasında scroll konumu, seçim ve odak gereksiz yere sıfırlanıyorsa iş akışı bilişsel olarak kesilir.

Klavye erişilebilirliğinde yalnız Tab ile dolaşabilmek yetmez. Odak göstergesi görünür olmalı, modal/popup açıldığında odak doğru yere taşınmalı, kapatıldığında önceki mantıksal elemana dönmelidir. Dinamik liste ve grid bileşenlerinde DOM yeniden kurulurken focus kaybı ayrıca test edilmelidir.

Hata sonrası toparlanma da UX tasarımıdır. Kaydedilemeyen form içeriğinin korunması, kullanıcının neyin başarısız olduğunu anlayabilmesi ve güvenli yeniden deneme yolu sunulması; "hata mesajı göstermekten" daha yüksek bir kalite ölçütüdür.

Otomatik yenilemede bağlam kararlılığı

Veri yoğun arayüzlerde otomatik yenileme yalnız verinin tekrar alınması değildir; kullanıcının çalışma bağlamını koruma problemidir. Ekrandaki satırlar değişirken seçimin, odak noktasının, kaydırma konumunun ve açık panelin gereksiz yere sıfırlanması, teknik olarak doğru veriyi kullanılabilir olmayan bir arayüze dönüştürebilir.

Kararlı yenileme için görünüm kimliği ile veri sırası ayrılmalıdır. Kullanıcının seçtiği nesne kalıcı bir anahtar üzerinden yeniden bulunur; yeni veri geldiğinde liste deterministik biçimde sıralanır ve seçim mümkünse aynı nesneye bağlanır. Seçili nesne artık yoksa arayüz bunu sessizce başka satıra kaydırmak yerine açık bir durum değişikliği olarak ele almalıdır.

mevcut görünüm
  |-- seçim kimliği
  |-- odak
  |-- kaydırma
  |-- açık panel
  v
yeni veri -> kararlı sıralama -> kimliği yeniden eşle -> görünümü koru

Asenkron yenilemede ikinci sorun eski cevabın yeni cevabın üstüne yazılmasıdır. Kullanıcı art arda filtre değiştirdiğinde önceki istek daha geç tamamlanabilir. Çözüm, artık geçersiz olan isteği AbortController ile iptal etmek veya her isteğe monoton bir nesil numarası verip yalnız en güncel neslin sonucu işlemesine izin vermektir. Böylece ağ zamanlaması kullanıcı niyetini tersine çeviremez.

Otomatik yenileme klavye odağını da ele geçirmemelidir. Kullanıcı metin alanında yazarken, tablo satırında gezinirken veya bir eylemi onaylarken DOM'un yeniden kurulması odak kaybına yol açabilir. Mümkün olduğunda mevcut düğümler güncellenmeli; zorunlu yeniden oluşturma durumunda odak semantik kimlik üzerinden geri kurulmalıdır.

Bu yaklaşım Web Programlama içindeki event loop ve Fetch API konuları ile Yazılım Test Mühendisliği içindeki durum geçişi testlerini birleştirir. UI güvenilirliği yalnız ilk çizim kalitesi değil, veri değişirken çalışma bağlamının ne kadar kararlı kaldığıdır.

Kullanılabilirliği gözlenebilir görevlerle değerlendirmek

Bir arayüzün iyi görünmesi, görevin kolay tamamlandığını göstermez. Değerlendirme için gerçek görev tanımı, başarı ölçütü, hata sayısı, tamamlama süresi ve kullanıcının nerede tereddüt ettiği birlikte gözlenebilir.

Erişilebilirlik yalnız otomatik tarayıcı puanına indirgenmemelidir. Klavye akışı, odak sırası, ekran okuyucu adı/rolü, kontrast ve hata sonrası toparlanma gerçek etkileşimle kontrol edilmelidir. Otomatik araçlar eksikliği bulmaya yardım eder, kullanılabilirliği bütünüyle kanıtlamaz.

Performans tarafında da tek Lighthouse skoru yeterli değildir. Gerçek cihaz, ağ koşulu, uzun liste, yavaş API ve hata durumu gibi senaryolar kullanıcı deneyiminin sınırlarını gösterir.

Ünite 11: Stratejiden Yüzeye UX Karar Zinciri

Kullanıcı deneyimi, son aşamada renk ve bileşen seçerek eklenen bir kaplama değildir. Görünür arayüz, daha önce verilmiş ürün, kapsam, bilgi mimarisi ve etkileşim kararlarının sonucudur. Bu nedenle UX kararlarını birbirine bağlı katmanlar halinde izlemek, özellikle uzun yaşayan web uygulamalarında tasarımın neden belirli bir biçime dönüştüğünü anlamayı kolaylaştırır.

Jesse James Garrett'ın yaygınlaştırdığı beş düzlem yaklaşımını mühendislik açısından şöyle okuyabiliriz:

STRATEJİ
  kullanıcı hedefi + iş hedefi
        |
        v
KAPSAM
  hangi işlev + hangi içerik
        |
        v
YAPI
  bilgi mimarisi + etkileşim modeli
        |
        v
İSKELET
  gezinme + bilgi yerleşimi + kontrol konumu
        |
        v
YÜZEY
  renk + tipografi + ikon + görsel ayrıntı

Bu sıralama bir şelale süreci olmak zorunda değildir. Prototipte bulunan sorun daha üstteki strateji veya kapsam kararını değiştirebilir. Değerli olan, katmanlar arasında izlenebilirlik kurmaktır.

Strateji katmanı: Kimin hangi hedefini çözüyoruz?

Bir ekran tasarlamadan önce iki tarafın hedefi görünür olmalıdır:

• Kullanıcı hangi işi tamamlamak istiyor?
• Ürün veya kurum hangi sonucu üretmek istiyor?
• Bu iki hedef nerede örtüşüyor, nerede gerilim oluşturuyor?
• Başarı hangi gözlenebilir ölçütle anlaşılacak?

Örneğin yönetim ekranında kurum daha fazla veri toplamayı isteyebilir; kullanıcı ise görevi en az adımla tamamlamak ister. Her alanı forma eklemek kapsamı büyütür, fakat UX'i iyileştirmez. Strateji katmanı bu gerilimi erken görünür kılar.

Kapsam katmanı: Özellik listesi değil, görev sözleşmesi

Kapsam yalnız "hangi butonlar olsun?" sorusu değildir. İşlevsel kapsam ile içerik kapsamı birlikte düşünülmelidir.

görev
  |
  +--> gerekli veri
  +--> gerekli eylem
  +--> gerekli açıklama
  +--> hata/kurtarma yolu
  +--> yetki sınırı

Bir alan kullanıcı görevi için gerekli değilse yalnız veri tabanında bulunduğu için ekranda görünmek zorunda değildir. Tersine, kullanıcı karar vermek için belirli bir bağlama ihtiyaç duyuyorsa veri modelinde doğrudan alan olmasa bile bu bilgi arayüz tarafından türetilip sunulabilir.

Yapı katmanı: Bilgi ve davranış birlikte

Bilgi mimarisi ile etkileşim mimarisi ayrı ama bağlıdır. Aynı veriyi göstermek için sekme, yan panel, ayrı sayfa veya satır içi genişletme kullanılabilir. Doğru seçim kullanıcının görev devamlılığına bağlıdır.

aynı kayıt üzerinde kal
     |
     +--> kısa karşılaştırma -> yan panel
     +--> paralel görünüm    -> sekme
     +--> derin alt görev    -> ayrı sayfa

Teknik route yapısı kullanıcı yapısını zorunlu olarak belirlememelidir.

İskelet katmanı: Yerleşim kararının kanıtı

Kontrolün nerede bulunduğu, hangi sırada görüldüğü ve ne kadar görünür olduğu kullanıcı davranışını etkiler. İskelet katmanında artık şu sorular ölçülebilir hâle gelir:

• Birincil eylem ilk bakışta bulunabiliyor mu?
• Aynı görevin ilişkili verileri göz hareketini gereksiz artırıyor mu?
• Kritik durum bilgisi kaydırma dışında kalıyor mu?
• Klavye ve dokunma akışında aynı anlam korunuyor mu?

Yüzey katmanı: Son katman ama önemsiz değil

Renk, tipografi, ikon ve hareket yüzey katmanıdır. "Yalnız görsel" olduğu için önemsiz değildir; fakat alttaki yanlış yapıyı onaramaz.

yanlış görev modeli
     +
güzel yüzey
     =
güzel görünen yanlış deneyim

Bu ayrım tasarım tartışmalarında "renk mi, özellik mi?" ikilemini azaltır. Önce hangi katmanda problem olduğu belirlenir.

Katmanlar arası izlenebilirlik

Bir UI kararının yukarı doğru gerekçesi olmalıdır:

ikon konumu
 -> iskelet kararı
 -> etkileşim akışı
 -> kullanıcı görevi
 -> ürün hedefi

Aşağı doğru da doğrulama izi kurulabilir:

ürün hedefi
 -> görev ölçütü
 -> etkileşim tasarımı
 -> prototip
 -> kullanılabilirlik testi
 -> üretim metriği

Bu yaklaşım, tasarım kararını kişisel beğeniden çıkarıp mühendislik gerekçesine dönüştürür.

Ünite 12: Kullanıcı Analizi, Karma Yöntem ve Kurgusal Kullanıcı Karakterleri

Kullanıcı merkezli tasarım "kullanıcıyı düşünmek" değildir; gerçek kullanıcı davranışı hakkında sistematik kanıt toplamaktır. Tasarımcının kendi deneyimi başlangıç hipotezi olabilir, kullanıcı araştırmasının yerine geçmez.

Araştırma sorusu yöntemi belirler

Farklı yöntemler farklı sorulara cevap verir.

Ne yapıyor?
 -> gözlem / kullanım verisi

Neden böyle yapıyor?
 -> görüşme

Nasıl grupluyor?
 -> kart sıralama

Ne kadar yaygın?
 -> anket / nicel ölçüm

Görevi başarabiliyor mu?
 -> kullanılabilirlik testi

Aynı yöntem bütün sorular için kullanılmamalıdır.

Görüşme: yönlendirmeden öğrenmek

İyi görüşme kullanıcının deneyimini açar; tasarımcının çözümünü onaylatmaya çalışmaz.

Yönlendiren:

"Bu ekranda hızlı filtre olsa daha iyi olmaz mı?"

Daha açık:

"Bu kaydı bulmak için bugün hangi adımları izliyorsunuz?"

İkinci soru mevcut davranışı ve gerçek problem alanını keşfetmeye daha uygundur.

Gözlem: söylenen ile yapılan arasındaki fark

Kullanıcılar alışkanlık hâline gelmiş küçük sorunları görüşmede hatırlamayabilir. Gerçek görev sırasında:

• hangi alanı tekrar kontrol ettiği,
• hangi bilgiyi başka ekrandan kopyaladığı,
• nerede beklediği,
• hangi geçici notu tuttuğu,
• hangi klavye kısayolunu kullandığı

gözlenebilir.

Bu tür davranışlar özellikle yoğun iş uygulamalarında gereksinim kaynağıdır.

Kart sıralama ve bilgi mimarisi

Kart sıralama, içerik ve özelliklerin kullanıcı zihninde nasıl kümelendiğini araştırmak için kullanılabilir. Sonuç doğrudan menü üretmez; fakat tasarımcının kurum içi bölüm adlarını kullanıcıya zorlayıp zorlamadığını gösterir.

kurum yapısı ≠ kullanıcı zihinsel modeli

Açık kart sıralamada kullanıcı kategorileri kendisi oluşturur. Kapalı kart sıralamada mevcut kategorilere yerleştirir. İki yaklaşım farklı araştırma sorularına hizmet eder.

Karma yöntem ve üçgenleme

Tek bir araştırma yöntemi yanlış güven üretebilir.

telemetri:
"Kullanıcılar burada çok bekliyor."

görüşme:
"Neden beklediklerini söylüyorlar."

gözlem:
"Gerçekte hangi davranışın gecikmeyi oluşturduğunu gösteriyor."

Birden fazla kanıt türü aynı probleme işaret ediyorsa bulgu güçlenir. Çelişiyorsa bu da değerlidir; ölçümün veya varsayımın yeniden incelenmesini gerektirir.

Kurgusal kullanıcı karakteri (persona)

Kullanıcı karakteri, hayalî biyografi yazmak değildir. Araştırmada gözlenen davranış kümelerinin karar aracı hâline getirilmesidir.

İyi bir kullanıcı karakterinde şu özellikler yararlıdır:

• hedef,
• görev sıklığı,
• alan bilgisi,
• teknoloji okuryazarlığı,
• hata maliyeti,
• kullandığı cihaz/giriş yöntemi,
• bağlamsal kısıtlar,
• gerçek araştırma bulgusuna dayalı davranış örüntüsü.

Şunlar yalnız tasarım kararını etkiliyorsa eklenmelidir: yaş, meslek, aile durumu veya demografik ayrıntı. Dekoratif persona ayrıntısı stereotip üretir.

Senaryo

Persona "kim?" sorusunu, senaryo "hangi koşulda ne yapmaya çalışıyor?" sorusunu cevaplar.

kullanıcı karakteri
       +
bağlam
       +
hedef
       +
engel
       =
senaryo

Senaryo prototip ve kullanılabilirlik testinin temelini oluşturabilir.

Araştırma etiği

Kullanıcı araştırması da veri işleme faaliyetidir.

• Gereksiz kişisel veri toplanmamalı.
• Katılımcı neye katıldığını anlayabilmeli.
• Kayıt ve ekran görüntülerinin saklama süresi belirli olmalı.
• Hassas iş verisi araştırma çıktısına kontrolsüz taşınmamalı.
• Kullanıcı davranışı "hata yapan insan" diliyle damgalanmamalı.
• Katılımcı örneklemi yalnız en erişilebilir uzmanlardan oluşmamalı.

UX araştırması, kullanıcının sisteme karşı değil; sistemin kullanıcı gereksinimine karşı sınanmasıdır.

Ünite 13: Kullanıcı Çeşitliliği, Bağlam ve Teknoloji Okuryazarlığı

"Evrensel kullanıcı" yoktur. Aynı kişi bile farklı cihaz, ortam, stres düzeyi ve zaman baskısında farklı davranabilir. Kullanıcı özelliklerini yalnız kalıcı demografik etiketler olarak değil, yetenek + deneyim + bağlam bileşimi olarak değerlendirmek daha sağlıklıdır.

Fiziksel ve duyusal özellikler

Görme, işitme, motor kontrol, el açıklığı, yorgunluk veya geçici yaralanma etkileşimi değiştirebilir. Erişilebilirlik yalnız kalıcı engellilik için tasarlanmaz.

kalıcı durum
geçici durum
durumsal kısıt

aynı tasarım gereksinimine yol açabilir.

Örneğin:

• kalıcı işitme kaybı,
• geçici kulak enfeksiyonu,
• gürültülü ortam

üçü de sesli içeriğin metin alternatifi ihtiyacını görünür kılar.

Bilişsel ve psikolojik yük

Kullanıcının dikkat kapasitesi sınırsız değildir. Zaman baskısı, stres, kesinti ve çoklu görev ortamı hata olasılığını artırır.

Kritik iş ekranlarında şu varsayım tehlikelidir:

Kullanıcı yeterince dikkat ederse hata yapmaz.

Daha doğru soru:

Dikkat bölündüğünde sistem hangi hatayı önleyebilir veya güvenli biçimde toparlayabilir?

Sosyokültürel bağlam

Dil, sayı/tarih biçimi, renk çağrışımı, isim yapısı, adres biçimi, okuma yönü ve kurumsal terminoloji kültürel bağlamdan etkilenir.

Yerelleştirme yalnız metni çevirmek değildir.

translation
  +
format
  +
layout direction
  +
content convention
  +
domain terminology
  =
localization

Bir İngilizce etiket Türkçeye çevrildiğinde daha uzun olabilir. Tasarım yalnız İngilizce metin genişliğiyle doğrulanmamalıdır.

Uluslararasılaştırma Mühendisliği: Çeviriden Önce Yapısal Hazırlık

Uluslararasılaştırma (internationalization, i18n) bir ürünü farklı dil, yazı sistemi ve yerel biçimlere uyarlanabilir tasarlama işidir. Yerelleştirme (localization, l10n) ise bu hazırlanmış yapıyı belirli bir dil ve kültürel bağlama uyarlamadır. Bir ürün metinleri çevrilebilir olduğu hâlde tarih, sayı, yön, sıralama veya girdi modeli sabit kodlanmışsa uluslararasılaştırılmış değildir.

W3C Internationalization rehberliği UTF-8, belge dilinin doğru belirtilmesi, yerel isim/adres/tarih biçimlerinin desteklenmesi ve sağdan sola metin yönünün semantik olarak tanımlanması gibi konuları temel web mühendisliği gereksinimleri olarak ele alır.

Belge dili yalnız SEO metadata'sı değildir

lang bilgisi telaffuz, ekran okuyucu davranışı, yazım araçları ve dil duyarlı işleme için anlam taşır. Bir belge içinde dil değişiyorsa ilgili bölümün dili de gerektiğinde belirtilmelidir.

<p lang="tr">...</p>
<blockquote lang="en">...</blockquote>

Bu, görünüşten çok semantiktir.

Yazı yönü görsel hizalamadan ibaret değildir

RTL desteği yalnız text-align: right vermek değildir. Metin yönü, satır başlangıcı, ikon yönü, breadcrumb akışı, önce/sonra kavramları ve karma LTR/RTL içerikte Unicode Bidi davranışı birlikte düşünülmelidir.

CSS tarafında fiziksel:

left / right
margin-left / padding-right

yerine uygun olduğunda mantıksal:

inline-start / inline-end
margin-inline / padding-inline

kavramlarını kullanmak LTR/RTL uyarlamasını daha yapısal hâle getirir.

Ancak her ikon aynalanmaz. Oynat, indirme veya markaya özgü simge yön bağımsız olabilirken geri/ileri oku okuma ve gezinme yönüne göre değişebilir. Aynalama semantik karardır.

Unicode karakter sayısı kullanıcı karakteri değildir

JavaScript dizesi UTF-16 kod birimlerinden oluşur. Kullanıcının "bir karakter" olarak algıladığı emoji veya birleşik işaretli harf birden çok kod noktası ve kod birimi içerebilir. Karakter sınırı, kesme, sayaç ve imleç mantığı kullanıcı tarafından algılanan grafem kümeleriyle (grapheme cluster) ilgiliyse basit string.length yeterli olmayabilir.

Bu ayrım özellikle:

• kullanıcı adı sınırı,
• SMS/metin sayacı,
• editör istatistiği,
• kısaltma/truncation,
• karakter bazlı seçim

özelliklerinde görünür olur.

IME ve bileşim (composition) olayları

Çince, Japonca, Korece ve başka yazı sistemlerinde kullanıcı tek tuş vuruşuyla bitmiş karakter üretmeyebilir; Input Method Editor ara bileşim durumu oluşturabilir. Her input/tuş olayını tamamlanmış kullanıcı niyeti gibi işlemek canlı arama, doğrulama ve kısayollarda hata üretebilir.

tuşlar
 -> bileşim sürüyor
 -> aday seçimi
 -> bileşim tamamlandı
 -> bitmiş metin

Klavye odaklı arayüzlerde test matrisi yalnız Latin klavye ile sınırlanmamalıdır.

Metin genişlemesi ve yalancı yerelleştirme (pseudo-localization)

Çeviri sonrası etiketlerin uzayabileceği baştan kabul edilmelidir. Sabit genişlik, metni resim içine gömme ve yalnız İngilizce kelime uzunluğuna göre tasarım yerelleştirme sırasında kırılır.

Yalancı yerelleştirme, gerçek çeviri yapılmadan önce metinleri yapay biçimde uzatarak, aksanlı karakterler kullanarak ve gerektiğinde yönü değiştirerek şu problemleri erken görünür kılabilir:

• kesilen etiket,
• sabit yükseklik,
• birleşik string üretimi,
• çevrilmeyen sabit metin,
• yanlış sıralanan ikon/metin,
• LTR varsayımı.

Bu test gerçek yerelleştirme incelemesinin yerine geçmez; yapısal hazırlığın erken kalite kapısıdır.

Bilişsel Erişilebilirlik: Bilişsel Yükten Farklı Bir Katman

Bilişsel yük kavramı bütün kullanıcılar için görev karmaşıklığını ve çalışma belleği maliyetini tartışır. Bilişsel erişilebilirlik ise öğrenme, dikkat, bellek, dil işleme, planlama veya problem çözme farklılıkları olan kişilerin içeriği ve etkileşimi kullanabilmesini ayrıca ele alır. Bu iki alan kesişir fakat aynı değildir.

W3C COGA çalışmaları WCAG'ın normatif başarı ölçütlerini tamamlayan, bilgilendirici tasarım örüntüleri sunar. Bu rehberlik WCAG'a ek bir uygunluk seviyesi değildir; standardın kapsamadığı bazı kullanıcı ihtiyaçlarını daha ayrıntılı görünür kılar.

Tanıdık ve öngörülebilir etkileşim

Yeni ve yaratıcı bir kontrol, kullanıcıdan gizli bir kural öğrenmesini istiyorsa maliyeti yüksektir. Aynı işlevin aynı ad, yer ve davranışla sunulması özellikle hafıza ve öğrenme yükünü azaltır.

aynı görev
 -> aynı isim
 -> benzer yer
 -> benzer sonuç

Bu yaklaşım tasarım sistemindeki tutarlılığın erişilebilirlik gerekçesidir.

Kritik yol kısa, yardım bulunabilir olmalıdır

Karmaşık görevde bütün bilgiyi tek ekrana sıkıştırmak ile kullanıcıyı gereksiz adımlara bölmek iki ayrı uçtur. Kullanıcı gerekli bilgiyi doğru anda görebilmeli, ana görev ile ikincil açıklamayı ayırabilmeli ve yardımı sürekli farklı yerde aramak zorunda kalmamalıdır.

WCAG 2.2'nin Consistent Help ve Redundant Entry ölçütleri bu konunun bazı normatif parçalarını kapsar; COGA ise daha geniş anlaşılabilirlik ve destek ihtiyaçlarını açıklar.

Kişiselleştirme erişilebilirliği destekleyebilir

Bazı kullanıcılar daha az hareket, sadeleştirilmiş görünüm, metin okuma desteği veya alıştığı kontrol düzeninden yararlanabilir. Kişiselleştirme, temel işlevi saklayan tahminsel yeniden düzenleme anlamına gelmemelidir. Kullanıcı tercihi açık, geri alınabilir ve varsayılan davranış anlaşılır olmalıdır.

Bilişsel erişilebilirlik testinin öznesi gerçek kullanıcıdır

Otomatik erişilebilirlik aracı başlık sırasını veya ARIA hatasını bulabilir; bir işlemin hatırlanamayacak kadar karmaşık olup olmadığını tek başına kanıtlayamaz. Bilişsel erişilebilirlik değerlendirmesinde gerçek görev, hata toparlanması, metin anlaşılırlığı ve kullanıcıyla yapılan testler önemini korur.

Teknoloji okuryazarlığı

Yeni kullanıcı ile uzman kullanıcı arasındaki fark yalnız hız değildir. Uzman:

• daha yoğun veri ister,
• klavye kısayolu kullanabilir,
• birden fazla paneli birlikte okuyabilir,
• daha az açıklamayla ilerleyebilir.

Yeni kullanıcı ise daha görünür yönlendirmeye ihtiyaç duyabilir.

Bu nedenle progressive expertise yaklaşımı değerlidir:

başlangıç:
görünür kontrol + açıklama

uzman:
aynı kontrol + kısayol + toplu işlem

İki ayrı ürün tasarlamak gerekmez; aynı arayüz deneyimle birlikte daha verimli hâle gelebilir.

Bağlam kullanıcı profilinden daha dinamiktir

Aynı kullanıcı:

• masaüstünde klavye,
• tablette dokunma,
• hareket hâlinde telefon,
• düşük bant genişliği,
• parlak gün ışığı,
• sessiz ofis,
• kriz anı

gibi farklı bağlamlarda çalışabilir.

UX testi bu koşullardan en kritik olanları örneklemelidir.

Ünite 14: Tasarım Yoluyla Gizlilik, Güvenlik ve Anlaşılır Seçenekler

Gizlilik ve güvenlik üretim sonrasında eklenen ayar sayfaları değildir. Kullanıcının hangi verinin neden istendiğini, ne kadar süre saklandığını ve hangi seçimin ne anlama geldiğini anlayabilmesi kullanıcı deneyiminin parçasıdır.

Tasarım yoluyla gizlilik

Temel yaklaşım:

önce veri topla
sonra gizlilik ekle

değil,

amaç
  |
  v
asgari gerekli veri
  |
  v
koruyucu varsayılan
  |
  v
erişim / saklama sınırı
  |
  v
anlaşılır kullanıcı kontrolü

olmalıdır.

Bu bakış, Güvenli Yazılım Mühendisliği ile UI/UX'in doğrudan kesişimidir.

Gizlilik ile güvenlik aynı şey değildir

Güvenlik "yetkisiz biri veriye erişebiliyor mu?" sorusunu çözer.

Gizlilik ayrıca şunları sorar:

• Bu veri baştan toplanmalı mıydı?
• Bu amaç için gerekli miydi?
• Kullanıcı kullanım amacını biliyor mu?
• Saklama süresi makul mü?
• Başka amaçla yeniden kullanılıyor mu?
• Kullanıcı hangi kontrolü gerçekten kullanabiliyor?

Şifrelenmiş gereksiz veri hâlâ gereksiz veridir.

Bağlamsal izin isteme

Uygulama ilk açıldığında gelecekte gerekebilecek bütün izinleri istemek, kullanıcının karar kalitesini düşürür.

Daha anlaşılır desen:

özellik başlatıldı
      |
      v
neden izin gerektiğini açıkla
      |
      v
izin iste
      |
      +--> verildi -> devam
      |
      +--> verilmedi -> güvenli alternatif

İzin reddedildiğinde uygulama kullanıcıyı cezalandırmamalı; mümkünse sınırlı işlevle devam etmelidir.

Koruyucu varsayılan

Kullanıcı hiçbir ayarı değiştirmese de mahremiyet açısından makul bir durum oluşmalıdır. Varsayılanı daha fazla veri toplamaya ayarlayıp kullanıcının karmaşık menülerde bunu kapatmasını beklemek gerçek kontrol değildir.

Gizlilik seçeneğinin dili

"Deneyimi iyileştir" gibi belirsiz bir ifade, hangi verinin hangi amaçla işlendiğini açıklamaz.

Daha iyi gizlilik metni şu dört bilgiyi ayırır:

hangi veri?
neden?
kim kullanacak?
nasıl değiştiririm?

Gerektiğinde saklama süresi ve üçüncü taraf paylaşımı da görünür olmalıdır.

Seçim mimarisi ve karanlık kalıplar

Kabul seçeneğini büyük ve renkli, reddi küçük ve belirsiz yapmak kullanıcının kararını yönlendirebilir. Gizlilik arayüzünde görsel hiyerarşi, kullanıcının özgür seçimini bozmamalıdır.

Aynı şekilde:

• önceden işaretli gereksiz izinler,
• reddetmek için çok daha fazla adım,
• kapatınca yeniden tekrar tekrar sorma,
• "hayır, kötü deneyim istiyorum" gibi suçlayıcı metin

etik tasarım değildir.

Yerel işleme ve veri minimizasyonu

Bazı özelliklerde veriyi sunucuya göndermek zorunlu olmayabilir. Cihaz üzerinde işleme:

• ağdan veri sızıntısı yüzeyini küçültebilir,
• gecikmeyi azaltabilir,
• çevrimdışı kullanım sağlayabilir.

Ancak "yerel" otomatik olarak güvenli demek değildir. Cihaz saklama, yedekleme, hata günlükleri ve uygulama izinleri yine değerlendirilmelidir.

Kimlik Doğrulama ve Hesap Yaşam Döngüsü UX'i

Kimlik doğrulama ekranı güvenlik mekanizmasının yalnız görünen yüzüdür. Kullanıcı deneyimi girişten ibaret değildir:

hesap oluşturma / davet
        ↓
giriş
        ↓
gerekirse ek doğrulama
        ↓
oturum
        ↓
yeniden doğrulama
        ↓
kurtarma / cihaz değişimi
        ↓
oturum kapatma / erişim sonlandırma

Bu zincirin bir halkası kullanılamazsa güçlü kriptografi tek başına iyi ürün deneyimi oluşturmaz.

Parola yöneticilerini ve otomatik doldurmayı bozmayın

Kullanıcı adı ve parola alanlarında standart form semantiğini gereksiz özel kontrollerle bozmak parola yöneticilerinin çalışmasını güçleştirebilir. Uygun autocomplete değerleri, gerçek form kontrolleri ve yapıştırmayı keyfî biçimde engellemeyen tasarım hem güvenlik hem erişilebilirlik açısından daha sağlıklı olabilir.

"Güvenlik için yapıştırmayı kapatma" gibi önlemler kullanıcıyı kısa veya tekrar kullanılan parolaya itebilir. Güvenlik UX'i saldırı modeline dayanmalı, kullanıcıyı cezalandıran varsayımlara değil.

Erişilebilir kimlik doğrulama

WCAG 2.2 Accessible Authentication ölçütleri, kullanıcıdan bilişsel işlev testi gerektiren kimlik doğrulama akışlarının erişilebilirliğini ele alır. Parola yöneticisi kullanımı, kopyala-yapıştır ve cihazın desteklediği kimlik doğrulama mekanizmaları erişilebilir yolu güçlendirebilir.

CAPTCHA veya tek seferlik kod gibi ek adımlar gerçekten gerekli olduğunda alternatif yol, hata toparlanması ve zaman aşımı davranışı düşünülmelidir. Kodun süresi dolduğunda kullanıcının bütün formu kaybetmesi gereksiz cezadır.

Geçiş anahtarı (passkey) ve WebAuthn

Web Authentication Level 3, 25 Ağustos 2026 tarihinde W3C Recommendation olarak yayımlandı. WebAuthn, web uygulamalarının açık anahtarlı kimlik bilgisi (public-key credential) oluşturup kullanmasına ve kullanıcı aracısının doğrulayıcı (authenticator) erişimini aracılık etmesine ilişkin standart API modelini tanımlar.

Passkey deneyimi kullanıcıya kriptografik ayrıntıyı öğretmeye çalışmamalıdır. Arayüzün açıklaması şu sorulara yanıt vermelidir:

• kullanıcı hangi hesapla devam ediyor?
• doğrulama hangi cihaz/kimlik sağlayıcı üzerinden gerçekleşiyor?
• başka cihaz veya yöntem gerekiyorsa alternatif nedir?
• başarısızlıkta kullanıcı hesabını nasıl kurtarır?

Yeni yöntem eklenmesi eski ve güvenli kurtarma yollarının düşünülmesini gereksiz kılmaz.

Çok faktörlü kimlik doğrulama (MFA) ve güçlendirilmiş yeniden doğrulama (step-up authentication) aynı şey değildir

Çok faktörlü kimlik doğrulama hesabın giriş politikasının parçası olabilir. Step-up authentication ise oturum zaten açıkken daha riskli bir işlem için yeniden veya daha güçlü doğrulama istemektir.

normal görüntüleme
 -> mevcut oturum yeterli

yetki değiştirme / hassas işlem
 -> ek doğrulama gerekli olabilir

Her küçük işlemde yeniden parola sormak güvenliği artırmak yerine kullanıcıyı otomatik davranışa itebilir. Risk seviyesi ile sürtünme dengelenmelidir.

Oturum süresi dolması veri kaybı üretmemelidir

Uzun form veya editörde oturum süresi dolabilir. Bir sonraki Kaydet işleminde giriş sayfasına atıp bütün taslağı kaybetmek kimlik doğrulama hatasını veri kaybına dönüştürür.

Daha güvenli akış:

oturum geçersiz
 -> taslağı koru
 -> yeniden doğrula
 -> yetkiyi tekrar değerlendir
 -> işlem hâlâ geçerliyse devam et

Yeniden doğrulama sonrasında önceki yetkinin hâlâ geçerli olduğu varsayılmamalıdır.

Hesap kurtarma en zayıf halka olabilir

Güçlü giriş yöntemi, kolay ele geçirilebilen kurtarma akışıyla etkisiz hâle gelebilir. Kurtarma UX'i aynı anda güvenlik ve erişilebilirlik problemi olarak ele alınmalıdır:

• kullanıcı hangi kimliğini kanıtlıyor?
• saldırganın bildiği kamuya açık bilgiler yeterli mi?
• eski cihaz kaybolduğunda güvenli alternatif var mı?
• kurtarma sonrası diğer oturumların durumu ne olacak?
• kullanıcıya hangi güvenlik değişikliği açıkça bildirilecek?

Hesap yaşam döngüsü tasarımı, yalnız "Giriş Yap" ekranının görsel kalitesinden daha geniştir.

Ünite 15: Gestalt İlkelerini UI İçin Algısal Dil Olarak Kullanmak

Gestalt ilkeleri arayüzü otomatik olarak iyi yapan reçeteler değildir. İnsan görsel sisteminin parçaları nasıl gruplayabildiğini açıklayan güçlü algısal ipuçlarıdır. Değerleri, arayüzün yapısını ek açıklama olmadan görünür kılabilmeleridir.

Yakınlık

Yakın öğeler aynı gruba ait algılanma eğilimindedir.

Ad
[________]

Soyad
[________]


İzinler
[ ] Oku
[ ] Yaz

"İzinler" ile önceki form alanları arasındaki daha büyük boşluk yeni bir kavramsal grup sinyali verir.

Benzerlik

Aynı görsel özellikleri paylaşan öğeler ilişkili algılanabilir.

Bu nedenle aynı düzeydeki birincil eylemler tutarlı bileşen stili kullanmalıdır. Fakat benzerlik yanlış kullanılırsa tıklanabilir ve tıklanamaz öğeler birbirine karışabilir.

aynı görünüm
    ≠
aynı işlev değilse risk

Ortak bölge

Aynı sınır veya yüzey içindeki öğeler grup olarak algılanabilir. Kart, panel, fieldset ve araç çubuğu bu ilkenin UI karşılıklarıdır.

Her şeyi karta koymak ise ortak bölgenin anlamını tüketir. Gruplama yalnız gerçek ilişki olduğunda kullanılmalıdır.

Süreklilik

Göz hizalanmış öğeleri ortak akışın parçası olarak izleme eğilimindedir. Form etiketleri, tablo kolonları, zaman çizelgesi ve adım göstergeleri bu nedenle hizalamadan güçlü biçimde etkilenir.

Tamamlama

Eksik biçimler zihinsel olarak tamamlanabilir. Logo ve ikon tasarımında yararlı olabilir; ancak kritik durum simgesinin anlaşılmasını yalnız bu algısal eğilime bırakmak doğru değildir.

Şekil-zemin

Kullanıcı hangi öğenin ön planda, hangisinin arka planda olduğunu hızla ayırabilmelidir. Modal arka plan karartması, seçili satır ve aktif panel bu ayrımı destekleyebilir.

Fakat aşırı blur, gölge ve katman görsel gürültü üretir. Şekil-zemin ilişkisi "daha fazla efekt" demek değildir.

Ortak kader

Aynı yönde hareket eden öğeler ilişkili algılanabilir. Animasyonda birlikte hareket eden bir grup, yapısal ilişkinin sinyalini verebilir.

Buna karşılık sırf dekorasyon için çok sayıda hareket kullanmak dikkat rekabeti yaratır. prefers-reduced-motion gibi erişilebilirlik tercihleri korunmalıdır.

İyi biçim ve sadelik

İnsan algısı çoğu zaman karmaşık görüntüyü daha basit ve düzenli yapılara dönüştürmeye çalışır. Bu, sadeliğin yalnız "az öğe" olmadığını tekrar gösterir.

İyi bir yoğun iş ekranı çok veri taşıyabilir; yine de gruplama, hizalama ve hiyerarşi sayesinde algısal olarak sade olabilir.

az veri ≠ otomatik sadelik
iyi örgütlenmiş veri -> algısal sadelik

Gestalt doğrulama yerine hipotez üretir

"Yakınlık ilkesi böyle diyor" kullanılabilirlik testinin yerine geçmez. İlkeler tasarım hipotezi üretir; gerçek görev testi hipotezin bu kullanıcı ve bu bağlamda çalışıp çalışmadığını gösterir.

Ünite 16: Çok Kipli, Uyarlanabilir ve Ortama Yayılmış Deneyimler

Web arayüzü yalnız fare + klavye + ekran kombinasyonundan ibaret değildir. Ses, dokunma, kamera, sensör, giyilebilir cihaz, artırılmış gerçeklik ve yapay zekâ aynı kullanıcı görevinin farklı kanalları olabilir.

Çok kipli etkileşim

Kullanıcı aynı görevi farklı giriş/çıkış kipleriyle sürdürebilir:

girdi:
klavye
dokunma
ses
kamera / sensör

çıktı:
ekran
ses
titreşim
bildirim

Amaç her işlevi her kipte sunmak değildir. Göreve uygun alternatifler oluşturmaktır.

Örneğin sesli arayüz, ellerin meşgul olduğu durumda yararlı olabilir; yoğun veri karşılaştırmasında ise görsel tablo daha güçlüdür.

Sesli etkileşim

Ses arayüzünde görünür seçenekler azalır. Bu nedenle:

• sistemin ne duyduğunu göstermesi,
• yanlış anlamayı düzeltebilme,
• kritik eylem öncesi güvenli doğrulama,
• sessiz ortam alternatifi,
• gizlilik göstergesi

önem kazanır.

NLP ve Büyük Dil Modelleri sesli veya doğal dil arayüzünün dil işleme tarafını açıklar; UX tarafı ise kullanıcı kontrolü ve hata toparlanmasına odaklanır.

Yapay zekâ ile kişiselleştirme

Kişiselleştirme, her kullanıcıya farklı ve tahmin edilemez UI göstermek değildir.

İyi uyarlama:

• kullanıcıya açıklanabilir,
• geri alınabilir,
• temel işlevi gizlemez,
• profil hatasında sistemi kullanılamaz hâle getirmez.

tahmin
  |
  v
öneri
  |
  +--> kullanıcı kabul eder
  +--> reddeder
  +--> varsayılana döner

Yapay zekâ kararı kullanıcı kontrolünün yerine geçmemelidir.

Gerçek zamanlı geri bildirim

Gerçek zamanlı geri bildirim, her olayda bildirim göstermek değildir. Hangi durum değişikliğinin kullanıcının sonraki kararını etkilediği belirlenmelidir.

durum değişti
    |
    +--> kullanıcının kararı etkileniyor -> görünür geri bildirim
    |
    +--> teknik ayrıntı, eylem gerektirmiyor -> sessiz/log düzeyi

Aşırı gerçek zamanlı geri bildirim dikkat parçalanması üretir.

IoT ve cihaz sürekliliği

Nesnelerin İnterneti deneyiminde tek ekran yerine cihazlar arası durum önemlidir.

telefon
   |
   v
bulut / yerel durum
   |
   +--> sensör
   +--> giyilebilir
   +--> masaüstü
   +--> sabit panel

Kullanıcı aynı görevin hangi cihazda başladığını ve nerede devam edeceğini anlayabilmelidir. Durum çakışması ve gecikmiş güncelleme görünür biçimde yönetilmelidir.

Artırılmış ve sanal gerçeklik

AR/VR arayüzlerinde ekran koordinatının yerini uzamsal yerleşim, görüş alanı, baş hareketi, el hareketi ve fiziksel güvenlik alabilir.

Buradaki temel UX ilkeleri yine tanıdıktır:

• sistem durumu görünür olmalı,
• eylem geri bildirimi anlaşılır olmalı,
• hareket hastalığı ve fiziksel yük gözetilmeli,
• sanal kontrol gerçek çevrede tehlike oluşturmamalı,
• erişilebilir alternatifler düşünülmeli.

Yeni teknoloji temel insan faktörlerini geçersiz kılmaz; yalnız etkileşim yüzeyini değiştirir.

Ünite 17: UX Kalite Kapıları ve Sürekli İyileştirme

Bir arayüzün "test edildi" denmesi dört farklı kalite sorusunu tek cümlede gizleyebilir.

1. İşlevsellik

Beklenen işlem gerçekten gerçekleşiyor mu?

Kaydetme, silme, filtreleme, hesaplama, yetki ve veri bütünlüğü bu katmandadır.

2. Kullanılabilirlik

Gerçek kullanıcı görevi makul maliyetle tamamlayabiliyor mu?

Tamamlama oranı, süre, hata, tekrar, yardım ihtiyacı ve tereddüt noktaları burada ölçülür.

3. Erişilebilirlik

Farklı yetenek ve giriş yöntemleriyle aynı amaç tamamlanabiliyor mu?

Klavye, ekran okuyucu, zoom/reflow, kontrast, hedef boyutu, hareket tercihi ve anlamlı alternatifler değerlendirilir.

4. Görsel ve davranışsal tutarlılık

Ürün kendi tasarım sözleşmesine uyuyor mu?

Token, tipografi, bileşen durumu, hizalama, boşluk, ikon ve hareket kalıpları burada test edilir.

Bu dört kapı birbirinin yerine geçmez.

işlevsel
   !=
kullanılabilir
   !=
erişilebilir
   !=
görsel olarak tutarlı

İyi üretim sürümü hepsini birlikte karşılamaya çalışır.

Araştırma ile telemetrinin birlikte kullanılması

Üretim metriği davranışı gösterir, niyeti değil.

Örneğin bir işlevin az kullanılması:

• gereksiz olduğu,
• bulunamadığı,
• yavaş olduğu,
• yalnız nadir görevde gerektiği

anlamına gelebilir.

Bu nedenle telemetri yeni araştırma sorusu üretmelidir; tek başına tasarım kararı olmamalıdır.

Sürekli iyileştirme ama sürekli oynatma değil

Sürekli iyileştirme, arayüzün her hafta yer değiştirmesi değildir.

Yoğun kullanılan sistemlerde değişiklik:

kanıt
 -> hipotez
 -> prototip
 -> test
 -> kontrollü dağıtım
 -> ölçüm
 -> kalıcılaştır / geri al

çevrimiyle yapılmalıdır.

Kas hafızasını etkileyen yerleşim ve klavye değişiklikleri özellikle güçlü kanıt gerektirir.

UX borcu

Teknik borç gibi UX borcu da birikir:

• aynı kavramın farklı adlarla kullanılması,
• üç farklı modal deseni,
• tutarsız hata metinleri,
• sürekli bozulan odak,
• açıklanamayan otomatik davranış,
• kullanılmayan fakat kaldırılamayan eski akışlar.

Bu borcun çözümü görsel yeniden tasarım kampanyası değil; davranış sözleşmelerinin ve tasarım sisteminin aşamalı olarak birleştirilmesidir.

Temel ilke

Kullanıcı deneyimi tasarımında amaç her zaman daha yeni, daha hareketli veya daha kişiselleştirilmiş bir arayüz değildir.

Amaç:

Kullanıcının kendi bağlamında doğru görevi, gereksiz bilişsel ve fiziksel yük taşımadan, sistemin durumunu anlayarak, hata yaptığında toparlanarak ve verisi üzerinde makul kontrol sahibi olarak tamamlayabilmesidir.

Progressive Enhancement ve İşlevsel Eşdeğerlik

Modern web platformunda bütün tarayıcıların veya bütün giriş ortamlarının aynı piksel çıktısını üretmesini beklemek gerekli değildir. Daha önemli hedef, temel görevin desteklenen ortamlar arasında korunmasıdır. Bu yaklaşım görsel eşitlikten çok işlevsel eşdeğerliği hedefler.

Bir deneyim üç katmanla düşünülebilir:

Temel (baseline)
├─ semantik HTML
├─ okunabilir içerik
├─ klavye ile ana görev
└─ güvenli form/gönderim davranışı

Geliştirilmiş (enhanced)
├─ Grid/Flex/container uyarlaması
├─ pointer-aware ergonomi
├─ gelişmiş tipografi/görseller
└─ zengin ama geri düşebilir etkileşim

İleri/opsiyonel (advanced)
├─ yeni platform primitive'leri
├─ gelişmiş geçişler
├─ anchor/scroll tabanlı sunum
└─ destek yoksa ana görevi etkilemeyen efektler

Bu katmanlama “eski tarayıcıya aynı görünümü zorla” yaklaşımından farklıdır. Temel katman görev bütünlüğünü sağlar; daha yeni özellikler deneyimi iyileştirir fakat işlevin tek yolu olmaz.

Tarayıcı destek matrisi isim listesi değil yetenek sözleşmesidir

“Chrome, Firefox, Safari destekleniyor” gibi bir liste tek başına yetersiz olabilir. Daha yararlı matris şu soruları cevaplar:

• Ana görev hangi minimum yeteneklerle çalışır?
• Hangi özellikler gelişmiş katmandır?
• Desteklenmeyen özellikte fallback nedir?
• Hangi regresyonlar release blocker'dır?
• Hangi farklılıklar yalnız görsel varyasyondur?

Böylece browser support ürün kararıyla bağlanır.

Feature detection ve fallback tasarımı

Yeni CSS veya HTML özelliği kullanılacaksa önce başarısızlık biçimi tasarlanmalıdır. Bir özellik yokken içerik kayboluyorsa, ana eylem erişilemez hale geliyorsa veya yalnız boş bir panel kalıyorsa progressive enhancement başarısızdır.

Kalite kapısına şu soru eklenmelidir:

Bu özellik devre dışı kaldığında kullanıcı ana görevi hâlâ tamamlayabiliyor mu?

Cevap hayırsa özellik artık enhancement değil, temel bağımlılıktır ve destek matrisi buna göre yönetilmelidir.

Yardımcı Teknoloji Test Mühendisliği

Erişilebilirlik doğrulaması yalnız otomatik tarayıcı eklentisi çalıştırmak değildir. Otomatik araçlar önemli sınıf hataları bulabilir; fakat görev tamamlama davranışını bütünüyle gözleyemez.

Daha güvenilir test katmanları:

statik / otomatik kontrol
        ↓
klavye ile görev
        ↓
zoom / reflow / text spacing
        ↓
renk ve forced-colors benzeri modlar
        ↓
ekran okuyucu + tarayıcı kombinasyonu
        ↓
gerçek kullanıcı görevi

şeklinde düşünülebilir.

Klavye testi yalnız Tab tuşuna basmak değildir

Klavye testi şu soruları kapsar:

• tüm işlevlere ulaşılabiliyor mu?
• odak sırası görev akışını izliyor mu?
• odak görünür mü ve sabit üst/alt katman altında kayboluyor mu?
• modal açıldığında ve kapandığında odak doğru yönetiliyor mu?
• grid, sekme, menü gibi bileşik bileşenler kendi klavye sözleşmesine uyuyor mu?
• drag gerektiren işlev için alternatif var mı?

WCAG 2.2 Focus Not Obscured, Dragging Movements ve Target Size gibi ölçütler bu testlerin belirli kısımlarına normatif sınırlar getirir.

Ekran okuyucu testi semantik modeli sınar

Aynı sayfa görsel olarak doğru görünürken şu problemleri taşıyabilir:

• erişilebilir adı olmayan kontrol,
• yanlış başlık hiyerarşisi,
• gereksiz tekrar,
• durum değişikliğinin duyurulmaması,
• yanlış role sahip özel bileşen,
• görsel sırayla DOM sırasının anlamsal olarak kopması.

Tek bir ekran okuyucu/tarayıcı kombinasyonu bütün kullanıcı ortamlarını temsil etmez. Ürünün gerçek kullanıcı tabanına göre temsilî bir kombinasyon matrisi seçilmeli; sonuçlar "bu araçta çalıştı" düzeyinde genellenmemelidir.

Otomasyon regresyon kapısıdır, insan değerlendirmesinin yerine geçmez

CI içinde erişilebilirlik denetimi, bilinen ihlallerin geri gelmesini engelleyebilir. Ancak otomatik puanın yükselmesi, metnin anlaşılır veya görevin öğrenilebilir olduğunu kanıtlamaz. Erişilebilirlik kalite kapısı hem makineyle doğrulanabilen hem insan yargısı gerektiren ölçütleri açıkça ayırmalıdır.

Kontrollü UX Deneyleri ve Güvenli Yayılım

Üretim telemetrisi bir tasarım değişikliğinin davranışla ilişkisini gösterebilir; kontrollü deney ise uygun koşullarda nedensel etki hakkında daha güçlü kanıt üretebilir. Ancak A/B testi kullanılabilirlik araştırmasının veya mühendislik doğrulamasının yerine geçmez.

Kohavi, Tang ve Xu'nun çevrimiçi kontrollü deneyler yaklaşımının temel dersi, deney altyapısının yalnız varyant göstermediği; atama, ölçüm, veri kalitesi ve istatistiksel yorumun birlikte güvenilir olması gerektiğidir.

Başarı metriği tek başına yeterli değildir

Bir değişiklik hedef metriği artırırken başka bir kritik niteliği bozabilir.

birincil metrik
   +
koruyucu metrikler
   +
teknik sağlık
   +
erişilebilirlik / hata güvenliği

birlikte değerlendirilmelidir.

Örneğin daha agresif bir akış tamamlanma oranını artırırken yanlış onay sayısını da artırıyorsa "kazandı" demek eksik yorumdur.

Feature flag, kademeli dağıtım ve deney aynı şey değildir

• Özellik bayrağı (feature flag): davranışı açıp kapatmak veya belirli gruba sunmak için mühendislik kontrolüdür.
• Kademeli dağıtım: riski sınırlamak için özelliği aşamalı kullanıcı yüzdesine açmaktır.
• Kontrollü deney: önceden tanımlanmış hipotez ve ölçümle varyantların etkisini karşılaştırır.

Bir özelliğin yüzde 10 kullanıcıya açılması onu otomatik olarak A/B testi yapmaz.

UX değişikliğinin geri dönüş yolu olmalıdır

Özellikle kritik iş akışında yeni tasarım yalnız kod olarak doğrudan dağıtılmamalı; davranışsal regresyon görülürse güvenli geri alma mekanizması bulunmalıdır. Ancak geri alma işlemi veri modelini veya kullanıcı tarafından oluşturulmuş yeni durumu kaybettiriyorsa "eski UI'ye dön" tek başına yeterli strateji değildir.

Deney etiği ve erişilebilirlik sınırı

Kullanıcıları bilerek erişilemez, yanıltıcı veya güvenlik açısından zayıf varyanta maruz bırakmak "deney" gerekçesiyle meşrulaşmaz. Normatif erişilebilirlik, güvenlik ve veri bütünlüğü gereksinimleri deney varyantlarının altında bir taban sözleşmesi olmalıdır.

Ünite 18: Kurgusal Kullanıcı Arayüzleri (FUI), Operasyonel Tasarım ve Görsel Dil

Kurgusal kullanıcı arayüzü (Fictional User Interface, FUI); film, oyun, televizyon ve benzeri anlatı ortamlarında görülen, bir sistemin nasıl çalıştığını izleyiciye ve karaktere anlatmak için tasarlanan arayüzdür. Bu alan UI/UX mühendisliği açısından değerlidir; çünkü tasarımcıyı hazır bileşen kitaplıklarının ve mevcut ürün kalıplarının dışına çıkararak arayüzün neyi anlatması, hangi bilgiyi öne çıkarması ve hangi etkileşimi görünür kılması gerektiğini yeniden düşünmeye zorlar.

Fakat kurgusal arayüz ile gerçek ürün arayüzünün başarı ölçütleri aynı değildir.

Kurgusal arayüz
  + karaktere hizmet eder
  + kadraja hizmet eder
  + izleyiciye bilgi taşır
  + anlatı temposuna uyar

Gerçek ürün arayüzü
  + gerçek görevi tamamlatır
  + hata riskini azaltır
  + durumu doğru gösterir
  + erişilebilir ve sürdürülebilir olmalıdır

Bu nedenle FUI'dan aktarılması gereken şey parlak çizgiler, yoğun animasyonlar veya bilim-kurgu süsleri değil; görevi görselleştirme, bağlam kurma ve bilgi hiyerarşisini bilinçli biçimde inşa etme yaklaşımıdır.

18.1 Brief, görünüşten önce gelir

Arayüz tasarımı renk paletiyle başlamamalıdır. İlk karar, ekranın hangi görevi yerine getireceğidir.

İyi bir tasarım brief'i en az şu soruların cevabını vermelidir:

Amaç:
Sistem hangi kararı veya işi destekliyor?

Kullanıcı:
Uzman, genel kullanıcı, yönetici, operatör veya gözlemci mi?

Ortam:
Masa başı, hareketli araç, mobil cihaz, kontrol merkezi veya saha mı?

Veri:
Bilgi ne hızla değişiyor ve hangi bölüm kritik?

Etkileşim:
Klavye, fare, dokunma, ses veya fiziksel kontrol mü?

Hata maliyeti:
Yanlış işlem geri alınabilir mi, yoksa kritik sonuç mu doğurur?

Süre:
Ekran saniyelik mi yoksa saatler süren kullanım için mi?

Bu sorular cevaplanmadan hazırlanmış görsel dil, etkileyici olsa bile göreve yabancı kalabilir.

18.2 Persona kadar görev bağlamı da önemlidir

Aynı insan farklı anlarda farklı iş rolleri üstlenebilir. Bir kullanıcı sabah veri girişi yapan personel, birkaç dakika sonra ayrıntılı inceleme yapan analist, daha sonra yalnızca genel durumu izleyen gözlemci olabilir.

Bu nedenle profesyonel uygulamalarda yalnız “kullanıcı kim?” sorusu yetmez:

Kim kullanıyor?
        +
Şu anda hangi görevi yapıyor?
        +
Karar için hangi bilgiye ihtiyacı var?

soruları birlikte değerlendirilmelidir.

Uzman kullanıcı arayüzünde yüksek bilgi yoğunluğu başlı başına kötü değildir. Sorun yapılandırılmamış yoğunluktur.

yüksek yoğunluk
+ sabit yerleşim
+ güçlü hiyerarşi
+ klavye erişimi
+ tutarlı durum işaretleri
= verimli uzman arayüzü

Aynı yoğunluk rastgele panel yerleşimi, sürekli hareket ve değişken renk anlamlarıyla birleşirse bilişsel yük üretir.

18.3 Ortam, tasarım kararının bir parçasıdır

Bir arayüzün kullanıldığı fiziksel çevre, görsel tasarımı doğrudan etkiler.

Işık, kontrast ve tema ihtiyacını değiştirir. Mesafe, yazı boyutunu ve yoğunluğu etkiler. Hareket, hassas işaretleme işlemlerini zorlaştırır. Gürültü, sesli geri bildirimin değerini azaltabilir veya artırabilir. Kullanım süresi, yüksek kontrast, parlama ve hareket toleransını belirler.

Bu nedenle:

"koyu tema daha teknolojik görünür"

yerine:

"bu çalışma koşulunda koyu tema daha okunabilir mi?"

sorusu sorulmalıdır.

18.4 Bilgi mimarisi, görsel efektten önce kurulmalıdır

Yoğun profesyonel ekranlarda bütün bilgi aynı ağırlıkta gösterilmemelidir.

Pratik bir ayrım:

Birincil bilgi
 -> karar vermek için şimdi gerekli

İkincil bilgi
 -> birincil bilgiyi yorumlamak için gerekli

Üçüncül bilgi
 -> gerektiğinde açılacak ayrıntı

Örneğin bir olay inceleme ekranında önce durum ve ana bağlam, sonra kişi/nesne ilişkisi, ardından zaman ve diğer üst veriler, en son teknik ayrıntı görünür olabilir.

Bu yapı aşamalı açımlama (progressive disclosure) ile desteklenebilir; ancak kritik bilgi yalnız “arayüz sade görünsün” diye gizlenmemelidir.

18.5 Bakışta anlaşılabilirlik

Kurgusal arayüzler çoğu zaman ekranda yalnız birkaç saniye kalır. Bu durum gerçek operasyon ekranları için yararlı bir test fikri üretir: kullanıcı kısa bakışta hangi bilgiyi çıkarabiliyor?

Katı standart olmamakla birlikte şu düşünce deneyi yararlıdır:

1 saniye:
hangi modüldeyim?

3 saniye:
aktif bağlam ve durum nedir?

5 saniye:
burada hangi işlemleri yapabilirim?

Bu test özellikle kontrol merkezi, telemetri, izleme, medya inceleme ve alarm ekranlarında görsel öncelikleri ortaya çıkarır.

18.6 Kart çoğaltmak yerine yapı kurmak

Genel web tasarımında her bilgi grubunu ayrı kart içine koymak yaygındır. Yüksek yoğunluklu uzman uygulamalarda bunun bedeli gereksiz kenarlık, yarıçap, gölge ve boşluktur.

Alternatif yaklaşım:

BÖLÜM BAŞLIĞI
────────────────────────────
birincil içerik

ikincil içerik
────────────────────────────

Çizgi, hizalama, yüzey ve boşlukla oluşturulan yapı; sürekli iç içe kartlardan daha yüksek veri yoğunluğu sağlayabilir.

Bu özellikle:

• kontrol merkezi,
• güvenlik operasyon ekranı,
• ağ/altyapı izleme,
• aviyonik,
• SCADA,
• adli bilişim,
• finansal işlem,
• telemetri

gibi alanlarda önemlidir.

18.7 Renk, dekorasyon değil semantik kanaldır

Renk sistemi, ekranlar arasında aynı anlamı korumalıdır.

Örneğin:

aktif / seçili -> vurgu rengi
başarılı       -> olumlu durum
uyarı          -> dikkat
kritik         -> hata / risk
özel durum     -> ayrı ama tutarlı vurgu
normal         -> nötr

Bir renk bir sayfada “aktif”, başka sayfada “hata”, üçüncü sayfada yalnız süs anlamına geliyorsa kullanıcı zamanla renk sistemine güvenemez.

Durum yalnız renkle verilmemelidir:

renk
+ simge
+ metin
+ biçim

birlikte kullanıldığında renk körlüğü, düşük kaliteli ekran ve kötü ışık koşullarına karşı daha dayanıklı bir arayüz oluşur.

18.8 Gri tonlama testi

Arayüzün renklerini geçici olarak kaldırmak güçlü bir görsel hiyerarşi testidir.

Gri tonlamada kullanıcı hâlâ:

• seçili olanı,
• uyarıyı,
• başlığı,
• normal veriyi,
• etkileşimli kontrolü

ayırt edebiliyorsa yapı büyük ölçüde renkten bağımsızdır.

İyi tasarım önce biçim, konum, boşluk ve tipografiyle iletişim kurar; renk bunu güçlendirir.

18.9 Tipografi veri mimarisinin parçasıdır

Teknik arayüzde tipografi yalnız yazı tipi seçimi değildir.

Ayrı roller tanımlanabilir:

Arayüz metni
 -> açıklama ve eylem

Sayısal veri
 -> zaman, oran, sayaç, adres

Teknik etiket
 -> kısa kategori ve sistem durumu

Sürekli değişen sayılar için eş genişlikli rakamlar (tabular-nums) kolonların titremesini önleyebilir.

Büyük harfli ve geniş harf aralıklı teknik etiketler kısa bölüm adlarında işe yarayabilir; uzun açıklama ve gövde metninde okunabilirliği düşürür.

18.10 Hareket, durum geçişini açıklamalıdır

Animasyonun en güçlü görevi süslemek değil, neden-sonuç ilişkisini görünür kılmaktır.

İyi örnek:

beklemede
   |
kullanıcı seçti
   v
seçili
   |
işlem başladı
   v
işleniyor
   |
sonuç geldi
   v
tamamlandı

Bu hareket kullanıcıya sistemin ne yaptığını anlatır.

Sürekli dönen halka, amaçsız nabız efekti, kayan ızgara veya her panelde tekrarlanan parlama ise zamanla görsel gürültüye dönüşür.

Bir animasyonu değerlendirirken şu test kullanılabilir:

Animasyon kapatıldığında hangi anlam kayboluyor?

Hiçbir bilgi, neden-sonuç veya yönlendirme kaybolmuyorsa hareket büyük ölçüde dekoratiftir.

18.11 Ses yalnız anlam taşıdığında kullanılmalıdır

Sesli geri bildirim kritik alarm, erişilebilirlik desteği veya kullanıcının ekrana bakamayacağı durumlarda değerlidir.

Buna karşılık her hover, her tıklama veya her küçük onay için ses üretmek uzun süreli iş uygulamalarında dikkat yorgunluğu yaratabilir.

Ses tasarımı için de aynı ilke geçerlidir:

ses başladı
   |
   v
hangi olay bunu gerektirdi?

Cevap belirsizse ses büyük olasılıkla gereksizdir.

18.12 Etkileşim modeli görsel tasarımdan ayrı değildir

Arayüzün fare, klavye, dokunma, ses veya fiziksel kontrolle kullanılması yerleşimi ve kontrol boyutlarını etkiler.

Fare öncelikli
 -> hassas işaretleme

Klavye öncelikli
 -> hızlı uzman iş akışı

Dokunma öncelikli
 -> daha büyük hedefler

Çok kipli
 -> giriş yöntemleri arasında tutarlı durum

Klavye ağırlıklı profesyonel uygulamayı yalnız ikonlardan oluşan ve kısayolları gizleyen bir araç çubuğuna dönüştürmek “modernizasyon” değil UX regresyonu olabilir.

18.13 Gerçek veri, dekoratif mikroveriden daha değerlidir

Kurgusal ekranlarda küçük rastgele sayılar ve kodlar teknoloji hissi yaratabilir. Gerçek üründe her ek bilgi kullanıcının dikkat bütçesini tüketir.

Bu nedenle:

0xA91C
SYS-XY-882
RND-42

gibi anlamsız süsler yerine:

428 kayıt
3 aktif filtre
12 bağlantı
son güncelleme 14:32

gibi gerçek üst veriler kullanılmalıdır.

Böylece arayüz aynı anda teknik, yoğun ve işlevsel görünebilir.

18.14 Kurumsal kimlik, kurgusal world-building'in gerçek ürün karşılığıdır

Kurgusal yapımda arayüz, içinde bulunduğu dünya ve karakter hakkında bilgi verir. Gerçek üründe bunun karşılığı iş alanı ve kurumsal kimliktir.

Bir sağlık sistemi, aviyonik ekran, finansal işlem terminali ve güvenlik operasyon uygulaması aynı görsel dile sahip olmak zorunda değildir.

Kimlik şu bileşenlerin birlikte çalışmasıyla oluşur:

terminoloji
yoğunluk
renk sistemi
tipografi
durum gösterimi
etkileşim modeli
hareket davranışı

Logo eklemek tek başına ürün kimliği oluşturmaz.

18.15 Style frame ve en kötü durum ekranı

Yüksek doğruluklu statik tasarım karesi (style frame), üretime geçmeden önce görsel sistemin nasıl davranacağını sınamak için yararlıdır.

Fakat yalnız temiz ve ideal örnek ekran hazırlamak yanıltıcıdır.

Profesyonel tasarımda ayrıca en kötü durum tasarım karesi hazırlanmalıdır:

• uzun etiketler,
• yoğun veri,
• seçili kayıt,
• uyarı,
• hata,
• klavye odağı,
• aktif işlem,
• devre dışı kontrol,
• dar ekran

aynı anda test edilmelidir.

Gerçek tasarım sistemi, ideal ekran kadar kötü durum ekranında da ayakta kalmalıdır.

18.16 Tasarım süreci: CSS'ten önce problem modeli

FUI üretimindeki brief, araştırma, görsel çerçeve, hareket prototipi ve üretim sıralaması gerçek yazılım arayüzüne şu biçimde uyarlanabilir:

problem tanımı
   ↓
mevcut iş akışını inceleme
   ↓
bilgi mimarisi
   ↓
statik görsel sistem denemesi
   ↓
etkileşim prototipi
   ↓
uygulama
   ↓
görev tabanlı doğrulama

Buradaki temel nokta şudur:

CSS yazmak, arayüz tasarım sürecinin başlangıcı değildir.

18.17 İşlevsel ve dekoratif katmanı ayırmak

FUI estetiğinden yararlanan gerçek ürünlerde en güvenli mimari, işlevsel arayüz ile dekoratif katmanı birbirinden ayırmaktır.

İŞLEVSEL KATMAN
├─ veri
├─ kontrol
├─ durum
├─ form
└─ gezinme

GÖRSEL KATMAN
├─ yapısal çizgiler
├─ hafif ızgara
├─ teknik köşeler
├─ sınırlı parlama
└─ düşük yoğunluklu doku

İkinci katman tamamen kaldırıldığında uygulama hâlâ anlaşılır, erişilebilir ve kullanılabilir olmalıdır.

Bu ilke görsel modernizasyon sırasında regresyon riskini ciddi biçimde düşürür.

18.18 “Gelecekçi görünüm” anti-pattern'i

Yüzeysel bilim-kurgu taklidi genellikle aynı öğelere dayanır:

camgöbeği
+ parlama
+ altıgen
+ tarama çizgisi
+ rastgele sayı
+ dönen çember

Bunların hiçbiri tek başına gelişmiş teknoloji hissi oluşturmaz.

Daha güçlü teknik görünüm:

gerçek veri
+ kesin hizalama
+ kararlı yerleşim
+ tutarlı durum dili
+ güçlü tipografi
+ amaçlı hareket
+ anlamlı geometri

ile oluşur.

18.19 Erişilebilirlik ve performans, görsel katmanın sınırıdır

FUI esintili bir tasarım:

• klavye kullanımını,
• görünür odağı,
• kontrastı,
• renk dışı durum işaretlerini,
• hareket azaltma tercihini,
• metin okunabilirliğini

bozmamalıdır.

Aynı şekilde aşırı bulanıklık, büyük gölgeler, sürekli animasyon, çok sayıda DOM düğümü ve gereksiz yeniden çizim performans borcu oluşturabilir.

Bir ekran görsel olarak etkileyici olduğu hâlde kaydırma sırasında takılıyorsa veya kullanıcı girişine geç cevap veriyorsa UX açısından başarısızdır.

18.20 FUI'dan gerçek ürüne aktarım matrisi

Kurgusal arayüzden doğrudan stil kopyalamak yerine tasarım fikrini dönüştürmek gerekir.

FUI öğesi                 Gerçek ürün karşılığı
────────────────────────────────────────────────────
sinematik vurgu           güçlü görsel hiyerarşi
world-building            alan / kurum kimliği
mikroveri                 gerçek bağlamsal üst veri
hareketli grafik          durum geçişi
teknik etiket             kısa ve tutarlı kategori dili
holografik katman         derinlik / katman ilişkisi
kurgu içi alarm           semantik uyarı sistemi
karmaşık HUD              göreve göre düzenlenmiş yoğunluk

Aktarılmaması gerekenler ise düşük okunabilirlik, sürekli hareket, anlamsız dekoratif veri, aşırı parlama ve gerçek görevi yavaşlatan etkileşimlerdir.

18.21 FUI esintili operasyon ekranı için değerlendirme soruları

Bir ekran tamamlandığında şu sorular birlikte sorulmalıdır:

1. Kullanıcı temel görevi hızlı ve doğru tamamlayabiliyor mu?
2. Ekranın amacı kısa bakışta anlaşılabiliyor mu?
3. Birincil ve ikincil bilgi açıkça ayrılıyor mu?
4. Mevcut durum yalnız renge bağlı olmadan okunabiliyor mu?
5. Hareket gerçekten bir durum değişimini mi anlatıyor?
6. Kullanım ortamı kontrast, boyut ve giriş modeli kararlarına yansıtılmış mı?
7. Dekoratif katman kapatıldığında işlev kaybı oluşuyor mu?
8. Ekran uzun süreli kullanımda görsel yorgunluk üretiyor mu?
9. En kötü veri yoğunluğunda yerleşim bozuluyor mu?
10. Arayüz gerçekten ait olduğu iş alanına mı benziyor?

Bu soruların tümüne olumlu cevap vermeyen ekran, ne kadar “sinematik” görünürse görünsün operasyonel açıdan tamamlanmış sayılmamalıdır.

18.22 Sonuç

FUI, gerçek ürün arayüzü için hazır bir tema değildir. Değeri, tasarımcının neden, bağlam, bilgi hiyerarşisi, hareket, kimlik ve etkileşim arasındaki ilişkiyi yeniden düşünmesini sağlamasındadır.

Gerçek UI/UX mühendisliğinde doğru aktarım sırası şöyledir:

görev
  ↓
bilgi
  ↓
durum
  ↓
etkileşim
  ↓
görsel sistem
  ↓
hareket
  ↓
dekoratif karakter

Bu sıra tersine çevrildiğinde kullanıcı arayüzü “gelecekçi” görünebilir fakat kullanılabilirliğini kaybeder. Doğru uygulandığında ise FUI araştırmaları, yoğun ve uzman odaklı arayüzlerin daha okunabilir, daha tutarlı ve daha karakterli tasarlanması için güçlü bir düşünme aracı hâline gelir.

Ünite 19: Kanıt Farkındalıklı Konuşmalı Analitik Arayüzler

Konuşmalı arayüz bir sohbet balonu tasarımı değildir. Analitik iş uygulamasında kullanıcı aynı anda ne sorduğunu, sistemin hangi veri üzerinde çalıştığını, hangi sonucun seçili olduğunu, cevabın hangi kanıta dayandığını ve hangi işlemlerin gerçekten yapılabileceğini anlayabilmelidir.

Kullanıcı sorusu görünür kalmalıdır

Sistem cevabı çok uzun olsa bile kullanıcının sorusu bağlamın parçasıdır. Yeni cevap geldiğinde arayüz yalnız en alta atlamak yerine yeni cevabın başlangıcını görünür hâle getirebilir.

kullanıcı sorusu
      ↓
cevabın başlangıcı
      ↓
ayrıntı
      ↓
kanıt / sonraki işlem

Bu akış cevabın hangi soruya karşılık okunduğunu görünür tutar.

İşlem durumu anlamlı olmalıdır

Tek bir "Yükleniyor..." metni yerine istek alındı, yorumlanıyor, analiz çalışıyor, sonuç hazırlanıyor ve tamamlandı gibi anlamlı fakat iç uygulama ayrıntısını ifşa etmeyen aşamalar gösterilebilir.

Sonuç ve kanıt aynı bilgi mimarisinde

Bir analitik bulgu:

bulgu
  ↓
kısa gerekçe
  ↓
kapsam / sınırlama
  ↓
kanıt eylemleri

yapısında sunulabilir.

Kanıt bağlantısı açıklamanın dipnotu değil, sonucun doğal parçasıdır.

Seçim bağlamı görünür olmalıdır

Kullanıcı ikinci bulguyu seçip ardından "neden?" veya "kanıtını göster" dediğinde arayüz hangi bulgunun aktif olduğunu görsel olarak korumalıdır.

Seçili satır, aktif dönem, filtreler ve konuşma referansı aynı bağlamı işaret etmelidir.

Yeni veri ile eski seçimi ayırmak

Yeni analiz geldiğinde eski seçimin aynı sıra numarasıyla korunması tehlikelidir.

aynı analiz sürümü
 -> seçimi koru

yeni analiz sürümü
 -> seçimi doğrula veya görünür biçimde sıfırla

yaklaşımı bağlam karışmasını azaltır.

Cevap modu hesaplamayı değiştirmemelidir

Kısa, normal, ayrıntılı veya teknik anlatım tercihi yalnız sunum biçimini değiştirmeli; analitik sonucu veya veri kapsamını değiştirmemelidir.

analysis state
!=
presentation preference

Öneri butonları gizli kestirme olmamalıdır

Bir öneri düğmesi metin taşıyorsa, düğmenin bambaşka gizli bir işlem yolunu çalıştırması zihinsel modeli bozar.

Daha tutarlı yapı:

öneri metni
 -> normal kullanıcı mesajı
 -> aynı routing / doğrulama yolu

şeklindedir.

Oturum farkındalığı

Konuşmalı arayüz kendi çalışma bağlamını açıklayabilmelidir:

kaç gözlem üzerinde çalışılıyor?
kapsam tam mı?
son hangi analiz yapıldı?
seçili bulgunun kaç kanıtı var?
hangi eylemler mevcut?

Bu sorular yeni veri sorgusu çalıştırmadan mevcut oturum durumundan cevaplanabilir.

Affordance capability ile uyumlu olmalıdır

UI bir eylem gösteriyorsa uygulama da bu eylemi gerçekten desteklemelidir. Tersi de önemlidir: dil katmanı bir eylemi anlayabiliyor diye görünmeyen veya yetkisiz işlev çalıştırılmamalıdır.

Progressive disclosure

İlk cevapta ana bulgu ve birincil metrik gösterilip kapsam, yöntem ve kanıt ayrıntıları isteğe bağlı açılabilir.

Ancak kritik sınırlama kullanıcı açmadıkça tamamen gizlenmemelidir.

Hata ve fallback dili

Kullanıcı isteği anlaşılamadığında UI internal enum, sınıf adı, araç adı veya stack trace göstermemelidir.

Bunun yerine kullanıcıya eylem yolu sunan açıklama ve netleştirme seçenekleri vermelidir.

Kanıt farkındalıklı konuşmalı arayüzün başarısı chatbot görünümünden değil; bağlamı, seçimi, veri kapsamını, kanıtı ve eylem sınırlarını görünür tutmasından gelir.

Sohbet ve grafik arayüz aynı görevin iki yüzüdür

Konuşmalı arayüz, mevcut uygulamanın yanına eklenmiş ayrı bir metin kutusu gibi tasarlandığında kullanıcı iki farklı sistemle çalışıyormuş hissine kapılabilir. Daha güçlü yaklaşım, sohbet ile grafik arayüzü aynı görev modelinin iki görünümü olarak ele almaktır.

Sohbet; niyeti kısa yoldan ifade etmek, karmaşık filtreleri doğal dille kurmak ve sonucu açıklamak için uygundur. Grafik arayüz ise seçim, karşılaştırma, doğrulama ve kesin eylem için daha güçlüdür. Bu nedenle amaç bütün denetimleri konuşmaya çevirmek değil, her işi en az bilişsel yükle yapan yüzeyi seçmektir.

doğal dil
 -> niyeti belirtme / ayrıntı isteme

grafik arayüz
 -> seçenek görme / karşılaştırma / kesin seçim

ortak durum
 -> aynı kayıt, dönem, filtre ve seçim

Örneğin kullanıcı "son 30 günü önceki dönemle karşılaştır" diyebilir; sonuçtaki iki dönemi, kayıtları veya kanıtları ise görünür düğme ve listelerle inceleyebilir. Kullanıcı bir kaydı arayüzden seçtiğinde sohbet de hangi kaydın konuşulduğunu bilmelidir. Böylece sohbet kestirme yol, grafik arayüz ise görünür çalışma alanı olur.

Bu yaklaşımın sınırı da açıktır: form, tablo veya seçim listesi doğal olarak daha kesin ise sırf konuşmalı görünmek için metne dönüştürülmemelidir. İyi hibrit arayüz, konuşmayı grafik arayüzün rakibi değil tamamlayıcısı yapar.

Konuşma onarımı: yanlış anlamadan göreve dönmek

Doğal konuşmada düzeltme olağandır. Kullanıcı eksik bir ifade yazabilir, önceki seçimini değiştirebilir veya sistemin yanlış kişiyi anladığını fark edebilir:

"hayır, diğer Mehmet"
"son 7 gün değil 30 gün"
"ilkini demiştim"
"sadece konuşmaları kullan"

Bu ifadeleri bağımsız ve sıfırdan başlayan yeni sorular gibi ele almak bağlam kaybı üretir. Daha doğal davranış, yalnız değişen parçayı düzeltip güvenli olan diğer bağlamı korumaktır.

önceki durum:
  kişi = Mehmet A
  dönem = son 30 gün
  işlem = karşılaştırma

düzeltme:
  kişi = Mehmet B

korunan:
  dönem + işlem

Onarım her zaman otomatik yapılamaz. Birden fazla aday varsa sistem tahmin etmek yerine kısa ve görünür seçenekler sunmalıdır. "Hangisini kastettiniz?" sorusunun altında bilinen adayların düğme olarak gösterilmesi, kullanıcının belleğine değil tanımasına dayanır.

Kesinti de onarımın bir parçasıdır. Kullanıcı uzun bir işlem sürerken yeni bir soru sorarsa eski işlemin sonucu daha sonra ekrana düşüp yeni bağlamı kirletmemelidir. Arayüzdeki "Durdur" denetimi de yalnız görsel bir jest değil, aktif işin artık geçerli olmadığını belirleyen açık bir durum değişimidir.

Tanıma, hatırlamadan daha güvenlidir

Konuşma geçmişi görünür olsa bile kullanıcıdan sürekli önceki kişi, dönem, filtre veya bulgu numarasını hatırlaması beklenmemelidir. Etkin bağlam gerektiğinde kısa ve kaldırılabilir işaretlerle görünür tutulabilir:

Kişi: Ahmet Yılmaz
Dönem: Son 30 gün
Metinler: Konuşmalar

Bu gösterim teknik oturum durumunu teşhir etmek için değil, "şu anda ne hakkında konuşuyoruz?" sorusuna cevap vermek içindir.

Aynı ilke sonraki adımlarda da geçerlidir. Kullanıcıya yalnız boş bir metin alanı sunmak yerine mevcut sonuçla gerçekten ilişkili birkaç seçenek gösterilebilir:

Önceki dönemle karşılaştır
İlgili kayıtları aç
Kaynakları göster

Öneri, gizli bir kestirme yol çalıştırmamalıdır. Kullanıcı aynı ifadeyi kendisi yazdığında da aynı doğrulama ve çalışma yolundan geçmelidir. Böylece görünür kontrol ile doğal dil aynı kavramsal modeli paylaşır.

Çıkmaz yerine güvenli bir sonraki yol

İyi konuşmalı arayüz her durumda yeni konuşma üretmek zorunda değildir; fakat çözülebilir bir durumda kullanıcıyı çıkmazda da bırakmamalıdır.

Kötü hata:

Bu istek desteklenmiyor.

Daha yararlı davranış:

Bu isteği doğrudan çalıştıramıyorum.
Mevcut kayıtlarla zaman dağılımını veya ilişki yoğunluğunu inceleyebilirim.

Buradaki amaç kullanıcıyı konuşmaya zorlamak değildir. Sistem yalnız gerçekten mümkün olan bir sonraki yolu göstermelidir. Veri yoksa dönem genişletme, birden fazla kişi varsa seçim yapma, sonuç eski kapsama aitse güncel verilerle yeniden çalıştırma gibi eylemler anlamlıdır. Hiç güvenli devam yolu yoksa kısa ve dürüst bir sonlandırma, yapay öneriden daha iyidir.

Konuşmalı deneyimde başarı, bir cevap üretmek değildir

Bir sohbet sistemi metin ürettiği için görev tamamlanmış sayılmaz. Kullanıcının sorusu doğru anlaşılmış, doğru kapsam kullanılmış, sonuç doğru sunulmuş ve gerekiyorsa kullanıcı kaynak kayda veya eyleme ulaşabilmiş olmalıdır.

Bu nedenle deneyim şu zincirle değerlendirilebilir:

anlama
 -> doğru kapsam
 -> doğru işlem
 -> anlaşılır sonuç
 -> kanıta / eyleme erişim

Bir halkadaki kopukluk, dilbilgisel olarak düzgün bir cevabı yine de başarısız yapabilir. Tersine, sistemin "bu veriyle güvenilir sonuç üretilemez" demesi görev açısından doğru davranış olabilir.

Konuşmalı UX'in olgunluğu, asistanın ne kadar çok konuştuğuyla değil; kullanıcının niyetini ne kadar az sürtünmeyle doğru işe dönüştürdüğü, hatadan nasıl toparlandığı ve sonucu ne kadar sınanabilir kıldığıyla ölçülmelidir.

Kaynaklı özetin arayüz sözleşmesi

Uzun bir analitik yanıt için yalnız kaydırılabilir metin sunmak, kullanıcının bilgiye erişim maliyetini artırır. Özette kısa görünüm, konu başlıkları ve ayrıntı açma seçenekleri aynı veriden türeyebilir. Ancak özet uzunluğunu değiştiren denetim ile yeni bir hesaplama başlatan denetim görünüşte aynı davranışı sergilememelidir. Kullanıcı “daha ayrıntılı” dediğinde kapsam değişmiyorsa önceki doğrulanmış kaynak kümesi kullanılabilir; “yalnız son bölüm” dediğinde ise kapsam açıkça daraltılmalıdır.

Örnek soru düğmeleri gerçek veri yeteneklerine dayanmalıdır. Metin kaynağı yokken konuşma özeti vaat eden bir düğme yanlış beklenti üretir; kaynak mevcutken yalnız sayısal analiz düğmelerinin gösterilmesi ise metin yeteneğini keşfedilemez kılar. Başlangıç ekranındaki birkaç çalışır örnek, daha geniş bir yetenek paneliyle desteklenebilir. Her örnek, elle yazılan aynı soruyla eşdeğer işleme gitmeli; tıklama ile yazılı sorgu arasında farklı yetki veya kaynak yolu oluşmamalıdır.

Özetten kaynağa geçişte bağlantının ne açacağı anlaşılır olmalıdır: belge, özgün cümle veya gerçek zaman damgalı ses aralığı. Zaman bilgisi yoksa arayüz sahte bir oynatma konumu göstermemelidir. Uzun özet oluşturma sırasında ilerleme ve iptal denetimleri erişilebilir olmalı; iptal edilmiş eski bir isteğin geç gelen sonucu yeni sorunun üstüne yazılmamalıdır. Kullanıcının odak konumu ve mevcut klavye kısayolları korunarak sohbet içinde doğal kaydırma davranışı sürdürülmelidir.

Ünite 20: Tablet-Sınıfı Web Arayüzleri ve Dokunma Ergonomisi

Tablet için iyi bir web arayüzü, telefon arayüzünün büyütülmüş ya da masaüstü arayüzünün küçültülmüş sürümü değildir. Aynı uygulama; parmak, kalem, klavye, trackpad ve fare arasında geçiş yapabilen, dikey-yatay yönelim değiştiren, bölünmüş pencerede daralan ve kimi zaman düşük çözünürlüklü kurumsal ekranlarda çalışan tek bir etkileşim sistemi olarak ele alınmalıdır.

Eski tablet kullanılabilirliği araştırmalarının kalıcı dersi cihaz modelinden çok insan faktörleri ile ilgilidir: yanlış dokunma olasılığı masaüstüne göre daha yüksektir; görünmeyen jestlerin öğrenilebilirliği düşüktür; ekran büyük görünse bile içerik alanını gereksiz bölmek görev performansını bozabilir; telefon kalıbını yalnız ölçeklemek tablet alanını verimsiz kullanır. Buna karşılık eski işletim sistemi sürümlerine, sabit çözünürlüklere veya dönemsel gezinme kalıplarına ait kurallar güncel web için doğrudan taşınmamalıdır.

Cihaz adı değil kullanılabilir alan ve giriş yeteneği

tablet, telefon ve masaüstü sınıfları tasarım iletişiminde yararlıdır; CSS ve etkileşim mantığı açısından ise yetersizdir. Aynı fiziksel tablet:

tam ekran + dokunma
bölünmüş pencere + dokunma
harici klavye + trackpad
yatay + kalem
masaüstü modunda pencere + fare

biçimlerinde kullanılabilir.

Bu nedenle yerleşim kararı şu sinyallerin bileşiminden üretilmelidir:

kullanılabilir inline-size
container genişliği
yazı büyütme / zoom
giriş doğruluğu (coarse / fine)
hover yeteneği
klavye odağı
içeriğin gerçek minimum genişliği

Bir 1024 px kırılma noktası yalnızca ölçüdür; “iPad modu” değildir. Aynı şekilde geniş ekranın varlığı hassas işaretçi bulunduğunu kanıtlamaz.

Dokunma hedefinde standart ile ergonomi aynı eşik değildir

WCAG 2.2 başarı ölçütü 2.5.8, işaretçi hedefleri için genel olarak en az 24 × 24 CSS px alan veya tanımlı boşluk/istisna koşullarından birini ister. Bu değer AA uygunluk tabanıdır; rahat dokunma için ideal ölçü olduğu anlamına gelmez.

Apple'ın güncel Human Interface Guidelines dokümanı genel düğmeler için en az 44 × 44 pt vuruş bölgesini önerir. pt ile CSS px aynı ölçü birimi değildir; bu nedenle 44 sayısı web'e mekanik biçimde dönüştürülmemelidir. Mühendislik açısından doğru ayrım şudur:

WCAG 2.2 / 24 CSS px  -> web erişilebilirlik uygunluk tabanı
platform ergonomisi    -> rahat ve hataya dayanıklı hedef için referans
ürün tasarım tokenı    -> gerçek görev, kullanıcı ve cihaz testinden türetilen değer

Kritik veya sık kullanılan bir eylem yalnız standardın en küçük sınırında bırakılmamalıdır. Yanlış dokunmanın maliyeti yükseldikçe hedef alanı ve komşu kontroller arasındaki ayrım da artırılmalıdır.

Görsel boyut ile vuruş bölgesini ayırmak

Bir ikon görsel olarak küçük kalabilir; ancak etkileşim alanı daha büyük olabilir. Bu, özellikle yoğun araç çubuklarında görsel sadelik ile dokunma ergonomisini uzlaştırır.

┌──────────────────────┐
│      hit region      │
│      ┌────────┐      │
│      │  icon  │      │
│      └────────┘      │
└──────────────────────┘

Burada üç ölçü ayrı tasarlanmalıdır:

• iç dolgu (padding): simge/metin ile kontrol sınırı arasındaki alan,
• kontroller arası boşluk (gap): komşu hedeflerin birbirinden ayrılması,
• dış boşluk (margin): bileşenin çevresindeki yerleşim ilişkisi.

Küçük buton problemi yalnız font-size artırılarak çözülmez. Vuruş alanı, iç dolgu, ikon-metni hizası, satır yüksekliği ve komşu eylemler birlikte ele alınmalıdır.

Eylem hiyerarşisi görünür olmalıdır

Tablet-sınıfı iş uygulamalarında çok sayıda küçük ikon yan yana dizildiğinde kullanıcı her eylemi yeniden çözmek zorunda kalır. Eylemler görev sıklığı ve sonuç maliyetine göre sınıflandırılabilir:

birincil    -> mevcut iş akışını ilerleten ana eylem
ikincil     -> sık ama ana olmayan eylem
tersinir    -> geri alınabilir yardımcı işlem
yıkıcı      -> veri kaybı / iptal / silme riski taşıyan işlem
bağlamsal   -> yalnız seçili öğe veya durumda geçerli işlem

Birincil eylem yalnız renkle değil; konum, boyut, etiket ve çevresindeki boşlukla da ayırt edilmelidir. Yıkıcı eylemin ana eylemle aynı görsel ağırlıkta yan yana tutulması yanlış dokunma riskini artırır.

İkon kütüphanesi kullanmak tutarlılık sağlar ancak semantiği otomatik olarak çözmez. İkon-only kontrol:

• gerçekten yerleşik bir anlam taşımalı,
• erişilebilir ada sahip olmalı,
• klavye odağı görünür olmalı,
• gerekiyorsa tooltip/yardım metni sunmalı,
• metinsel karşılığın görevi daha hızlı açıkladığı durumda etiketten kaçmamalıdır.

Yoğunluk tek değer değil kullanım profilidir

Masaüstü veri uygulamalarında compact, dokunmatik yüzeylerde comfortable yoğunluk gerekebilir. Bunun güvenli yolu aynı arayüzü rastgele ölçeklemek değildir.

compact:
  daha sıkı satır ve araç çubuğu
  fine pointer + klavye verimliliği

comfortable:
  daha geniş hit region ve satır aralığı
  coarse pointer / tablet kullanımı

accessible:
  büyütülmüş metin ve kontroller
  yeniden akış ve odak görünürlüğü öncelikli

Profil değiştiğinde bilgi mimarisi, eylem anlamı ve sıra korunmalıdır. Kullanıcı “rahat” moda geçtiği için aynı eylemi farklı yerde aramak zorunda kalmamalıdır.

Tablet yerleşiminde master-detail ve bölünmüş görünüm

Eski tablet araştırmalarında ekranın gereğinden fazla bölünmesinin içerik alanını daralttığı sık görülmüştür. Bu bulgu “split view kullanma” kuralına dönüştürülmemelidir. Modern geniş tabletlerde ve yeniden boyutlandırılabilir pencerelerde master-detail güçlü bir kalıp olabilir; koşul, iki panelin de kendi görevini yerine getirecek minimum genişliği korumasıdır.

uygun:
  liste/seçim  |  seçili kaydın ayrıntısı

uygunsuz:
  dar liste | dar grid | dar form | sabit sağ panel

Bir panel, yalnız “boş alan var” diye eklenmemelidir. İkinci panel kullanıcıyı bağlam kaybından koruyor, karşılaştırmayı hızlandırıyor veya sık ileri-geri gezinmeyi azaltıyorsa değerlidir.

Daralma durumunda dönüşüm deterministik olmalıdır:

geniş:     liste + ayrıntı
orta:      dar liste + ayrıntı
küçük:     liste -> ayrıntı geçişi

Bu dönüşüm seçim durumunu kaybetmemeli ve geri davranışını öngörülemez hâle getirmemelidir.

Yönelim, yeniden boyutlandırma ve çoklu pencere

Dikey ve yatay yönelim iki ayrı ürün değildir. Aynı görev farklı geometri altında sürdürülür. Yönelim değiştiğinde:

• seçili kayıt,
• form verisi,
• kaydırma bağlamı,
• filtreler,
• açık sekme,
• klavye odağı

gereksiz yere sıfırlanmamalıdır.

Aynı ilke tarayıcı penceresi yeniden boyutlandırıldığında veya tablet çoklu pencereye geçtiğinde de geçerlidir. Yerleşim yeniden hesaplanabilir; iş durumu yeniden başlatılmamalıdır.

Jest temel işlevin tek yolu olmamalıdır

Dokunma jestleri hızlı olabilir fakat görünmezdir. Kaydırma, sürükleme ve uzun basma gibi hareketler yardımcı kestirme olarak değerlidir; temel işlev yalnız jestle erişilebiliyorsa keşfedilebilirlik ve erişilebilirlik düşer.

Özellikle:

• swipe ile silme için görünür alternatif,
• drag-and-drop için düğme veya klavye alternatifi,
• uzun basma menüsü için keşfedilebilir başka yol,
• pinch/zoom gerektiren içerik için standart tarayıcı büyütmesine engel olmama

tercih edilmelidir.

WCAG 2.2'nin sürükleme hareketlerine ilişkin kriteri de sürükleme gerektiren işlevler için, hareket esas olmadığı sürece, işaretçiyle sürüklemeden çalışan alternatif istemektedir.

Klavye, pointer ve kalem sonradan eklenen özellik değildir

Tablet kullanıcıları harici klavye ve trackpad bağlayabilir; dönüştürülebilir bilgisayarlar aynı oturumda dokunma ve fare arasında geçebilir. Bu nedenle etkileşim sözleşmesi tek giriş aygıtına bağlanmamalıdır.

Örnek:

parmak     -> büyük hit region
fare       -> hassas seçim + hover geliştirmesi
klavye     -> görünür focus + mantıklı tab sırası
kalem      -> hassas pointing, fakat hover varsayımı yok

Hover yardımcı bilgi verebilir; temel eylem veya zorunlu açıklama taşıyamaz. Klavye kısayolu deneyimli kullanıcıyı hızlandırabilir; görünür kontrolün yerini almak zorunda değildir.

Araç çubuğu ve butonlarda tablet yaklaşımı

Tablet hissi, her bileşeni büyük karta dönüştürmek değildir. Daha doğru hedef şudur:

• önemli eylemler yeterli vuruş alanına sahip,
• buton grupları nefes alıyor,
• ikonlar aynı optik kutu ve çizgi ağırlığında,
• etiketler kesilmeden anlaşılabiliyor,
• araç çubuğu yüksekliği içerikten değil ergonomi tokenından türetiliyor,
• ikincil eylemler ana görevi bastırmıyor,
• yatay alan daralınca eylemler kontrollü biçimde taşınıyor veya gruplanıyor.

Bir araç çubuğunda sekiz küçük ikon göstermek yerine üç sık eylemi görünür tutup daha az kullanılanları bağlamsal menüye almak, ancak gizlenen eylemlerin keşfedilebilirlik maliyeti kabul edilebiliyorsa uygundur. “Daha fazla” menüsü, bilgi mimarisi kurmak yerine her şeyi gizleyen bir çöplük olmamalıdır.

Geri bildirim parmağa yakın, durum modele yakın olmalıdır

Dokunma arayüzünde kullanıcı fiziksel geri bildirim alamaz. Basma durumu, odak, yükleme ve başarı/başarısızlık görsel olarak yeterince hızlı görünmelidir.

Bir düğmeye dokunulduktan sonra uzun işlem başlayacaksa:

Idle -> Pressed -> Pending -> Success | Error

durumları ayrılmalıdır. Aynı düğmede ilerleme göstermek, işlemle geri bildirim arasındaki uzamsal ilişkiyi koruyabilir; ancak ekranın başka bölümlerini etkileyen uzun işlemlerde yalnız buton içi spinner yeterli olmayabilir.

Gecikme sırasında kontrolü hemen devre dışı bırakmak çift gönderimi azaltabilir fakat sunucu tarafı idempotency veya durum kontrolünün yerini tutmaz.

Düşük çözünürlük ve tablet için kabul profili

Kurumsal web uygulamasının yalnız geliştiricinin geniş monitöründe doğrulanması yeterli değildir. En azından şu davranış sınıfları birlikte sınanmalıdır:

768 × 1024  dikey tablet sınıfı görünüm
1024 × 768  yatay tablet / düşük çözünürlük
1366 × 768  düşük yükseklikli masaüstü
320 CSS px  WCAG yeniden akış senaryosu
400% zoom   düşük görme / yeniden akış kontrolü
coarse      dokunma öncelikli pointer
fine        fare/trackpad
keyboard    tam klavye akışı

Bunlar belirli cihazları taklit etmek için değil, yerleşim ve giriş sözleşmesinin sınırlarını görmek için kullanılır.

Kabul soruları:

1. Sık kullanılan eylemler yanlış dokunmaya karşı yeterince ayrılmış mı?
2. İkon-only düğmeler erişilebilir ada ve anlaşılır semantiğe sahip mi?
3. Dikey-yatay veya yeniden boyutlandırma seçim/form durumunu kaybettiriyor mu?
4. Ekran daraldığında ikinci panel görevi bozuyor mu, yoksa kontrollü biçimde kapanıyor mu?
5. İşlev yalnız hover, swipe, drag veya uzun basma ile mi erişiliyor?
6. Dokunma için büyütülen bileşenler klavye/fare verimliliğini gereksiz yere düşürüyor mu?
7. Düşük yükseklikte araç çubukları ve sabit başlıklar gerçek çalışma alanını tüketiyor mu?
8. Birincil ve yıkıcı eylemler görsel ve uzamsal olarak yeterince ayrılmış mı?
9. Yoğunluk profili değiştiğinde semantik sıra ve klavye odağı korunuyor mu?
10. Kullanıcı eyleminden sonra geri bildirim doğru bileşen ve doğru zaman aralığında mı oluşuyor?

Tablet-sınıfı tasarımın özü, bir cihazı taklit etmek değil; dokunmanın hata payını, değişken pencere geometrisini ve çoklu giriş yöntemlerini aynı güvenilir istemci davranışında birleştirmektir.

Büyük Ekranda Ergonomik Süreklilik

Tablet ergonomisi yalnız 768 veya 1024 piksel genişlikte devreye giren bir “tablet modu” olarak tasarlanmamalıdır. Aynı okunabilirlik, kontrol edilebilirlik ve görsel hiyerarşi büyük ekranlarda da korunmalıdır.

Yanlış yaklaşım:

ekran büyüdü
→ daha küçük font
→ daha kısa buton
→ daha sıkışık toolbar
→ daha fazla ama mikro ölçekte bilgi

Daha doğru yaklaşım:

ekran büyüdü
→ ergonomik kontrol boyutu korunur
→ çalışma alanı genişler
→ daha fazla panel/kolon aynı anda görünür
→ içerik ve bağlam birlikte tutulabilir

Bu nedenle responsive tasarımda yoğunluk ile kapasite ayrılmalıdır. Kapasite, aynı anda ne kadar yararlı bilginin gösterilebildiğidir. Yoğunluk, o bilginin ne kadar sıkışık sunulduğudur. Büyük ekran kapasiteyi artırmak için değerlidir; yoğunluğu sınırsız artırmak için değil.

Örneğin 1920×1080 veya 2560×1440 ekranlarda form kontrollerini, sekmeleri veya toolbar butonlarını küçültmek yerine şu kazanımlar aranabilir:

• ana gridde daha fazla yararlı sütun;
• detay panelinde daha az truncation;
• master-detail görünümün aynı anda korunması;
• editör ve kanıt/yardım panelinin yan yana kalabilmesi;
• uzun metin için makul okuma genişliği korunurken çevresindeki operasyonel alanın genişlemesi.

Buna karşılık 1366×768 gibi düşük yükseklikli ekranlarda çözüm kontrolleri mikro boyuta indirmek değildir. Sabit başlıkların yüksekliği, toolbar wrapping, panel oranı ve yerel scroll sahipliği yeniden değerlendirilmelidir.

Ergonomik floor bütün pointer türlerinde anlamlıdır

Coarse pointer için yaklaşık 44px sınıfındaki hedefler güçlü bir dokunma ergonomisi sağlar; ancak fine pointer kullanıcısı için bunun karşıtı “mümkün olan en küçük kontrol” değildir. Mouse hassasiyeti daha küçük hedeflere izin verse bile okunabilirlik, motor yük ve hızlı tarama maliyeti devam eder.

Bu nedenle masaüstü kompakt modu ile dokunmatik rahat modu arasında fark olabilir; fakat ikisi de kullanılabilir bir alt sınırın üzerinde kalmalıdır. Büyük ekranın rolü, bu alt sınırı aşağı çekmek değil çalışma alanını genişletmektir.

Ünite 21: Modern Web Platformu, İlerletici Geliştirme ve Yetenek-Temelli Arayüzler

Modern CSS ve HTML platformu her yıl yeni primitive'ler ekliyor. Bu yenilikleri kullanmak ile ürünü onlara bağımlı hale getirmek aynı karar değildir. Uzun ömürlü bir arayüzde yeni özellik, ancak hangi problemi çözdüğü, destek yokken ne olacağı ve ana görevin korunup korunmadığı açık olduğunda değerlidir.

Platform primitive'i önce düşünmek

Özel tooltip, açılır panel, modal, disclosure veya konumlandırılmış katman yazmadan önce platformun mevcut primitive'leri incelenmelidir. dialog, details/summary, Popover API ve yeni konumlandırma yetenekleri bazı sınıflarda özel JavaScript miktarını azaltabilir.

Bununla birlikte karar yalnız kod satırı sayısı değildir. Şunlar birlikte değerlendirilir:

• erişilebilirlik davranışı;
• odak ve klavye sözleşmesi;
• desteklenen tarayıcı matrisi;
• fallback yolu;
• stil gereksinimi;
• var olan üretim koduyla entegrasyon maliyeti.

Popover ve anchor positioning

Popover API, sayfa üzerinde geçici katmanların açılıp kapanmasını platform seviyesinde ifade etmeye yardımcı olabilir. Anchor positioning ise bir popup/yardım katmanını onu tetikleyen öğeye göre konumlandırma problemini CSS tarafında çözmeyi hedefler.

Bu tür özellikler menü, bağlamsal yardım veya bilgi kartı sınıflarında değerlidir; ancak ana görevin tek erişim yolu olmamalıdır. Destek yokken temel içerik veya eylem görünür kalabiliyorsa progressive enhancement modeli korunur.

View transitions ve scroll-driven animation

Geçişler, bağlam değişimini anlamaya yardım ettiğinde UX değeri üretir; yalnız “daha modern” görünmek için kullanıldığında dikkat maliyeti oluşturabilir. View Transition veya scroll-driven animation gibi yeni platform araçları bu nedenle önce şu soruyla değerlendirilmelidir:

Hareket, kullanıcının durum değişimini anlamasına yardım ediyor mu?

Eğer cevap hayırsa efekt opsiyoneldir. Ayrıca prefers-reduced-motion ve hareket azaltılmış durumda anlam kaybı olmaması zorunlu tasarım koşuludur.

Yeni form ve select yetenekleri

Tarayıcıların form kontrollerini özelleştirme kapasitesi gelişmektedir. Bununla birlikte native kontrolün platform entegrasyonu — klavye, erişilebilirlik, otomatik doldurma, mobil giriş deneyimi — yalnız görsel özelleştirme uğruna kaybedilmemelidir.

Yeni bir control özelliği için güvenli yaklaşım:

1. semantik native temel;
2. destek varsa geliştirilmiş görünüm/davranış;
3. destek yoksa işlevsel fallback;
4. sunucu tarafında değişmeyen veri doğrulama sözleşmesi.

Capability detection, CSS desteği ve katmanlı kabul

Yeni özellik kullanılırken koşullu destek mekanizmaları, örneğin uygun CSS feature query'leri, temel stil ile gelişmiş stili ayırmaya yardımcı olabilir. Ancak feature detection da ürün davranışının yerine geçmez; yalnız hangi sunum katmanının uygulanacağını belirler.

Kabul testi şu katmanlarla yapılabilir:

Baseline kabulü
- ana görev tamamlanıyor
- içerik okunuyor
- klavye yolu var
- veri kaybı yok

Enhanced kabulü
- responsive kompozisyon iyileşiyor
- pointer yetenekleri değerlendiriliyor
- modern görsel/typographic araçlar çalışıyor

Advanced kabulü
- yeni platform özelliği çalışıyor
- fallback ile aynı görev korunuyor
- destek yokluğu hata görünümü oluşturmuyor

Yatay kaydırma, scroll snap ve truncation

Yatay kaydırmalı panel veya scroll snap bazı içerik tiplerinde yararlı olabilir; ancak kritik eylemleri görünmez bir yatay alana göndermek için kullanılmamalıdır. Kullanıcı kaydırılabilirliği anlayabilmeli ve klavye/pointer yolları korunmalıdır.

Benzer şekilde truncation yer kazanma aracıdır, bilgi silme yöntemi değildir. Kullanıcının karar vermesi için gerekli içerik kesiliyorsa tooltip, detay görünümü veya genişleyebilir alan gibi bir geri kazanım yolu gerekir. Özellikle tablo, kimlik ve durum alanlarında “...” kullanıcıya hangi kaydın seçildiğini belirsiz hale getirmemelidir.

Gerçek cihaz, lint ve performans birlikte kalite kapısıdır

Responsive kalite yalnız ekran görüntüsüne bakılarak doğrulanamaz. Üretim öncesi süreç üç farklı sınıfı kapsamalıdır:

• statik kalite: lint, validator, erişilebilirlik ve CSS/HTML tutarlılık kontrolleri;
• emülasyon: hızlı viewport, zoom, input ve tema matrisi;
• gerçek ortam: fiziksel cihaz, gerçek input, gerçek performans ve yönelim/split-window davranışı.

Bu testlerin hiçbiri tek başına diğerinin yerine geçmez.

Son ilke: yenilik değil görev sürekliliği

Modern web platformu güçlüdür; fakat iyi mühendislik en yeni özelliği en hızlı kullanan arayüz değildir. İyi mühendislik, ana görevi kalıcı tutarken yeni yetenekleri güvenli biçimde ekleyebilen arayüzdür.

Bir özellik ancak şu üç sorudan geçebiliyorsa güçlü bir adaydır:

1. Hangi kullanıcı veya mühendislik problemini çözüyor?
2. Destek yokken güvenli fallback nedir?
3. Kullanıcının ana görevi bu özellik olmadan da devam ediyor mu?

Bu sorular, responsive tasarım ile progressive enhancement arasında ortak kalite sözleşmesini oluşturur.

Teknik Standartlar ve Dayanaklar

Son teknik doğrulama: 28 Eylül 2026

Normatif erişilebilirlik hükümleri W3C WCAG 2.2 ve WAI-ARIA APG'ye, HTTP idempotency semantiği RFC 9110'a, performans metrikleri ise güncel web.dev belgelerine dayanır. Ürün örnekleri ilgili kurumların resmî dokümantasyonu, teknik yayınları veya SEC beyanlarıyla; altın oran tartışması ise deneysel akademik çalışmalarla sınırlandırılmıştır. Kullanılabilirlik ölçümü ve görev modelleme açıklamaları Card, Moran ve Newell'in GOMS/KLM çalışması ile Sauro ve Lewis'in kullanıcı araştırması istatistikleriyle desteklenir. ISO 9241-940:2017 yalnız dokunsal ve haptik etkileşim kapsamındaki değerlendirme terminolojisi ve yöntem ayrımı için kullanılmış; web arayüzlerine özgü genel bir norm gibi yorumlanmamıştır. Session history, URL durumu, web storage ve sekmeler arası mesajlaşma açıklamalarında WHATWG HTML Living Standard; çevrimdışı yeteneklerde W3C Service Workers; uluslararasılaştırmada W3C Internationalization; bilişsel erişilebilirlikte W3C WAI COGA rehberliği kullanılmıştır. WebAuthn Level 3'ün 25 Ağustos 2026 tarihli W3C Recommendation durumu doğrulanmış; kimlik doğrulama erişilebilirliği WCAG 2.2'nin Accessible Authentication ölçütleriyle birlikte ele alınmıştır. RFC 9110 yalnız idempotency için değil, koşullu isteklerin lost update önleme rolü için de esas alınmıştır. Kontrollü UX deneyleri için Kohavi, Tang ve Xu'nun çevrimiçi kontrollü deneyler çerçevesi kullanılmıştır.

Uzun Süre Yaşayan Bir Uygulama Örneği

Bu ilkelerin kişisel ölçekte uzun süreli uygulandığı örneklerden biri alikoker.com.tr projemdir. Burada kullanılabilirlik kararları yalnız tek ekran tasarımına değil; yıllar içinde büyüyen içerik, eski URL'lerin korunması, arama ve farklı içerik türleri arasında gezinmeye uygulanıyor.

Bu Çalışmaya Atıf

Köker, M. A. (2023). Web Uygulamalarında UI/UX Mühendisliği: Kullanılabilirlik, Duyarlı Tasarım ve Güvenilir İstemci Davranışı. alikoker.com.tr. https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi

• BibTeX: https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi.bib
• RIS: https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi.ris
• CSL-JSON: https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi.csl.json

Operasyonel Arayüzlerde Durumsal Farkındalık ve Ekolojik Tasarım

Yoğun operasyonel arayüzlerde kullanılabilirlik, bileşenlerin kolay tıklanmasından daha geniştir. Kullanıcı yalnız arayüzü kullanmaz; sistemin mevcut durumunu anlamaya, hangi değişikliğin önemli olduğunu ayırt etmeye ve yakın gelecekte ne olacağını öngörmeye çalışır. Bu problem Bilişsel Sistemler Mühendisliği kapsamında durumsal farkındalık ve Ekolojik Arayüz Tasarımı ile daha sistematik ele alınır.

Endsley'nin yaygın modelinde durumsal farkındalık; ilgili öğeleri algılama, anlamlarını kavrama ve olası gelecek durumunu öngörme düzeyleriyle açıklanır. Arayüz tasarımı açısından bunun önemli sonucu şudur:

veri görünür → gerekli ama yeterli değil
ilişki anlaşılır → daha güçlü
trend ve sınır görünür → öngörü mümkün

Örneğin dört ayrı kartta giriş hızı, işleme hızı, kuyruk ve kapasite göstermek teknik olarak doğrudur. Fakat kullanıcı zihninde bu dört değeri birleştirip “kuyruk büyüyor ve mevcut kapasiteyle toparlanamayacak” sonucunu hesaplamak zorundaysa bilişsel iş arayüz dışına bırakılmıştır.

Ekolojik Arayüz Tasarımı

Ekolojik Arayüz Tasarımı (Ecological Interface Design, EID), iş alanındaki gerçek kısıt ve ilişkileri algılanabilir biçime getirmeyi amaçlar. Bu yaklaşım dekoratif grafik üretmek değildir. Gösterilen ilişki fiziksel, işlevsel veya operasyonel bir değişmeze dayanmalıdır.

giriş  > işleme kapasitesi  → birikim
sıcaklık > güvenli sınır    → marj azalması
aktif yük + yedek kapasite  → toparlanma olanağı

Böyle bir temsil, özellikle beklenmeyen durumda kullanıcının yalnız ezberlenmiş prosedüre değil, sistemin temel ilişkilerine dayanarak karar verebilmesini destekler.

Veri tazeliği ve belirsizlik de görsel bilgidir

Gerçek zamanlı bir ekranda iki değerin yan yana görünmesi eşzamanlı oldukları anlamına gelmez. Kritik göstergelerde zaman damgası, güncelleme yaşı, veri kaynağı ve tahmin/ölçüm ayrımı gerektiğinde doğrudan görünür olmalıdır. Yapay zekâ veya istatistiksel model çıktısı da doğrulanmış kayıtla aynı görsel kesinlikte sunulmamalıdır.

Operasyonel UI/UX bu nedenle yalnız görsel hiyerarşi değil; bilgi epistemolojisi, zaman semantiği ve karar gereksinimi tasarımıdır.

Ünite 22: Erken Aşama Değerlendirme, Bilişsel Gezinti ve Evrensel Tasarım

Mevcut kullanılabilirlik testi, analitik inceleme ve prototipleme teknikleri birbirinin alternatifi değil, farklı hata sınıflarını erken yakalayan araçlardır. Özellikle kritik iş uygulamalarında arayüzün kodlanmasını beklemeden görev akışını sınamak, sonradan yapılacak yüksek maliyetli davranış değişikliklerini azaltır.

Bilişsel gezinti: öğrenilebilirliği görev adımlarıyla incelemek

Cognitive walkthrough, özellikle ilk kez veya seyrek kullanılan bir iş akışının öğrenilebilirliğini uzman değerlendirmesiyle incelemek için kullanılır. İnceleme genel "bu ekran güzel mi?" sorusu yerine her görev adımında daha dar sorular sorar:

kullanıcının doğru hedefi kurması beklenebilir mi?
        ↓
doğru eylem ekranda fark edilebilir mi?
        ↓
kullanıcı bu eylemi hedefiyle ilişkilendirebilir mi?
        ↓
eylemden sonra ilerleme anlaşılır geri bildirimle doğrulanıyor mu?

Bu yöntem heuristic evaluation ile aynı değildir. Heuristic evaluation arayüzü genel kullanılabilirlik ilkelerine göre tararken cognitive walkthrough belirli persona/görev/başlangıç durumunda eylem dizisini yürür.

Örneğin "bir kaydı bul, ayrıntısını doğrula, not ekle ve sonraki kayda geç" görevi tek tek incelendiğinde görünür fakat yanlış etiketlenmiş bir buton, klavye odağının kaybolması veya başarı geri bildiriminin belirsizliği ayrı kırılma noktaları olarak ortaya çıkar.

Kağıt ve düşük aslına uygunluklu prototip

Prototipin değeri gerçeğe benzemesinden değil, doğru belirsizliği ucuz biçimde sınamasından gelir. Erken aşamada kağıt eskiz veya düşük fidelity wireframe şu sorular için yeterli olabilir:

• bilgi mimarisi anlaşılır mı?
• kullanıcı doğru başlangıç noktasını buluyor mu?
• görev sırası doğal mı?
• kritik eylem yanlışlıkla ikincil görünüyor mu?
• geri dönüş ve iptal yolu görünür mü?

Düşük fidelity prototip, performans, gerçek erişilebilirlik ağacı, browser davranışı veya eşzamanlılık gibi teknik özellikleri doğrulamaz. Buna karşılık yanlış ekran hiyerarşisini production kodla cilalamadan önce tespit etmeyi sağlar.

Bu nedenle fidelity seçiminde temel kural:

soru davranış/akış ise        → düşük fidelity yeterli olabilir
soru etkileşim ayrıntısı ise   → interaktif prototip gerekir
soru platform davranışı ise    → gerçek kod gerekir
soru performans/eşzamanlılık ise→ production-benzeri ölçüm gerekir

Prototip sonucunu gereksinime çevirmek

Prototip testinde "kullanıcı zorlandı" tek başına uygulanabilir gereksinim değildir. Gözlem ölçülebilir sözleşmeye dönüştürülmelidir.

Kötü sonuç:

Arama daha kolay olmalı.

Daha güçlü sonuç:

başlangıç durumu : kayıt listesi açık
hedef             : bilinen kimlikli kaydı bulmak
ölçüt              : yalnız klavye ile ≤ 3 etkileşim
hata koşulu         : odak görünmez olmamalı
geri bildirim       : filtre uygulandığında sonuç sayısı duyurulmalı

Bu dönüşüm UX bulgusunu test edilebilir acceptance criterion haline getirir.

Evrensel tasarım ve erişilebilirlik aynı kavram değildir

Universal design, ürün ve ortamların olabildiğince geniş kullanıcı çeşitliliği tarafından özel uyarlama gerektirmeden kullanılabilmesini hedefleyen daha geniş bir tasarım yaklaşımıdır. Web erişilebilirliği ise standartlarla test edilebilen, engelli kullanıcıların içeriğe ve işleve erişimini doğrudan ele alan somut gereksinimler içerir.

Bu iki alan kesişir fakat birbirinin yerine kullanılmamalıdır:

evrensel tasarım
→ başlangıçtan itibaren çeşitliliği tasarıma dahil eder

accessibility
→ algılanabilirlik, çalıştırılabilirlik, anlaşılabilirlik ve uyumluluk gibi
  doğrulanabilir erişim gereksinimlerini uygular

Örneğin büyük hedef alanları çok sayıda kullanıcı için yararlıdır; fakat yalnız "herkes için iyi" gerekçesi WCAG klavye erişimi, accessible name veya contrast gereksinimini ortadan kaldırmaz.

Kritik iş uygulamalarında erken değerlendirme matrisi

Yüksek trafik veya operasyonel kritikliği olan bir arayüzde erken UX değerlendirmesi yalnız görsel tasarım toplantısı değildir. Tasarım kararı farklı doğrulama katmanlarına ayrılabilir:

| Soru | Uygun erken yöntem | Daha sonra doğrulanacak katman | |---|---|---| | Kullanıcı görevi bulabiliyor mu? | Cognitive walkthrough | Kullanılabilirlik testi | | Bilgi mimarisi anlaşılır mı? | Düşük fidelity prototip | Gerçek içerikle test | | Klavye akışı tutarlı mı? | Etkileşim prototipi | Browser + AT testi | | Yarış koşulu oluşuyor mu? | Durum modeli | Entegrasyon/E2E testi | | Büyük veriyle tablo kullanılabilir mi? | Gerçekçi veri prototipi | Performans ve görev süresi ölçümü | | Hata halinde geri dönüş açık mı? | Senaryo walkthrough | Fault-injection / operasyon testi |

Bu yaklaşım UX'i koddan ayrı bir estetik faaliyet olmaktan çıkarır. Erken değerlendirme, yanlış davranış sözleşmesini production'a taşımadan önce yapılan düşük maliyetli doğrulamadır.

Algılanan Hız ile Sistem Gecikmesinin Birleştirilmesi

Bir web arayüzünün hızlı algılanması, yalnız sunucu yanıt süresinin düşük olmasına bağlı değildir. Etkileşim başlatıldıktan sonra ana iş parçacığındaki uzun görevler, layout hesaplamaları, gereksiz yeniden çizimler ve ağ dönüş süreleri görünür yanıtı birlikte belirler. Kullanıcıya yansıyan etkileşim gecikmesi tarayıcı performans kayıtlarıyla incelenmeli; sunucudaki p95/p99 değerleri ve istek korelasyonu ile ilişkilendirilmelidir. Skeleton veya spinner kullanımı, gerçek işlem süresini kısaltmayan bir görsel geri bildirimdir.

• Interaction-to-next-paint benzeri kullanıcı metriği ile backend p95/p99 gecikmesinin aynı işlem zincirinde izlenmesi.
• Optimistic UI kullanımında rollback ve hata görünürlüğünün tasarlanması.
• Ana thread doygunluğu ile ağ/backend beklemesinin ayrı kaynaklar olarak ölçülmesi.

Ünite 23: Yoğun Bilgi Uzaylarında Analitik Gezinme ve Görselleştirme

Metin madenciliği ve benzeri analitik sistemlerde arayüz yalnız sonucu çizen son katman değildir. Kullanıcı hangi alt kümeyi inceleyeceğine, hangi kısıtları uygulayacağına ve hangi bulgudan kaynağa geri döneceğine arayüz üzerinden karar verir. Bu nedenle browsing, query refinement ve visualization aynı keşif döngüsünün parçalarıdır.

Genel görünümden kanıta doğru ilerlemek

Yoğun bilgi uzayında güçlü etkileşim kalıbı:

overview
   ↓
filter
   ↓
focus
   ↓
details
   ↓
source evidence

şeklindedir.

Kullanıcıya ilk anda bütün düğüm, kenar, etiket ve tablo satırını göstermek bilgi sağlamak değil, görsel gürültü üretmek olabilir. İlk görünüm yön bulmayı sağlamalı; ayrıntı isteğe bağlı ve geri dönüşü kolay olmalıdır.

Pattern overabundance bir UI problemidir

Analitik motor binlerce geçerli pattern üretebilir. Arayüz bunları yalnız listelemek yerine:

• sıralama,
• filtreleme,
• bastırma,
• gruplama,
• top-N,
• threshold,
• bağlamsal alt küme,
• progressive disclosure

ile yönetilebilir hale getirmelidir.

Buradaki hedef "en çok veriyi göstermek" değil, kullanıcının hangi bulgunun neden görünür olduğunu anlayabilmesidir.

Browse–refine döngüsü

Kullanıcı keşfi doğrusal olmayabilir:

sorgu
 ↓
sonuç kümesi
 ↓
gözlem
 ↓
yeni kısıt
 ↓
daha dar sonuç
 ↺

Bu nedenle filtre durumu, seçili kapsam ve önceki adıma geri dönüş görünür olmalıdır. Bir kısıt uygulandığında kullanıcı yalnız sonucun değiştiğini değil, hangi kapsamın artık analiz dışında kaldığını da anlayabilmelidir.

Focus + context

Büyük hiyerarşi veya graf görüntülerinde yalnız zoom yapmak kullanıcıyı bağlamdan koparabilir. Focus + context yaklaşımı, seçilen bölgeye daha fazla görsel alan verirken koleksiyonun geri kalanını referans olarak görünür tutar.

Pratik karşılıkları:

• seçili düğümü büyütüp komşu yapıyı korumak,
• ayrıntı paneli açarken overview haritasını kaybetmemek,
• filtrelenmiş sonuç sayısını toplam kapsamla birlikte göstermek,
• breadcrumb veya scope chip ile analitik bağlamı görünür tutmak.

Graf görselleştirmede semantik disiplin

Graf yerleşim algoritması okunabilirlik içindir. Düğümlerin ekrandaki yakınlığı kanıt değildir:

visual distance ≠ analytical distance

Düğüm boyutu, renk, çizgi kalınlığı ve konum hangi metriği taşıyorsa legend veya doğrudan etiketle açıklanmalıdır.

Ayrıca bir edge'e tıklanabiliyorsa kullanıcı mümkün olduğunda onu destekleyen kaynak kayda veya belge pasajına geri gidebilmelidir:

node / edge
    ↓
derived metric
    ↓
supporting record

Görselleştirme türü analitik göreve göre seçilir

Yoğun metin ve bağlantı analizinde tek bir "en iyi" grafik yoktur:

• dağılım için histogram/çubuk,
• zaman değişimi için çizgi/alan,
• ilişki için node-link graph,
• hiyerarşi için tree,
• karşılaştırma için tablo

daha uygun olabilir.

Daha karmaşık veya üç boyutlu gösterim otomatik olarak daha fazla içgörü sağlamaz. Occlusion, perspektif, gezinme maliyeti ve bağlam kaybı analitik doğruluğu düşürebilir. Görsel teknik, kullanıcının sorduğu soruyu en düşük bilişsel yükle cevaplamalıdır.

Analitik arayüzde kanıt geri dönüşü

Özet, cluster, trend veya ilişki gibi türetilmiş bir öğe için şu geri dönüş zinciri korunmalıdır:

görsel bulgu
    ↓
hesaplanan değer
    ↓
kullanılan veri alt kümesi
    ↓
kaynak kayıt / belge

Bu, analitik UI'ı dekoratif dashboard olmaktan çıkarır ve doğrulanabilir çalışma yüzeyine dönüştürür.

Kaynakça

• Amazon, 5 Ways Amazon Is Making It Easier to Search and Shop

https://www.aboutamazon.com/news/retail/amazon-makes-it-easier-to-search-and-shop

• Amazon, Enhanced Homepage Features

https://www.aboutamazon.com/news/retail/amazon-homepage-redesign-features

• Anderson, J.; McRee, J.; Wilson, R.; EffectiveUI Team. Effective UI. O'Reilly, 2010.

• Android Developers / Material 3, NavigationBar

https://developer.android.com/reference/kotlin/androidx/compose/material3/NavigationBar

• Apple Human Interface Guidelines, Buttons

https://developer.apple.com/design/human-interface-guidelines/buttons

• Apple Human Interface Guidelines, Sidebars

https://developer.apple.com/design/human-interface-guidelines/sidebars

• Apple Human Interface Guidelines, Tab Bars

https://developer.apple.com/design/human-interface-guidelines/tab-bars

• Apple Human Interface Guidelines, Toolbars

https://developer.apple.com/design/human-interface-guidelines/toolbars

• Atlassian Design System, Elevation

https://atlassian.design/foundations/elevation

• Atlassian Design System, Foundations

https://atlassian.design/foundations

• Brendan Gregg. Systems Performance: Enterprise and the Cloud. Pearson Education, 2014.

• Budiu, R.; Nielsen, J. Tablet Website and Application UX: Design Guidelines for Improving the Usability of Websites Viewed on Tablets and Tablet-Specific Apps. Nielsen Norman Group.

• Card, S. K.; Moran, T. P.; Newell, A. The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates, 1983; CRC Press reprint, 2008.

• Cavoukian, A. Privacy by Design: The Seven Foundational Principles. Information and Privacy Commissioner of Ontario, 2011.

• Colborne, G. Simple and Usable Web, Mobile, and Interaction Design. New Riders, 2011.

• Colborne, G. Simple and Usable: Web, Mobile, and Interaction Design, 2nd Edition. New Riders, 2018.

• Coleman, B.; Goodwin, D. Designing UX: Prototyping. SitePoint, 2017.

• D-MARKET / Hepsiburada, 2025 Form 20-F, SEC

https://www.sec.gov/Archives/edgar/data/1850235/000110465926053195/heps-20251231x20f.htm

• Enders, J. Designing UX: Forms. SitePoint, 2016.

• Frain, B. Responsive Web Design with HTML5 and CSS, Fifth Edition. Packt, 2025.

• Garrett, J. J. The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd Edition. New Riders, 2011.

• GOV.UK Design System, Back Link

https://design-system.service.gov.uk/components/back-link/

• GOV.UK Design System, Check Answers

https://design-system.service.gov.uk/patterns/check-answers/

• GOV.UK Design System, Complete Multiple Tasks

https://design-system.service.gov.uk/patterns/complete-multiple-tasks/

• GOV.UK Design System, Date Input

https://design-system.service.gov.uk/components/date-input/

• GOV.UK Design System, File Upload

https://design-system.service.gov.uk/components/file-upload/

• GOV.UK Design System, Layout

https://design-system.service.gov.uk/styles/layout/

• GOV.UK Design System, Question Pages

https://design-system.service.gov.uk/patterns/question-pages/

• GOV.UK Design System, Spacing

https://design-system.service.gov.uk/styles/spacing/

• GOV.UK Design System, Step by Step Navigation

https://design-system.service.gov.uk/patterns/step-by-step-navigation/

• Hoober, S. Touch Design for Mobile Interfaces. Smashing Media AG, 2021.

• Hoober, S.; Berkman, E. Designing Mobile Interfaces. O'Reilly Media, 2011.

• IBM Carbon Design System, Data Table — Usage

https://carbondesignsystem.com/components/data-table/usage/

• IBM Carbon Design System, Pagination — Usage

https://carbondesignsystem.com/components/pagination/usage/

• IETF, RFC 9110 — HTTP Semantics, §9.2 Safe and Idempotent Methods; §13 Conditional Requests

https://www.rfc-editor.org/rfc/rfc9110.html

• Instructure Canvas, Canvas Student Guide / Canvas Student iOS Guide, updated 2025-06-27

https://community.canvaslms.com/html/assets/Canvas_Student_Guide.pdf https://community.canvaslms.com/html/assets/Canvas_Student_iOS_Guide.pdf

• ISO. ISO 9241-940:2017 — Ergonomics of human-system interaction — Part 940: Evaluation of tactile and haptic interactions. International Organization for Standardization, 2017.

• İstanbul Üniversitesi, AKSİS Kullanım Kılavuzu — Belge Talepleri

https://cdn.istanbul.edu.tr/FileHandler2.ashx?f=aksis-kullanim-kilavuzu-omyo.pdf

• Kohavi, R.; Tang, D.; Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. DOI: 10.1017/9781108653985

https://doi.org/10.1017/9781108653985

• Krug, S. Don't Make Me Think, Revisited. New Riders, 3rd edition.

https://sensible.com/dont-make-me-think/

• MacDonald, D. Practical UI Patterns for Design Systems: Fast-Track Interaction Design for a Seamless User Experience. Apress.

• Maeda, J. The Laws of Simplicity: Design, Technology, Business, Life. MIT Press, 2006.

• MDN, AbortController

https://developer.mozilla.org/en-US/docs/Web/API/AbortController

• MDN, clamp()

https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

• MDN, CSS Container Queries

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries

• Meta, Guiding You Through Your Privacy Choices

https://about.fb.com/news/2020/01/privacy-checkup/

• Meta, How We're Making It Easier to Navigate Settings

https://about.fb.com/news/2021/08/facebook-settings-redesign/

• Microsoft Fluent 2, Color

https://fluent2.microsoft.design/color

• Microsoft Fluent 2, Typography

https://fluent2.microsoft.design/typography

• Miller, Richard H. UX for Enterprise ChatGPT Solutions: A Practical Guide to Designing Enterprise-Grade LLMs. Packt Publishing, 2024. ISBN 978-1-83546-119-8.

• MoodleDocs 5.2, Dashboard

https://docs.moodle.org/502/en/Dashboard

• Mor Harchol-Balter. Performance Modeling and Design of Computer Systems: Queueing Theory in Action. Cambridge University Press, 2013.

• Neil, T. Mobile Design Pattern Gallery: UI Patterns for Smartphone Apps. O'Reilly Media, 2014.

• Nielsen Norman Group, Animation for Attention and Comprehension

https://www.nngroup.com/articles/animation-usability/

• Nielsen Norman Group, Application Design Showcase resources

https://www.nngroup.com/reports/best-applications-1/

• Nielsen Norman Group, Data Tables: Four Major User Tasks

https://www.nngroup.com/articles/data-tables/

• Nielsen Norman Group, Horizontal Attention Leans Left

https://www.nngroup.com/articles/horizontal-attention-leans-left/

• Nielsen Norman Group, Information Architecture: Study Guide

https://www.nngroup.com/articles/ia-study-guide/

• Nielsen Norman Group, The 3-Click Rule for Navigation Is False

https://www.nngroup.com/articles/3-click-rule/

• Nielsen Norman Group, The Risks of Imitating Designs (Even from Successful Companies)

https://www.nngroup.com/articles/risks-imitating-designs/

• Nielsen Norman Group, Universal Navigation: Connecting Subsites to Main Sites

https://www.nngroup.com/articles/universal-navigation/

• Nielsen Norman Group, Web UX: Study Guide

https://www.nngroup.com/articles/web-ux-study-guide/

• Norman, D. The Design of Everyday Things, Revised and Expanded Edition.

https://mitpress.mit.edu/9780262525671/the-design-of-everyday-things/

• Norman, D. A. Emotional Design: Why We Love (or Hate) Everyday Things. Basic Books, 2004.

• Norman, D. A. The Design of Future Things. Basic Books, 2007/2009.

• Podmajersky, T. Strategic Writing for UX: Drive Engagement, Conversion, and Retention with Every Word, 2nd Edition. O'Reilly, 2025.

• Rams, D. Ten Principles for Good Design. İlk kez 1970'lerin sonlarında biçimlenen tasarım ilkeleri; Vitsœ ve tasarım manifestosu derlemelerinde yayımlanan sürümler.

• Ronen Feldman; James Sanger. The Text Mining Handbook: Advanced Approaches in Analyzing Unstructured Data. Cambridge University Press, 2007.

• Rosenfeld, L.; Morville, P.; Arango, J. Information Architecture, 4th Edition. O'Reilly.

https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/

• Sakarya Üniversitesi, SABİS / Öğrenci Bilgi Sistemi kullanım rehberleri

https://iletisim.sakarya.edu.tr/sites/iletisim.sakarya.edu.tr/file/2023-2024_YKS_KAYIT_KILAVUZU_1.pdf

• Saleema Amershi et al. “Guidelines for Human-AI Interaction.” CHI Conference on Human Factors in Computing Systems, 2019. https://doi.org/10.1145/3290605.3300233

• Samsung Electronics. One UI Design Guidelines. Mobile UX Center, Mobile Communications Business.

• Sauro, J.; Lewis, J. R. Quantifying the User Experience: Practical Statistics for User Research. Morgan Kaufmann / Elsevier, 2012.

• Shariat, J.; Savard Saucier, C. Tragic Design: The Impact of Bad Product Design and How to Fix It. O'Reilly, 2017.

• Staiano, F. Designing and Prototyping Interfaces with Figma. Packt, 2022.

• Stripe API Reference, Idempotent Requests

https://docs.stripe.com/api/idempotent_requests

• Tidwell, J.; Brewer, C.; Valencia, A. Designing Interfaces, 3rd Edition. O'Reilly.

https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/

• Tractinsky, N.; David, E.; Krupnik, A. Exploring the Aesthetic Effects of the Golden Ratio in the Design of Interactive Products. AMCIS 2013.

https://aisel.aisnet.org/amcis2013/HumanComputerInteraction/GeneralPresentations/12/

• Trendyol Tech, Trendyol Homepage: How Did We Implement a Nearly Real-Time Homepage? — Part 1

https://medium.com/trendyol-tech/trendyol-homepage-how-did-we-implement-a-nearly-real-time-homepage-dc2dcb5eb0e4

• U.S. Web Design System, Design Tokens

https://designsystem.digital.gov/design-tokens/

• U.S. Web Design System, Spacing Units

https://designsystem.digital.gov/design-tokens/spacing-units/

• U.S. Web Design System, Step Indicator

https://designsystem.digital.gov/components/step-indicator/

• UXPin. The Curated Collection of Web Design Techniques: Cards & Minimalism. UXPin, 2015.

• UXPin. Zen of White Space in Web UI Design: Balance, Contrast, Hierarchy. UXPin, 2015.

• Van Schaik, P.; Ling, J. The effects of screen ratio and order on information retrieval in web pages. Displays, 24(4–5), 187–195.

DOI: 10.1016/j.displa.2004.01.005 https://research.tees.ac.uk/en/publications/the-effects-of-screen-ratio-and-order-on-information-retrieval-in/

• W3C Internationalization, Internationalization Quick Tips for the Web

https://www.w3.org/International/quicktips/Overview

• W3C WAI, ARIA Authoring Practices Guide — Dialog Modal Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

• W3C WAI, ARIA Authoring Practices Guide — Grid Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/grid/

• W3C WAI, ARIA Authoring Practices Guide — Table Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/table/

• W3C WAI, ARIA Authoring Practices Guide — Tabs Pattern

https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

• W3C WAI, Cognitive Accessibility at W3C

https://www.w3.org/WAI/cognitive/

• W3C WAI, Making Content Usable for People with Cognitive and Learning Disabilities. Working Group Note, 2021.

https://www.w3.org/TR/coga-usable/

• W3C WAI, Understanding Success Criterion 2.5.8: Target Size (Minimum)

https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum

• W3C, Service Workers

https://www.w3.org/TR/service-workers/

• W3C, Understanding SC 1.4.10: Reflow

https://www.w3.org/WAI/WCAG22/Understanding/reflow.html

• W3C, Understanding SC 1.4.11: Non-text Contrast

https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html

• W3C, Understanding SC 1.4.12: Text Spacing

https://www.w3.org/WAI/WCAG22/Understanding/text-spacing.html

• W3C, Understanding SC 1.4.3: Contrast (Minimum)

https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html

• W3C, Web Authentication: An API for Accessing Public Key Credentials — Level 3. W3C Recommendation, 25 August 2026.

https://www.w3.org/TR/webauthn-3/

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2

https://www.w3.org/TR/WCAG22/

• Walter W. Piegorsch, Richard A. Levine, Hao Helen Zhang, Thomas C. M. Lee (eds.). Computational Statistics in Data Science. Wiley, 2022. ISBN 9781119561071.

• web.dev, Interaction to Next Paint (INP)

https://web.dev/articles/inp

• web.dev, Optimize Input Delay

https://web.dev/articles/optimize-input-delay

• web.dev, Responsive Web Design Basics

https://web.dev/articles/responsive-web-design-basics

• web.dev, Web Vitals

https://web.dev/articles/vitals

• Weinschenk, S. M. 100 Things Every Designer Needs to Know About People. New Riders, 2011.

• Weinschenk, S. M. Neuro Web Design: What Makes Them Click? New Riders.

• Whalen, J. Design for How People Think: Using Brain Science to Build Better Products. O'Reilly, 2019.

• WHATWG, HTML Living Standard — Navigation and Session History; Web Storage; Web Messaging

https://html.spec.whatwg.org/multipage/nav-history-apis.html https://html.spec.whatwg.org/multipage/webstorage.html https://html.spec.whatwg.org/multipage/web-messaging.html

• Wroblewski, L. Web Form Design: Filling in the Blanks.

https://www.lukew.com/resources/web_form_design.asp

• X Help, Accessibility Features of X

https://help.x.com/en/using-x/accessibility-features

• Yablonski, J. Laws of UX: Using Psychology to Design Better Products & Services. O'Reilly, 2020; kaynak derlemesinde ikinci baskı da bulunmaktadır.

• Yuen, J. FUI: How to Design User Interfaces for Film and Games. HUDS+GUIS, 2017. ISBN 9781975795122.

https://www.hudsandguis.com/fui

• Snyder, C. Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces. Morgan Kaufmann, 2003.

• The Center for Universal Design, NC State University. The Principles of Universal Design, Version 2.0. 1997. https://design.ncsu.edu/research/center-for-universal-design/

• Wharton, C.; Rieman, J.; Lewis, C.; Polson, P. "The Cognitive Walkthrough Method: A Practitioner's Guide." In Nielsen, J.; Mack, R. L. (eds.), Usability Inspection Methods. Wiley, 1994.