UX Borçlarını Tanıma ve Yönetme

Kullanıcı deneyimi borç kaçınılmaz olarak zamanla olur. Bu toplamı gecikmiş tasarım ve kullanılabilirlik görevleri hızlı iş kararları, tasarım kısayolları, kaçırılmış fırsatlar, zaman kısıtlamaları ve diğer faktörler gibi şeylerden elde edilir..

Kullanıcı deneyimi borçlarına, gerçek hayattaki borçlara benzer bir borç denir; şimdiki zamanda bir şey buluruz, ama sadece gelecekte bunun için ödemek. Borç ödenene kadar, faiz oranları kalıcı bir maliyet olarak ortaya çıkmak.

Kullanıcı deneyimi borç - yakın kuzeni ile birlikte, teknik borç - bir dizayn bir projenin kalitesini düşüren antipattern. Kullanıcı deneyimi borçları daha az tartışılan bir konu olduğundan, onu tanımak her zaman kolay olmasının yanı sıra, bu makalede daha yakından inceliyoruz.

UX Borç vs Teknik Borç

Web geliştirmede farklı borç türleri vardır. En iyi bilinen teknik borç CSS Tricks tarafından tanımlanmıştır. "toplamı uzlaşma Geliştirme sürecinde kod yazarken yapıyoruz ".

Daha sonra iş akışımızda, bununla başa çıkmamız gerekecek bu uzlaşmaların sonuçları, Bu, gelecekte ek iş anlamına gelir.

Teknik borç kesin hatalarla ilgili değildir, ancak en iyi kodlama uygulamalarında bile bir kodun geleceğe yönelik olarak tamamen imkansız hale getirilmesi imkansızdır, ancak verimli kod optimizasyonu kesinlikle yardımcı olabilir.

Antipatterns, kodlama kısayolları, etkisiz mimari veya yönetilmesi zor bağımlılıklar kullanmak, teknik borca ​​katkıda bulunabilir, ancak asıl konu, optimal, varsayımsal bir ideal senaryoda bile, bundan kaçınmanın imkansız olmasıdır - gelecekteki uyumsuzluklar, ihtiyaçlar ve sorunlar gibi Tahmin edilemez. Bu nedenle bir süre sonra refactoring önerilir..

Kullanıcı deneyimi borcu, şu anlamda olduğu gibi teknik borca ​​benzer:

• kaçınılması mümkün değil (azaltılabilir)
• tanımak zor
• bir projenin başarısını tehlikeye atabilir.

Kullanıcı deneyimi borcu, daha geniş bir kategoridir kullanılabilirlik borcu, Sadece bir web sitesinin veya uygulamanın ne kadar kullanışlı olduğu ile ilgili değil kullanıcıların ürününüzü deneyimleme şekli - eğlenceli, yararlı bir ödüllendirme veya hedef kitlenizde ne tür bir duygu uyandırmak istediğinizi bulup bulmadıkları.

Kullanımı zor bir site, kullanıcıların kendilerini rahat hissetmelerini sağlamayacağından, kullanıcı deneyimi de kullanılabilirliği kapsar ve aynı şekilde UX borçları da kullanılabilirlik borçlarını kapsar..

Maalesef, kullanılabilirlik borcu ve kullanıcı deneyimi borcu hakkında pek çok çevrimiçi kaynak yok, ancak burada yararlı bulduğum bazı konular var ve bu konudaki görüşlerimi oluşturmama yardımcı oldular:

• Catriona Cornett, SalesforceIQ de Ürün Tasarım Direktörü kullanılabilirlik borçlarının etkin bir şekilde ele alınması (burayı oku)
• TryMyUI en blogda UX borç krizinden nasıl kaçınılır (burayı oku)
• Kullanıcı Deneyimi Profesyonelleri Derneği UX borcuna yaklaşımı üzerine bir öneri ile hacmi nasıl hesaplanır (burayı oku)
• Andrew Wright'ın UX borçlarının açıklanması ve sınıflandırılması nForm Blog'da (burada okuyun)

UX borcunda bulabildiğim tüm olası çizimler arasında, bu, özünde kesin bir özveri gösterdiğini düşündüğümden beri, en iyi seçimdir..

Kullanıcı deneyimi borcu olarak tanımlanabilir Mevcut deneyiminizin kalitesi ile optimum ürün arasındaki fark.

UX borcu teknik borçtan daha öznel, elde etmek istediğiniz kaliteye karar veren siz (veya müşteriniz) olduğu gibi. Örneğin, hedefleri "fonksiyonel" uygulanabilir minimum bir ürün için seviye belirleyebilir, ancak yüksek (ancak genellikle pahalı) standartlar da hedefleme "Keyifli" premium ürün seviyesi - hepsi hedeflerinize bağlı.

Teknik borç, çoğu durumda kötü yönetilen kod açısından anlamlıdır sadece çalışmayı durdurur. UX borcu var bu kadar sert değişiklik yok, Oysa bu sadece bir perk değil, aynı zamanda bir tehdit bu tür borcu ihmal etmeyi kolaylaştırır.

UX Borç Nasıl Tanınır?

UX borcunu yönetmek için öncelikle onu tanımamız gerekir. Kasıtlı ve kasıtsız olmak üzere iki tür UX borcu vardır..

