Mülakata götüren bir UX case study'nin anatomisi

Her hafta UX portfolyoları inceliyorum; hem işe alan bir design lead hem de mentor olarak. En sık gördüğüm örüntü, bu kadar önlenebilir olduğu için canımı sıkıyor: sağlam iş çıkarmış bir tasarımcı ve işe alım yöneticisinin aradığı her şeyi saklayan bir case study.

İşin kendisi nadiren sorun oluyor. Sorun anlatımda.

Suçun bir kısmı hepimizin öğrendiği formatta. Behance bir tasarımcı kuşağına case study’nin bir poster olduğunu öğretti: uçsuz bucaksız, tam genişlikte görsellerden oluşan, kanıt gibi sunulan şık bir kaydırma. Görsel zanaat için bu format dürüst; iş kendi adına konuşur. Product design case study’leri ise posteri olduğu gibi devraldı ve bu miras, işe alım yöneticisinin sayfada aradığı tek şeyi sessizce sildi. Bir poster ne yaptığını gösterebilir. Neye karar verdiğini, kararın neye mal olduğunu, bir odada neyi savunacağını gösteremez. Herkes aynı kalıpla yayınladığı için kalıp artık kanıtlanmış bir kural gibi görünüyor; oysa başka bir işten ödünç alınmış bir alışkanlık.

Ne demek istediğimi tam olarak göstermek için biraz alışılmadık bir şey yapacağım. Aşağıda aynı case study iki kez yazılmış halde duruyor. Tasarımcı Maya, mentorluk pratiğimde kullandığım kurgusal bir öğretim örneği; projesinin iki sürümü de kurgu. Yine de ilk sürümdeki her hata, gerçek portfolyolarda defalarca gördüğüm, hak ettiğinden zayıf sunulmuş işlere ait hatalar. Projenin kendisi bilerek sıradan: bir e-ticaret ürün sayfası yeniden tasarımı, incelediğim portfolyoların yarısının üzerine kurulduğu türden bir case study. Yaklaşım burada işliyorsa her yerde işler.

Bölüm bölüm ilerleyeceğiz. Her biri için: zayıf sürüm, değerlendiricinin ona ayırdığı üç saniyede neden elendiği, güçlü sürüm ve gerçekte neyin değiştiği.

1. Problem bölümü: sayılar taşıyıcı kolondur

Önce:

“Ürün sayfası düşük performans gösteriyordu. Analitik veriler özellikle mobilde düşük bir sepete ekleme oranı ve yüksek bir hemen çıkma oranı gösteriyordu. Sayfa tasarımı rakiplere göre eski kalmıştı ve paydaşlar daha modern bir görünüm istiyordu.”

Neden eleniyor: “Düşük performans” ve “eski kalmış” birer görüş. Değerlendirici bu projenin önemli olup olmadığını anlayamıyor; daha kötüsü, “paydaşlar modern bir görünüm istedi” cümlesi problem tanımını sessizce başkasına devrediyor. Tasarımcı bir problemi sahiplenmek yerine bir talebi uygulamış gibi okunuyor.

Sonra:

“Marlo’nun ürün sayfasında bir dönüşüm problemi vardı. Son çeyreğin analitiği %6 sepete ekleme oranı ve %58 genel hemen çıkma oranı gösteriyordu. Mobilde hemen çıkma %67’ye tırmanıyordu. […] Yerleşim kötü ürünleri saklamıyordu. Doğru bilgiyi yanlış anda saklıyordu.”

Ne değişti: Sayılar aynı anda iki iş yapıyor. Sıfata ihtiyaç duymadan riski ortaya koyuyor ve daha gelmeden sonuç bölümünü kuruyor. Şuna da dikkat: problem, bilgi ve zamanlama üzerine spesifik bir teşhis olarak çerçevelenmiş; yeniden tasarımın tamamı bu teşhise cevap verecek. Problem cümlesi, case study’nin geri kalanının neyi kanıtlayacağına dair bir sözdür.

