UX Case Study'de Neyi Göstermeli, Neyi Kesmeli
Portfolyodaki case study'lerin neredeyse tamamı aynı kalıptan çıkıyor: problem, süreç, sonuç. Kalıbın kendisi yanlış değil, ama okuyanın aradığı şeyi çoğu zaman gizliyor. Bir tasarımcının nasıl düşündüğü seçtiği çözümde değil, elediği seçeneklerde görünür.
Hikaye anlatıcılığı bu kadar merkezde olmayı hak ediyor mu
Case study rehberlerinin ortak nakaratı hikaye anlatmak. Gerekçe de hazır: insanlar hikayeyle öğrenir, empati kurar, akılda kalır. Kulağa doğru geliyor, fakat bir portfolyoyu okuyan kişinin durumu tipik bir okuyucununkine benzemiyor. Elinde on iki başvuru var, her birine ayıracağı süre sınırlı ve empati kurmaya değil, karar vermeye çalışıyor.
Hikayenin işe yarayan tarafı duygusal değil, yapısal: olayları sıraya koyar, hangi bilginin hangi kararı doğurduğunu gösterir. Kronolojiyi bunun için kullanın. Sırf akış hoş görünsün diye "başta her şey belirsizdi" tonuyla açılan girişler ise okuyucunun ilk yarım dakikasını harcıyor, sonra da asıl karar üçüncü ekranda kalıyor.
Bağlam demek, kısıt demek
İlk bölümde çoğu yazar projenin vizyonunu anlatıyor. Vizyon serbest bir metin, kimse doğrulayamaz. Kısıt öyle değil.
Örneğin bir hatırlatma uygulaması üzerinde çalıştığınızı yazıyorsunuz ve hedefi "kullanıcılar hatırlatmayı tam ihtiyaç duydukları anda alsın" diye koyuyorsunuz. Bu bir hedef değil, temenni. Hedef şuna benzer: bildirim gecikmesi konum değişiminden sonra en fazla otuz saniye, arka planda çalışan servis günlük pil tüketiminin yüzde ikisini geçmeyecek. İkisi arasındaki fark, tasarımın gerçekten yapılıp yapılamayacağını belirleyen tek şey.
Ekibin büyüklüğü, süre, mevcut sistemin taşıdığı teknik borç ve sizin roldeki payınız da buraya girer. Tek başına çalıştığınız bir projeyle beş kişilik bir ekipte etkileşim akışını devraldığınız proje aynı ağırlıkta okunmuyor, okunmamalı da.
Süreçte asıl gösterilecek olan reddedilen seçenek
Araştırma yaptınız, persona çıkardınız, wireframe çizdiniz. Bunların ekran görüntüsü tek başına bir şey söylemiyor, çünkü herkeste var. Bir case study okurken önce reddedilen seçeneği ararım. Yoksa geriye kalan şey, sonucun kendi kendini haklı çıkarmasından ibaret oluyor.
Reddedilen seçeneği yazmanın maliyeti düşük: iki cümle yeter. Hangi alternatifi denediniz, neden bıraktınız, o kararı hangi bulguya dayandırdınız. "Kaydırmalı liste denedik, kullanıcıların dördü de son maddeyi hiç görmedi, sabit sekmeye geçtik" cümlesi, on sayfalık süreç anlatımından daha çok şey anlatır.
Bir de şu var: prototipte iki saniyede çalışan bir etkileşimin üretim ortamında ne kadara mal olduğunu yazan case study neredeyse hiç yok. Halbuki tasarım kararını gerçek yapan şey tam olarak bu. Eğer çözümünüz hiç uygulanmadıysa bunu saklamak yerine açıkça söyleyin; uygulanmamış bir tasarımı uygulanmış gibi sunmak, ilk teknik soruda dağılıyor.
Sayı verecekseniz paydayı da verin
Sonuç bölümlerinin standart cümlesi şu: görev tamamlama oranı yüzde yirmi arttı. Payda yoksa bu cümlenin bilgi değeri sıfıra yakın. Yirmi kişiyle yapılan bir testte bir kişinin davranış değiştirmesi yüzde beş demek; iki kişi yön değiştirdiğinde grafiğiniz yüzde on oynuyor. Aynı yüzde, iki bin kullanıcılık bir ölçümde tamamen başka bir şey ifade eder.
Yazarken üçünü birlikte verin: kaç kişi, ne kadar süre, hangi başlangıç değerine göre. Ölçüm yapamadıysanız yapamadığınızı yazın. Ölçülmemiş bir iyileşmeyi sayıya çevirmek, case study'nin en kolay fark edilen zayıf noktası.
Kesilecekler
Uzunluk kendi başına bir erdem değil. Şunlar çıktığında hemen hiçbir case study zayıflamıyor:
- Empathize-Define-Ideate-Prototype-Test diyagramı. Herkes aynısını koyuyor, sizin projenize dair sıfır bilgi taşıyor.
- Kullanılan araçların logo şeridi. Figma bildiğinizi göstermek istiyorsanız dosyanın kendisini paylaşın.
- Sürecin hiçbir yerinde işe yaramamış persona kartları. Persona bir karara dayanak olduysa kalsın, dekor olarak durduysa gitsin.
- Moodboard sayfaları, projenin görsel yönü asıl mesele değilse.
Geriye kalan üç dört ekran, bir sayfa metin ve iki net karar yeter. Okuyan kişi zaten bunu arıyor.