UX Case Study'de Tasarım Kararlarını Nasıl Açıklarsın?

Asıl problem

Tasarım kararları güçlü bir UX case study’nin omurgasıdır. Ekranlar neyin değiştiğini gösterir; kararlar neden değiştiğini açıklar. İşe alım ekipleri nadiren kusursuz süreç arar. Belirsizliğe nasıl yaklaştığını, seçimlerini hangi sinyallerin şekillendirdiğini ve kullanıcı ihtiyaçları, iş hedefleri ve kısıtları nasıl dengelediğini anlamak isterler.

Birçok portfolyo burada güç kaybeder. Aktivite gösterir ama akıl yürütmeyi göstermez. Artifact gösterir ama arkasındaki düşünceyi anlatmaz. İşe alım ekibi, mentor ya da reviewer için bu eksik akıl yürütme, iyi işi bile değerlendirmesi zor bir şeye dönüştürür.

Bunun yerine neye odaklanmalı?

Güçlü bir case study dramatik görünmek zorunda değildir. İşi anlaşılır hale getirmek zorundadır. Okur hangi problemi ele aldığını, rolünün ne olduğunu, hangi seçimleri yaptığını, bu seçimlerin neden mantıklı olduğunu ve işin sonunda neyin değiştiğini görebilmeli.

Temel ilkeler:

• Seçim yapılması gereken anla başla.
• Hangi seçeneklerin değerlendirildiğini açıkla.
• Kararın arkasındaki kanıtı, kısıtı ya da tradeoff’u anlat.
• Kararı kullanıcı problemi ya da iş hedefiyle bağla.
• “Karar verdik” deyip nedenini açıklamadan geçme.

Pratik bir yapı

Şu akışı kullanabilirsin:

1. Bağlam: Ürün, ekip ya da durum neydi?
2. Problem: Neyin değişmesi ya da netleşmesi gerekiyordu?
3. Rol: Sen neyden sorumluydun?
4. Karar: Hangi önemli seçimleri yaptın?
5. Gerekçe: Hangi kanıt, kısıt ya da tradeoff bu seçimleri şekillendirdi?
6. Sonuç: Ne değişti, ne öğrenildi ya da ne kolaylaştı?

Bu yapı case study’yi sığ bir şablona dönüştürmeden okunabilir tutar. Amaç bölümleri doldurmak değil, birinin senin nasıl düşündüğünü anlamasına yardım etmektir.

Örnek çerçeveleme

Zayıf çerçeve:

Akışı yeniden tasarladım ve kullanıcı deneyimini iyileştirdim.

Daha güçlü çerçeve:

Kullanıcıların bir sonraki adımda ne yapacağını anlamadığı onboarding noktasına odaklandım. Daha fazla açıklama eklemek yerine sıralamayı sadeleştirdim ve sonraki aksiyonu daha görünür hale getirdim. Bu, ekibin daha net bir ilk kullanım deneyimi etrafında hizalanmasına yardımcı oldu.

Güçlü versiyon abartılı iddialara dayanmaz. Durumu, kararı ve gerekçeyi açıklar.

Nelerden kaçınmalı?

• Case study’yi ekran galerisine dönüştürme.
• Rolünü belirsiz “biz” dilinin arkasına saklama.
• Kanıtın yoksa etkiyi büyütme.
• Her adımı eşit anlatma; önemli kararları öne çıkar.
• Başka bir tasarımcının yapısını kendi projene uyarlamadan kopyalama.

Son düşünce

Güçlü bir UX case study yalnızca bir ürün üzerinde çalıştığının kanıtı değildir. Bir problemi düşünebildiğinin ve seçimlerini net açıklayabildiğinin kanıtıdır.

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?