Yazılımcıdan UX'e Geçiş: Neyi Taşırsın, Neyi Bırakırsın
Yazılımdan UX'e geçenler genelde aynı yerde takılır: kod tarafındaki refleksler tasarımda bazen avantaj, bazen köstek olur. Zor kısım yeni araç öğrenmek değil, "doğru çözüm" arayışını "daha iyi çözüm" arayışıyla değiştirmek. Teknik arka plan bu değişimi hızlandırabilir, tamamen de bloke edebilir.
Ortak olan yöntem, konu değil
Hata ayıklama ile kullanılabilirlik testi arasındaki mesafe sanıldığından kısa. İkisi de aynı döngüyü çalıştırır: hipotez kur, gözlemle, hipotezi güncelle. Fark gözlemin nereden geldiğinde: kodda gözlem log satırıdır, tasarımda ekranın karşısındaki insan. Geçişte en hızlı ilerleyen kısım bu yüzden çoğunlukla araştırma tarafı olur.
Asıl zorlanılan yer karar kriteri. Yazılımda çözümün doğruluğu kendi içinden kanıtlanır, test geçer ya da geçmez. Arayüzde böyle bir hakem yok. Hangi çözümün daha iyi olduğunu kullanıcı davranışı söyler ve cevap bağlama göre değişir.
Teknik bilginin ters çalıştığı yer
Geliştirici arka planının en çok anlatılan faydası şu: neyin ne kadar tutacağını baştan bilirsin, uygulanamaz akışlar çizmezsin. Doğru. Ama aynı bilgi eskiz aşamasında zarar verir, çünkü maliyeti bilen kişi fikri test etmeden eler. "Bunu üç haftada yapamayız" cümlesi, henüz kimsenin işe yarayıp yaramadığını bilmediği bir akışı gündemden düşürür.
Çözüm basit: maliyet konuşmasını ayrı bir adıma taşı. Eskiz sırasında uygulanabilirlik sorusu sorma, eskizden sonra sor. (Bu ayrımı takvime yazmadan yapmak bende hiç işlemedi.)
Öğrenme sırası
Kullanıcı araştırmasıyla başla. Görüşme yapmak, ne sorulacağını bilmek ve söylenenle yapılanı ayırmak, sonraki her adımın girdisini üretir. Ardından kullanılabilirlik testi gelir; beş kişilik bir oturum, üç aylık bir tartışmayı bir öğleden sonrada bitirir.
A/B testini bu ikisinden sonraya bırak. Analitik geçmişi olan biri için en cazip başlangıç noktası orasıdır, oysa A/B testi trafik ister. Günde birkaç yüz kişinin girdiği bir kurumsal panelde iki varyant arasındaki farkı anlamlı hale getirecek örnekleme aylarca ulaşamazsın; aynı soruyu beş kullanıcıyla yapılan bir testte bir günde cevaplarsın. A/B, hangi tasarımın doğru olduğunu değil, zaten çalışan iki seçenekten hangisinin biraz daha iyi olduğunu ölçer.
Heuristik değerlendirme ucuz ama tek başına yanıltıcı. Tek bir değerlendirici sorunların ancak bir bölümünü yakalar, bu yüzden yöntem birkaç kişiyle ayrı ayrı uygulanır ve bulgular sonradan birleştirilir. Tek kişilik heuristik inceleme rapor üretir, güvence üretmez.
Erişilebilirlik, teknik arka planı olan birinin gerçekten öne çıktığı alan. Odak sırası, klavyeyle gezinme, form etiketleri, kontrast: bunların hepsinin kodda bir karşılığı var, tasarım dosyasında yok. WCAG kriterlerini okuyup doğrudan bileşen katmanına yazabiliyorsan, ekipte kimsenin kapatamadığı bir boşluğu kapatıyorsun demektir.
Portföyde gösterilecek şey ekran değil karar
Portföy için en sık verilen tavsiye kendi ürününü elden geçirmek. Yararlı, ama bir çelişkisi var: aynı metin hem "eleştiriyi kişisel algılama" der hem de değerlendireceğin ürünü senin yazmanı önerir. Kendi kodunun üstünde tarafsız değerlendirici olamazsın. Kendi ürününle çalışacaksan testi başkasına yaptır, sen sadece izle.
Gösterdiğin işte ekran görüntüsünden çok kararın gerekçesi görünsün: hangi varsayımı test ettin, test ne gösterdi, tasarımı buna göre nasıl değiştirdin. İşe alan taraf zaten güzel ekran görmüştür. Nadir olan, bir fikrinden veri yüzünden vazgeçmiş adayı görmektir.
Geçişin gerçek karşılığı
Bu geçişte en değerli konum saf tasarımcı olmak değil, iki tarafın dilini birden konuşan kişi olmak. Tasarım kararının uygulama maliyetini söyleyebilen, mühendisin "yapılamaz" dediğinde bunun gerçek bir sınır mı yoksa alışkanlık mı olduğunu ayırabilen biri, ekipte tek başına bir köprü. Bu rolü hedefliyorsan kod yazmayı bırakma; UX'i kodun yerine değil, üstüne koy.