Proje İyi Olduğu Halde UX Case Study Neden Zayıf Hissettirir?

Son on yılda çok sayıda tasarımcı değerlendirdim. Önce mentor ve eğitmen olarak, son beş yıldır da işe alım tarafında. Beni hâlâ şaşırtan şey şu: Güçlü bir proje, zayıf bir case study’nin altında çok kolay kaybolabiliyor. Gerçek iş var, gerçek sonuç var, gerçek karmaşıklık var. Ama okur sayfadan ayrılırken ne olduğunu tam anlayamıyor.

Çoğu zaman eksik olan şey, zaten sayfada duran parçaları birbirine bağlayan anlatı çizgisidir.

Aslında ne yanlış gidiyor?

Zayıf case study’lerin çoğunda ortak bir sorun var: Okur akıl yürütmeyi takip edemiyor.

Ekranları görebiliyorsun. Artifact’leri görebiliyorsun. Ama tasarımcının her kararı neden verdiğini göremiyorsun. Bu bağlantı kurulmadığında iş, bir aktivite koleksiyonu gibi görünür. Bir işe alım ekibi pazar akşamı on iki portfolyoyu hızlıca tararken, geri dönüş alıp almamanı çoğu zaman bu bağlantı belirler.

İşin ilginç tarafı, zayıf case study yazan tasarımcılar çoğu zaman en titiz çalışan kişiler oluyor. Ellerinde kanıt var. Sadece bunu sayfaya koymuyorlar, çünkü okurun proje çıktılarından düşünceyi çıkaracağını varsayıyorlar. Okur bunu yapmayacak. İşe alım yöneticilerinin senin yerine çıkarım yapacak zamanı yok.

Başarılı Bir Yapı

Sihirli bir şablon yok. Ama işe yarayan çoğu case study aynı zemini kapsar: durum neydi, neyin değişmesi gerekiyordu, sen özellikle ne yaptın, bu yaklaşımı alternatiflere göre neden seçtin ve sonunda ne oldu?

Bunların her biri için etiketli bölüm açman gerekmez. Kısa bir paragraf çoğu zaman yeterlidir. Önemli olan beş çizginin de görünür olmasıdır.

Bir portfolyo incelerken “tamam ama bunu neden yapmış?” diye sormaya başlıyorsam, case study beni kaybetmiştir. Genellikle bu beş çizgiden biri eksiktir.

Küçük bir örnek

Şu iki açılışı karşılaştır:

“Kullanıcı aktivasyonunu iyileştirmek için onboarding akışını yeniden tasarladım.”

Bu cümle bir şey yaptığını söylüyor. Ama neyin bozuk olduğunu, neyi değerlendirdiğini ya da ne öğrendiğini anlatmıyor. Sana tamamen güvenmem gerekiyor; henüz güvenmem için bir sebep de yok.

“Aktivasyon oranı yaklaşık %18’de kalıyordu. İlk hipotez, kullanıcıların boş ana ekranda ne yapacağını anlamadığıydı. Fakat session replay’ler asıl kaybın eski wizard’ın üçüncü adımında yaşandığını gösterdi. Bu yüzden akışı iki adıma indirdim ve üçüncü adımı opt-in bir tutorial ile değiştirdim. Aktivasyon %26’ya çıktı ve iki çeyrek boyunca bu seviyede kaldı.”

Aynı proje, farklı hikaye. İkinci versiyon daha etkileyici görünmeye çalışmıyor. Sadece düşünce zincirini görünür kılıyor. Okur karar akışını takip edebiliyor.

Her zaman sonunda sert bir metrik olması gerekmez. “İki çeyrek boyunca korundu” önemlidir. “Ekip daha net bir model üzerinde hizalandı” da önemlidir, ne kastettiğini dürüstçe açıklıyorsan. Güveni zedeleyen şey genellemelerin arkasına saklanmaktır.

Case study’leri sessizce zayıflatan şeyler

Portfolyonu inceliyor olsam şu kalıplara özellikle itiraz ederdim:

Katkını “biz” dilinin arkasına saklamak. Ekip işi normaldir. Ama işe alım ekipleri senin özellikle neyi şekillendirdiğini bilmek ister. Case study’nde “biz” kelimesi “ben”den fazlaysa, her “biz”i işaretle ve yabancı birinin hangi kararların sana ait olduğunu anlayıp anlamayacağını sor.

Savunamayacağın sonuçları büyütmek. “Kullanıcı deneyimini iyileştirdik” anlamsızdır. “Dönüşümü %40 artırdık” cümlesi de bağlam yoksa “neye göre?” sorusunu davet eder. Sert sayın varsa zemine oturt. Yoksa niteliksel değişimi dürüstçe anlat. Savunamayacağın sayıdan daha güvenilir olur.

Her adımı eşit göstermek. Çoğu case study tüm fazlara aynı ağırlığı verir. Oysa hepsi aynı önemde değildir. Sonucu gerçekten şekillendiren iki üç karar, rutin işlerden çok daha fazla yer hak eder. Sert edit yap.

Kısıtları saklamak. Özellikle kariyerinin başındaki tasarımcılar kısıtları bahane gibi duyulur diye saklıyor. Halbuki kısıtlar gerçek işin parçasıdır. Onları saklamak hikayeyi düzleştirir.

Denemeye değer

Takıldıysan en güncel case study’ni tasarım dışından birine sesli oku. Nerede soru sorduklarını izle. O boşluklar, akıl yürütmenin sayfada görünmediği yerlerdir.

Bu çoğu zaman herhangi bir yeniden yazma framework’ünden hızlıdır. Sorular hangi çizginin eksik olduğunu doğrudan gösterir.

Bu çizgiler üzerinden daha yapılandırılmış düşünmek işine yararsa, Portfolyo Mentor ile çözmeye çalıştığım şeylerden biri de bu. Kendi projen üzerinde denemek istersen uxcase.app tarafında ücretsiz bir şablon da var.