Haftalık incelemelerimde gerçek bir problemin yerine en sık geçen iki şey var: kapsam cümlesi (“amaç ürün sayfasını yeniden tasarlamaktı”) ve problem kılığına girmiş eksik özellik (“uygulamada X yoktu, o yüzden X gerekiyordu”). İkisi de aynı soruları atlıyor: neyin, kimin için, ne kadar kötü bozulduğu. Hızlı bir öz test: problem bölümün, proje hiç yaşanmasaydı da aynı okunacaksa bir görevi tarif ediyordur ve değerlendirici bunu fark eder.

2. Araştırma bölümü: bulgular bir yere işaret edene kadar değersizdir

Önce:

“Kullanılabilirlik testleri birkaç sorun noktası ortaya çıkardı. Kullanıcılar renk ve beden seçeneklerini bulmakta zorlandı, daha fazla ürün görseli istedi, teslimat sürelerini ve yorumları sordu.”

Neden eleniyor: Bu bir gözlem listesi ve kendi başına sorun yok. Eleyen şey etrafındaki boşluk: bu altı oturumun neden yapıldığına, hangi soruyu cevapladığına, her bulgunun tasarımda neyi değiştirdiğine dair tek bir işaret yok. Böyle sunulan araştırma dekordur. Değerlendiriciler “kullanılabilirlik testi yaptık” cümlesinin hiçbir sonuca bağlanmadığı yüzlerce case study görmüş durumda.

Rakip benchmark’ı bu hatanın en cilalı hali ve her hafta karşıma çıkıyor. Adaylar hızlı ilerliyor, hızlı prototip alıyor ve ilk refleks benchmark oluyor: gerçekten kapsamlı karşılaştırma tabloları, bazen tüm case’in en emek yoğun ürünü. Sonra case study, benchmark’ın hangi fırsatı ya da içgörüyü ortaya çıkardığını hiçbir yerde söylemiyor ve hikâyenin ilerisindeki tek bir karar bile ona geri dönmüyor. Emek gerçekti. Sunulduğu haliyle mobilya.

Sonra:

“Örneklem bilinçli olarak küçük tutuldu. Amaç yön bulmaktı: GA4 funnel düşüşlerinin ve Hotjar kaydırma verisinin arkasındaki nedeni açıklamak; istatistiksel olarak temsili bulgular üretmek değil. […] Bu üç bulgu doğrudan analitikteki boşluklara oturdu. Kaydırma derinliği verisi kullanıcıların varyantlara ve yorumlara ulaşamadan ayrıldığını gösteriyordu. Kullanılabilirlik oturumları neden ayrıldıklarını gösterdi.”

Ne değişti: Çalınmaya değer iki şey var. Birincisi, güçlü sürüm kendi sınırlarını kimse saldırmadan önce savunuyor: altı katılımcı ve altının bu amaç için neden yeterli olduğu. Bu tek hamle, duvar kaplayan affinity map fotoğraflarından daha fazla araştırma olgunluğu sinyali verir. İkincisi, her bulgu başka bir kaynaktan gelen kanıta bağlanmış. Nicel veri kullanıcıların nerede ayrıldığını söylüyor, nitel veri nedenini. Araştırma, iş yaparken gösterildiği anda case study’deki yerini hak eder.

3. Süreç bölümü: kararlarını adlandır

Önce:

“Double Diamond çerçevesine dayalı, kullanıcı odaklı bir tasarım süreci izledim: Keşfet, Tanımla, Geliştir, Teslim Et.”

Neden eleniyor: Her aday tam olarak bu paragrafı yazıyor. Bir çerçevenin adını vermek, değerlendiriciye hangi şablonu doldurduğunu söyler; nasıl düşündüğün hakkında hiçbir şey söylemez. Zayıf sürümde düşüncenin durması gereken yerde bir elmas diyagramı duruyor.

Sonra:

“Daha zor karar, ekranın üst kısmındaki alandı. Galeri, fiyat, varyantlar ve güven sinyalleri aynı alan için yarışıyordu. Onları karar hiyerarşisine göre sıraladım: önce gör, sonra seç, fiyatın yanında kompakt bir güven satırı. Her şey ilk sırada olamazdı. Hiyerarşi, kesilenleri savunulabilir kıldı. […] Mobilde en tartışmalı karar sabit sepete ekleme barıydı. Dönüşümü güvenilir biçimde artırır; kalıcı ekran alanı tüketir ve rahatsız edici hissettirme riski taşır. %67 mobil hemen çıkma oranı bu takası değerli kıldı.”

