Bir UI Tasarım Eleştirisi Nasıl Çalıştırılır

Eleştiri kolaydır. Görünüşe göre herkesin bir fikri var, ancak yazar Harlan Ellison'ın belirttiği gibi, “Fikrinize hakkınız yok. Bilgilendirilmiş görüşünüze hakkınız var.” Ancak bilgi sahibi olmak keşif gerektirir. Tasarım eleştirileri, herhangi bir ürün araştırmasının önemli bir parçasıdır.

Yaratıcının ekibin geri kalanı ve/veya müşteri ile tasarımı tartıştığı ve açıkladığı bir tasarım eleştirisi, tasarımcıyı üzmek veya verdikleri her kararı haklı çıkarmaya zorlamakla ilgili değildir. Bu sadece eleştiri. İyi bir tasarım eleştirisi, tasarımı keşfetmek, nerede çalıştığını ve nerede geliştirilebileceğini bulmak içindir . İyi yapılırsa, tasarım eleştirileri ekipteki herkesin duyulmuş gibi hissetmesine ve müşterilerin değerli geri bildirimde bulunmasına izin verir.

SmashingMag'de Daha Fazla Okuma :

• Web Tasarım Eleştirisi: Nasıl Yapılır
• Korkularınızla Yüzleşmek: İnsanlara Araştırma İçin Yaklaşmak
• Tasarım Eleştirisine Etkili Bir Şekilde Nasıl Cevap Verilir?
• Rainbow Elektronik Tablosu: İşbirliğine Dayalı Bir Yalın UX Araştırma Aracı

Eleştiriyi yürüten kişi sizseniz, özellikle tasarım eleştirisi formatı konusunda deneyimi olmayan gruplarda, yapıcı eleştiriye ulaşmak genellikle zor bir iştir. Çevik bir ortamda, geri bildirim vermek için genellikle kodlayıcılar, proje yöneticileri, ürün yöneticileri ve diğer disiplinlerden kişiler bulunur ve herhangi bir yere hızlı bir şekilde ulaşmak istiyorsanız, onları beklentileri hızla nasıl hızlandıracağınızı bilmeniz gerekir. .

Harika Bir UI Eleştirisini Çalıştırmanın İlkeleri

