UX Case Study'de Tasarım Kararları Nasıl Gerekçelendirilir?

İyi bir UX case study yalnızca ne tasarladığını göstermez.

Tasarımın neden mantıklı olduğunu açıklar.

İşe alım ekipleri düşünme sürecini anlamak ister. Problemden karara nasıl ilerlediğini görmek ister.

Tasarım kararı sayılan şeyler neler?

Bir tasarım kararı şunlarla ilgili olabilir:

• Bilgi mimarisi
• Kullanıcı akışı
• Form yapısı
• Buton konumu
• Navigasyon
• Empty state’ler
• Hata mesajları
• Görsel hiyerarşi
• Etkileşim pattern’leri
• Erişilebilirlik seçimleri

Küçük kararlar iyi açıklandığında güçlü düşünceyi gösterebilir.

Zayıf açıklama

“CTA’yı alta koyduk çünkü daha iyi görünüyordu.”

Bu gerekçeyi açıklamaz. Sadece bir tercihi tarif eder.

Daha güçlü açıklama

“CTA’yı fiyat özetinden sonra yerleştirdik çünkü kullanıcıların karar vermeden önce toplam maliyeti anlaması gerekiyordu. Bu, karar noktasındaki belirsizliği azalttı.”

Bu açıklama daha güçlüdür çünkü kararı kullanıcı davranışıyla bağlar.

Karar üçgenini kullan

Her önemli karar için üç şeyi birbirine bağla:

1. Kullanıcı ihtiyacı
2. İş hedefi
3. Kısıt

Güçlü tasarım kararı genellikle üçünü dengeler.

Örneğin:

• Kullanıcı ihtiyacı: toplam maliyeti anlamak
• İş hedefi: checkout tamamlanmasını artırmak
• Kısıt: mobilde sınırlı alan
• Karar: CTA’dan önce kompakt fiyat özeti göstermek

Artık tasarım seçimi sadece görsel değildir. Stratejiktir.

Kendine sorabileceğin sorular

Case study yazarken şunları sor:

• Bu karar hangi problemi çözüyordu?
• Hangi alternatifleri düşündük?
• Hangi kullanıcı davranışı bunu şekillendirdi?
• Hangi kısıt etkiledi?
• Hangi tradeoff’u kabul ettik?
• Daha iyi olduğunu nasıl anladık?

Her detay için hepsini cevaplaman gerekmez.

Ama en önemli tasarım kararlarının net bir nedeni olmalı.

Önce ve sonrayı göster

Mümkünse önceki versiyonu göster ve neyin değiştiğini açıkla.

Sadece “akışı iyileştirdik” deme.

Önceden neyin belirsiz olduğunu ve yeni versiyonun neden daha iyi çalıştığını anlat.

Sahte kesinlikten kaçın

Her kararın arkasında kusursuz veri olmak zorunda değildir.

Şöyle demek sorun değildir:

• “Usability testine dayanarak…”
• “Teknik kısıt nedeniyle…”
• “Bilişsel yükü azaltmak için…”
• “Ekip daha sade bir MVP versiyonuna ihtiyaç duyduğu için…”

Dürüst gerekçe, abartılı iddiadan iyidir.

Sonuç

Ekranlar sonucu gösterir.

Tasarım kararları tasarımcıyı gösterir.

İlgili rehberler

• Metrik olmadan case study yazmak isteyebilirsin: rehberi oku
• Ekip projesinde katkını göstermek isteyebilirsin: rehberi oku