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

> Kullanılabilirlik, bilgi mimarisi, erişilebilirlik, duyarlı tasarım, veri tabloları, formlar, güvenilir istemci davranışı ve kritik iş uygulamalarında Zen yaklaşımını mühendislik bakışıyla ele alan kapsamlı ders notu.

- Author: Muhammet Ali Köker
- Language: tr
- Canonical: https://alikoker.com.tr/web-uygulamalarinda-ui-ux-muhendisligi
- Translation: https://alikoker.com.tr/en/ui-ux-engineering-in-web-applications
- Published: 2023-12-01T00:00:00+03:00
- Modified: 2026-08-26T11:10:00+03:00
- Verified: 2026-08-26T11:10:00+03:00
- Type: article

> **Yaklaşım:** Burada Zen sözcüğünü tarihsel ya da dinî bir öğretinin tasarım kuralına indirgenmiş karşılığı olarak kullanmıyorum. Benim için bu metindeki Zen; gereksiz kararı 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 anlamına geliyor. Bu yaklaşım estetik bir slogan değil; standart, ölçüm, hata maliyeti ve gerçek görev bağlamıyla sınanan bir mühendislik disiplini olarak ele alınmalıdır.


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.

Bu nedenle notu UI ve UX'in yalnız görsel tasarım tarafına değil, **insan-bilgisayar etkileşimi ile yazılım mühendisliğinin kesişimine** yerleştiriyorum. 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.

Notta 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: 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.

---

## Ünite 2: 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.

---

## Ünite 3: 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ı

```text
┌─────────────────────────────────────────────────────────────────────────┐
│ 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:

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

Yoğun iş uygulaması:

```text
┌───────────────────────────────────────────────┐
│ Ü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.

```text
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.

---

## Ünite 4: 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.

### Tutarlı boşluk ölçeği

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

```text
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

