Design Thinking'i Kendi UX Portföyünüze Uygulamak
UX portföyü okunan değil taranan bir belge. Design Thinking'in buradaki asıl katkısı yöntem listesi vermek değil, portföyün kendisini bir tasarım işi saymak: okuyucusunu tanı, sonra yalnızca o okuyucunun kullanabileceği kadarını bırak. Zor kısmı neyin ekleneceği değil, neyin atılacağı.
Portföyün kullanıcısı kim
Empati aşamasını kendi portföyünüze uygulamak fazla düz bir fikir gibi duruyor, ama çıkan sonuç ilginç: portföyü okuyan kişi çoğu zaman sizinle aynı dili konuşmuyor. İlk elemeyi genellikle işe alım tarafı yapar, tasarım kararlarınızı gerçekten değerlendirecek kişi sıraya daha sonra girer. Aynı sayfa iki farklı okuyucuya hizmet ediyor. Peki hangisi için yazmalı?
İkisi için de, ayrı katmanlarda. Üstteki katman sıralama içindir: ne yaptınız, hangi bağlamda, sonuç ne oldu. Alttaki katman gerekçe içindir ve ancak biri ilgilenirse okunur. Bu ayrımı yapmayan portföylerde gerekçe en üste çıkıyor, tarayan kişi de üç paragraf bağlam okuyup ne yaptığınızı hâlâ bilmeden sayfayı kapatıyor.
İki dakika ile sekiz maddelik kontrol listesi çelişiyor
Portföy tavsiyeleri iki şeyi aynı anda söylemeyi seviyor. Birincisi, karar birkaç dakika içinde veriliyor. İkincisi, her vaka çalışmasında problem tanımı, kısıtlar, süreç görselleri, elenen alternatifler, ekip iş birliği, ölçülebilir sonuç ve çıkarılan dersler bulunmalı.
Bu ikisi birlikte tutmuyor. Yedi başlık birkaç dakikaya sığmaz; sığdırmaya çalıştığınızda her başlık iki cümleye iner ve iki cümle kanıt taşımaz. Elinizde yedi tane kısa iddia kalır, hiçbirinin arkasında iş görünmez.
Tercih açık: bir vakayı derin, bir ya da iki vakayı özet düzeyinde anlatmak. Derin olanda kontrol listesinin tamamı bulunabilir, özet olanlarda yalnızca problem ve sonuç. Üç vakayı da eşit ağırlıkta anlatan portföy, üçünde de yüzeyde kalıyor.
Bir vakada asıl kanıt nerede
Vaka çalışmalarını genelde tek bir karar etrafında kurarım: iki yol vardı, biri seçildi, öbürü neden elendi. Elenen yolu yazmak, süreci anlattığınızı iddia etmenin en ucuz ve en inandırıcı biçimi, çünkü uydurulması zor. Kullanıcı yolculuğu şeması herkeste var. "Modal yerine ayrı sayfa seçtik, çünkü form iki adımdan uzundu ve mobilde klavye açıkken modal içeriği kesiyordu" cümlesi ise yalnızca o işi yapmış birinde var.
Aynı şey sonuç bölümü için de geçerli. Sayı verebiliyorsanız verin, veremiyorsanız neyin ölçülmediğini yazın. Ölçülmediğini kabul eden bir vaka, ölçüm süsü verilmiş bir vakadan daha güvenilir duruyor.
Uygulama maliyetini yazmayan vaka yarım kalıyor
Portföylerde en çok atlanan şey, tasarımın hayata geçerken ne kadar tuttuğu. Bir ekran akışını değiştirmek arayüzde tek sayfalık bir iş gibi görünür, arkada üç tablonun ilişkisini ve iki servisin yanıt sırasını ilgilendirebilir. Vakanın kısıtlar bölümü buraya bakmıyorsa, kısıt bölümü aslında yok demektir.
Peki geliştirme tarafından bir sayı elinizde yoksa? Ne konuşulduğunu yazın: hangi öneri "bu sprintte olmaz" diye geri geldi, siz neyi böldünüz. Ekip çalışmasını anlatmanın yolu iş birliği yaptığınızı söylemek değil, pazarlığın izini bırakmak.
Portföyü prototip gibi test edin
Portföy bir ürünse, test edilmeden yayına girmemesi gerekir. Alan dışından birine iki dakika verin, sonra sorun:
- Hangi problemi çözdüğümü tek cümlede söyleyebilir misin?
- Bu işte benim yaptığım kısım neresiydi?
- Sonuç iyi mi kötü mü, nereden anladın?
Üçüne de cevap gelmiyorsa eksik olan şey görsel değil, sıralama. Çoğu portföyde bilgi zaten var, sadece okuyucunun bakmayacağı yerde duruyor. Yeni bölüm eklemek yerine sıralamayı değiştirmek, çoğu durumda bir haftalık işi bir saate indiriyor.
Kaynaklar