Ne değişti: Bu, tüm incelemenin kalbi; o yüzden güçlü sürümde ne olduğunu net söyleyeyim. Bir çatışmayı adlandırıyor (dört öğe, tek ekran üstü). Tasarımcının bu probleme özel kurduğu bir düşünme aracını gösteriyor (gör, seç, güven, satın al). Bir kararın tartışmalı olduğunu kabul ediyor ve dengeyi neyin bozduğunu söylüyor. İşe alım yöneticileri case study’leri tam olarak bunun peşinde okur: şeyler yarıştığında bir seçme yöntemin olduğuna ve seçimi bir odada yüksek sesle savunabileceğine dair kanıt. Dürüstçe anlatılmış tek bir trade-off, koca bir süreç bölümünden daha değerlidir.

Mentorluk seanslarında bunu kurcalayıp “bunu neden seçtin?” diye sorduğumda iki cevap tekrar tekrar geliyor. İlki, iş rozeti takmış beğeni: “daha temiz hissettirdi”, “bu yönü daha çok sevdim”. İkincisi daha sinsi: birkaç arkadaş tasarıma bakmış, yorumları sessizce mutlak gerçeğe terfi etmiş ve bir tercih “kullanıcılar bunu kafa karıştırıcı buldu”ya dönüşmüş. İkisi de aynı sorunun mülakatta sorulan haline dayanamaz, çünkü ikisi de bir karar değildi. Bir kararın bir çatışması, bir ölçütü ve kabul ettiğin bir bedeli vardır.

4. Sonuçlar bölümü: belirsiz başarı, başarı yokluğundan ayırt edilemez

Önce:

“Yeni sayfa belirgin şekilde daha iyi performans gösterdi: sepete ekleme oranı iyileşti, mobil hemen çıkma oranı düştü ve daha fazla kullanıcı ödeme adımına ulaştı. Müşteri sonuçtan çok memnun kaldı.”

Neden eleniyor: “Belirgin şekilde iyileşti” doğrulanamaz, karşılaştırılamaz, sorgulanamaz; deneyimli bir değerlendirici bunu sıfır sayar. “Müşteri memnun kaldı” hiç yoktan daha kötü; onay bir sonuç sayılmaz. Üstelik her metrik pürüzsüzce iyileştiğinde bölümün tamamı, mutlu sondan geriye doğru yazılmış gibi kokmaya başlar.

Sonra:

“Yeniden tasarım, orijinal ürün sayfasına karşı iki hafta A/B testi olarak koştu. Tüm artışlar göreli ve baz oranlara karşı ölçüldü. Sepete ekleme oranı: göreli +%18 (baz ~%6, yeni tasarım ~%7,1). Mobil hemen çıkma oranı: göreli −%12. […] En büyük artış mobildeydi; sabit sepete ekleme barı ve ekran üstü güven sinyalleri işin çoğunu orada yaptı.”

Ne değişti: Güçlü sürüm sayılardan önce ölçüm yöntemini gösteriyor, artışları göreli olarak işaretliyor ve baz değerleri veriyor. O titizlik başlı başına sinyaldir. Şunu söyler: bu tasarımcı göreli +%18 ile +18 puan arasındaki farkı biliyor ve ikisini de şişirmeyecek. Sonucun belirli kısımlarını belirli tasarım kararlarına yazıyor; bu da problem bölümünün açtığı döngüyü kapatıyor. Gerçek projende temiz sayılar yoksa neyi ölçeceğini ve erken sinyallerin hangi yöne işaret ettiğini söyle. Dürüst kısmi kanıt, kendinden emin belirsizlikten daha iyi okunur.

5. Çıkarımlar bölümü: klişeler israf edilmiş bir kapanış savunmasıdır

Önce:

“Bu proje bana kullanıcı odaklı tasarımın ve geri bildirimle yinelemenin önemini öğretti. Yeniden tasarımın vardığı noktadan gurur duyuyorum ve bu öğrenimleri gelecekteki projelere taşımak için heyecanlıyım.”

