UX Case Study Nasıl Yazılır: Süreç Değil Karar Anlatın

UX case study, yaptığınız işin fotoğrafı değil, verdiğiniz kararların kaydıdır. Portföyünüze bakan kişi ekran görüntülerini saymaz; hangi seçeneği elediğinizi ve neden elediğinizi arar. Aşağıdaki yapı, dolaşımdaki şablonların atladığı iki noktayı düzeltiyor: problemin ne zaman tanımlandığı ve sürecin ne kadarının yazıya gireceği.

Süreç günlüğü case study değildir

"Kullanıcı görüşmeleri yaptık, persona çıkardık, wireframe çizdik, test ettik" cümlesi hiçbir şey söylemez. Bunu herkes yazar, çünkü bu bir yöntem listesidir ve yöntemler ücretsiz. Değerli olan, o yöntemin çıktısının tasarımı nerede değiştirdiğidir. Bir görüşmede duyduğunuz şey yüzünden kurduğunuz akışı bozup baştan kurduysanız, case study'nin merkezi orasıdır. Böyle bir an yoksa proje anlatmaya hazır değildir.

Somut olun. "Kullanıcılar zorlandı" değil, "altı kişiden dördü ödeme adımında kupon alanını aradı, bulamayınca sepete geri döndü" yazın. Sayı vermek için araştırmanın büyük olması gerekmiyor, sadece gerçek olması gerekiyor.

Problem tanımı araştırmadan önce gelmez

Şablonların çoğu birinci adıma "problem tanımı", üçüncü adıma "problem doğrulama" koyar. Bu sıralama kendi kendini çürütür. Birinci adımda elinizdeki şey problem değil brief'tir: müşterinin ya da sizin başlangıçtaki varsayımınız. Araştırmayı bu varsayımı doğrulamak için yaparsanız, araştırma bir törene dönüşür ve sonucu baştan bellidir.

Doğru dizilim brief, araştırma, problem tanımı şeklindedir. Case study'nin en değerli cümlesi de buradan çıkar: başlangıçtaki varsayımın nerede yanıldığını söyleyen cümle. Bir portföyde "kullanıcıların onboarding'i uzun bulduğunu sanıyorduk, asıl şikayet kayıt sonrası boş ekrandı" yazan aday, altı aşamayı kusursuz sıralayan adaydan önde başlar.

Her aşamayı belgelemek okunmamayı garantiler

Klasik tavsiye ikiye bölünmüş bir şey söyler: bir yandan "her aşamayı belgeleyin, sonunda öğrendiklerinizi özetleyin", öbür yandan "kısa ve akıcı yazın". İkisi aynı sayfada duramaz. Altı aşamanın her birine giriş, yöntem, bulgu ve çıkarım yazarsanız yirmi dört bloklu bir metin ortaya çıkar. O artık portföy sayfası değil, proje raporudur ve baştan sona okunmaz.

Sınırı kendiniz koyun: üç, en fazla dört karar noktası seçin, bunları ayrıntılı anlatın, geri kalan aşamaları tek paragrafta geçin. Ham malzeme (görüşme notları, tüm ekran varyasyonları, test kayıtları) ayrı bir bağlantının arkasında dursun. İsteyen açar, açmayan da metnin akışını kaybetmez.

Redesign tuzağı

Gerçek projesi olmayanların çoğu tanınmış bir uygulamayı yeniden tasarlar. Buradaki sorun estetik değil epistemik: problemi de siz uydurursunuz, başarı ölçütünü de siz koyarsınız, dolayısıyla yanılma ihtimaliniz sıfırdır. Kısıtı olmayan bir projede verilmiş karar da yoktur.

Bunun yerine küçük ve gerçek bir şey seçin. Mahalledeki işletmenin randevu akışı, üyesi olduğunuz derneğin aidat sayfası, kendi kullandığınız bir aracın tek bir ekranı. Beş kullanıcıyla yapılmış gerçek bir test, hayali bir marka için hazırlanmış on beş sayfalık sunumdan daha fazlasını kanıtlar. Kısıt yoksa üretin: bütçe yok, mevcut altyapı değişmeyecek, ekip iki kişi. Kısıt, tasarım kararını görünür kılan tek şeydir.

Nerede yayınlanacağı

Behance ve benzeri platformlar görünürlük sağlar, ama sıralama görsel çekiciliğe göre işler ve uzun metin orada okunmaz. Pratik çözüm ikisini ayırmaktır: platformda güçlü görseller ve kısa bir özet, tam metin kendi alan adınızda. İş başvurusunda verdiğiniz bağlantı da kendi sayfanız olsun, çünkü orada düzeni siz kurarsınız.

Katıldığınız eğitimlerin sertifikaları en sona, tek satır halinde gitsin (bu listenin portföyün en zayıf bölümü olduğunu düşünüyorum). Kimse sertifikaya bakarak tasarımcı işe almıyor; iki paragraflık bir karar gerekçesi, on sertifikadan daha ikna edici.