UX Case Study Girişi: Problem, Çözüm ve Rol

Bir UX case study'sinde giriş, okuyan kişinin devamını okuyup okumayacağına karar verdiği yerdir. Üç şeyi söylemesi yeter: hangi problem, ne yapıldı, sizin payınız neydi. Gerisi zaten sayfanın devamında duruyor.

Girişin tek işi var

Case study'yi değerlendiren kişi onu baştan sona okumuyor. Portföyü tarıyor, birkaç saniyede devam edip etmeyeceğine karar veriyor. Giriş, o kararın verildiği yer. Yani girişin işi süreci anlatmak değil; sürecin neden başladığını ve sizin orada ne yaptığınızı tek bakışta göstermek.

Bu yüzden Freytag'ın beş bölümlü dramatik yapısına, üç perdeye, hikâye anlatıcılığı benzetmelerine ihtiyaç yok. Case study drama değil. Karşı taraf doruk noktasını merak etmiyor, sizin nasıl düşündüğünüzü merak ediyor. Dramatik yapıya atıf yapan girişler de zaten o yapının yalnızca ilk perdesini kullanıyor, geri kalanı süs.

Problem: iş tarafına bağlanmayan problem yarım kalır

“Tasarım eskimişti, yeniledik” bir problem tanımı değil, bir gözlem. Problem tanımı, işin nerede zarar gördüğünü söyler. Kullanıcı bir özelliği bulamıyorsa bunun karşılığı yarım kalan sepet, açılmayan hesap, hiç kullanılmayan bir modül lisansıdır. Girişte bu bağı kurun; kurmazsanız yaptığınız iş, sonuçları ölçülmemiş bir görsel tazeleme gibi okunur.

Sürecin başındaki tereddüdü ya da heyecanı bir cümleyle geçmek girişi insanlaştırır. Bir cümle. Duygu bölümüne dönüştüğü anda okuyucu problemi kaybediyor.

Çözüm: yöntemin adı değil, verilen karar

“Design thinking uyguladık, sprint yaptık, kullanıcı testi koştuk” cümlesi hiçbir şey anlatmaz, çünkü aynı cümle her portföyde var. Girişe yöntemin adını değil, işi belirleyen kararı yazın: neyi neyin uğruna feda ettiniz, hangi yolu denediniz ve neden vazgeçtiniz. Yöntem anlatımının yeri süreç bölümü.

Varsa çıktıyı da buraya koyun. Ölçtüğünüz bir sayı yoksa uydurmayın; “tamamlama süresi kısaldı” demek, kaynağı olmayan bir yüzdeden daha güçlü durur.

Rolünüz: sıfat değil fiil

“Projede yer aldım” belirsiz. Ne yaptığınızı fiille söyleyin: akışı kurdum, testleri yürüttüm, bileşen kütüphanesini yazdım. Ekipteki diğer insanları silmeye gerek yok, üstelik tek başına yapılmış gibi duran bir iş zaten inandırıcı gelmiyor. Katkınızı net söylemek ile takımı yok saymak arasındaki fark, cümlenin öznesini doğru seçmekte.

Yazma yöntemi ve içindeki çelişki

Pratikte işleyen sıra şu: boş bir dosyaya “Problem”, “Çözüm”, “Rolüm” başlıklarını atın, her birini uzun uzun doldurun, sonra tamamını üç dört cümleye indirin.

Bu tarifin yaygın halinde bir tutarsızlık var. “Her başlığı ayrıntılı doldurun” ile “toplamı dört beş cümleye indirin” aynı anda geçerli olamaz; üç bileşene beş cümle dağıtırsanız her birine ortalama bir buçuk cümle düşer. O yüzden eşit dağıtmayın. Makaleyi taşıyan bileşen hangisiyse ona iki cümle verin, kalan ikisini birer cümleye sıkıştırın. Çoğu projede taşıyan bileşen problemdir; problemi anlaşılan bir iş, çözümü merak edilen bir iş oluyor.

Son sürümde o üç başlığı silersin. Başlıklar taslak iskelesi; okuyucuya gösterildiğinde giriş, akıcı bir paragraf yerine doldurulmuş bir forma benziyor.

Örnek bir giriş ve eksiği

Kategorisinde lider bir platformdu, ancak arayüz beş yıl boyunca parça parça büyümüş, yeni özellikler eski akışın üstüne eklenmişti. Yenileme kararı, destek ekibine gelen “ayarı bulamıyorum” taleplerinin artmasıyla alındı. Ortak bir tasarım sistemi kurduk; ben görsel dili ve etkileşim kalıplarını tanımladım, en çok kullanılan altı ekranı yeniden tasarladım.

Bu giriş üç bileşeni de veriyor ve gereksiz süsü yok. Eksiği de belli: sonucu söylemiyor. Bir cümle daha eklenip “yenileme sonrası aynı destek talebi kategorisi geriledi” denseydi, geri kalanı okumak için bir sebep daha olurdu. Giriş yazarken en son bakacağınız şey bu olsun: metin, devamını okumak için tek bir sebep veriyor mu?