Neden eleniyor: Bu paragraf herhangi bir yılda, herhangi bir tasarımcının, herhangi bir projesine zımbalanabilir. Bu kadar jenerik bir kapanış aktif olarak zarar verir, çünkü değerlendiricinin fikrini oluşturmadan önce okuduğu son şeydir.

Sonra:

“Başlangıç varsayımım bilgiyi görünür kılmanın yeteceğiydi. Varyantları, yorumları ve teslimatı ekranın üstüne taşı, dönüşüm arkasından gelir. Bu yalnızca yarı yarıya doğru çıktı. Her şeyi ilk çektiğimde sayfa kalabalıklaştı ve testlerde daha kötü sonuç verdi. […] Ders: ekranın üstü bir hiyerarşi kararıdır, alan kapmaca değildir.”

Ne değişti: Güçlü sürüm yanlış bir varsayımı itiraf ediyor ve kırıldığı anı gösteriyor. Bu, hiçbir beceri listesinin yapamayacağı bir şey yapar: tasarımcının gerçekle temastan öğrendiğini kanıtlar ve yalnızca bu projeden çıkabilecek kadar spesifik bir içgörü üretir. İyi bir çıkarımlar bölümü, değerlendiricinin seni ekibine getirirken hayal edebileceği taşınabilir bir fikirdir.

Anatomi, tek yerde

Bu incelemeden tek bir şey alacaksan beş bölümün arkasındaki örüntüyü al:

• Problem: sıfat ve paydaş talebi yerine sayılar ve bir teşhis.
• Araştırma: kararlara bağlanmış bulgular, baştan savunulmuş sınırlar.
• Süreç: çerçeve diyagramı yerine adlandırılmış trade-off’lar ve tartışmalı kararlar.
• Sonuçlar: sayılardan önce yöntem, artışların yanında baz değerler, kararlara yazılmış pay.
• Çıkarımlar: teşekkür yerine kırılmış bir varsayım ve taşınabilir bir içgörü.

Kendi case study’ni bu beş satıra karşı koş. İşi yapan cümleyi gösteremediğin her bölüm, değerlendiriciye muhakemeni göstermesi gereken yerde faaliyetlerini anlatıyordur.

Maya’nın projesinin iki sürümünde de iş birebir aynıydı. Aynı araştırma, aynı tasarım, aynı test. Bir sürüm kibar bir geçiştirme alır; diğeri tasarımcıyı işini konuşabileceği odaya sokar. Aradaki fark, tamamen görünür kılınmış kararlarla inşa edildi.

SSS

Bir UX case study’yi mülakata hazır yapan nedir?

Görünür kararlar. Değerlendirici hızlı bir taramada sayılarla kurulmuş bir problem, tasarımı değiştirmiş bulgular, adlandırılmış en az bir trade-off, baz değerli sonuçlar ve dürüst bir çıkarım bulabilmeli.

Güçlü bir problem tanımı nasıl yazılır?

Neyin, kimin için, ne kadar kötü bozulduğunu o sırada elindeki sayılarla söyle. İşe yarayan bir öz test: paragraf, proje hiç yaşanmasaydı da aynı okunacaksa bir kapsam cümlesidir, problem tanımı sayılmaz.

Projemde metrik yoksa ne yapmalıyım?

Neyi ölçeceğini ve erken sinyallerin hangi yöne işaret ettiğini yaz. Dürüstçe sunulmuş nitel kanıt, uydurulmuş kesinlikten ve kendinden emin belirsizlikten çok daha iyi okunur.

Bir case study’de ne kadar araştırma yeterli?

Adını koyduğun soruyu cevaplamaya yetecek kadar. Amacını söyleyip sınırını baştan savunduğun sürece küçük örneklem sorun olmaz; sonrasında her bulgunun bir kararı değiştirdiğini göster.

Double Diamond gibi bir çerçeveden bahsetmeli miyim?

Kısaca bahsedebilirsin; tek başına çerçeve adı sinyal taşımaz. Değerlendiricinin gerçekten okuduğu bölüm, yarışan seçeneklerin, bir ölçütün ve kabul edilmiş bir bedelin adlandırıldığı bölümdür.