Kendi deneyimlerime göre, kullanıcı arayüzleri (UI'ler) için tasarım eleştirilerinin tüm ürün tasarımı ve geliştirme süreci boyunca, en az haftalık ve hatta belirli zamanlarda muhtemelen günlük olarak yapılması gerektiğini buldum. Ürün tasarımını yolunda tutarlar ve tasarımların dağıtımdan önce birden çok yinelemeden geçtiği etkileşimli çevik veya yalın UX ürün ortamında daha da kritik hale gelirler. Bir UI tasarım eleştirisi yürütmek, yalnızca kararları açıklamanızı değil, aynı zamanda diğer fikirleri de dikkatle dinlemenizi gerektiren bir zorluktur.

Her eleştirinin başında “kurallar” değil, net ilkeler belirlemek zorunludur. Dogmatik ve kısıtlayıcı olan kuralların aksine, ilkeler herkesin beklentileri anlamasına yardımcı olur, ancak yine de ihtiyaç duyulan serbest biçimli tartışmaya izin verir.

Bu beklentilerin başında, baktığınız şeyi neden eleştirdiğiniz konusunda herkesin hemfikir olmasıdır. Jason Ulaszek şunları tavsiye ediyor:

Eleştirdiğiniz tasarımın arkasındaki amacı veya niyeti sorarak başlayın. Bu bilgiyi neden istiyoruz? Bunu istememize izin veren hangi beklentiler belirlendi? Onunla ne yapacağız? Bu soruları cevaplayabilirsek, o zaman öğeye olan ihtiyacı ve her bir seçenekle ilgili avantaj ve dezavantajları yorumlamak için çeşitli seçenekleri tartışmaya devam ederiz.

Bu yönergeye bağlı kalmanıza yardımcı olmak için, kullanıcı arayüzü tasarımı içerip içermediğine bakılmaksızın herhangi bir tasarım eleştirisine uygulayabileceğiniz standart ilkeleri izlemenizi öneririm:

• Saygı göster. . Klişe gelebilir, ancak eleştirideki herkes masadaki diğerlerinin görüş ve becerilerine saygılı değilse, eleştiri hızla düşmanlığa dönüşecektir.
• Rolleri belirleyin. . Başlamadan önce, eleştiri sırasında kimin hangi rolü/rolleri üstleneceğini netleştirin. Bunları kimsenin dışlanmış hissetmemesi için eleştiriden eleştiriye karıştırmak en iyisidir ve üç başrolün farklı insanlar olması en uygunudur (ancak bu her zaman pratik değildir).
  • sunucu Bu, tasarımı ve arkasındaki düşünceyi sunmaktan sorumlu kişidir. Bu kişi tüm soruları yanıtlar veya eleştiride cevap verebilecek diğer kişilere yönlendirir.
  • moderatör Mümkünse, bu rolün tasarımdan doğrudan sorumlu olmayan biri tarafından, genellikle proje veya ürün yöneticisi tarafından yerine getirilmesi en iyisidir. Moderatör, herkesin konuyla ilgili kalmasını ve herkesin dinlenmesini sağlar.
  • Not tutan . Bu kişi, tartışılanları kaydetmeye odaklanır ve eleştirinin sonunda çıkarımların (başka bir ilke, aşağıda listelenmiştir) açıkça tanımlandığından emin olmak için özellikle hayati önem taşır. Not alıcı, rolü ekibin diğer üyelerinin söylediklerini netleştirmeye yönelik olmasına rağmen, tartışmanın dışında bırakılmamalıdır.
• Proje ve eleştiri için hedefleri önceden belirtin. . Herkese projenin hedeflerini ve bu özel eleştirinin neleri kapsayacağını çabucak hatırlatın. Kapsamın tartışmanın birincil amacını rayından çıkaracak diğer hususlara kaymasına izin vermek yerine, eleştiriyi eldeki göreve odaklayın.
• İzleyicileri gözden geçirin. . Eleştirideki kişilerin ürünün hedef kitlesi olmadığını pekiştirmek için herkese kim olduğunu hatırlatın.
• “Cevaplar” bulmaktan kaçının. Katılımcılar sorunları çözmek için güçlü bir istek duyacaklar ve bir eleştiride “cevap” bulacaklar. Ancak, en iyi çözümler nadiren gerçek toplantıda ortaya çıkar. Bir eleştirinin amacı, sorunları araştırmak ve tasarımcının alıp düşünmesi için birden fazla olası çözümü tartışmaktır.
• Paket servisler üzerinde anlaşın. . Eleştiride her şey söylendikten sonra, not tutan kişinin bir sonraki eleştiri için herkesin aynı sayfada olmasını sağlamak için katılan herkes için paket servis görevlerini gözden geçirmesi gerekir.

Ne yazık ki, çoğu zaman, UI tasarım eleştirileri ağırlıklı olarak görsele odaklanır ve tasarımın etkileşimli, çok daha az zamansal doğasına yeterince odaklanmaz. Bir UI tasarım eleştirisi için aşağıdaki öğeleri ekleyin:

• Sunum ortamını tanımlayın. . Hedef kitleyi belirlemenin yanı sıra, ürünü oluşturmak için kullanılan platformu ve teknolojileri gözden geçirin. Bu bir iPhone uygulaması mı? Bir internet sitesi? AngularJS kullanıyor musunuz? C#? İşe yaramayacak çözümler önermekten kaçınmak için bunların hepsinin dikkate alındığından emin olun.
• Süreç akışını ana hatlarıyla belirtin. . Yol haritasını bilmeniz gerekiyor. UI tasarımı için, kullanıcının deneyimi için süreç akışı bu olacaktır. Bu, storyboard'lar, yolculuk haritaları veya süreci tanımlamanın diğer yolları biçiminde olabilir, ancak kullanıcı arayüzünü düşünmeden önce herkesin buna aşina olması gerekir.
• Ürünü demo yapın, ancak anlatmaktan fazlasını gösterin. . Bunu yeterince vurgulayamam: Harika bir kullanıcı deneyimi anlatmaktan çok daha fazlasını gösterir. Son kullanıcının, ürünün minimum açıklama ile tam olarak nasıl çalıştığını bilmesi gerekecektir. Demonuz ayrıca mümkün olduğunca az açıklama gerektirmelidir. Söylendiği gibi, iyi bir kullanıcı arayüzü şaka gibidir: Açıklamanız gerekiyorsa, pek iyi değil.

Doğru Soruları Sormak

Çok sayıda soru ve ifade, bir tasarım eleştirisinde güçlü işbirliğine karşı çalışır. İşte, ekibinize önerebileceğiniz, mücadeleci yerine işbirlikçi bir şekilde tasarımları keşfetmek için açık diyalog bulduğum birkaç soru.

“Bu Çözümü Nasıl Buldunuz?”

Herhangi bir eleştiriye veya sohbete başlamak için harika bir yer, tasarımcıya bir şeyi neden değil, nasıl yaptıklarını sormaktır. Neden diye sormak onları hemen savunmaya geçirirken, nasıl olduğunu sormak, gerekçeye ihtiyaç duymadan kavramın kökenini keşfetmeye davet ediyor.

"Neden" soruları, bizi bir şeyin "doğru" olduğunu kanıtlamaya, onu bir olasılık olarak açıklamak yerine, onu kanıtlamaya iter. Aaron Morton'a göre:

“Neden” bir hikayeyi ortaya çıkarır, bir şeyin neden doğru olduğuna dair açıklamalar. Neden hiçbir şeyin istediğiniz gibi gitmediğini sorarsanız, muhtemelen doğru olabilecek veya olmayabilecek bir hikaye yaratacaksınız. Bu, kendinizi kötü hissetmeniz için tehlikeli bir bölgedir.

“Neden” diye sormak yerine, varoluşun bir savunması yerine yaratılış süreci hakkında bir hikaye ortaya çıkarmak için “nasıl” soruları sormayı düşünün. Oradan, tasarımcının daha önce hangi olasılıkları düşündüğünü sorabilir ve ancak o zaman düşünmemiş olabilecekleri alternatifleri keşfedebilirsiniz. Ancak önerilerde bulunmadan önce tasarımcının daha önce denediklerini dikkatlice dinleyin . Bir şeyi gözden kaçırmış olabilirler, ancak bunu varsayarak sohbete girmeyin.

"Bunu Böyle Yapma Fikrine Nereden Ulaştınız?"

Thomas Edison'un ünlü sözü, "Deha yüzde bir ilham ve yüzde doksan dokuz terdir." Ama Nikola Tesla'dan büyük oranda yüzde birini çaldı. Sonra tekrar Picasso, “İyi sanatçılar ödünç alır, büyük sanatçılar çalar” dedi (ama muhtemelen bu satırı çaldı).

Pixar Animation başkanı Ed Catmull'un Creativity, Inc adlı kitabının ana fikirlerinden biri, harika bir ekibe sahip olmanın harika bir fikre sahip olmaktan daha önemli olduğudur:

Doğru insanları ve doğru kimyayı bulmak, doğru fikri bulmaktan daha önemlidir.

Fikirleri nadiren bir boşlukta düşünürüz ve ilhamımızı nereden aldığımızı düşünmek kendi inovasyonumuzu zorlayabilir. Daha da iyisi, ilhamlarımızı bir ekip ortamında bir araya getirmek yeni fikirlerin ortaya çıkmasına neden olabilir.

Bir uyarı: Suçlayıcı veya küçümseyici konuşmamaya dikkat edin - yani fikri çaldıklarını ima ederek. Yine de, tasarımcının, inovasyonu ezmeden, fikirlerinin motivasyonları ve nereden geldikleri konusunda kendi anlayışlarını zorlamasını istiyorsunuz.

“Bunun Ne Zaman Olması Gerekiyor?”

Tıpkı komedide olduğu gibi, zamansal tasarımda zamanlama her şeydir ve olayların doğru zamanda ve doğru sırada gerçekleşmesi gerekir. Yine de tasarlarken, oturup açıklamamız gerekene kadar bu düzen her zaman açık değildir.

Harika bir kullanıcı arayüzü harika bir hikaye gibidir ve bu, onu dikkatli bir şekilde hızlandırmanız gerektiği anlamına gelir. Bir formu kullanmaya başlamak için ne kadar bilgi yeterlidir? Verileri, kullanıcının anlaması için doğru bağlamda mı görüntülüyorsunuz? Sonucu açıklamak için doğru an bu mu?

Kâr amacı gütmeyen kuruluşların haberler aracılığıyla insanlarla bağlantı kurmasına yardımcı olan bir girişim olan Public Good'un CEO'su Jason Kunesh bana şunları söylüyor:

Müşterilerimiz için, doğru anda harika bir etkileşim, ürün veya hizmetin mutlu bir hayranı ile kaybedilen bir bağlantı fırsatı arasındaki farktır. Sıradan bir etkileşimi kalıcı bir ilişkiye dönüştürmek, bir dizi küçük, olumlu etkileşime ve insanlar hazır olduğunda gelen mesajlara bağlıdır.

Eleştiri sürecinin bir parçası, her fırsatta bir eylem gerçekleştirmek, soru sormak veya veri sunmak için doğru an olup olmadığını sorarak arayüzün zamanlamasındaki kırışıklıkları gidermek olmalıdır.

“Görsel İpuçları Eklemek İçin Hareketi Kullanabilir miyiz?”

Bu soru, UI tasarımına yıllardır hakim olan statik doğaya alışmış birçok tasarımcıyı şaşırtacak. Ancak hareket, animasyon ve geçişler deneyim tasarımında norm haline geliyor. Yakında bir tasarımda hareket, renk kadar önemli hale gelecek.

UI animasyon uzmanı Rachel Neighbours'a göre:

Düz tasarımın yükselişi ve beraberinde gelen UX tökezlemeleriyle, bir sitenin bileşenlerinden görsel ipuçlarını çıkarmanın ne kadar tehlikeli olabileceğini gördük. Animasyon ters etki için kullanılabilir.

Hareket veya değişiklik, opaklık veya renkteki bir değişiklik veya sayfa boyunca uzanan bir maymun kolu veya kullanıcı bir görevi tamamlarken yükselen bir güneş kadar basit olabilir. Bir UI tasarımına an be an hareket ekleme hakkında soru sormak, genellikle tasarımcıyı bakış açısını iyi yönde değiştirmeye zorlar. Tasarımcıyı ayrık anın ötesinde düşünmeye ve tasarımı sadece uzayda değil, zamanda tartışmaya zorlayın.

“Nasıl Basitleştirebiliriz?”

Sadelik zordur. Eklemek, almaktan her zaman daha kolay gibi görünüyor ve birçok kullanıcı arayüzü, “kar fırtınasında kar tanesi” olarak adlandırdığım şeyden muzdarip: Elbette, her kar tanesi benzersizdir, ancak bunu bir kar fırtınasında asla fark etmeyeceksiniz. UI tasarımında, bağlantılarla, düğmelerle, kontrollerle ve resimlerle dolu arayüzleri çok sık görüyoruz. Müşteriler genellikle, gerçekten ihtiyacınız olan hiçbir şeyi bulamayacağınız noktaya kadar, izleyicinin ihtiyaç duyabileceği her şeyi dahil etmeleri gerektiğini düşüneceklerdir.

Basitlik sorusunu Don't Make Me Think'in yazarı Steve Krug'a yönelttim:

Bence çok faydalı bir soru. Herkesin şimdiye kadar emdiği bir ders olduğunu düşünürdüm, ama anlamadıklarını biliyorum. Sayfada veya ekranda çözümün bir parçası olmayan her şeyin - kullanıcının gerçek hedefleri için - gürültü olduğunu ve denize atılmaya aday olduğunu her zaman söylemek isterim.

Bir tasarımın her adımında kendimize şunu sormalıyız: Daha az düşünme gerektiren ama aynı gücü koruyan bir şeyi nasıl yaratabiliriz? Bir eleştiride, bu en iyi şekilde bir şeyin nasıl daha basit hale getirileceğini sorarak ifade edilir. Tasarımda netliği korumak önemlidir , ancak bunu daha az tıklama, daha az metin ve çok fazla form alanı ile yapmamak önemlidir. İşi halletmek için gereken minimum seviyeye inin ve kullanıcılarınız size teşekkür etsin.

"Sonra ne olur?"

Harika bir tasarım eleştirisi, harika bir röportajla pek çok ortak noktaya sahiptir: Her ikisi de keşifle ilgilidir. En büyük röportajcılardan biri olan Studs Terkel şunları söyledi:

[Röportaj] bir engizisyon değildir; Bu bir keşif, genellikle geçmişe yapılan bir keşif. Bu yüzden en nazik sorunun en iyisi olduğunu düşünüyorum ve en nazik soru, "Peki sonra ne oldu?"

Bunu bir UI tasarımına uygulayarak, her zaman tasarımcıdan sonra ne olacağını düşünmesini istememiz gerekir. Bu soru onları son olarak düşündükleri şeyin ötesinde düşünmeye davet ediyor. Kullanıcıların her zaman bir sonraki gidecekleri bir yeri olmalıdır.

Herhangi bir kullanıcı arayüzünü tasarlamanın en büyük zorluklarından biri, yalnızca kullanıcının kullanmasını istediğimiz "mutlu yol"u değil, tüm olası yolları göz önünde bulundurmaktır. Bir düğmeye tıkladıktan sonra ne olur? Bir hata olursa ne olur? Bir form gönderdikten sonra ne olur? Her olası senaryoyu değerlendirene kadar sonra ne olacağını sorun, aksi takdirde kullanıcıyı askıda bırakma riskiyle karşı karşıya kalırsınız, bu her zaman kötü bir deneyimdir.

Sadece Cevaplamak İçin Soru Sormayın

Bu soruları - veya bu konuda başkalarını - sorarken, kendinize cevap verebilmek için sormayın. Birisi size cevabınızı duymak veya düşüncenizi anlamak için değil, sadece kendi sesini duymak için bir soru sorduğunda can sıkıcıdır.

Eğer o insanlardan biriyseniz, hemen kesin. Tüm sorularınızı verilen cevaplara karşı zihniniz sonuna kadar açık olarak sorun. Ardından, yanıtlarınızı duymak istediğiniz yanıtlara değil, bu yanıtlara göre oluşturun.

İyi Bir Kullanıcı Arayüzü Eleştirisi Nasıl Görünür?

Eleştiriler, katılımcıların becerilerine, amaçlarına ve sorumluluklarına bağlı olarak büyük ölçüde değişecektir. Bununla birlikte, iyi bir eleştiri her zaman ürünün belirli yönlerine odaklanır ve sunulan çözümü derinlemesine araştırır.

Bir UI eleştirisi, yalnızca ürünün o anda nasıl göründüğüne değil, zaman içinde nasıl çalıştığına ve bunun kullanıcının ihtiyaçlarına en iyi şekilde uyup uymadığına odaklanır. Kullanıcının ihtiyaçlarını düşünmek yerine, katılımcılar genellikle bir şeyin neden bekledikleri gibi yapılmadığını merak edeceklerdir. UX for Good'dan Jason Ulaszek de aynı fikirde ve bana kendi eleştirilerini anlatıyor:

Tartışmamızda nesnel kalmak ve tasarımı kullanmakla görevlendirilen bireyin zihinsel modelini [yani kullanıcıyı] dikkate almak, çözümü nasıl tartışacağımız konusunda kritik öneme sahiptir.

Her zaman aklınızda bulundurun - son filmin bir saniyesinin üretilmesinin haftalar veya aylar alabileceği hücre tabanlı animasyon gibi - arayüzde bir dakikalık ayrıntı için saatler harcayabilirken, muhtemelen sadece bir anlık görüntü olacaktır. kullanıcının radarı.

Steve Krug'a bunu sorduğumda şunları söyledi:

Kullanıcının gerçekliği “saatte 60 mil hızla giden reklam panosuna” çok daha yakınken, “harika literatür” (veya en azından “ürün broşürü”) düşünüyoruz. Kullanıcı arabirimi tasarımcılarının, geliştirmek için çok çalıştıkları arabirimi ne kadar hızlı yakınlaştırdıklarını - veya geçmişlerini - ve gerçekte ne kadar azını aldıklarını fark etmeleri inanılmaz derecede zor.

İyi bir kullanıcı arabirimi eleştirisi, her öğeyi dikkate almak için yavaşlar, ancak kullanıcının tasarımı bu şekilde görmeyeceğinin farkındadır. Eleştirinizdeki katılımcılar doğrudan renk, tipografi veya deneyim tasarımı hakkında konuşmak için resmi bir eğitime sahip değillerse, yine de tüm UI tasarımlarında şu önemli faktörleri göz önünde bulundurabilirler:

• tutarlılık Tasarım ve uygulaması ürün genelinde tutarlı mı? Bu, arayüzde birden fazla kullanılan renk, tipografi, kontroller, görüntüler ve herhangi bir tasarım öğesini (statik veya etkileşimli) içerir.
• Bağlam . Ürünü kullanırken kullanıcının bağlamına sürekli olarak saygı duydunuz mu? Bu soruyu sürekli olarak sormak çok önemlidir, çünkü muhtemelen bu bağlamda değilsiniz, ancak tasarlarken veya test ederken yalnızca simülasyonu gerçekleştiriyorsunuz.
• ses . Marka ve tasarımın net, tutarlı ve tanınabilir bir sesi var mı?
• geçişler Kullanıcı arayüzünde herhangi bir önemli değişiklik için durumdan duruma geçişler kullanıyor musunuz? Modern tasarımlar görselden çok daha fazlasıdır. Kullanıcının etkileşimi sırasında tüm arayüz öğelerinin nasıl hareket ettiğini ve değiştiğini düşünün.
• sadelik Tasarım, işi halletmek için olabildiğince basit mi?

Düşmanca Eleştirilerden Kaçınmak

Eleştiriler, ekip üyelerinin, her ne sebeple olursa olsun, işin yaratılmasına giden düşünce sürecini dinlemeden işi eleştirmeye meyilli olduğu, kavgacı bir şekilde yapılabilir ve çoğu zaman yapılır. Kullanıcıyı düşünmek yerine tasarıma kendi önyargılarını getiriyorlar ve genellikle ne kadar akıllı olduklarını göstermeye çalışıyorlar.

Bir eleştirinin aşırı agresifleştiğini her zaman anlayabilirsiniz: Tasarımcı, kararlarına nasıl ulaştığını açıklamak ve alternatifleri tartışmak yerine kararları konusunda inatçı olmaya meyillidir. Agresif eleştirilerden kaçınmanın anahtarı, net ilkeler belirlemek ve açık uçlu, yapıcı sorular sormaktır. Fikir, bir tasarım savaşını kazanmak değil, tasarımı işbirliği içinde güçlendirmektir .

Agresif eleştirileri yararsız ve genellikle zararlı buluyorum. Antagonistik eleştiriler, tasarımcıyı savunmacı bir duruşa zorlayarak, onları genişletmek için güçlendirmek yerine yaptıkları şeye yerleştirir. Tasarım - çok büyük ölçüde - sezgiseldir ve her zaman kolayca nitelenemez, çok daha az ölçülebilir.

Ancak bu, eleştirinin yalnızca tasarımcının görüşüyle ​​ilgili olduğu anlamına gelmez; tasarımcının yıllar süren çalışmalar sonucunda edindiği bilgili fikirlerle ilgilidir. Agentic'ten web yapımcısı Phillip Djwa, anahtarın…

… tecrübelerime dayanarak konuşun ve genellemeye çalışmayın. Örneğin, "Açılış afişinin marka hakkında yeterince iletişim kurup kurmadığını merak ediyorum?" "Vay canına, insanlar hangi marka değerine sahip olduğumuzu asla anlamayacaklar" yerine.

Son Söz: Eleştiri Kullanılabilirlik Testi Değildir

Kişileri veya kendi önyargılarınızı kullanarak dinleyiciler adına konuştuğunuzu düşünerek kendinizi kandırmak kolaydır. Ne kadar çok kişi yaratırsanız ya da eleştirirseniz eleştirirsiniz , hedef kitleniz değilsiniz . Steve Krug bana şunları söylüyor:

Bu, her tasarımcının, insanların ürettiklerini kullanmaya çalıştıklarını (yani kullanılabilirlik testleri) izleyerek zaman harcaması gerektiğini düşünmemin bir nedenidir.

Bir lazer seviyesinin baloncuk seviyesine karşı olduğu gibi, kullanılabilirlik testi dahili eleştirilerden daha kesin ve doğrudur, ancak aynı zamanda genellikle daha fazla zaman alıcı ve pahalıdır. Düzenli tasarım eleştirileri, bir projeyi hedefte tutmak için paha biçilmezdir, ancak asla sahaya çıkmanın ve gerçek hayattaki kullanıcılarla test etmenin yerini alamaz. Aksi takdirde, yaptığınız tek şey kendi kendinize konuşmaktır.