UX ve UI Ayrımı: Tanımda Net, Ekranda Bulanık
UX ve UI'yi ayıran tanımlar kitapta düzgün durur: biri deneyimin bütünü, diğeri o deneyimin görünen yüzü. Masaya oturunca bu netlik kaybolur, çünkü kullanıcı yüzeyden başka hiçbir şeye dokunmaz. Ayrımın gerçekten iş gördüğü bir yer var, bir de sırf ekip şeması öyle diye sürdürüldüğü yerler.
İki tanım, tek yüzey
UX, kullanıcının ürünle kurduğu ilişkinin tamamıdır: ne aradığı, kaç adımda bulduğu, bulamayınca ne yaptığı. UI ise bu ilişkinin geçtiği yüzeydir; butonlar, tipografi, boşluk, hareket. Ayrımın kitaptaki hali bu kadar.
Pratikte tökezlediği nokta şu: bilgi mimarisi ne kadar sağlam kurulmuş olursa olsun, kullanıcıya ulaşma biçimi menüdeki üç kelimedir. Yanlış seçilmiş üç kelime, arkasındaki doğru yapıyı tamamen görünmez yapar. Bu yüzden "UX kararı verildi, gerisi görsel iş" cümlesi çoğu ekipte doğru değil.
Otomobil benzetmesi nerede kopuyor
Bu ayrımı anlatmak için en sık başvurulan örnek otomobildir: gösterge paneli UI, yolculuğun rahatlığı ve direksiyonun tepkisi UX. Akılda kalıyor, ama yazılımda tam karşılığı yok. Arabada arayüzden bağımsız bir mekanik katman vardır ve sürücü onu doğrudan hisseder: süspansiyon, motor sesi, frenin tutuşu. Bir web uygulamasında öyle bir katman yok. Sunucu tarafındaki her şey kullanıcıya yalnızca ekran üzerinden ulaşır. Sorgunun 40 milisaniye değil de 900 milisaniye sürdüğünü kullanıcı ancak dönen bir ikonu izleyerek anlar; yani performansı bile arayüz üzerinden deneyimler.
Benzetmeyi çöpe atmak gerekmiyor, sınırını bilmek yetiyor. Yazılımda UX'in arayüzden bağımsız bir gövdesi yoktur. Arayüzün altında verilmiş kararların toplamıdır, o kadar.
Ayrım nerede iş görüyor: unvanda değil, sırada
Faydası şurada: ekran düzenine karar vermeden önce o ekranın hangi soruya cevap verdiğini bilmek gerekir. Kullanıcı buraya niye geldi, çıkarken elinde ne olacak, hangi bilgiyi yanında getirmiyor. Bu sorular cevaplanmadan başlayan görsel çalışma, sonra baştan yapılır.
Tek kişilik ekipte bunu iki unvana bölmek anlamsız. Sırayı korumak yine de gerekli, çünkü sıra bozulduğunda düzeltmenin bedeli piksel değil, veri modeli oluyor. Shazam bunun temiz bir örneği: uygulamanın tek bir işi olduğuna karar verilmiş, ekranın ortasındaki dev buton o kararın sonucu. Butonu güzelleştirerek o kararı üretemezdiniz.
Devir sırasında kaybolan şey
Ayrımın en pahalı yan etkisi devir anında ortaya çıkıyor. Bir tarafta "deneyim tasarlandı" deniyor, diğer tarafta gelen şey bir ekran görüntüsü oluyor; aradaki varsayımlar kimsenin yazmadığı yerde kalıyor. Bir e-ticaret projesinde filtre panelini "sadece görsel düzenleme" diye devralmıştık, iki gün sonra asıl meselenin filtre durumunun adres çubuğunda tutulmaması olduğunu gördük.
Bir arayüz iddiasının kodda karşılığı var mı diye sormak, tasarım tarafında da işe yarayan bir alışkanlık. "Kullanıcı istediği ana geri dönebilsin" cümlesi, durumun nerede saklandığına dair bir karar demektir. Saklanmıyorsa cümle sadece niyet olarak kalır ve kimse fark etmez, ta ki biri paylaştığı bağlantıyı açıp bomboş bir liste görene kadar.
Peki hangisine yatırım yapmalı
Bu soru genelde "ikisi de eşit derecede kıymetli" diye kapatılır. Pek yardımcı olmuyor. Ürün henüz ne işe yaradığını kanıtlamamışsa yatırım sıraya gider: akış doğru mu, adım sayısı gerçekten gerekli mi, kullanıcı ilk oturumda bir sonuç alabiliyor mu. Ürün oturduktan sonra kazanç yüzeye kayar; aynı akış üzerinde okunabilirlik, tepki süresi ve tutarlılık, dönüşümde ölçülebilir fark yaratır.
Ölçmek isteyen için pratik sınır şu: arayüz değişikliğinin etkisini görmek için tek metrik yetmez. Tamamlama oranı yükselirken destek talepleri de yükseliyorsa, akışı kısaltmışsınız ama bir yerde belirsizlik bırakmışsınızdır.
Kaynaklar