UX/UI Vaka Çalışması: Süreci Değil Kararları Yazın

Portföydeki vaka çalışmalarının çoğu aynı beş başlıkla ilerler: problem, araştırma, eskiz, prototip, sonuç. Sıralama yanlış değil, ama karşıdaki kişi bu sırayı zaten biliyor. Onun merak ettiği şey, elinizde iki seçenek varken neden birini seçtiğiniz ve seçmediğinizin bedelinin ne olduğu.

Süreç değil, karar

Beş aşamalı şablonun sorunu, her aşamaya eşit yer ayırması. Eşit yer ayrılınca hepsi eşit derecede önemsiz görünüyor. Bir vaka çalışmasında gerçekten okunan kısım dardır: hangi iki yol vardı, hangisini seçtiniz, seçmediğiniz yol size ne kazandırırdı.

Kolay bir testi var. Yazdığınız her paragrafı okuyup sorun: burada bir tercih mi var, yoksa sadece yapılan iş mi anlatılıyor? Kullanıcı görüşmeleri yaptık yapılan iştir. Dördüncü görüşmede aynı cümleyi üçüncü kez duyduğumuz için altıncıyı iptal ettik tercihtir. İkincisi bir satır, birincisi bir paragraf, ve işe alan kişi ikincisini okur.

Araştırma bölümü neden şişiyor?

Çünkü elle tutulur çıktısı var. Persona kartı, empati haritası, affinity duvarının fotoğrafı. Bunlar sayfayı doldurur ve emek harcandığını gösterir, ama hiçbiri tek başına bir karara bağlanmadığı sürece dekordur. Persona görselini koyacaksanız, hemen altına o personanın hangi tasarım kararını değiştirdiğini yazın. Değiştirmediyse görsel de gitsin.

Bir e-ticaret filtresi projesinde kullanıcılar filtreyi bulamıyor cümlesi kimseyi ikna etmemişti, ekran kaydından iki kişinin aynı boşlukta durakladığı on saniyeyi izletince tartışma bitmişti.

Hikâye anlatın deyip her bölümü maddeye bölmek

Vaka çalışması rehberlerinin çoğu iki tavsiyeyi yan yana verir: anlatınızı bir hikâye gibi kurun, ve her bölümü madde listesiyle özetleyin. Bu ikisi aynı metinde çalışmaz. Madde işareti neden-sonuç bağını siler, cümleleri eşit ağırlıkta kutulara böler, sıralamayı da rastgele gösterir. Hikâyeyi taşıyan şey tam olarak o bağdır.

Liste, gerçekten liste olan yerde kalsın: kullanılan araçlar, ekipteki roller, test edilen üç varyant. Karar anlatan yerde cümle kurun.

Peki proje yayına çıkmadıysa?

Portföylerin görünmeyen yarısı bu. Şirket önceliği değişti, bütçe kesildi, ürün rafa kalktı. Böyle bir projeyi yazmamak kolay yol, ama sonuç bölümünde metrik yok diye iyi bir vaka çalışması olmayacağı da doğru değil.

Yayına çıkmamış işte anlatılabilecek şey şudur: neyi öğrendiniz ve o öğrenme neyin yerine geçti. Beş kullanıcıyla yapılan bir testin sonucunda iki aylık geliştirmenin iptal edilmesi, ölçülebilir bir sonuçtur. Kaç kişinin dönüşüm yaptığını yazamazsınız, ama kaç haftalık işin çöpe gitmekten kurtulduğunu yazabilirsiniz. Bunu açıkça söyleyin, sonucu yokmuş gibi geçiştirmeyin.

Sayı verecekseniz nereden geldiğini de verin

Sonuç bölümlerinde en sık gördüğüm şey bağlamsız yüzde: dönüşüm %18 arttı. Neye göre, hangi sürede, kaç kullanıcıda, aynı dönemde başka ne değişti? Bunlardan hiçbiri yoksa sayı bir iddia değil, süs. Ölçemediğiniz yerde ölçmediğinizi yazmak, uydurma yüzdeden daha güçlü duruyor.

Aynı titizlik arayüz iddiaları için de geçerli. Prototipte anında açılan filtre panelinin üründe her tıklamada sunucuya gidip yarım saniye beklettiği bir durumda, hız iddianız prototipe aittir, kullanıcının eline geçen şeye değil. Vaka çalışmasında hangisini anlattığınızı ayırt edin, çünkü teknik tarafı bilen biri bu farkı görüşmede ilk sorar.

Başka alandan geçenler için

Önceki mesleğinizi bir eksik gibi açıklamaya çalışmayın. Öğretmenlik yaptıysanız bir konuyu bilmeyen birine anlatmanın nasıl bir şey olduğunu biliyorsunuzdur, çağrı merkezinde çalıştıysanız şikâyetin altındaki asıl problemi ayıklamayı. Bunları genel bir yetkinlik listesi olarak değil, o projede tam olarak nerede işinize yaradığı üzerinden yazın. Fark yaratan cümle iletişim becerilerim güçlü değil, o becerinin hangi toplantıda hangi tıkanmayı açtığıdır.