“Proje sahibi bizden ne bekliyor?” sorusuna daha işin başında yanıt almayı ve olası beklentilere dair endişeleri gidermeyi kolaylaştıran onlarca yöntem mevcut.
Kabul edelim, biz kullanıcı deneyimi tasarımı profesyonelleri, işlerimiz hakkında açıklama yaparken hâlâ (jargona aşina olmayanlar için) Klingonca’ya yakın bir dil konuşuyoruz. Bilgi mimarisi, kullanıcı deneyimi yol haritası, taksonomi, wireframe, mockup, prototip, low fidelity, high fidelity derken proje sahibi olarak konumlanan profesyonelin ya bu teknik terimlerle önceden mesaisi olmasını ya da çok hızlı bir öğrenme yeteneğine hasıl olmasını şart koşuyoruz. Bu durum da ne yazık ki yazının başlığında yer alan, proje sahibi dışavurumunun sıklıkla ortaya çıkmasına sebep oluyor. Sonuç: Her iki tarafın da oldukça heves bükücü bir havayı teneffüs etmesi, motivasyon kaybı ve odağın dağılması… Kısaca, hüsran.
Beklenti yönetimi
“Proje sahibi bizden ne bekliyor?” sorusuna yanıt almayı kolaylaştıran onlarca yöntem mevcut. Kapsam tanımlama, gereksinimlerin analiz edilmesini sağlama, proje vizyonunu belirleme ilk çırpıda akla gelenler. Lakin iş “tasarım”a gelince, “neyin tasarlandığı” kadar “neyin, nasıl tasarlandığı ve sunulduğu” da hayati önem taşımaya başlıyor.
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ş.
Anlatımı örnekle pekiştirmek gerekirse: Bir kullanıcı deneyimi tasarımcısının, onlarca öncül karar ve onaydan sonra “Anasayfanız bu şekilde olacak.” diye sunduğu görsel çözüm, proje sahibinin “görsel çözüm kütüphanesi”ndeki “tasarım” karşılığıyla eşleşmediğinde, beklentisine de ne yazık ki yanıt verilmemiş oluyor. İşte tam da bu noktada, teknik jargonun her iki taraf için de aynı anlamları ifade etmesi, “Wireframe nedir?”, “Mockup nedir?”, “Prototip nedir?” sorularının yanıtlarının birebir aynı olması, hem zaman hem de motivasyon kaybını engellemenin yegane yolu.
Projenin başlangıç aşamasında, olası beklenti karşılayamama endişelerini gidermenin ve tüm diğer Klingonca zaafiyetlerinden kurtulmanın en kolay yolu, ortak bir Tasarım Taksonomisi ya da UX Sözlüğü üzerinde anlaşmak. Teslimat zamanlaması rahatsız edici seviyede yakın olan projelerde, bu tip ortak bir proje dili belirleme çalışması proje sahiplerince “lüks” görülecektir, bu anlaşılabilir. Lakin bu çalışmanın eksikliğinin, sonradan neden olabileceği katastrofik sonuçlar projenin karar vericilerine doğru şekilde aktarılabilirse, bu çalışmanın pratiğinin projenin başarısında büyük pay sahibi olacağına emin olabilirsiniz.
Beklentiyi karşılamanın çıkış noktası: Çıktıların olması gerektiği gibi yorumlanabilmesini mümkün kılmak
Kullanıcı deneyimi tasarlarken onlarca çıktı sunulduğunun bilincinde olarak, UX çıktıları içinden en yüksek frekansta sunulan bir örnekle savımızı destekleyelim: Wireframe.
Türkçe izdüşümü “tel çizim” olarak tanımlanabilecek wireframe’ler, genelde low-fidelity (yani bağımlı kalma zorunluluğunun düşük olduğu), (renklerle hiyerarşi atamasını yapmamak adına) tercihen gri kutular ve yer tutucu içeriklerle sunulan örnek metinlerle hazırlanmış, stil bağımsız bilgi mimarisi eskizleridir. Bir wireframe çizmekte temel amaç; neyin nerede konumlanacağına, estetik ve stil atamasındaki kaygılara kaynak harcamadan göz atabilmeyi sağlayan bir iterasyon gerçekleştirebilmektir. Başarılı bir wireframe’in aşağıdaki özelliklere sahip olması beklenir:
İçeriği nasıl grupladığını net anlatabilmek
Bilginin yapı taşlarını doğru ve yine net bir şekilde organize edebilmek
En temel kullanıcı etkileşimlerinin (navigasyon gibi) eksiksiz konumlandırmasını yapabilmek
Tanımlama aşamasında iyi bir noktadayız, tamam. Lakin, eğer ki proje sahibiyle projenin başlangıç aşamasında ortak bir Tasarım Taksonomisi çalışması yapmadıysanız, proje sahibinin sizden aşağıdaki gibi bir çıktı beklemesi bir hayli muhtemel. (Bize güvenin, bunu onlarca kez deneyimledik.)
Oysa ki bu bir wireframe değil, mockup. Mockup; ürünün, servisin ya da dijital varlığınıza nasıl bir isim veriyorsanız onun, son kullanıcı tarafından görüntülenecek haline en yakın görünümüyle, sunulacak en temel fonksiyonalitenin (etkileşim senaryolarının) simüle edildiği çözümdür. Mockup tasarlandığında görseller, tipografi ve tasarımınızın estetik kaygısını tanımlayacak unsurları devreye girer. Mockup’a bakıldığında —her ne kadar işlevselliği tam anlamıyla çalışmasa da— “Demek ki işin sonunda böyle bir şey göreceğim.” beklentisinin giderilmesi amaçlanır. Özetle mockup, yüksek profilde hazırlanmış bir görsel tasarım sunumudur.
Wireframe temelleri atar, mockup ise ona bağlı kalarak görsel zenginliğin atamasını gerçekleştirir. Tasarım ve Geliştirme ekiplerinin besleneceği Tasarım Dokümantasyonu wireframe’lerle start verir ve mockup’larla pekiştirilir. Mockup’lar, wireframe’lerden farklı olarak işin görsel estetiğini tanımlar ve tabii ki proje sahibi sunumlarındaki hayal gücü temassızlıkları ile çözümü algılama sorunlarını ortadan kaldırır. Wireframe’lerdeki gri kutulardan çok daha estetik oldukları da aşikardır.
Peki, siz wireframe sunduğunuz sırada proje sahibi mockup beklediği için gelişen beklentinin karşılanamamasından mütevellit krizin yaşanmasını nasıl önleyebilirsiniz? Bu sorunun yanıtı, yukarıdaki anlatım içinde birkaç kez vurgulanmış olsa da tekrar altının çizilmesinde fayda var: Detaylıca hazırlanarak proje sahibiyle paylaşılmış bir Tasarım Taksonomisi, onun verildiği taraf nezdinde anlaşıldığını garanti etmez.
Beklentinin ne olduğu üzerinde el sıkışırken elinizdeki geçmiş örnekleri kullanın
Basit bir çözüm, öyle değil mi? Ama inanın, bu da kolay değil, ancak zaruri bir prosedür. Biz SHERPA’da örneklerin sunumunu mümkün kılabilmek, daha doğrusu bu adımda proje sahibiyle birlikte çalışabilmek adına süreci aşağıdaki gibi yönetiyoruz:
“Size projeniz boyunca sunacağımız çıktılar şunlar {buraya örnekler gelir} ve bu çıktılar projenin gelişiminde şu kararları {çıktının hangi işlevi yerine getireceğine dair anlatım} almamızda fayda sağlayacaktır. Eğer tercihiniz bu çıktılardan {proje sahibinin üretilmesini tercih etmeyeceği çıktılar buraya gelir} çalışmalarının yürütülmesini şart koşmuyorsa, ilgili çıktılar sayesinde gerçekleştireceğimiz takım içi tartışmalar ve o tartışmalar sayesinde alabileceğimiz kararları da pas geçeceğimiz çıkarımında bulunacağız. Bu durum, deneyim tasarımının çok önemli adımlarındaki bazı kararların, projenin deneyim tasarımının üstlenicisi olan bizler tarafından alınacağını ifade etmektedir. Eğer bize böyle bir yetki veriyorsanız, âlâ. Kararları biz alır ve ilerleriz. Yok, ‘O kararları da birlikte alalım’ diyorsanız, üretime geçmeden önce size teslim edeceğimiz tüm çıktıların örnekleri üzerinden birlikte geçmek ister misiniz?”
Altın vuruş
Tüm bu adımları atabildiğinizi ve beklentinin gayet net bir şekilde her iki taraf için de tanımlanmasını mümkün kıldığınızı varsayalım. Üzgünüz, hâlâ üzerinde çalışılması gereken bir detay var: Beklentisini net bir şekilde anladığınız kişinin işi sunacağı (o) diğer kişinin beklentisi (Evet, her proje sahibinin böyle bir rol sahibi de var). “İyi de tüm bu olasılıkları düşünmek zorunda mıyız? Baştan karar vericiler kim olacak tartışmasını yapıp bu engeli ortadan kaldıramaz mıyız?” diye soruyorsanız: Üzgünüz, bu olasılığı dikkate almadan ilerlerseniz, beklenti yönetiminin başka bir bağlamda başarısızlıkla sonuçlanacağını da peşin peşin kabul etmeniz gerekecektir.
Hayatında hiç wireframe görmemiş, onun ne işe yaradığı konusunda hiçbir fikir sahibi olmayan ve daha da kötüsü, “tasarım” denildiğinde aklına “mockup” gelebilecek o kişiyi düşünün, işte altın vuruşu onun için yapacağız.
Altın vuruş için sunulan tüm wireframe’leri anotasyonla destekleyin ve her bir görsel disiplin kararını, kullanılacak metin bloğunun işlevini, wireframe’in (tarayıcıda veya hangi görüntüleyicide sunuluyorsa oradaki) güvenli alanları nasıl kullandığının senaryolarını wireframe’in üzerinde tanımlayın. Eğer zamanınız varsa wireframe’iniz üzerinde, etkileşimli alanların (düşük kaynakla kotarabileceğiniz) animasyonlarına dahi yer verin.
