İşe alım müdürünün UX case study'ni sessizce eleyip geçtiği 5 an

Bir UX case study çoğu zaman yazarına gayet net görünür. Toplantıları, kısıtları, stakeholder’la geçen zor konuşmaları ve küçük bir tasarım detayının neden önemli olduğunu hatırlarsın. Kendi hafızan, sayfanın anlatmadığı boşlukları kendiliğinden doldurur.

İşe alım müdürünün böyle bir hafızası yoktur. Case study’ni sınırlı bir zamanla ve tek bir hedefle açar: bir tasarımcı olarak nasıl düşündüğünü anlamak. Problemi çerçeveleyebildiğini, karar verebildiğini ve işini bir sonuca bağlayabildiğini gösteren işaretleri arar. Bu işaretler görünmüyorsa çoğu okuyucu sadece okumayı bırakır.

Aşağıda işe alım tarafının bir UX case study’de sessizce vazgeçtiği 5 yaygın an ve her biri için somut bir düzeltme var.

1. Çözümle açıyorsun, problem netleşmeden

Birçok case study cilalı bir final UI ile açılıyor: temiz bir hero mockup, birkaç final ekran, belki kısa bir prototip görüntüsü. İlk bakışta özgüvenli duruyor, reviewer’ın henüz cevaplayamadığı basit bir sorusu var: bu ekran gerçekte neyi çözüyor?

Cilalı bir arayüz, tek başına kullanıcı problemini veya projeyi gerekli kılan kısıtı anlatmaz. Bu bağlam olmadan final UI, bir tasarım cevabı değil sadece görsel bir çıktı gibi okunur.

Somut düzeltme: ilk iki cümlede spesifik problemi ve önemli kısıtı yaz.

Genel bir açılış yerine:

“Onboarding akışını daha kullanıcı dostu hale getirmek için yeniden tasarladım.”

Şunu dene:

“Yeni kullanıcılar hesap kurulumu sırasında kimlik doğrulama adımı onboarding’in geri kalanından kopuk hissettirdiği için süreci terk ediyordu. Ekip bunu, uyumluluk gereksinimlerini değiştirmeden çözmek zorundaydı.”

Bu açılış reviewer’a gerçek bir problem, gerçek bir kısıt ve final UI’ın neden var olduğuna dair bir gerekçe verir.

2. Süreç dolu, karar yok

Çoğu case study tanıdık bir sırayı içeriyor: araştırma, persona, journey map, wireframe, usability test. Bu çıktılar, bir kararın nasıl alındığını göstermeden yer kaplayabiliyor.

İşe alım müdürü öğrendiğin şeyle ne yaptığını görmek istiyor: hangi seçeneği eledin, hangi kısıt seni bir karara zorladı, iki makul fikir yarışırken neyi önceliklendirdin?

Somut düzeltme: en az bir gerçek trade-off’u gerekçesiyle göster.

Örnek:

“İlk konseptte tüm filtre seçeneklerini ilk ekranda gösteriyordum, bu da ürünle yeni tanışan biri için ekranı ağırlaştırıyordu. En sık kullanılan üç filtreyi ilk ekranda bıraktım, geri kalanını ikincil bir aksiyonun arkasına taşıdım.”

Bu anlatım reviewer’a kullanılabilirlik ile kontrolü tarttığını ve kullanıcıların ürünü gerçekte nasıl kullandığını temel alarak karar verdiğini gösterir.

3. Anlatıyorsun, kanıtlamıyorsun

Case study’lerde sık geçen cümleler:

“User research yaptım."
"Yeni akış daha sezgisel hissettirdi.”

Bu cümleler doğru olabilir, reviewer bunları görecek bir yolu olmadığı için sana güvenmek zorunda kalır.

İşe alım tarafı kanıt arar, büyük bir araştırma raporu değil. Bir usability test bulgusu, eski-yeni akış karşılaştırması veya kısa bir kullanıcı alıntısı, çok daha az yerde aynı ağırlığı taşıyabilir. Önemli olan, iddia ile arkasındaki kanıt arasındaki görünür bağlantıdır.

Somut düzeltme: her önemli iddianın hemen altına bir kanıt ekle.

Şunun yerine:

“Kullanıcılar teslimat seçeneklerinde kafası karıştığı için checkout akışını iyileştirdim.”

Şunu dene:

“İlk usability testinde 5 kullanıcıdan 3’ü teslimat seçimini ödeme onayıyla karıştırdı. Teslimat seçimini akışta daha öne aldım ve adım başlıklarını ayırdım.”

Bu versiyon gözlemi, tasarım cevabını ve ikisini birbirine bağlayan gerekçeyi gösterir.

