UI/UX Tasarım ve Kullanıcı Deneyimi

UI ve UX aynı şey mi?

Sık karıştırılıyor ama iki farklı iş. UX (kullanıcı deneyimi), kullanıcının bir işi yaparken izlediği yolu tasarlamaktır: kaç adımda tamamlanacak, hangi bilgi ne zaman istenecek, hata olduğunda ne görecek. UI (kullanıcı arayüzü) ise bu yolun görsel karşılığıdır: tipografi, renk, boşluk, ikonografi, bileşen davranışları.

Kötü bir UX iyi bir UI ile kurtarılamaz. Formunuz on beş alan soruyorsa, o formu ne kadar güzel tasarlarsanız tasarlayın terk oranı yüksek kalır. Tersi de geçerlidir: doğru kurgulanmış bir akış, tutarsız görsel dil yüzünden güven kaybedebilir. Bu yüzden ikisini ayrı ayrı satmıyor, tek bir çalışma olarak yürütüyoruz.

Çalışma nasıl ilerliyor?

Süreç her zaman anlamakla başlar, çizmekle değil. İlk hafta bir satır arayüz tasarlanmaz.

• Keşif: Ürünü kim kullanıyor, hangi işi yapmaya çalışıyor, şu an nerede takılıyor. Elinizde analitik varsa GA4 üzerinden huni terk noktalarını, ısı haritası kaydı varsa kullanıcıların gerçekte nereye tıkladığını inceliyoruz. Destek ekibinizin en sık aldığı sorular, kullanılabilirlik sorunlarının en dürüst kaynağıdır.
• Araştırma: 5-8 gerçek kullanıcıyla yarı yapılandırılmış görüşme yapıyoruz. Bu sayı kulağa az gelebilir ancak kullanılabilirlik sorunlarının büyük bölümü ilk beş görüşmede ortaya çıkar. Bulguları temalara ayırıp önceliklendiriyoruz.
• Yapılandırma: Bilgi mimarisi çıkarılıyor, gerekiyorsa kart gruplama çalışmasıyla menü yapısı kullanıcıların zihnindeki gruplamaya göre yeniden kuruluyor. Ardından kritik işler için akış şemaları çiziliyor.
• Prototip: Tıklanabilir tel çerçeve hazırlanıyor. Bu prototip gerçek bir ürün gibi kullanılabildiği için kullanıcı testi buradan yapılıyor; henüz tek satır kod yazılmamış oluyor.
• Test ve düzeltme: Prototip 5-6 kullanıcıya belirli görevlerle veriliyor. Görev tamamlama oranı, takılma noktaları ve sözlü geri bildirimler kaydediliyor. Bulgulara göre akış düzeltiliyor.
• Arayüz tasarımı ve sistem: Onaylanan akış üzerine görsel katman kuruluyor ve tasarım sistemi belgeleniyor.

Kullanıcı testi gerçekten gerekli mi?

Gerekli, çünkü hiçbir tasarımcı hedef kullanıcının zihnini tahmin edemez. Ürününüze her gün bakan bir ekip, arayüzü öğrenmiş olduğu için artık kafa karışıklığını göremez hâle gelir. Bu duruma "bilgi laneti" deniyor ve en tecrübeli ekiplerde bile görülüyor.

Katılımcı seçimi de sonucu doğrudan etkiliyor. Ürünü hiç görmemiş ama hedef kitleye ait kişilerle çalışıyoruz; şirket çalışanları, tedarikçiler ve yakın çevre katılımcı olarak kullanıldığında bulgular yanıltıcı çıkıyor. Katılımcılara ne yapacaklarını değil hangi işi tamamlamaları gerektiğini söylüyoruz: "Sipariş oluşturma butonuna basın" değil, "elinizdeki listedeki ürünleri sipariş edin" gibi. Yönlendirici talimat, test edilmesi gereken şeyin ta kendisini ortadan kaldırıyor.

Test pahalı ya da uzun olmak zorunda değil. Uzaktan yürütülen, kişi başı 30-40 dakikalık, beş katılımcılı bir tur çoğu projede yeterli sonuç veriyor. Ölçtüğümüz üç şey var: görev tamamlanabiliyor mu, ne kadar sürede tamamlanıyor, kullanıcı hangi noktada duraksıyor. Bu ölçüler öznel "beğendim/beğenmedim" yorumlarından çok daha kullanışlı.

Tasarım sistemi neden bu kadar önemli?

Tasarım sistemi, arayüzün kurallarını yazılı hâle getirmektir. İçinde şunlar bulunur:

• Tasarım jetonları: Renkler, tipografi ölçeği, boşluk skalası, köşe yarıçapları ve gölge seviyeleri isimlendirilmiş değişkenler olarak tanımlanır. Böylece geliştirici "bu gri hangi gri" diye sormaz.
• Bileşenler: Buton, form alanı, kart, tablo, bildirim, modal gibi parçalar tüm durumlarıyla tasarlanır: varsayılan, üzerine gelme, odaklanmış, devre dışı, yükleniyor, hatalı.
• Kullanım kuralları: Hangi bileşenin ne zaman kullanılacağı yazılır. Örneğin birincil buton bir ekranda yalnızca bir kez kullanılır.

