UX Olgunluk Modelinde İlk Dört Aşama

Bir kurumun kullanıcı deneyimiyle ilişkisi bir gecede kurulmuyor. Nielsen Norman Group'un sekiz aşamalı olgunluk modeli bu ilişkiyi kademelere ayırır; ilk dördü, şirketlerin büyük kısmının hâlâ içinde olduğu bölümdür. Aşamaları birbirinden ayıran şey bütçenin büyüklüğü değil, kullanıcıyla ilgili kararın kimin elinde olduğudur.

1. Aşama: Kullanıcıya düşmanlık

Burada ölçüt tektir: sistem çalışıyor mu? Çalışıyorsa iş bitmiştir. Arayüz çoğunlukla veri modelinin birebir yansımasıdır, form alanlarının sırası tablodaki kolon sırasıdır, hata mesajı da veritabanının döndürdüğü metindir. Şikayetler destek hattına düşer ama ürüne geri dönmez, çünkü bunları toplayıp geliştirmeye taşıyan bir yol yoktur. Arayüzle ilgili bir soruya verilen cevap düzenli olarak "kullanıcı yanlış kullanıyor" oluyorsa, kurum bu aşamadadır.

2. Aşama: Geliştiricinin sezgisi

Ekip kullanıcı deneyiminin var olduğunu kabul etmiştir, fakat elinde veri yoktur. Boşluğu kendi kullanımıyla doldurur: ekranı yapan kişi, kolay bulduğu akışı herkesin kolay bulacağını varsayar. Bir kurumsal panelde kullanıcı testi diye ekibin kendi geliştiricilerini ekrana oturttuğunu gördüm, herkes görevi akıcı biçimde tamamladı, çünkü kısayolları zaten hepsi biliyordu. Bu aşamanın tehlikesi yanlış cevap üretmesi değil, kendinden emin bir cevap üretmesidir.

3. Aşama: Bütçesiz, gönüllü testler

Sonra biri inisiyatif alır. Beş kişiyle koridor testi, kısa bir anket, tanıdık bir araştırmacıya sorulan soru. Resmî bütçesi ve takvimde yeri olmayan bu işler şaşırtıcı ölçüde verimlidir; çoğu ciddi kullanılabilirlik sorunu zaten ilk birkaç katılımcıda ortaya çıkar. Zayıf tarafı sonuçları değil, sahipsizliğidir: testi yürüten kişi ekipten ayrıldığında pratik de onunla gider, çünkü hiçbir sürece bağlanmamıştır. Araştırma birinin gönüllülüğüne bağlıysa, kurum bu aşamayı geçmemiştir.

4. Aşama: Bütçe var, sıra sonda

UX artık bütçede ayrı bir kalemdir. Araştırmacı işe alınır, testler planlanır, bulgular raporlanır. Ne var ki iş akışında UX hâlâ en sonda, geliştirme bittikten sonraki parlatma adımı olarak durur. Bunun maliyeti soyut değil: bir akış değişikliğini eskiz aşamasında yapmak birkaç dakika sürer, veri modeli ve ekranlar yazıldıktan sonra yapmak bir sprint yer. Testi yayından iki hafta önce kurarsanız, çıkan bulguların çoğu için yapılabilecek tek şey backlog'a not düşmek olur, çünkü değiştirilmesi gereken şey artık arayüz değil altındaki yapıdır.

Modelin düz ilerlemediği yer

Aşamalar bir merdiven gibi anlatılır, oysa ikinci aşama her ürün için hata değildir. Geliştirici araçlarında ekip gerçekten hedef kitlenin içindedir ve sezgisi, küçük de olsa gerçek bir örneklemden gelir. Hatalı olan sezgiye başvurmak değil, ekibin kullanıcı olmadığı ürünlerde aynı alışkanlığı sürdürmektir; bunu test etmenin ucuz bir yolu var: ekibin akışı tamamlama süresiyle ekip dışından beş kişinin süresini yan yana koyun.

Üçüncü aşamadan dördüncüye geçişi de bütçe belirlemez. Para ayırıp araştırma bulgularını yine geliştirme ekibinin isteğine bırakan bir kurum, daha pahalı bir üçüncü aşamadadır. Fark, bulgunun bir işi durdurma yetkisi olup olmadığında ortaya çıkar.