şu anda oldukça karmaşık bir web portalı geliştiriyoruz. Kullanıcı deneyimini geliştirmek için, kullanıcının sitenin belirli yönlerini anlamasına yardımcı olabilecek içeriğe duyarlı bir çevrimiçi yardım sistemi sunmak istiyoruz.
Bizim durumumuzda, sitenin her türlü tablo verisi, grafik, vb. Görüntüleyen çeşitli widget'ları var. Örneğin, böyle bir widget VIX ve a yardım sistemi, VIX'in ne olduğu hakkında kısa bir açıklama sunar.
Şimdi, internette dolaştım ve Çevrimiçi Yardım için Tasarım Kontrol Listeleri gibi bazı ilginç makaleler buldum, ancak bulduğum şeylerin çoğu oldukça eski görünüyor. Özellikle ilgilendiğim şeyler şu gibi tasarım sorunları:
Bu soruların bazılarının cevapları açık görünebilir, ancak kullanılabilirlik söz konusu olduğunda, sezgisel cevabın her zaman en iyi olmadığı deneyimini yaşadım. İkincisi, ben bir yazılım geliştiricisiyim ve bir şeylere bir mühendisin bakış açısıyla bakma eğilimindeyim. Ve sanırım hepimiz bunun bir kullanıcı arayüzünün tasarımına yaklaşmak için oldukça zayıf bir açı olduğunu biliyoruz. Bu yüzden bu alanda daha deneyimli insanlardan bazı geri bildirimler almak istiyorum.
Dar bir yanıta katkıda bulunacağım, bu yüzden tüm sorunuza cevap vermeyeceğim.
Andrea Ames tarafından birkaç yıl önce UBC'nin şehir kampüsünde yapılan bir mini konferansta rapor edilen araştırma, yerleşik yardım ve kullanılabilirliğin Yardım'dan daha iyi olduğunu gösterdi. Üç farklı Yardım sağlama yöntemini bir hanehalkı finansal yazılımında/yazılımda nasıl karşılaştırdığını anlattı. Kullanıcılar, katıştırılmış yardımı bir Yardım biçimi olarak algılamaz ve onlara yazılım aracılığıyla yönlendiren ve yönlendiren bilgileri kullanmak yerine "yalnızca yazılımı kullandıklarını" bildirir. Kullanıcılar bir sorunla meşgul olduklarında, yapmak istedikleri son şey bağlantıyı kesip başka bir şey başlatmaktır. Birçok kullanıcı için, Yardım'ı başlatmak "başka bir şey" kategorisine uyar; her ne kadar mantıksız olursa olsun. En son duydum, Andrea IBM için çalışıyordu. katıştırılmış yardım Etiketlere ve düğme adlarına değil, doğrudan işlevi yönlendirmek, açıklamak, talimat vermek ve bağlam sağlamak olan bir kullanıcı arabiriminde görünen metne atıfta bulunuyorum.
Lois Hawk, beyinde başgösteren uyaran yanıtı adı verilen istemsiz bir yanıt bildirdi. Görsel alanınızda (kaplan gibi) beklenmedik bir şekilde değiştiğinde, beyniniz aşağıdaki gibi yanıt verir: 1) kısa süreli belleği yıkayın, 2) harekete hazırlanmak için bazı adrenalin salın ve 3) çevrenin görsel olarak yeniden taranmasını sağlayın. Bir pop-up'ın bu istemsiz yanıtı da tetiklediğini ve dolayısıyla kullanıcılarınızın kısa süreli belleğini Yardım açılır pencerelerinizle yıkadığını ve streslerini artırdığını düşünebilirsiniz. deneyimin neden hoşlanmadıklarından emin olacaklar, ama hoşlanmayacaklar. Bu araştırma makalesi 2000 yılında Honolulu'daki STC ortak bölge 7 ve 8 konferansının çalışmalarında yer almaktadır (sanırım o yıl oldu). Bir kopyasını bulmak zor.
İnsanların okumasını sağlamak zor olabilir. Bazen ne istediğini bildiklerini varsayarlar ve yardımı okumayı reddederler. Açık cevap, uygulamanızı hiçbir açıklama gerektirmeyecek kadar basit hale getirmek olacaktır. Ama bu her zaman kolay değil ve uzun zamandır mücadele ettiğim bir şey.
Ancak bağlama özgü yardım açısından, bir metin kutusuna odaklandığınızda yardımın görünmesini sağlamayı seçtim. Örneğin, aşağıdaki turuncu kutu yalnızca Posta kodu metin kutusu odaklandığında görünür ...
Bu şekilde, kullanıcının yardımın görünmesi için bir simgeyi tıklaması gerekmez. Uygulamayı doldururken doğal olarak görünecek.
Bu elbette her şey için işe yaramıyor. Radyo düğmeleri veya onay kutuları için çalışmaz, böylece bunlar için kendi mekanizmanızı icat etmeniz gerekir. Küçük
i bilgi simgeleri bir sorunun yanında iyi çalışır.
Diğer sorularınıza cevap vermeye çalışacağım ...
pop-up'lar, div'ler veya harici sayfalara bağlantı kullanıp kullanmayacağınız (veya ne zaman)
Kimse pop-up'ları sevmiyor. Mümkünse her alanın yanında yukarıda gösterildiği gibi yardımın görülebileceği boş bir yer bulmaya çalışın. Bu şekilde hiçbir şeyi örtmez. Her şeyi (yardımınız dahil) mümkün olduğunca kısa tutun.
yardım girişi istek üzerine AJAX (biraz berbat, bilgiyi hemen istiyorsunuz) veya önyükleme (tonlarca gereksiz trafiğe neden olan) ile yüklenirse
Buradaki seçeneklerinizi, ne kadar yardım metni kullandığınıza bağlı olarak tartmanız gerekir. Yine de gzip sıkıştırmasını kullanıyorsanız, hepsini HTML'de tutmak büyük bir sorun olmayabilir.
Temel ipuçları veren araç ipuçlarının kısaltması veya her zaman görülebilen alanları çağırıyorum ve daha gelişmiş bağlamsal yardıma bağlandım. Araç ipuçları soru işaretleri veya benzerleri üzerinde olma eğilimindedir, ancak lotlara ihtiyaç duyulursa, bu amaç için başlangıç tasarımında olan basit bir çağrı alanı kullanın.
Araç ipucu veya çağrı, doğru yardım öğesine gitmek için bir kimlik kullanır. Yeni bir pencere/sekme/pop-up/div açmıyorum, ancak gelişmiş yardım istiyorlarsa, onları geri döndürmek için ekran kimliğini ve araç ipucu/ek bilgi kimliğini kullanan belirgin bir bağlantı GERİ ile bu sayfaya götürüyorum formları doldurmak için doğru nokta.
Gelişmiş yardım olduğundan, yine de ilgili öğelere ve tam yardım navigasyonuna bağlantıların bulunduğu "RoboHelp" yardım stiline geri dönme eğilimindeyim. Üzerinde çalıştığım uygulamaların çoğu farklı düzeylerde erişim/kullanıcı türleri/rol öznitelikleriyle doğrulandığından, hangi bilgilerin görüntüleneceğine karar vermek için yardımda gezilebilecekler Kullanıcılar simgesine bakar.
Umarım bunlardan bazıları yararlı olur.
Uygulamanız belirli bir konuya odaklandığında ve kısaltmalar/garip terimlerle dolu olduğunda, kullanıcılar bunun odaklanmış bir uygulama olduğunu (öğrenirlerse onlara biraz üretkenlik kazandırabilir) bilecek ve bir öğrenme deneyimine katılmak isteyecektir. Sorun şu ki, bu istek sadece birinci-üçüncü karşılaşma için.
İlk kullanım için kullanıcıya rehberli bir eğitim isteyip istemediğini sorabilirsiniz. Vurgulanan öğeleri sunan adımlarla bunu bir sihirbaz gibi yapabilir veya kullanıcının neyi tıkladığını/odaklandığını dinleyebilir ve mevcut öğe için yardım sağlayabilirsiniz. IMO bu bir öğretici oyun deneyimi gibidir, kontrolleri öğrenirsiniz, amacı elde edersiniz. Kullanıcı bu öğreticiden istediği zaman çıkabilmeli, isterse geri dönebilmeli ve öğretici davetiyesini tekrar görüp görmeyeceğini kontrol etmelidir. Bu deneyim yeni başlayan bir kullanıcı için sağlanmalıdır.
Orta/ileri düzey kullanıcılar için kısaltmaların ve başlık/araç ipucu öğelerinin yeterli olduğunu düşünüyorum (yani açık bir IA ve sezgisel/tutarlı öğeleriniz varsa). Araç ipuçları kullanıcının yolunda gitmez, ancak kullanıcının can sıkıcı olmadan yardıma ihtiyacı vardır. Oldukça ayrık ama yine de gözlemlenebilir olmalıdır.
Bu, canlı sohbetin çevrimiçi yardım için bir araç olarak kullanılması için bir bağlantıdır, umarım bu yardımcı olur https://www.experienceux.co.uk/ux-blog/2017/05/30/6-steps Projede öngörülen teslim-birinci sınıf-canlı-sohbet-kullanıcı deneyimi /
Gönderinin özeti:
Canlı Sohbet harekete geçirici mesajını kolayca görünür/erişilebilir hale getirin (ör. Web sitesinin sağ alt alanı).
Sayfa içeriğinin geri kalanından sonra yükleyerek harekete geçirme ifadesine daha fazla dikkat çekin (örneğin birkaç saniye sonra).
Kişinin adını ve fotoğrafını göstererek "Bu gerçek bir insan mı?" Engelinin üstesinden gelmeye yardımcı olun.
Sohbet penceresini tarayıcı penceresine yerinde yükleyerek ve kullanıcıların pencereyi simge durumuna küçültmesine izin vererek kullanıcıların paralel olarak göz atmalarını kolaylaştırın.
Facebook Messenger ve WhatsApp gibi tanıdık mesajlaşma servislerinin tasarım modellerini takip ederek kullanıcıların yeni şeyler öğrenme ihtiyacını azaltın.
Yeni mesaj bildirimi gösterirken web sohbet penceresinin simge durumuna küçültülmesine izin verin.