4. Sonuç değerlendirilemeyecek kadar muğlak

Zayıf bir kapanış bölümü sağlam bir case study’yi bile düzleştirebilir. Yaygın sonuç cümleleri şöyle görünür:

“Deneyim iyileşti."
"Kullanıcılar yeni akışı daha kolay buldu.”

Bu cümleler olumlu duruyor, reviewer’a değerlendirme yapacağı yeterli bilgiyi vermiyor. Neye göre iyileşti? Güçlü bir sonuç bir iş metriği gerektirmez. NDA’lı işler dahil pek çok proje dönüşüm verisine erişemez. Önemli olan sonucun spesifik ve dürüst kalması.

Somut düzeltme: before/after yapısı kullan. Gerçek bir sayı varsa bağlamıyla ver, sayı yoksa dürüst bir nitel sonuç yaz.

Sayı varsa:

“Eski akışta kullanıcı ödemeye ulaşmadan önce altı ekrandan geçiyordu. Yeni akışta teslimat incelemesi ve onayı tek adımda birleştirilerek bu sayı dörde indi.”

Ürün metriği yoksa:

“Bu konsept canlıya alınmadığı için gerçek etki hiç ölçülemedi. Usability testlerinde katılımcılar ikinci iterasyondan sonra teslimat ve ödemeyi daha tutarlı ayırt etti, bu bulgu checkout yapısının sonraki versiyonunu şekillendirdi.”

İkinci örnek uydurma bir sayı içermiyor, yine de neyin öğrenildiğini net anlatıyor.

5. “Sen ne yaptın” belirsiz kalıyor

Takım projeleri çoğu UX portfolyosunda yer alır. Önemli olan, kendi katkının “biz karar verdik” ve “ekip test etti” cümlelerinin içinde kaybolup kaybolmaması. İşe alım müdürü seni işe alırsa tam olarak neyi yapmanı bekleyeceğini bilmek ister: araştırma planını sen mi yönettin, ana akışı sen mi tasarladın, bulguları sahaya çıkan kararı sen mi çevirdin?

Somut düzeltme: başta kısa bir rol özeti kullan, sonra anlatı boyunca katkını görünür tut.

Rol: Product designer
Süre: 6 hafta
Ekip: 1 product manager, 2 developer
Sahiplendiğim alanlar: kullanıcı akışı, prototip, usability test planı, tasarım iterasyonu

Sonra anlatı içinde de pekiştir:

“PM ile başarı kriterini netleştirdikten sonra üç alternatif çıkardım, en gerçekçi ikisini test ettim ve bulgulara dayanarak daha kısa akışı önerdim.”

Muhtemelen kendi case study’ne fazla yakınsın

Bu beş anı kendi işinde fark etmek zordur, çünkü ekran görüntüleri arasında ne olduğunu zaten biliyorsun. Sayfa hiç yazmasa bile bir kararın neden önemli olduğunu hatırlıyorsun. İşe alım müdürü ise sadece sayfada gerçekten yazılan ve gösterileni görür.

Güçlü bir UX case study projenin her adımını belgelemek zorunda değil. Beş şeyi net göstermesi gerekir: hangi problemi çözdüğünü, işi hangi kısıtların şekillendirdiğini, hangi kararları verdiğini, bu kararların kanıtını ve neyi kişisel olarak sahiplendiğini.

SSS

UX case study kaç kelime olmalı?

Tek bir ideal uzunluk yok. Önemli olan problem, kısıt, karar, kanıt, sonuç ve kişisel katkının hepsinin net görünmesi. Kısa ama gerekçesi net bir case study, genelde uzun bir süreç günlüğünden daha güçlü okunur.

UX case study’de metrik yoksa ne yazmalıyım?

Bunu doğrudan belirt ve yerine nitel sonuçlara dayan: usability test bulgusu, before/after akış farkı, stakeholder kararı veya bir sonraki iterasyonda değişen şey.

NDA’lı projeyi portfolyoda nasıl anlatabilirim?

Evet, anlatabilirsin. Hassas detayları genelleştirebilir, gizli ekranları saklayabilir ve özel veriyi paylaşmadan problem tipini, rolünü, kısıtları ve etkiyi açıklayabilirsin.

İşe alım müdürleri final UI ekranlarını önemsiyor mu?

Evet, final ekranlar problem, karar süreci ve kanıt net olduğunda en güçlü halini alıyor. Bu bağlam olmadan cilalı bir ekranı tek başına değerlendirmek zor.

Takım projesinde kendi rolümü nasıl gösteririm?

Başta kısa bir rol özeti ekle ve case study boyunca hangi kısımları sen yönettiğini, hangilerine katkı verdiğini net bir dille sürdür.