Basit Bir UX Projesini Güçlü Bir Case Study'ye Nasıl Çevirirsin?

Neden küçük projeyi küçük gösteriyorsun?

Birçok tasarımcı daha küçük projeler hakkında yazmaktan kaçınır, çünkü işin yeterince etkileyici olmadığını düşünür. Oysa güçlü bir case study her zaman büyük bir ürün lansmanından çıkmaz. Net bir problemden, düşünülmüş bir karardan, gerçek bir kısıttan ve işe yarar bir öğrenimden de çıkabilir.

”Küçük proje” çoğu zaman kötü çerçevelemenin sonucudur

Bir özellik değişikliği var, tek bir kullanıcı akışı var, belki dört ekran. Ama bu ekranların arkasında gerçek bir karar süreci varsa, case study yazılabilir.

Somut bir senaryo: onboarding’in üçüncü adımında kullanıcılar çıkıyor. Elinde tam session data yok, kullanıcı görüşmesi yapacak zamanın da yok. Support kanalından gelen mesajları okudun ve ortak bir karışıklık noktası tespit ettin. O kanalı araştırma kaynağı olarak kullanman ve bu kısıtı case study’de açıkça ifade lemen, seni “daha iyi UX yaptım” diyen on tasarımcıdan ayıran şeydir. Proje küçük olabilir. Düşünce sürecini görünür kılmak büyüklükle ilgili değildir.

Ne üzerine odaklanmalı?

Proje büyüklüğüne değil, şu sorulara odaklan:

• Bu problemin neden önemli olduğunu açıklayabiliyor musun?
• Alternatif bir yaklaşım düşündün mü, neden bu yolu seçtin?
• Kısıtın ne olduğunu ve o kısıtla nasıl çalıştığını gösterebiliyor musun?
• Sonunda ne değişti ya da ne öğrenildi?

Bu dört soruya dürüst yanıt veren bir case study, çok daha büyük ama yüzeysel kalan bir vakaya kıyasla çok daha fazla güven inşa eder.

Aynı projenin iki farklı çerçevesi

Zayıf:

Onboarding akışını yeniden tasarladım ve kullanıcı deneyimini iyileştirdim.

Daha güçlü:

Üçüncü onboarding adımında yüksek çıkış görünüyordu. Tam session verisi yoktu; support mesajlarından ortak karışıklık noktasını tespit ettim: form alanı fazlaydı. Wizard’ı iki adıma indirdim ve zorunlu olmayan alanları sonraki ekrana taşıdım. Bir sonraki sprint’te çıkış oranında belirgin düşüş gözlemlendi.

Güçlü versiyon daha uzun değil, daha şeffaf. Kısıtı saklamamış, verinin kaynağını söylemiş, kararı gerekçelendirmiş.

Sık yapılan hatalar

• Projenin “küçük” olduğundan özür dilemek. Özür değil bağlam ver.
• Ekranları arka arkaya koymak ama hiçbirinin neden o hale geldiğini açıklamamak.
• “Kullanıcı odaklı bir yaklaşım benimsedik” gibi genel ifadelerin arkasına sığınmak.
• Öğrenimlerden hiç bahsetmemek. Neyin işe yaramadığı, neyin işe yaradığı kadar değerlidir.

Sonuç

Basit projeleri büyük göstermeye çalışmana gerek yok. Gerçekte nasıl düşündüğünü gösteren bir hikaye yaz.

Diğer case study rehberleri

• UX case study’lerde işe alım ekipleri neye bakar?
• Metrik yokken UX case study nasıl yazılır?
• Ekip projesinde katkını nasıl gösterirsin?