Portfolyo Mentor
Blog'a dön

Case Study Yazımı

Dağınık Bir Tasarım Sürecini Net UX Case Study'ye Nasıl Çevirirsin?

Gerçek tasarım işi nadiren lineerdir. Dağınık bir UX sürecini net, dürüst ve okunabilir bir case study anlatısına nasıl çevireceğini öğren.

Ömer Arı avatar

Ömer Arı

2 dk okuma

Dağınık tasarım sürecini net UX case study'ye çevirmek üzerine Neo-Brutalist editoryal kapak görseli

Gerçek tasarım projeleri nadiren tertemiz ilerler.

Brief değişir.
Paydaşlar aynı fikirde olmaz.
Araştırma geç gelir.
İlk çözüm çalışmaz.
Ekip yön değiştirir.

Ama case study’nin yine de okunabilir olması gerekir.

Hata: süreç mükemmelmiş gibi davranmak

Birçok tasarımcı case study’yi her şey temiz bir sırayla olmuş gibi yazar:

Araştırma → İdeation → Wireframe → Test → Final UI

Bu düzenli görünebilir ama çoğu zaman sahte hisseder.

Gerçek projeler daha karmaşıktır. İşe alım ekipleri bunu bilir.

Amaç süreci mükemmel göstermek değildir. Amaç düşünceni anlaşılır hale getirmektir.

Daha iyi hedef: dürüst yapı

Güçlü bir case study dağınıklığı saklamaz.

Onu organize eder.

Okur şunları anlamalı:

  • Ne belirsizdi?
  • Ne değişti?
  • Hangi kararlar önemliydi?
  • Ne öğrendin?
  • Proje nasıl ilerledi?

Dürüstlük netliğin karşıtı değildir. Çoğu zaman case study’yi gerçek hissettiren şeydir.

Dönüm noktalarıyla başla

Her adımı listelemek yerine projeyi değiştiren anları belirle.

Bunlar şunlar olabilir:

  • Şaşırtıcı bir araştırma içgörüsü
  • Teknik bir kısıt
  • Paydaş anlaşmazlığı
  • Başarısız usability testi
  • Scope değişimi
  • İş önceliği değişimi
  • Çözümü sadeleştirme kararı

Düşüncenin görünür olduğu anlar bunlardır.

Hikayeyi kararlar etrafında kur

Net bir case study günlük değildir.

Bir karar izidir.

Her önemli an için şunları açıkla:

  1. Durum neydi?
  2. Hangi seçenekleri düşündün?
  3. Hangi kararı verdin?
  4. Bu karar neden mantıklıydı?
  5. Sonra ne değişti?

Bu, her workshop’ı, her wireframe’i ve her toplantı notunu göstermekten daha faydalıdır.

Basit bir yapı kullan

Şu yapıyı dene:

  1. Bağlam
  2. Problem
  3. Kısıtlar
  4. Ana kararlar
  5. Çözüm
  6. Sonuç
  7. Öğrenimler

Bu, sürecin lineer olduğu anlamına gelmez.

Hikayenin okunabilir olduğu anlamına gelir.

Neleri çıkarmalı?

Okurun projeyi anlamasına yardım etmeyen detayları çıkar.

Muhtemelen şunlara ihtiyacın yok:

  • Her araştırma screenshot’ı
  • Her erken wireframe
  • Her paydaş yorumu
  • Her workshop fotoğrafı
  • Her UI varyasyonu

Akıl yürütmeyi açıklayan anları tut.

Sonuç

Sürecin mükemmel görünmek zorunda değil.

Anlaşılır olmak zorunda.

Dağınık bir proje, düşünce net olduğunda güçlü bir case study’ye dönüşebilir.

İlgili rehberler

  • İşi şekillendiren kararları açıklamak isteyebilirsin: rehberi oku
  • Ekip projesinde katkını göstermek isteyebilirsin: rehberi oku

Benzer yazılar