Sistemin asıl faydası zamanla ortaya çıkıyor. Altı ay sonra yeni bir ekran eklendiğinde, o ekran mevcut bileşenlerden kurulduğu için ürün bütünlüğünü kaybetmiyor. Sistemsiz ilerleyen ürünlerde ise iki yıl içinde birbirine benzemeyen dört farklı buton tipi ortaya çıkıyor.

Erişilebilirlik tasarımın neresinde?

Sonunda değil, başında. WCAG 2.2 AA hedefiyle çalışıyoruz ve bunun tasarım aşamasındaki karşılığı somut: normal metinlerde en az 4,5:1, büyük metin ve arayüz bileşenlerinde en az 3:1 kontrast oranı; yalnızca renkle bilgi taşımamak; her etkileşimli öğe için görünür bir odak halkası; dokunma hedeflerinin yeterli boyutta olması; form alanlarında etiketin yer tutucu metinle değiştirilmemesi.

Bu kurallar sadece görme engelli kullanıcılar için değil. Güneş altında telefonuna bakan, tek eliyle otobüste ilerlemeye çalışan ya da yaşa bağlı görme kaybı olan kullanıcılar da aynı iyileştirmelerden yararlanıyor. Erişilebilirliği sonradan eklemek ise çok daha pahalı; renk paletiniz kontrast sağlamıyorsa tüm arayüzü baştan boyamanız gerekir.

Sadece tasarım alıp kendi ekibimize kodlatabilir miyiz?

Evet, projelerin önemli bölümü böyle ilerliyor. Bu durumda teslim dosyasının kalitesi kritik hâle geliyor. Figma dosyasında her bileşenin ölçüleri, tüm durumları, duyarlı davranışı (hangi kırılma noktasında ne olacağı), boş durum ve hata ekranları ile animasyon süreleri belirtiliyor. Ayrıca geliştirici ekiple bir devir toplantısı yapıyor, uygulama sırasında ortaya çıkan soruları yanıtlamak için belirli bir destek süresi tanımlıyoruz.

Deneyimimize göre teslim sonrası en sık sorun, tasarımda düşünülmemiş uç durumlardan çıkıyor: çok uzun ürün adı, hiç kaydı olmayan liste, yavaş bağlantıda yükleme durumu, çok basamaklı sayılar. Bu yüzden tasarım paketimizde uç durum ekranları ayrı bir teslim kalemi olarak yer alıyor.

Fiyat ve süre neye göre belirleniyor?

Belirleyici olan ekran sayısı değil, benzersiz akış sayısıdır. Bir e-ticaret sitesinde ürün listeleme, ürün detayı, sepet ve ödeme dört ayrı akıştır; buna karşılık yüzlerce ürün sayfası tek şablondur. Fiyatı etkileyen diğer başlıklar araştırma derinliği (kaç görüşme yapılacağı), test turu sayısı, tasarım sisteminin kapsamı ve mevcut bir ürünün yeniden tasarlanıp tasarlanmadığıdır.

Mevcut ürünün yeniden tasarımı çoğu zaman sıfırdan tasarımdan daha uzun sürer, çünkü işleyen bir sistemin tüm iş kurallarını çözmek gerekir. Bu tür projelerde ilk iki haftayı yalnızca mevcut davranışın haritasını çıkarmaya ayırıyoruz.

Tasarımın işe yaradığını nasıl anlayacağız?

Tasarım çalışmasının başarısını beğeni üzerinden ölçmek yanıltıcıdır. Bunun yerine devreye alma öncesinde ve sonrasında karşılaştırılabilir göstergeler tanımlıyoruz. Ölçtüklerimiz genellikle şunlar:

• Görev tamamlama oranı: Belirlenen işi (kayıt oluşturma, sipariş verme, randevu alma) tamamlayabilen kullanıcı yüzdesi. Kullanılabilirlik testinde ölçülür ve yayın sonrası analitikle doğrulanır.
• Görev süresi: Aynı işin ortalama kaç saniyede bittiği. Panel ve iş uygulamalarında en somut kazanç genellikle buradan çıkar.
• Hata oranı: Form doğrulama hatası alma sıklığı, yanlış adımda geri dönme, işlemi iptal etme.
• Adım bazlı terk: Çok adımlı akışlarda kullanıcının hangi adımda çıktığı.
• Destek talebi hacmi: Arayüzle ilgili gelen soruların sayısı. Tasarım iyileştikçe belirli soru tipleri kaybolur.
• Kullanılabilirlik anketi puanı: Standart soru setiyle alınan öznel değerlendirme; tek başına değil, davranış verisiyle birlikte yorumlanır.

Bu göstergeleri proje başlangıcında ölçüp taban değer olarak kaydediyoruz. Taban değer olmadan "daha iyi oldu" cümlesi kanıtlanamaz. Yeni bir üründe taban değer yoksa ilk sürümün ölçümlerini referans alıp sonraki döngüleri buna göre değerlendiriyoruz.

Ölçüm aynı zamanda tartışmaları da bitiriyor. Ekip içinde bir tasarım kararı üzerinde uzlaşılamadığında, kararı en yüksek sesin değil verinin vermesini sağlıyor. Bu yaklaşım özellikle çok paydaşlı kurumsal projelerde, onay turlarının süresini gözle görülür biçimde kısaltıyor.