Kullanılabilirlikte 25 Yıl: Ne Değişti, Ne Değişmedi

Kullanılabilirliğin hikâyesi genelde büyüme üzerinden kurulur: alan genişledi, uzman sayısı arttı, şirketler ekip kurdu. Aynı hikâyenin içinde temel ilkelerin kırk yıldır değişmediği de söylenir. Bu iki cümle yan yana gelince ortaya rahatsız edici bir soru çıkıyor: büyüyen şey yöntem mi, yoksa sadece kadro mu?

1983'ün üç ilkesi hâlâ ayakta

Gould ve Lewis'in 1983'te formüle ettiği üç ilke bugün de omurga sayılıyor: tasarıma başlamadan kullanıcıyı ve yaptığı işi anlamak, kararları ölçerek sınamak, tasarımı tek seferde değil döngüyle geliştirmek. Araçlar kırk yılda tanınmayacak kadar değişti, ilkeler yerinde duruyor.

Bunu alanın olgunluğu diye okumak mümkün. Başka bir okuma daha var: bir ilke kırk yıl boyunca tekrar edilmek zorunda kalıyorsa, muhtemelen hâlâ yeterince uygulanmıyordur. Konferans açılış konuşmalarında 1983'ten kalma maddeleri hatırlatmaya devam etmemiz bunun göstergesi.

Büyüyen tam olarak ne

Kadro açmakla yöntem kurmak farklı şeyler. Bir şirkette araştırmacı unvanlı üç kişi çalışıyor olabilir ve üçü de kararlar alındıktan sonra masaya çağrılıyor olabilir. O noktadan sonra yapılan iş araştırma değil, alınmış kararın gerekçelendirilmesidir; çıktısı da genelde kimseyi rahatsız etmeyen bir slayt olur.

Olgunluğun ölçüsü unvan sayısı değil. Daha iyi bir ölçü şu soru: son çeyrekte bir araştırma bulgusu yüzünden vazgeçilen ya da baştan yazılan bir özellik var mı? Cevap yoksa ekip vardır, süreç yoktur.

Zamanlama, bulgudan daha belirleyici

Bir kullanılabilirlik bulgusunun değeri doğruluğundan çok ne zaman geldiğine bağlı. Kâğıt prototipteki akış hatası birkaç saatlik iş. Aynı hata veri modeline girdikten sonra tabloya, uçlara, mevcut kayıtların göçüne dokunur. Değiştirme maliyeti zamanla doğrusal artmıyor, o kararın bağlandığı yer sayısıyla artıyor.

Bu yüzden kaba bir prototiple yapılan beş oturumu, ürün bittikten sonra teslim edilen cilalı kullanılabilirlik raporundan daha güvenilir buluyorum. İkincisi çoğu zaman daha kapsamlı ve daha düzgün yazılmış oluyor, ama bulgularının büyük kısmı artık değiştirilemeyecek şeylerle ilgili olduğu için rafa kalkıyor. Kapsamlı ve geç olan, dar ve erken olanı yenmiyor.

Ucuz yöntemlerin sınırı

Gerilla testi, yani koridorda yakaladığın birine on dakika ekran gösterip izlemek, arayüz seviyesindeki tıkanmaları bulmakta gerçekten iyi: yanlış etiket, görünmeyen buton, anlaşılmayan ikon. Maliyeti neredeyse sıfır, o yüzden de sık yapılabiliyor ve asıl gücü sıklığından geliyor.

Bulamadığı şey, kullanıcının o işi neden yaptığı ve işin arayüzden önce ve sonra nereye bağlandığı. Saha çalışmasının yerini tutmaz, çünkü bağlamı laboratuvara taşımaz; sadece laboratuvarı koridora taşır. İkisini birbirinin alternatifi sayan ekipler bir süre sonra hep aynı türden küçük sorunları bulup büyük olanı hiç görmez.

Bu alanda çalışmak

İş ilanlarının saydığı beceriler yanlış değil ama ayırt etmiyor; empati ve iletişim maddelerini herkes aynı şekilde yazıyor. Pratikte farkı iki şey yaratıyor. Birincisi bulguyu karara çevirebilmek: on sorunu sıralamadan teslim eden araştırmacı ekibin yükünü artırır, üçünü seçip gerekçesini yazan azaltır. İkincisi ekibin diliyle konuşabilmek; yazılımcıya bu akış kafa karıştırıyor demekle, bu ekranda iki ayrı kaydın aynı kimlikle gösterildiğini söylemek aynı etkiyi yapmaz.

Türkiye'de talebin arttığı doğru. Ama artışın büyük kısmı arayüz tasarımı tarafında, araştırma bütçesi hâlâ ilk kesilen kalem. Alana yeni girecek biri için bunun anlamı açık: tek bir uzmanlığa yaslanmak riskli, araştırmayı tasarımla ya da uygulamayla birlikte taşıyabilenler daha uzun süre iş buluyor.