```text
[!] 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.

---

## Ünite 5: Altın Oran — Tasarım İlkesi mi, Tasarım Miti mi?

Altın oran:

```text
φ = (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.

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

---

## Ünite 6: Bilgi Mimarisi ve Gezinme

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

Belirsiz:

```text
İşlemler
Diğer
Hizmetler
Daha Fazla
```

Daha açıklayıcı:

```text
İ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.

```text
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.

---

## Ünite 7: 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.

### Yazdıkça arama

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

```text
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 8: 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

```text
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.

---

## Ünite 9: 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:

```text
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

```html
<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 özeti

```text
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.

---

## Ünite 10: 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.

```text
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.

```text
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:

```text
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

```text
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.

## Ünite 11: 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.

---

## Ünite 12: Sistem Geri Bildirimi, Yükleme Durumları ve Algılanan Performans

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

Kullanıcı açısından:

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

ile:

```text
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:

```text
Kayıt yok
```

yerine durumun nedenini ayırmalıdır.

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

veya:

```text
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.

---

## Ünite 13: 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:

```text
POST /save
POST /save
```

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

```javascript
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:

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

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

#### Debounce

```javascript
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

```text
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.

```javascript
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:

```text
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:

```text
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ı

```text
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.

---

## Ünite 14: 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:

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

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

Yanlış düşünce:

```text
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.

```css
.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:

```css
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.

```css
@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.

### 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ü:

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

Mobil:

```text
[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 | Örnek CSS görüntü alanı |
|---|---:|
| Çok dar telefon | 320 × 568 |
| Telefon | 360 × 800 |
| Modern telefon | 390 × 844 |
| Büyük telefon | 412 × 915 |
| Küçük tablet | 768 × 1024 |
| Tablet/yatay | 1024 × 768 |
| Küçük laptop | 1366 × 768 |
| Laptop | 1440 × 900 |
| Masaüstü | 1920 × 1080 |
| Geniş ekran | 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:

```text
|                 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.

---

## Ünite 15: 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:

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

Uygun değil:

```text
[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

Öncelik:

1. ana görev görünür,
2. ikincil görev taşma menüsünde,
3. 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.

```text
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.

---

## Ünite 16: 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

```css
: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

```css
@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ü:

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

Daha iyi:

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

### Canlı bildirimler

Dinamik durum:

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

Kritik hata:

```html
<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.

---

## Ünite 17: Performans Bir UX Özelliğidir

### Core Web Vitals

Google'ın güncel Core 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:

```text
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**.

---

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

### UI gizlemek yetkilendirme değildir

```text
if (!admin) hideDeleteButton();
```

yalnız UX'tir.

Sunucu tarafı ayrıca:

```text
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ü:

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

Doğru:

```text
Sunucu → yalnız yetkili kayıtlar
```

### Yıkıcı eylem

Silme düğmesinde:

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

açık olmalıdır.

```text
“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:

```text
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.

---

## Ünite 19: 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. Burada benim için dikkat çekici olan 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.
---

## Ünite 20: 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ü:

```text
[ 125 ]
[ 98 ]
[ 72 ]
[ 41 ]
```

Sayıların anlamı ve eylemi yoktur.

Daha iyi:

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

### 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.

---

## Ünite 21: 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:

```text
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.

---

## Ünite 22: Duyarlı Form ve Tablo Birlikte Tasarlama

### Masaüstü formu

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

                         [İptal] [Kaydet]
```

### İki sütun ne zaman?

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

```text
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

```text
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.

---

## Ünite 23: 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.

---

## Ünite 24: UI Durum Modeli

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

Asgari durum makinesi:

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

Değişiklik işlemi:

```text
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.

---

## Ünite 25: Form ve İşlem Durumları İçin Güvenilir Kalıp

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

```text
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.

---

## Ünite 26: 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

```css
: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:

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

Girdi:

```text
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.

---

## Ünite 27: 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:

```text
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:

```text
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:

```text
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.

---

## Ünite 28: 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ı:

```text
[Açıklamalı Yeni Kayıt]
```

Uzman:

```text
Ctrl+N
```

ile aynı görevi yapabilir.

### 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.

---

## Ünite 29: 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:

```text
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:

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

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

---

## Ünite 30: UI/UX Ölçümü

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

### 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ı.

### 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ç:

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

---

## Ünite 31: 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?

### 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?

---

## Ünite 32: Bir Web Uygulaması İçin Önerilen Temel Yerleşim

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

```text
┌──────────────────────────────────────────────────────────────────────┐
│ 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

```text
┌───────────────────────────┐
│ ←  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.

---

## Ünite 33: 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.

---

## Ünite 34: 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.

---

## Ünite 35: 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.

---

## Ünite 36: 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.

---

## Ünite 37: Tasarım Kararlarında Kanıt Hiyerarşisi

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

```text
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.

---

## Ünite 38: 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ç.**

---


## Ünite 39: 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.

Kaynak notlarında özellikle *Simple and Usable*, *Designing Interfaces*, *The Design of Everyday Things* ve *Don't Make Me Think* aynı noktaya farklı dillerle 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.

### 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:

```text
Kaydediliyor…
Kaydedildi
```

yeterliyken:

```text
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.

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

---

## Ünite 40: 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:

```text
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:

```text
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.

---

## Ünite 41: 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:

```text
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:

```text
Arşivlendi. [Geri Al]
```

çoğu zaman:

```text
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.

---

## Ünite 42: 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.

### Sonuç

Bir işlev:

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

olsa bile kullanıcı onu keşfetmeyebilir.

Çünkü mevcut yol:

```text
ç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:

```text
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:

```text
A → B → C
```

yeni tasarım:

```text
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.

---

## Ünite 43: 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ı:

```text
Çı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:

```text
Ne yapmak istiyorsunuz?
[Dosyayı Aç]
```

Gerekirse sonra:

```text
[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.

```text
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ı:

```text
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ç.

---

## Ünite 44: 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:

```text
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:

```text
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.

---

## Ünite 45: 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:

```text
Önceki sayfadaki kodu hatırla
→ bu sayfaya yaz
```

demek yerine:

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

bağlamı ekranda tutmak daha güvenlidir.

### Gruplama

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

Kötü:

```text
30 alan tek form
```

Daha iyi:

```text
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.

---

## Ünite 46: 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ı:

```text
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:

```text
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”:

```text
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.

---

## Ünite 47: 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.

```text
[24 kaydı dışa aktar]
```

`[Tamam]` düğmesinden daha fazla eylem öncesi yönlendirme sağlar.

### Geri bildirim

Eylemden sonra:

> Ne oldu?

sorusunu cevaplar.

```text
24 kayıt dışa aktarıldı.
```

### İyi kontrol metni

Düğme:

```text
[Gönder]
```

yerine bağlama göre:

```text
[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.

---

## Ünite 48: İ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.

### Zorlayıcı işlev

Bazı kritik işlemler yanlış sırayı fiziksel olarak engellemelidir.

Örnek:

```text
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.

---

## Ünite 49: 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ç:

```text
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:

```text
(555) 123-45-67
5551234567
555 123 45 67
```

aynı telefon semantiğine normalize edilebilir.

Ama:

```text
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.

---

## Ünite 50: Sadeleştirmenin Dört Stratejisi — Kaldır, Düzenle, Gizle, Yer Değiştir

*Simple and Usable* kaynak notlarının en uygulanabilir çerçevelerinden 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:

```text
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:

```text
Kullanıcı her seferinde tarih formatı seçmesin
→ yerel ayar/sistem tercihini uygulasın.
```

veya:

```text
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:

```text
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 51: 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ü:

```text
STAT_CD
```

Daha iyi:

```text
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 normalization anlam kaybı üretmemelidir.

### Review

Kritik formda son adım:

```text
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.

---

## Ünite 52: 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:

```text
satırı tıklamak = yalnız seçmek
```

mi,

```text
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:

```text
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.

---

## Ünite 53: Arayüz Metni Tasarımı — Kelime de Bileşendir

*Strategic Writing for UX* kaynak notları, 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:

```text
İşlemler
```

Daha iyi:

```text
Kullanıcı Yetkileri
```

### Düğme

Düğme metni sonucu açıklamalıdır.

```text
[OK]
```

yerine:

```text
[Değişiklikleri Kaydet]
```

### Boş durum

Boşluk yalnız “veri yok” demez; ne yapılabileceğini de anlatabilir.

```text
Henüz kayıt yok.
[Yeni kayıt oluştur]
```

veya:

```text
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.

---

## Ünite 54: 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:

```text
sahte veri + tek kullanıcı + sıfır gecikme
```

deseni üretimde:

```text
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.

---

## Ünite 55: 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.

---

## Ünite 56: 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 57: 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

```text
Token
  ↓
Primitive
  ↓
Bileşen
  ↓
Kalıp
```

Örneğin:

```text
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:

```text
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.

---

## Ünite 58: 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:

```text
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.

---


## Ünite 59: Önerilen Kitaplar

Aşağıdaki eserler bu ders notunu kitap temelli ikinci bir sürüme genişletmek için özellikle değerlidir.

### 1. Designing Interfaces, 3rd Edition

**Jenifer Tidwell, Charles Brewer, Aynne Valencia — O'Reilly**

Öncelik: **Çok yüksek**

Kapsam:

- etkileşim kalıpları,
- bilgi mimarisi,
- gezinme,
- yerleşim,
- formlar,
- veri,
- duyarlı/mobil,
- karmaşık uygulama kalıpları.

Bu notun “uygulama deseni” katmanını en fazla zenginleştirecek kitaptır.

### 2. The Design of Everyday Things — Revised and Expanded Edition

**Don Norman**

Öncelik: **Çok yüksek**

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**

Öncelik: **Yüksek**

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**

Öncelik: **Form yoğun uygulamalar için yüksek**

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**

Öncelik: **Büyük içerik/modül hiyerarşileri için yüksek**

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**

Öncelik: **İnsan bilişi ve davranışsal tasarım için yüksek**

Dikkat, bellek, algı, okuma, karar verme, hata ve sosyal davranışın tasarıma etkisini pratik başlıklarla ele alır. Bu nottaki bilişsel bütçe, görünürlük ve tanıma/hatırlama bölümlerini genişletmek için kullanılmıştır.

### 7. Design for How People Think

**John Whalen**

Öncelik: **Araştırma ile tasarım kararını bağlamak için yüksek**

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**

Öncelik: **Form yoğun uygulamalar için çok yüksek**

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**

Öncelik: **Uygulama davranışını üretimden önce doğrulamak için yüksek**

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ı**

Öncelik: **Psikolojik ilkeleri tasarım hipotezine dönüştürmek için yüksek**

Jakob, Fitts, Hick, Tepe–Son, aesthetic-usability, von Restorff ve Tesler gibi ilkeleri erişilebilir biçimde toplar. Bu ilkeler notta “evrensel yasa” değil, görev bağlamında doğrulanması gereken tasarım hipotezleri olarak kullanılmıştır.

### 11. Simple and Usable

**Giles Colborne — 2. baskı**

Öncelik: **Zen yaklaşımının pratik mühendislik karşılığı için çok yüksek**

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**

Öncelik: **UI metni, hata, onay, boş durum ve içerik tasarımı için çok yüksek**

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**

Öncelik: **Kritik sistemler ve etik UX için çok yüksek**

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ı**

Öncelik: **Stratejiden görsel yüzeye kadar bütünsel UX mimarisi için yüksek**

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**

Öncelik: **Güven, algılanan kalite ve duygusal tepki için orta/yüksek**

İş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**

Öncelik: **Büyük etkileşimli uygulamalarda süreç ve uygulama pratiği için orta/yüksek**

Kullanıcı deneyiminin yalnız ekran değil; ekip, süreç, mühendislik ve sürekli değerlendirme problemi olduğunu destekler.

Bu kaynakların adlarını yalnız bir okuma listesi oluşturmak için vermiyorum. Her biri farklı bir karar katmanını açıklıyor: etkileşim kalıpları, insan hatası, form tasarımı, bilgi mimarisi, biliş, arayüz metni, prototipleme ve kritik sistemlerde hata maliyeti. Metinde bir kaynağa dayandırılan görüş ile benim mühendislik sentezim mümkün olduğunca ayrı tutulmuştur; kaynakta doğrulanmayan ayrıntılar eserin görüşüymüş gibi aktarılmamıştır.

---

## Ünite 60: Sonuç

Bu notun sonunda geriye tek bir tasarım formülü kalmıyor; zaten kalmaması gerekir. 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:

```text
altın oran
```

ne:

```text
3 tıklama
```

ne:

```text
mobil öncelikli tasarım
```

ne de:

```text
Amazon böyle yapıyor
```

tek başına tasarım kararı için yeterlidir.

Benim için daha sağlam karar sırası şöyledir:

```text
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:

```text
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**.

---

# Kaynakça ve Teknik Doğrulama Kaynakları

## W3C / standartlar

1. W3C, **Web Content Accessibility Guidelines (WCAG) 2.2**  
   https://www.w3.org/TR/WCAG22/

2. W3C WAI, **ARIA Authoring Practices Guide — Tabs Pattern**  
   https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

3. W3C WAI, **ARIA Authoring Practices Guide — Grid Pattern**  
   https://www.w3.org/WAI/ARIA/apg/patterns/grid/

4. W3C WAI, **ARIA Authoring Practices Guide — Table Pattern**  
   https://www.w3.org/WAI/ARIA/apg/patterns/table/

5. W3C WAI, **ARIA Authoring Practices Guide — Dialog Modal Pattern**  
   https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

6. IETF, **RFC 9110 — HTTP Semantics**, §9.2 Safe and Idempotent Methods  
   https://www.rfc-editor.org/rfc/rfc9110.html

## Nielsen Norman Group

7. Nielsen Norman Group, **Web UX: Study Guide**  
   https://www.nngroup.com/articles/web-ux-study-guide/

8. Nielsen Norman Group, **Information Architecture: Study Guide**  
   https://www.nngroup.com/articles/ia-study-guide/

9. Nielsen Norman Group, **The 3-Click Rule for Navigation Is False**  
   https://www.nngroup.com/articles/3-click-rule/

10. Nielsen Norman Group, **Horizontal Attention Leans Left**  
    https://www.nngroup.com/articles/horizontal-attention-leans-left/

11. Nielsen Norman Group, **Universal Navigation: Connecting Subsites to Main Sites**  
    https://www.nngroup.com/articles/universal-navigation/

12. Nielsen Norman Group, **The Risks of Imitating Designs (Even from Successful Companies)**  
    https://www.nngroup.com/articles/risks-imitating-designs/

13. Nielsen Norman Group, **Data Tables: Four Major User Tasks**  
    https://www.nngroup.com/articles/data-tables/

14. Nielsen Norman Group, **Animation for Attention and Comprehension**  
    https://www.nngroup.com/articles/animation-usability/

15. Nielsen Norman Group, **Application Design Showcase** resources  
    https://www.nngroup.com/reports/best-applications-1/

## GOV.UK Design System

16. GOV.UK Design System, **Question Pages**  
    https://design-system.service.gov.uk/patterns/question-pages/

17. GOV.UK Design System, **Check Answers**  
    https://design-system.service.gov.uk/patterns/check-answers/

18. GOV.UK Design System, **Complete Multiple Tasks**  
    https://design-system.service.gov.uk/patterns/complete-multiple-tasks/

19. GOV.UK Design System, **Back Link**  
    https://design-system.service.gov.uk/components/back-link/

20. GOV.UK Design System, **Step by Step Navigation**  
    https://design-system.service.gov.uk/patterns/step-by-step-navigation/

## IBM Carbon / Apple / Android

21. IBM Carbon Design System, **Data Table — Usage**  
    https://carbondesignsystem.com/components/data-table/usage/

22. IBM Carbon Design System, **Pagination — Usage**  
    https://carbondesignsystem.com/components/pagination/usage/

23. Apple Human Interface Guidelines, **Tab Bars**  
    https://developer.apple.com/design/human-interface-guidelines/tab-bars

24. Apple Human Interface Guidelines, **Sidebars**  
    https://developer.apple.com/design/human-interface-guidelines/sidebars

25. Apple Human Interface Guidelines, **Toolbars**  
    https://developer.apple.com/design/human-interface-guidelines/toolbars

26. Android Developers / Material 3, **NavigationBar**  
    https://developer.android.com/reference/kotlin/androidx/compose/material3/NavigationBar

## Responsive / performans / istemci

27. web.dev, **Responsive Web Design Basics**  
    https://web.dev/articles/responsive-web-design-basics

28. MDN, **CSS Container Queries**  
    https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries

29. MDN, **clamp()**  
    https://developer.mozilla.org/en-US/docs/Web/CSS/clamp

30. MDN, **AbortController**  
    https://developer.mozilla.org/en-US/docs/Web/API/AbortController

31. web.dev, **Web Vitals**  
    https://web.dev/articles/vitals

32. web.dev, **Interaction to Next Paint (INP)**  
    https://web.dev/articles/inp

33. web.dev, **Optimize Input Delay**  
    https://web.dev/articles/optimize-input-delay

## API güvenilirliği

34. Stripe API Reference, **Idempotent Requests**  
    https://docs.stripe.com/api/idempotent_requests

## Altın oran araştırmaları

35. 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/

36. 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/

## E-ticaret ve büyük ölçekli ürün örnekleri

37. Amazon, **Enhanced Homepage Features**  
    https://www.aboutamazon.com/news/retail/amazon-homepage-redesign-features

38. 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

39. Meta, **How We're Making It Easier to Navigate Settings**  
    https://about.fb.com/news/2021/08/facebook-settings-redesign/

40. Meta, **Guiding You Through Your Privacy Choices**  
    https://about.fb.com/news/2020/01/privacy-checkup/

41. X Help, **Accessibility Features of X**  
    https://help.x.com/en/using-x/accessibility-features

42. 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

43. D-MARKET / Hepsiburada, **2025 Form 20-F**, SEC  
    https://www.sec.gov/Archives/edgar/data/1850235/000110465926053195/heps-20251231x20f.htm

## LMS ve üniversite otomasyonları

44. MoodleDocs 5.2, **Dashboard**  
    https://docs.moodle.org/502/en/Dashboard

45. 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

46. İstanbul Üniversitesi, **AKSİS Kullanım Kılavuzu — Belge Talepleri**  
    https://cdn.istanbul.edu.tr/FileHandler2.ashx?f=aksis-kullanim-kilavuzu-omyo.pdf

47. 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

## Kitaplar

48. Tidwell, J.; Brewer, C.; Valencia, A. **Designing Interfaces, 3rd Edition.** O'Reilly.  
    https://www.oreilly.com/library/view/designing-interfaces-3rd/9781492051954/

49. Norman, D. **The Design of Everyday Things, Revised and Expanded Edition.**  
    https://mitpress.mit.edu/9780262525671/the-design-of-everyday-things/

50. Krug, S. **Don't Make Me Think, Revisited.** New Riders, 3rd edition.  
    https://sensible.com/dont-make-me-think/

51. Wroblewski, L. **Web Form Design: Filling in the Blanks.**  
    https://www.lukew.com/resources/web_form_design.asp

52. Rosenfeld, L.; Morville, P.; Arango, J. **Information Architecture, 4th Edition.** O'Reilly.  
    https://www.oreilly.com/library/view/information-architecture-4th/9781491913529/


## Kaynak notlarıyla eklenen kitaplar

53. Tidwell, J.; Brewer, C.; Valencia, A. **Designing Interfaces: Patterns for Effective Interaction Design, 3rd Edition.** O'Reilly, 2020.

54. Norman, D. A. **The Design of Everyday Things, Revised and Expanded Edition.** Basic Books, 2013.

55. Weinschenk, S. M. **100 Things Every Designer Needs to Know About People.** New Riders, 2011.

56. Whalen, J. **Design for How People Think: Using Brain Science to Build Better Products.** O'Reilly, 2019.

57. Norman, D. A. **The Design of Future Things.** Basic Books, 2007/2009.

58. Enders, J. **Designing UX: Forms.** SitePoint, 2016.

59. Coleman, B.; Goodwin, D. **Designing UX: Prototyping.** SitePoint, 2017.

60. Krug, S. **Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability.** New Riders, 2014.

61. Anderson, J.; McRee, J.; Wilson, R.; EffectiveUI Team. **Effective UI.** O'Reilly, 2010.

62. Norman, D. A. **Emotional Design: Why We Love (or Hate) Everyday Things.** Basic Books, 2004.

63. Yablonski, J. **Laws of UX: Using Psychology to Design Better Products & Services.** O'Reilly, 2020; kaynak derlemesinde ikinci baskı da bulunmaktadır.

64. Weinschenk, S. M. **Neuro Web Design: What Makes Them Click?** New Riders.

65. MacDonald, D. **Practical UI Patterns for Design Systems: Fast-Track Interaction Design for a Seamless User Experience.** Apress.

66. Colborne, G. **Simple and Usable: Web, Mobile, and Interaction Design, 2nd Edition.** New Riders, 2018.

67. Podmajersky, T. **Strategic Writing for UX: Drive Engagement, Conversion, and Retention with Every Word, 2nd Edition.** O'Reilly, 2025.

68. Shariat, J.; Savard Saucier, C. **Tragic Design: The Impact of Bad Product Design and How to Fix It.** O'Reilly, 2017.

69. Garrett, J. J. **The Elements of User Experience: User-Centered Design for the Web and Beyond, 2nd Edition.** New Riders, 2011.

70. Staiano, F. **Designing and Prototyping Interfaces with Figma.** Packt, 2022.


---

**Son güncelleme:** Ağustos 2026  
**Son teknik doğrulama:** 26 Ağustos 2026

Bu notta normatif erişilebilirlik hükümleri W3C WCAG 2.2 ve WAI-ARIA APG ile; HTTP idempotency semantiği RFC 9110 ile; performans metrikleri güncel web.dev belgeleriyle doğrulanmıştır. Ürün örnekleri ilgili kurumların resmî dokümantasyonu, teknik yayınları veya SEC beyanları üzerinden değerlendirilmiştir. Altın oran bölümü, popüler tasarım anlatılarından bağımsız olarak deneysel akademik çalışmalarla sınırlandırılmıştır.

## 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