Kısa cevap: Kullanıcı deneyimi (UX) tasarımı, bir ürünü kullanan kişinin amacına ne kadar kolay, anlaşılır ve az hatayla ulaştığını araştırma, akış, prototip ve test yoluyla planlayan tasarım disiplinidir.
Ben Selçuk Aker; İstanbul'da çalışan, 19 yılı aşkın deneyime sahip bir grafik ve UI/UX tasarımcıyım. UX kelimesi bugün çok geniş anlamda kullanılıyor: bazen bir ekranın güzelliği, bazen bir şirketin müşteri hizmetleri, bazen de yalnızca kullanıcı testi kastediliyor. Bu rehberde UX tasarımının neyi kapsadığını, hangi adımlarla yürüdüğünü, hangi teslimleri ürettiğini ve nasıl ölçüldüğünü sade bir dille anlatıyorum. Alanın genel çerçevesi ve UI ile farkı için UI/UX tasarım ana sayfasına bakabilirsiniz.
Kullanıcı deneyimi ve UX tasarımı: tanım
Kullanıcı deneyimi, bir kişinin bir ürün, hizmet ya da sistemle karşılaşmadan önce, karşılaşırken ve sonrasında yaşadığı algıların ve tepkilerin bütünüdür. Uluslararası standartlarda da (ISO 9241-210, insan merkezli tasarım) deneyim yalnız ekranla sınırlı tutulmaz; beklenti, kullanım ve sonrasındaki izlenim birlikte düşünülür.
UX tasarımı ise bu deneyimi şansa bırakmadan planlama işidir. Pratikte şu soruları cevaplar:
- Bu ürünü kim, hangi amaçla ve hangi koşulda kullanıyor?
- Kişinin amacına ulaşmak için hangi adımlardan geçmesi gerekiyor ve hangileri gereksiz?
- Bilgi hangi sırayla ve hangi adlarla sunulursa kişi aradığını bulur?
- Kişi hata yaptığında ne olur, sistem bunu nasıl anlatır?
- Tasarımın işe yarayıp yaramadığını neyle anlayacağız?
"User experience" teriminin 1990'larda Apple'da çalışan Don Norman tarafından yaygınlaştırıldığı sıkça aktarılır. Norman, kavramı arayüzün ötesinde, kişinin bir ürünle ilişkisinin tamamını anlatmak için kullanmıştır. Bu tarihçe, UX'in yalnızca ekran tasarımı olmadığını hatırlatması açısından önemlidir.
UX'in bileşenleri
UX tek bir beceri değil, birbirine bağlı birkaç çalışma alanından oluşur. Küçük bir projede bunların hepsini aynı kişi yürütebilir; büyük ekiplerde ayrı uzmanlıklara dönüşür.
| Bileşen | Cevapladığı soru | Tipik çıktı |
|---|---|---|
| Kullanıcı araştırması | Kullanıcı kim, neye ihtiyaç duyuyor, nerede zorlanıyor? | Görüşme notları, bulgu özeti |
| Bilgi mimarisi | İçerik nasıl gruplanır ve adlandırılır? | Site haritası, menü yapısı |
| Etkileşim tasarımı | Kullanıcı bir eylem yaptığında ne olur? | Akış şeması, durum listesi |
| Kullanılabilirlik | Görev ne kadar kolay ve hatasız tamamlanıyor? | Test raporu, sorun listesi |
| Erişilebilirlik | Farklı yeteneklerdeki kişiler ürünü kullanabiliyor mu? | Kontrast, odak, ekran okuyucu kontrolleri |
| İçerik ve UX writing | Ekrandaki sözcükler yol gösteriyor mu? | Buton, hata ve yardım metinleri |
Arayüzün görsel katmanı, yani renk, tipografi ve bileşen tasarımı UI tarafında kalır. UX ile UI aynı ekranda buluşur ama farklı soruları cevaplar. Ekrandaki sözcüklerin rolü için UX writing: buton ve hata mesajı metinleri yazısına göz atabilirsiniz.
UX süreci adım adım
UX süreci doğrusal bir çizgi değil, öğrenildikçe geri dönülen bir döngüdür. Yine de çoğu projede adımlar şu sırayla ilerler:
- Keşif: İş hedefi, kısıtlar ve mevcut veriler toplanır. Kullanıcılarla görüşülür ya da mevcut kullanım gözlemlenir.
- Tanımlama: Bulgular gruplanır, asıl problem tek cümleyle yazılır. Persona ya da görev tanımı bu aşamada çıkar.
- Kullanıcı yolculuğu: Kişinin ürünle ilk karşılaşmasından görevini bitirmesine kadar geçtiği adımlar, duyguları ve temas noktaları çizilir.
- Bilgi mimarisi ve akış: Ekranların ve içeriğin yapısı, kullanıcı akışları ve karar noktaları belirlenir.
- Wireframe: Renksiz, düşük ayrıntılı yerleşimlerle her ekranda neyin olacağı ve önceliği kararlaştırılır.
- Prototip: Ekranlar birbirine bağlanır; kişinin tıklayıp deneyebileceği bir model kurulur.
- Kullanılabilirlik testi: Gerçek kullanıcılara görev verilir, nerede takıldıkları gözlenir.
- İterasyon: Bulgulara göre akış ve ekranlar düzeltilir, gerekirse yeniden test edilir.
- Ölçüm: Ürün yayına çıktıktan sonra görev başarısı ve sorun noktaları izlenir; bir sonraki döngünün girdisi olur.
Bu adımların her biri büyük bir bütçe gerektirmez. Önemli olan, ekranı çizmeden önce kimin hangi görevi yapacağının netleşmesidir. Wireframe ve prototipte hangi kararların sınanacağını wireframe ve prototip kararları yazısında anlattım.
Persona, kullanıcı yolculuğu ve bilgi mimarisi
Persona, hedef kullanıcı grubunu temsil eden, araştırma bulgularına dayanan kısa bir profildir. İşe yarayan bir persona yaş ve meslek listesinden çok amaç, engel ve kullanım bağlamını anlatır. Araştırmaya dayanmayan, hayal ürünü personalar ise ekibi yanlış bir güven duygusuna sokar. Birçok projede persona yerine "görev tanımı" daha pratiktir: "Kullanıcı, mesai arasında beş dakikada izin talebi oluşturmak istiyor" gibi.
Kullanıcı yolculuğu haritası, kişinin bir hedefe ulaşırken geçtiği aşamaları zaman çizgisi üzerinde gösterir. Uygulama dışı temas noktalarını da içerebilir: reklam, mağaza sayfası, e-posta, çağrı merkezi. Bu yüzden ekip içinde "sorun ekranda mı, yoksa ekrandan önce mi başlıyor?" sorusunu cevaplamak için iyi bir araçtır.
Bilgi mimarisi, içeriğin gruplanması, adlandırılması ve hangi yoldan bulunacağının kararıdır. Menü başlıklarının kullanıcının diliyle mi yoksa şirketin iç diliyle mi yazıldığı, çoğu gezinme sorununun kaynağıdır. Kart sıralama (card sorting) gibi yöntemlerle kullanıcıların içeriği nasıl grupladığı görülebilir.
Araştırma yöntemleri ve ne zaman seçilir?
Yöntem seçimi, cevaplanmak istenen soruya ve riskin büyüklüğüne bağlıdır. Her yöntemin gösterdiği ve göstermediği şeyler vardır.
| Yöntem | En çok işe yaradığı soru | Sınırı |
|---|---|---|
| Birebir görüşme | Kullanıcı neden ve nasıl davranıyor? | Az kişiyle yapılır, genelleme için tek başına yetmez |
| Bağlamsal gözlem | Gerçek ortamda iş nasıl yapılıyor? | Zaman ve erişim gerektirir |
| Anket | Bir görüş ya da davranış ne kadar yaygın? | Nedeni açıklamaz, soru yazımı sonucu etkiler |
| Kart sıralama | Kullanıcı içeriği nasıl gruplar? | Ekran akışını test etmez |
| Kullanılabilirlik testi | Kişi görevi tamamlayabiliyor mu, nerede takılıyor? | Pazar talebini ölçmez |
| Analitik | Kullanıcılar nerede ayrılıyor, ne kadar sürüyor? | Nedenini göstermez |
Pratik kural şudur: "Neden?" sorusu için nitel yöntemler (görüşme, gözlem, test), "Ne kadar?" sorusu için nicel yöntemler (anket, analitik) seçilir. Araştırma notlarını ekran kararlarına çevirmeyi kullanıcı araştırmasını ekran kararlarına dönüştürmek yazısında örneklerle ele aldım. Freelance bir tasarımcıyla bu sürecin nasıl kurulacağı için freelance UX tasarımcısı ile araştırma planı yazısına da bakabilirsiniz.
UX teslimleri: hangi dosyalar üretilir?
UX çalışmasının sonunda yalnızca bir ekran dosyası beklemek, sürecin büyük bölümünü görünmez kılar. Projeye göre değişmekle birlikte tipik teslimler şunlardır:
- Araştırma özeti: Kimlerle konuşuldu, ne gözlendi, hangi bulgular hangi kararı etkiledi.
- Persona ya da görev tanımları: Hedef kullanıcıların amaçları ve engelleri.
- Kullanıcı yolculuğu haritası: Aşamalar, temas noktaları ve sorun alanları.
- Site haritası ve akış şemaları: Ekranların ilişkisi ve karar noktaları.
- Wireframe seti: Her ekranın içerik önceliği ve yerleşimi.
- Tıklanabilir prototip: Test ve sunum için akışın çalışan modeli.
- Test raporu: Görev başarısı, gözlenen sorunlar ve önceliklendirilmiş öneriler.
- Durum listesi: Boş, yükleme, hata, izin ve başarı ekranları.
Bu teslimlerin kapsamı ve bütçesi projeye göre değişir. Fiyatı belirleyen etkenleri UX araştırması fiyatları ve user flow, wireframe ve prototip fiyatları yazılarında anlattım. Hizmet kapsamı için UX araştırma ve wireframe sayfalarına göz atabilirsiniz.
Kanıt ile varsayımı ayırmak
UX çalışmasında en sık yapılan hata, ekipteki bir kişinin görüşünü kullanıcı ihtiyacı gibi kabul etmektir. "Kullanıcılar bunu sevmez" cümlesinin arkasında bir gözlem mi, yoksa bir tahmin mi olduğu sorulmalıdır.
Basit bir yöntem, her kararın yanına kaynağını yazmaktır: görüşme bulgusu, test sonucu, analitik verisi ya da varsayım. Varsayım olarak işaretlenen kararlar, ilk test turunda öncelikle sınanır. Mevcut bir ürünü bu gözle değerlendirmek için UX audit ve öncelik planı yazısındaki adımları kullanabilirsiniz.
Kullanılabilirlik testi nasıl yapılır?
Kullanılabilirlik testi, kişiye gerçekçi bir görev verip onu nasıl tamamladığını gözlemlemektir. Kişiye "beğendiniz mi?" diye sormak test değildir; "bu üründe geçen ayki faturanızı bulun" demek testtir.
İyi bir test için:
- Görevleri kullanıcının dilinde ve ipucu vermeden yazın; buton adını görevde kullanmayın.
- Katılımcıdan düşüncelerini sesli söylemesini isteyin.
- Yardım etmeyin; takıldığı yeri not edin.
- Her oturumdan sonra gözlemleri hemen yazın; yorum ile gözlemi ayrı tutun.
- Sorunları sıklık ve etki büyüklüğüne göre sıralayın.
Küçük bir ekip için birkaç katılımcıyla yapılan kısa test turları, tek ve büyük bir testten genellikle daha fazla öğretir; çünkü her turdan sonra düzeltme yapılıp yeniden denenebilir.
UX'i ölçmek
UX'i ölçmek için tek bir sayı yoktur. Dönüşüm oranı önemli bir iş göstergesidir ama tek başına deneyimi anlatmaz; fiyat, kampanya ya da mevsim de onu etkiler. Daha açıklayıcı göstergeler şunlardır:
- Görev tamamlama oranı: Kişilerin yüzde kaçı görevi bitirebiliyor?
- Görev süresi: Görev ne kadar sürüyor, süre zamanla kısalıyor mu?
- Hata sayısı: Kişi kaç kez yanlış yere dokunuyor ya da geri dönüyor?
- Terk noktaları: Akışın hangi adımında ayrılma yoğunlaşıyor?
- Destek talepleri: Aynı konuda tekrar eden sorular var mı?
- Algılanan kolaylık: Kısa anketlerle kullanıcının kendi değerlendirmesi.
Ölçümü tasarımdan önce planlamak gerekir. Hangi olayın kaydedileceği belirlenmemişse, yayından sonra "işe yaradı mı?" sorusu cevapsız kalır.
Örnek: bir randevu akışında UX süreci
Bir güzellik salonunun online randevu akışını düşünelim. Keşif aşamasında müşterilerle konuşulduğunda, birçoğunun belirli bir hizmetten önce belirli bir çalışanı seçmek istediği anlaşılabilir. Bu bulgu, akışın "hizmet → tarih → çalışan" yerine "çalışan → hizmet → tarih" sırasıyla da başlatılabilmesi gerektiğini gösterir. Bilgi mimarisinde hizmet adları salonun iç dilinden müşterinin kullandığı adlara çevrilir. Wireframe'de takvimde dolu saatlerin hiç gösterilmemesi mi, yoksa pasif gösterilmesi mi gerektiği tartışılır ve prototip üzerinde iki seçenek de denenir. Test sırasında katılımcıların iptal koşullarını ödeme adımında görünce şaşırdığı gözlenirse, bu bilgi daha erken bir adıma taşınır. Yayından sonra ise randevu akışının hangi adımında terk edildiği ölçülür.
Bu örnekte hiçbir adım tek başına büyük bir çalışma değildir; ama her biri bir sonraki adımın daha az tahminle ilerlemesini sağlar.
UX, UI ve CX: sınırlar nerede?
UX, UI ve CX (müşteri deneyimi) sık sık birbirinin yerine kullanılır. Kabaca ayırmak gerekirse UI, ekranın görsel ve etkileşimli katmanıdır: buton, tipografi, renk, bileşen. UX, kullanıcının o ürünle bir görevi tamamlama deneyimidir: akış, bilgi mimarisi, durumlar, anlaşılırlık. CX ise müşterinin markayla bütün temaslarını kapsar: reklam, satış, teslimat, çağrı merkezi, iade ve ürünün kendisi.
Bu ayrım pratikte önemlidir; çünkü bir sorunun nerede çözüleceğini belirler. Kullanıcılar kargo gecikmesinden şikâyet ediyorsa sorun bir ekran tasarımıyla çözülmez; ama kargo durumunun uygulamada nasıl gösterildiği UX'in konusudur. Konuyu UI, UX ve CX temasları yazısında ayrıntılı ele aldım.
Web, mobil ve SaaS'ta UX farkları
Süreç aynı kalsa da bağlam değiştikçe öncelikler değişir. Web sitesinde kişi çoğu zaman bir aramadan gelir ve hızla aradığını bulmak ister; bilgi mimarisi ve sayfa hızı öne çıkar. Mobil uygulamada tek el kullanımı, kesintili dikkat, izinler ve bildirimler belirleyicidir; bu konuyu mobil uygulama tasarımı nedir rehberinde ayrıntılı anlattım. SaaS ve yönetim panellerinde ise kullanıcı aynı ekranı her gün saatlerce kullanır; yoğun veri, filtre, yetki ve toplu işlem tasarımı öne çıkar. Danone ve ERP Software projelerinde rolüm arayüz tasarımıydı; ERP Software'deki gibi yoğun veri içeren ekranlar, okunabilirlik ve tarama kolaylığı açısından ayrı bir dikkat ister.
Küçük bütçede UX: nereden başlanır?
Her proje kapsamlı bir araştırma bütçesine sahip değildir. Kısıtlı bütçede bile şu adımlar yapılabilir:
- Ürünün tek kritik görevini yazın ve diğer her şeyi buna göre sıralayın.
- Birkaç hedef kullanıcıyla kısa görüşmeler yapın; mevcut alışkanlıklarını sorun.
- Akışı kâğıtta çizip ekip dışından birine anlatın; nerede soru sorduğunu not edin.
- Wireframe ya da basit prototiple kısa bir kullanılabilirlik testi yapın.
- Yayından sonra en az bir görev için tamamlama oranını ölçün.
Bu adımlar araştırmanın yerini tutmaz ama hiç yapmamaktan çok daha fazla bilgi verir. Arayüz tasarımcısının bu süreçteki rolünü UI/UX tasarımcı ne iş yapar rehberinde, uygulama özelinde adımları mobil uygulama nasıl tasarlanır rehberinde, ekranda uyulacak temel kuralları da UI/UX tasarım ilkeleri sayfasında bulabilirsiniz.
Özet ve kontrol listesi
- UX, kullanıcının amacına kolay ve az hatayla ulaşmasını planlama işidir; ekranın görünümünden geniştir.
- Süreç keşif, tanımlama, akış, wireframe, prototip, test, iterasyon ve ölçümden oluşan bir döngüdür.
- Yöntem soruya göre seçilir: "neden" için nitel, "ne kadar" için nicel yöntemler.
- Persona yalnız araştırmaya dayanıyorsa değerlidir; yoksa görev tanımı daha dürüsttür.
- Kararların kaynağını yazın; varsayımları ilk test turunda sınayın.
- Ölçümü tasarımdan önce planlayın; tek başına dönüşüm oranına güvenmeyin.
Kullanıcı deneyimi tasarımı hakkında sık sorulan sorular
UX tasarımı yalnız dijital ürünler için mi?
Hayır. Kullanıcı deneyimi kavramı bir binadaki yön levhalarından bir başvuru formuna kadar her ürün ve hizmet için geçerlidir. Ancak "UX tasarımcı" unvanı bugün çoğunlukla web sitesi, mobil uygulama ve yazılım arayüzleri üzerinde çalışan kişileri tanımlar.
Kullanıcı araştırması kaç kişiyle yapılır?
Sabit bir sayı yoktur; yönteme ve kullanıcı grubunun çeşitliliğine bağlıdır. Kullanılabilirlik testlerinde birkaç katılımcıyla yapılan kısa turlar ana sorunları görmek için çoğu zaman yeterlidir. Yaygınlık ölçmek isteyen anketler ise çok daha büyük örneklem gerektirir. Birbirinden çok farklı kullanıcı grupları varsa her grup ayrı düşünülmelidir.
Persona her projede gerekli mi?
Gerekli değildir. Persona, araştırma bulgularını ekipçe akılda tutmak için yararlı bir araçtır; ama araştırma yapılmadan yazılmış persona yanıltıcıdır. Küçük projelerde açık bir görev tanımı ve hedef kullanıcı listesi çoğu zaman daha işlevseldir.
UX süreci ne kadar sürer?
Ürünün büyüklüğüne, araştırma kapsamına ve karar süreçlerine göre değişir. Tek bir akışın iyileştirilmesi ile sıfırdan bir ürünün tasarlanması aynı süreyi gerektirmez. Ayrıca UX tek seferlik bir iş değildir; ürün yayına çıktıktan sonra da ölçüm ve iyileştirme döngüsü devam eder.
UX ile kullanılabilirlik aynı şey mi?
Değildir. Kullanılabilirlik, bir görevin ne kadar etkili, verimli ve tatmin edici biçimde tamamlandığıyla ilgilidir ve UX'in bir parçasıdır. UX ise buna ek olarak beklentiyi, güveni, içeriği, erişilebilirliği ve ürünle ilişkinin bütününü kapsar.
Mevcut bir sitenin UX'i nasıl değerlendirilir?
Önce sitenin ana görevleri belirlenir, ardından bu görevler kullanılabilirlik ilkelerine göre incelenir, analitik veride terk noktalarına bakılır ve mümkünse birkaç kullanıcıyla test yapılır. Sonuçta sorunlar etki ve düzeltme maliyetine göre önceliklendirilir. Adımları UX audit yazısında anlattım.
UX tasarımı satışları artırır mı?
UX çalışması, kullanıcıların görevlerini tamamlamasını zorlaştıran engelleri bulup azaltmayı hedefler; bu da iş sonuçlarını olumlu etkileyebilir. Ancak satış fiyat, ürün uygunluğu, pazarlama ve rekabet gibi birçok etkene bağlıdır. Bu nedenle UX'in etkisi tahminle değil, önceden tanımlanmış göstergelerle ölçülmelidir.
UX tasarımcı ile UX araştırmacısı farkı nedir?
UX araştırmacısı araştırmayı planlar, yürütür ve bulguları analiz eder; ana çıktısı içgörü ve öneridir. UX tasarımcı bu bulguları akışa, wireframe'e ve prototipe dönüştürür. Küçük ekiplerde iki rol çoğu zaman aynı kişide birleşir; büyük ekiplerde ayrı uzmanlıklar olarak çalışır.