Önce ve Sonra UX Case Study Yeniden Yazım Örnekleri

Bu UX case study yeniden yazım örnekleri, belirsiz process anlatımını daha net bağlam, karar ve kanıtlarla nasıl güçlendirebileceğinizi gösterir.

Case study düzeltirken çoğu zaman tamamen yeni metin yazmak gerekmez. Bazen sorun, iyi malzemenin fazla genel cümleler içinde kaybolmasıdır. Bu yüzden rewrite çalışmasını “daha güzel yazma” işi gibi değil, kararları daha okunabilir hale getirme işi gibi görmek daha faydalıdır.

Aşağıdaki örnekler gerçek şirket veya gerçek aday hikayesi değildir. Portfolyo review’larda sık karşılaştığım kalıplardan türetilmiş genel örneklerdir.

Örnek 1: Problem tanımı

Önce:

Kullanıcıların daha iyi bir ödeme deneyimine ihtiyacı vardı. Bu yüzden checkout sürecini yeniden tasarladım.

Sorun:

Bu ifade problemi çok geniş bırakıyor. Hangi kullanıcı, hangi ödeme adımı, hangi sürtünme belli değil.

Sonra:

İlk kez alışveriş yapan kullanıcılar, ödeme adımında üyelik oluşturmadan devam edip edemeyeceklerini anlayamıyordu. Bu belirsizlik, özellikle adres bilgisinden önce akıştan çıkışlara neden oluyordu. Çalışmanın odağı, checkout başlangıcındaki karar yükünü azaltmak olarak belirlendi.

Neden daha iyi?

Kullanıcı grubu, bağlam ve davranış etkisi görünür hale geliyor. Çözüm hemen söylenmiyor, önce problem alanı kuruluyor.

Örnek 2: Araştırma özeti

Önce:

Kullanıcı görüşmeleri yaptım ve ihtiyaçları belirledim.

Sorun:

Bu cümle araştırma yapıldığını gösterir, ama araştırmanın tasarımı nasıl etkilediğini göstermez.

Sonra:

Görüşmelerde kullanıcıların en çok zorlandığı noktanın özellik sayısı değil, hangi özelliğin kendi durumlarına uygun olduğunu anlamak olduğunu gördüm. Bu bulgu, karşılaştırma tablosunu büyütmek yerine karar yardımını öne çıkarmama neden oldu.

Neden daha iyi?

Araştırma bulgusu doğrudan tasarım kararına bağlanıyor.

Örnek 3: Rol ve katkı

Önce:

Ekip olarak araştırma yaptık, wireframe hazırladık ve tasarımı tamamladık.

Sorun:

Ekip çalışması net, fakat kişinin katkısı belirsiz. Hiring manager bu adayın hangi bölümü taşıdığını anlayamaz.

Sonra:

Üç kişilik ekipte kullanıcı görüşme planını ben hazırladım, wireframe alternatiflerini oluşturdum ve test bulgularını final akış kararlarına çevirdim. Visual design tarafında ekip arkadaşım ana UI sistemiyle ilerledi.

Neden daha iyi?

Kişisel katkı ve ekip sınırı dürüst şekilde ayrılıyor.

Örnek 4: Tasarım kararı

Önce:

Kullanıcıların daha kolay ilerlemesi için ekranı sadeleştirdim.

Sorun:

“Sadeleştirdim” güçlü bir iddia gibi görünür, ama neyin neden sadeleştiği belli değildir.

Sonra:

İlk tasarımda kullanıcıdan aynı ekranda plan seçmesi, ödeme yöntemini eklemesi ve promosyon kodu girmesi bekleniyordu. Testte kullanıcıların plan seçmeden önce ödeme alanına geçtiğini gördüm. Bu yüzden plan seçimini ayrı bir adıma aldım ve promosyon kodunu ödeme özetinin altına taşıdım.

Neden daha iyi?

Karar, test gözlemi ve ekran değişikliği aynı paragrafta bağlanıyor.

Örnek 5: Etki

Önce:

Yeni tasarım kullanıcı deneyimini iyileştirdi.

Sorun:

Etki iddiası var, ama kanıt yok.

Sonra:

Çalışma canlıya alınmadığı için ürün metriği paylaşamıyorum. Ancak ikinci usability testte katılımcılar plan seçimi adımını daha az açıklamayla tamamladı. Bu sonuç, karar yardımını ilk adıma taşıma fikrini güçlendirdi.

Neden daha iyi?

Canlı metrik yoksa bile dürüst bir öğrenim ve test sonucu paylaşılıyor.

Kendi case study’nize nasıl uygulayabilirsiniz?

Her paragraf için şu üç soruyu sorun:

• Bu cümle sadece aktivite mi anlatıyor, yoksa karar da gösteriyor mu?
• Okuyucu benim rolümü anlayabiliyor mu?
• Bu ifade başka herhangi bir projeye de uyuyor mu?

Eğer cümle çok genel kalıyorsa, ona bir bağlam ekleyin. Eğer karar görünmüyorsa, “bu bulgu neyi değiştirdi?” sorusunu cevaplayın. Eğer rol belirsizse, ekip çalışmasını küçümsemeden kendi katkınızı netleştirin.

Sıkça Sorulan Sorular

Case study rewrite metni tamamen değiştirmek mi demek? Hayır. Çoğu zaman mevcut malzemeyi daha net sıraya koymak ve karar bağlantılarını güçlendirmek yeterlidir.

Önce ve sonra örnekleri portfolyoda göstermeli miyim? Genelde gerekmez. Fakat önemli bir iteration anlatıyorsanız önceki ve sonraki tasarım kararını göstermek faydalı olabilir.

Metnim fazla uzarsa ne yapmalıyım? Her açıklama gerekli olmayabilir. Kararı etkileyen bilgiyi tutun, sadece süreci belgeleyen detayları azaltın.

AI rewrite için kullanılabilir mi? Kullanılabilir, ama prompt’unuz karar boşluklarını bulmaya odaklanmalı. Sadece “daha profesyonel yaz” demek genelde metni jenerikleştirir.

Rewrite sonrası neyi kontrol etmeliyim? Problem, rol, karar, kanıt ve etki zinciri okunuyor mu? En kritik kontrol bu.