1. Kasıtlı UX borcu olduğu bilinçli kararlarımızın sonucu Biz ne zaman para, zaman, eğitim eksikliği, veya diğer kaynaklar, ya da biz dış kuralları takip etmek zorunda. Aceleye uğramış işin ortasında kaybettiğimiz iyi fikirler, kasıtlı UX borcuna da katkıda bulunuyor.
2. Bu kasıtlı UX borcunu görmek kolaydır herhangi bir zamanda oluşabilir bir ürünün kullanım ömrü boyunca.
3. Kasıtsız UX borcu kullanıcılarımız hakkında yaptığımız yanlış varsayımlardan kaynaklanmaktadır.. Çoğu zaman, kullanıcılarımızın ne istediğini, nasıl kullandıklarını veya kullanabileceklerini bildiğimizi düşünme eğiliminde değiliz ve bu sitenin tamamını (uygulama, ürün vb.) İnşa ediyoruz. varsayılan bilgi.
4. 'De kasıtsız UX borcunun büyük bir kısmı Ürün yaşam döngüsünün başlangıcı, ve o doğal olarak zamanla artar. Kasıtsız UX borcu, ihtiyacımız olduğu gibi yakalamak için çok daha zor varsayımlarımızı haklı çıkarma ihtiyacımızdan kurtulun.

Peki UX borcu gerçek hayatta nasıl görünüyor? Kullanıcılar, zayıf kullanıcı deneyimi nedeniyle sitemizi kullanmak istemediklerinde veya kullanamadıklarında. Onlar sadece nişanlanma; Biz dikkatlerini ve ilgilerini çekemiyorlar.

UX borcunun tezahürü siteden siteye değişir, ancak azalan dönüşüm oranı veya bir hemen çıkma oranının artması Çoğu durumda, çok miktarda UX borcu biriktiğimizi düşünebiliriz..

UX Borç Yönetme

Orada evrensel tarif yok UX borçlarını etkin bir şekilde yönetmek, çünkü birçok şey öznel özelliklere bağlı, ancak başkalarının kendi yolumuzu bulmak için konuyla nasıl başa çıktıklarına bir göz atmaya değer.

Örneğin, Catriona Cornett, SalesforceIQ Ürün Tasarım Direktörü, SalesforceIQ'daki kullanılabilirlik borcunu yönetmek için kullandıkları 5 aşamalı süreci göstermektedir..

Bunu kısaca görelim, böylece onu kendi iş akışımıza ne kadar iyi uygulayabileceğimizi değerlendirebiliriz.

1. Tanımla paylaşılan dil kullanılabilirlik konularını tartışmak için.
2. bulmak ve toplamak kullanılabilirlik sorunları.
3. Düzenlemek ve sınıflandırmak kullanılabilirlik sorunları.
4. öncelik kullanılabilirlik iyileştirmeleri.
5. Tedbir iyileştirmelerin etkisi.

Kullanıcı deneyimi, kullanılabilirlikten daha geniş bir alandır, ancak yukarıdaki iş akışının etkili bir şekilde uygulanabileceğini düşünüyorum..

Andrew Wright UX Borç sunumunda biraz farklı bir yönetim iş akışı ile geliyor ve UX borcu ile başa çıkmak için 4 aşamalı bir süreç öneriyor.

1. belirlemek Eğer ve nerede UX borcu var.
2. Karşılaştırmak önem derecesi.
3. Zaman yaratmak Tamir etmek için.
4. Sosyalleştirmek kavram.

Kasıtlı ve kasıtsız UX borcu ile ilgilenmek de gerekir farklı teknikler. Bilerek yaptığımız kısayollar ve işlem sırasında kaybolan iyi fikirler şu kullanıcı tarafından yönetilebilir. not alma, görev yönetimi, veya Sorun takibi uygulamaların.

Kasıtsız UX borcu düzenli olarak çalıştırılarak giderilebilir. kullanıcı testleri, rica etmek müşteri geribildirimi, veya farklı tasarımların etkisini görmek için A / B testi gibi ileri teknikleri kullanmak.

uygulama ilkeleri yinelemeli tasarım ayrıca faydalı olabilir; UX borç yönetimi adımlarımızı birikimini önlemek için her yinelemeye ekleyebiliriz.

UX borç yönetimi gerekir daha geniş iş akışımıza uyun, ekibimizin özellikleri, hedeflerimiz ve ürünümüzün doğası ile, ancak bazı evrensel şeyler her durumda takip edilmesi önerilir.

1. Bizim ihtiyacımız iletişim kurmak ekibimiz genelinde niye ya UX borcuyla uğraşmamız gerek, hedeflerimiz neler, ve nasıl başarmak istiyoruz onları.
2. Araç bulmamız gerekiyor kasıtlı UX borcunu takip et.
3. Ürünümüzü test etmenin ve kullanıcılarımızdan geri bildirim almanın yollarını bulmalıyız. kasıtsız UX borcunu yakalamak.
4. Bizim ihtiyacımız düzenlemek ve öncelik bizim sorunlarımız.
5. Bizim ihtiyacımız ölçmek çalışmamızın sonuçları, her zaman ihtiyacımız olduğu gibi ayarlamak Değişen ihtiyaçlarımıza UX borç yönetimi.

Son sözler

Kaliteli ürünler üretmek için sadece yenilikçi olmamız gerekmez, aynı zamanda ilk bakışta çok açık olmayan şeylere dikkat etmek için bunlardan biri de UX borcunu tanımak ve etkin bir şekilde yönetmek. Muhtemelen en ilginç iş değil ama zaman içinde önemli, çünkü zamanla UX borcu işimizin başarısı için ciddi bir tehdit olabilir.

UX borcunu dilimlendiriyorsak yönetilebilir parçalar, ve ilgili işleri iş akışımıza entegre etmek, Aynı anda çok fazla şey yapmak zorunda değiliz, hoş olmayan sürprizlerden kaçınabilir ve bir ürünün kalitesini rahat bir şekilde koruyabilir veya artırabiliriz..