Biz SHERPA’da, genel geçer kabullerin tam aksine, kullanıcı deneyimi yaratımı süreçlerinin en başından itibaren yazılım geliştiricilerin masada bizlerle yan yana olması gerektiğine inanıyoruz. Bu yazı da bu inancın nedenleriyle ilgili…
İçerikler ne zaman gelecek?
İşte, bizi bizden alan “bekleme” süreci bu soruyla baş gösterip, aşağıdaki varsayımlarla bizi usul usul, içten içten kemirmeye başlıyor:
İçerikler geç gelirse, UX tasarımı da geç başlayacak; UX gecikirse, UI da ötelenecek… UI onaylanmadan HTML’e (ya da gerekli olan arayüz geliştirme sürecine) geçemeyeceğiz.
Peki, siz sanıyor musunuz ki proje takımımızda bizlerle birlikte çalışan yazılımcıların içleri rahat?
It’s not “my”frame, it is “wireframe”
UX Designer rolündekilerin, kullanıcı deneyimi tasarım süreçlerindeki eskizlerini low-fi veya mid-fi wireframe’lerle proje sahibi ve diğer paydaşlarına aktarmaları esnasında ne yazık ki en tehlikeli virajlar “işini aşırı beğenme/sahiplenme” ve “iteratif tasarıma şüpheyle yaklaşma”da dönülüyor. Olur da ekip içi iletişim “Arkadaşlar, bu (wireframe çizimlerini kast ederek) benim işim. Herkes kendi uzmanlığı dahilindeki alanlar hakkında görüş bildirsin” yönünde seyrediyorsa, sonunda ortaya çıkan “wireframe” değil, “my” frame oluveriyor. Peki aslında nasıl olmalı?
Bu içerik ücretsiz!
Okumaya devam etmek ve SHERPA Blog okuru olmak için aşağıdakilerden birini seç. Her hafta yenileri eklenen yüzlerce içeriğe ücretsiz ve sınırsız eriş.
Mart 2015’te yine SHERPA Blog’da “Wireframe, Mockup ve Prototype” üçlemesi arasındaki farkları özetlemek için yazdığım yazıda, hangi eskiz yaratım tekniğinin, kullanıcı deneyim tasarımının hangi aşamasında kullanılabileceğini, nasıl artılara ve eksilere sahip olduğunu aktarmıştım. Bu tip eskiz yaratım süreçlerinin “neden” yapıldıklarının detayına ise girmemiştim. Wireframe, mockup veya prototip; tipi veya yaratım metodolojisi her ne olursa olsun bu çıktılar, ortaya çıkartılması hedeflenen kullanıcı deneyimi çözümünün, onun üretim mühendisliği sürecinde görev alacak her bir paydaşın aynı iletişim parametreleriyle tartışabilmesini mümkün kılıyor. Üretimin önceki veya sonraki aşamasında aktif rol alacak olmakla bu sürece dahil olup olmamak arasında hiçbir bağlantı da yok. Diğer bir deyişle “Arkadaş, ben yazılımcıyım. Bana PSD gelir, proje benim için o zaman başlar.” kafa yapısındaki yazılımcılarla çalışmayın. (Biraz sert oldu farkındayım. Test ettim. Test ettik. Olmadı. Olmuyor. Olmayacak da…)
UX ≠ Wireframe, Yazılımcı ≠ Yazılımcı
Nietzsche’nin dediği gibi “Bu dahil olmak üzere, tüm genellemeler yanlıştır.” ancak UX’i wireframe ile kısıtlamak ve her yazılımcının aynı bilgi seviyesinde ve çözümleme yeteneğinde olduğunu düşünmek de o kadar yanlıştır. Eğer ki kullanıcı deneyimi yaratımı sürecinize yazılımcıları da alarak başlamayı tercih ediyorsanız, bu yolda çok fazla işinize yarayacak bir set öneriyi sizlerle paylaşmak isterim:
Sketch, low-fi wireframe, mockup veya interactive protip, her ne üretiyorsanız üretin ama mutlaka çizimlerinizi notlarla (annotation) açıklayıcı kılın. Bu teknik hem statik olmayan çözümlemelerin çalışma senaryolarını daha rahat açıklayabilmenize imkan verecek hem de yazılımcıların daha işin çok başındayken interaksiyon senaryoları üzerinde AR&GE yapabilmelerini mümkün kılacaktır.
Akış diagramlarını sevin, kullanın, kullandırtın. Bazı durumlarda bir login süreci ya da e-ticaretteki sepet işlemini arayüz paternlerini kullanarak anlatabilmek için sayfalarca çizim yapmanız gerekebilir. Akış diagramları, işte tam da bu noktada hayat kurtarıcı rolüne bürünerek, kalite kontrol aşamasında başınızı çok ağrıtabilecek sorunları azaltacaktır.
Süreci storyboard’larla hikayeleştirin. Kullanıcı deneyimi tasarımı insandan uzaklaşmaya başlayıp analitikleştikçe, duygusal fayda da ortadan kalkmaya ya da arka plana itilmeye başlıyor. Storyboard’lardaki “insan” faktörü, her ne kadar çizgisel bir yaklaşımla dahi olsa, daima bağlı kalmamız gereken en önemli disiplini bizlere hatırlatıyor: iletişimi insan için tasarlıyoruz.
Persona ’larla kimin mutlu etmeye çalıştığınızı betimleyin. “Personalar kimsenin umrunda değil; biz sadece projenin sahibini mutlu etmeye çalışıyoruz.” kabulü ile yola çıkıyorsanız, bu maddeyi es geçebilirsiniz. Biz “direnmeyi” tercih edenlerdeniz. Bizim masamızda da HiPPo’lar var, doğrudur. Bizim masamızda da sübjektif değerlendirmelerle ateşi harlanan tansiyonu yüksek çatışmalar var. Bizim masamızda da “O öyle değil, böyle olmalılar.” var. Ancak tüm bunların yanı sıra bir de “Hedeflenen başarı için olması/yapılması/uygulanması gerekenler” var. Biz SHERPA’daki ana sorumluluğumuzun işte bu son yazdıklarımı, biz dahil tüm ekibin asla unutmaması gerektiğine inanıyoruz. SHERPA Blog’da Personalar ile ilgili yazdığımız şu yazıda, hedeflenen kitlenin proje paydaşlarına aktarımında kullanabileceğiniz araçları ve takip etmeniz gereken ilerleme şeklini detaylıca aktarmıştık. Unutmayın, bir kullanıcı deneyimi tasarımcısı hedef kitleyi çok ama çok yakında tanıyacak kadar araştırma yapabilir; lakin bunu projenin içerisindeki diğer paydaşlara doğru aktaramadığı sürece ne yazık ki her kararı, önermesi ve çıkarımı sorgulanacaktır.
UXPin, yukarıdaki 4 başlıkla ilgili güzel örnekler de içeren mini bir e-book yayınlandı. SHERPA’nın Behance portfolyosunda da her bir madde için birden çok örnek bulabilirsiniz.
“Yazıyoruz, çiziyoruz, resmediyoruz da, okuyan var mı?”
Yukarıdaki taktikleri harfiyen uygulayan, ekibin projenin başından sonuna “bir arada” ve “bir kafada” çalışmasını arzulayan proje yöneticilerinin en sık şikayet ettikleri konu da bu: çıktıların içselleştirilmemesi. Bu durum ne yazık ki yazılımcılar ekseninde biraz fazla tekrarlanıyor. (Bu da doğru.) Peki o kadar emeğe yazık değil mi? Farklı bir açıdan yaklaşırsak, “bu şekilde çalışmayı tercih etmeyen/sevmeyen yazılımcı ile çalışmaya çalışmak” bir efor kaybı yaratmıyor mu? Üretilen çıktıların tüm ekip tarafından içselleştirilmemesinin bir kayıp yarattığı kadar ekip içerisinde motivasyon ve inanç kaybına yol açtığı aşikar. Bu durumun ikili çatışmaları tetiklediği de sıkça gözlemlenen bir sonuç. Tercihlerimiz, tek şeritli yolun ortasında fil gibi kaya varken, aracı şarampole yuvarlama riskini göze alarak yandan geçmeye çalışmak mı yoksa “Bu sefer kesin aşağıya indireceğim” diyerek tam gaz o kayaya doğru aracı sürmek mi olmalı? Bence ikisi de değil.
Yine SHERPA Blog için yazdığım “Wirefaming’in Dünü, Bugünü ve Yarını” isimli yazıda tanıtmış olduğum Agile UX ve Lean UX kavramları işte tam da bu noktada anlam kazanıyor ve bu probleme çözüm sunuyor. Eğer yukarıda tasvir ettiğim takım içi problemden siz de muzdaripseniz, Agile UX’e bu soruyu aklınızdan hiç çıkarmadan alıcı gözüyle tekrar bir göz atın.
