Çevik UX: UX ve Ürün Tasarımını Çevik'e Nasıl Dahil Edebilirsiniz?

DevOps genellikle bir şirketin yazılım ve sistem geliştirmesini çevreleyen süreçler, operasyonlar, metodolojiler, araçlar ve kültür olarak tanımlanır.

Ancak mühendislik bir boşlukta çalışmaz. Planlar, fikirler, tasarımlar ve kavramlar, yerleşimlere, akışlara ve etkileşime karar veren ürün tasarım uzmanlarından gelir. Bunlar, DevOps'un hedeflerini ve istenen sonuçları paylaşan mühendislik dışı bireyler ve ekiplerdir.

DevOps, geliştiricilerin BT ile nasıl bağlantı kurduğundan, altyapının nasıl yönetildiğinden ve çerçevelerin nasıl iyileştirilebileceğinden çok daha fazlasıdır. Bu, yazılım geliştirme sürecine gerçekten kaç ekibin dahil olduğunu, rollerinin ve çalışmalarının ne kadar iç içe olduğunu anlamak ve herkesin masada olduğundan emin olmanın daha iyi yollarını bulmakla ilgilidir.

Geliştiriciler ve mühendislik mimarları, ürün ve yaratıcı ekipler yazılımı veya sistemi tasarlarken dahil olmak ister. Ancak DevOps'un şu anki tanımında bu nerede? Ürün, UX ve yaratıcı ekipler mühendislik süreçlerine dahil olmak ister, ancak pek çok metodoloji bunları hariç tutar. Bunlar yıkmamız gereken eski silolar.

Müşterileriniz yalnızca kullanıcı deneyiminizi (UX) görür. Kaç tane geliştiriciniz olduğunu veya Çevik veya Yalın olup olmadığınızı görmezler. Hangi DevOps araçlarının kullanıldığı hakkında hiçbir fikirleri yok. Şirketinizin UX'i bir üründür ve sizi yapabilir veya bozabilir. Bu hurda parçasını kimin yaptığını merak ediyorlar. Bu kadar çok rekabet ve bir uygulamayı kaldırmaktan veya bir web sitesinden ayrılmaktan mutlu olan insanlar varken, sizi terk eden müşteriyle ikinci bir şansınız olacak mı?

Agile Nadiren UX Üzerine Eğitiliyor veya UX Uzmanlarıyla Çalışıyor

Çoğu mühendislik ekibi, genellikle UX'i silo olarak bulur ve birlikte çalışmayı zorlaştırır. UX, Yalın görünmüyor ve Çevik'in birçok çeşidi, UX ile nasıl çalışılacağına ilişkin ayrıntıları hariç tutuyor. Bazı Çevik yaklaşımlar, özellikle bir özelliği tanımlayan bir ürün sahibinin "yeterince iyi" olduğunu öne sürer.

SAFe Agile, UX silosunu çözmenin en iyi yolunun onları tamamen dışlamak olduğuna karar verme hatasına düşer. SAFe, "Çevik ekiplere" kendi "Yalın UX"lerini yapmaları için güç verir. Daha fazla şirket, UX uzmanlarını ve eksiksiz bir UX sürecini birleştirmenin değerini anladıkça, SAFe yanlış yöne gidiyor.

Çevik eğitim ve kitaplardan UX ve süreçlerinin açıklanmaması, dünya çapında ekiplerin uzman ürün tasarımcılarının katılımını hariç tutmasına veya en aza indirmesine neden oldu.

• UX'in sayfalara sadece kutular çizdiğini yanlış bir şekilde hayal ettiğinizde, "Bu işi yapabilirim" diye varsaymak kolaydır. Pek çok American Idol seçmeninin gezegendeki en iyi şarkıcı olduklarından emin oldukları gibi, çoğu ürün yöneticisi ve mühendis de kendilerini UX'te harika olarak değerlendiriyor. Bu normalde ekranları yerleştirmede harika olduklarına inandıkları anlamına gelir. Ancak bu makale UX çalışmasına gerçekten neyin girdiğini açıklarken, bir UX uzmanının tel çerçeveler yapan bir geliştiriciyi UX görevleri verilmesi gereken biri olarak görmediğini göreceksiniz.
• Scrum üzerine kitaplar, bir UX uzmanı bir darboğaz haline gelirse, işini yapmak için UX olmayan rolleri eğitmesi gerektiğini önerir. Bu tür bir karar, yazılım geliştirmedeki diğer roller hakkında nadiren önerilir; Hiç kimse, eğitimsiz veya deneyimsiz bir geliştiricinin, bir eğitim kampından sonra veya programlama hakkında bir kitap okuduktan sonra bile kodlama yapmasını istemez. Bir geliştirici bir darboğaz haline gelirse, proje yöneticisini biraz kodlama yapmak için eğitmesi gerektiğini asla önermeyiz.
• UX'in sanatsal bir (UI) işi olduğuna yanlış bir şekilde inanan işe alım yöneticileri, UX çalışması yapmak için sanatçıları işe alır. UX ve UI'daki bir derece arasında eğitimsel bir örtüşme yoktur. Doğal yetenekler çoğu zaman örtüşmez; UX'te harika biri zayıf bir sanatçı olabilir ve bunun tersi de geçerlidir. "UX/UI" için işe alım, genellikle size minimum UX deneyimi, uzmanlığı, süreci veya eğitimi olan harika bir sanatçı sunar.

Yalnızca sonuca bakanlar, UX eğitimi, deneyimi, uzmanlığı, becerisi veya doğal yeteneği olmayan kişilere UX görevleri vererek bütçeyi kısmayı çok isterler. Ancak bu, dar görüşlüdür ve düşük üretkenlik, verimlilik, kültür, ürün ve müşteri memnuniyetine yol açabilir.

Uzman UX Uzmanlarını Agile'a Dahil Etmenin Önemi

2018 yılının sonlarında, yönetim danışmanlığı firması McKinsey & Company, 300'den fazla şirketle yaptıkları araştırma hakkında bir rapor olan "Tasarımın İş Değeri"ni yayınladı.

“Şirketlerin kalabalığın arasından sıyrılabilmesinin tek yolu tasarımdır” ifadesini buldular. Rakiplerin birbirine yakın özellik kümeleri olduğunda, onları farklı kılan nedir? Tasarım bazen sadece estetik veya bunu markamız gibi gösteren şey olarak düşünülür. Ancak "UX" ile birlikte kullanıldığında tasarım, özelliklerin mimarisi ve ekranlar, adımlar, akışlar, düzenler, süreçler, organizasyon ve menüler hakkında alınan kararlar anlamına gelir.

UX, sürekli iyileştirme sürecinin bir parçasıdır ve her zaman kullanıcıları daha iyi anlamaya ve ihtiyaçlarına en uygun özellikleri ve ürünü seçip tasarlamaya, sorunlu noktalarını çözmeye ve onlara anlamlı yenilikler getirmeye çalışır.

McKinsey ayrıca, "Şirketler, tasarımı daha sonra sığacak küçük bir araç olarak görmek yerine, sürecin başında ve bütünsel olarak benimsemeleri gerektiğini" bildirdi. Kullanıcı deneyimine verilen önemin en aza indirilebilecek, hariç tutulabilecek veya ürünü piyasaya sürdükten sonra yapılabilecek bir şey olduğunu varsayan ekipler yanlış bir yaklaşım sergiliyor.

McKinsey nicel veriler topladı ve UX tasarımını benimseyen firmaların 5 yıllık bir dönemde %32 daha fazla gelir ve %56 daha fazla hissedar getirisi sağladığını buldu. Şirketinizi “kullanıcı odaklı” ilan etmek yeterli değildir. UX uygulayıcılarını ve süreçlerini planlama ve portföyden geliştirme ve KG'ye kadar entegre ederek yürüyüşe çıkmalısınız.

UX İçeren ve UX Olmadan Yazılım Geliştirme Süreçleri

Şirketiniz yazılım tasarım ve geliştirme sürecine UX uzmanlarını dahil etmiyorsa, süreciniz büyük olasılıkla aşağıdaki görüntüye benziyor.

Bir müşteri, ürün yöneticisi, CEO veya vizyon sahibi biri mühendisliğe ne istediğini söyler. Mühendislik onu oluşturur, test eder ve bir hazırlama veya üretim sunucusuna alır. Vizyon sahibi kişi daha sonra onu görür ve bilmiyor musunuz, mutlu değiller. Farklı bir şey istiyorlar ya da fikirlerini değiştirmişler.

Mühendislik daha sonra başlangıca geri dönmeli, bu kişinin şimdi ne istediğini bulmalı, inşa etmeli, test etmeli ve bunun cazibe olduğuna dair parmaklarını çarpmalıdır.

Ekipte UX uzmanları varsa, süreç oldukça farklıdır. Vizyona sahip olan kişi, fikirler, veriler ve müşteri acı noktaları ile UX'e gelir. UX, kullanıcı merkezli tasarım sürecinde görevler arasında geçiş yapar ve ardından mühendislik bir satır kod yazmadan önce bu kavramları test eder. Bu, oluşturmayı düşündüğümüz ürün veya özelliğin, hedef müşterilerimiz için doğru fikrin doğru şekilde yürütülmesini sağlar.

Test, bazı kusurları gün ışığına çıkarabilir, bu da UX'in yinelenmesine ve sıklıkla tekrar test etmesine olanak tanır. UX sürecinden sonra, mühendisliğe teslim edilmeye hazır, tamamen incelenmiş bir tasarımınız olur.

Birisi yol boyunca fikrini değiştirirse, o kişi, geliştiricilere bir değişiklik talebi olarak koymak yerine UX ile konuşur. UX, süreçleri sırasında parazit yapar ve UX gerçek veya arketipsel müşteriler üzerinde tasarımlara, kararlara ve testlere dahil olmadan mühendisliğe hiçbir şey gönderilmez.

Bu noktada fikir değişiklikleri felaket değildir çünkü birinin bu noktada fikrini değiştirmesinin maliyeti minimumdur. Mühendislik, planları teslim etmedi, başlamadı ve yeniden inşa edecek hiçbir şeyleri yok. UX, tasarımlarını yineler ve fikirlerin müşteri tabanına iyi ve güçlü bir şekilde uyduğundan emin olmak için kullanıcı testleri yapabilir. Zihin değişiklikleri zaman kaybına neden olur, ancak bütçe üzerindeki genel etki küçüktür.

UX'in Resmi Bir Süreci Var

Kullanıcı merkezli tasarım (UCD), UX uzmanlarını araştırma, tasarım, prototip, gerçek veya arketipsel kullanıcılar üzerinde test etmeye ve ardından testlerden edinilen bilgilere dayalı olarak yinelemeye yönlendiren görevleri içeren resmi bir süreçtir.

Bu alanlardan birkaçına odaklanarak, özellikler ve projeler hakkında gereksinimler ve erken tartışmalarla başlıyoruz. UX gereksinimleri ve diğer proje bilgilerini ilk aldığında, hemen işbirliğine başlamak önemlidir. UX, inşa edilemeyecek bir şey tasarladıklarını daha sonra öğrenmemelidir.

Ürün veya proje yöneticileri özelliklere ve önceliklendirmeye karar verirken UX çalışanlarını veya yöneticilerini işe alarak başlayın. Kullanıcı için hiçbir değeri olmayan bir proje kaldırılabilir, bu da anlatılmamış zaman ve para tasarrufu sağlar. İşte burada yapılmayan iş miktarını maksimize etmek devreye giriyor. Ürün ve Mühendislik, özellikleri veya tüm projeleri azaltarak veya kaldırarak Mühendislik için daha az iş yarattıklarında UX'i desteklemelidir. Bununla birlikte, çoğu zaman projelerde ego iliştirilir ve ekip arkadaşları genellikle projeye fon sağlanabilmesi için UX'i bu erken konuşmalardan hariç tutar.

Araştırma , UX'in yaptıklarının önemli bir parçasıdır. Kullanıcıları dahil etmeden kullanıcı merkezli değildir. İstatistikler ve nicel veriler harikadır ancak kullanıcılarla görüşmenin, onları derinlemesine anlamanın ve nitel veriler elde etmenin yerini hiçbir şey tutamaz. UX, yalnızca neyi değil, nedenini de bilmek ister.

UX araştırması ayrıca, herkesi hedef müşterilerin arketipleri olan kişiler etrafında birleştirerek ekip arkadaşlarını aynı sayfada toplar. Kullanıcılarla yapılan görüşmelere dayanarak öğrendiklerimizi topluyoruz ve herkesi 6 veya daha az kişiye indiriyoruz. Onları ne motive eder? Neye ihtiyaçları var? Şirketimiz, ürünümüz veya hizmetimiz için fırsatlar nerede?

Kişilerin en iyi kullanımı, onları her yere dahil etmek olacaktır. Ürün, kişiliklere (ve iyi verilere) dayalı özellikleri hayal eder. Kişilere dayalı UX tasarımları. QA testleri, bu kişiler olduklarını hayal ederken. Pazarlama, demografik ve diğer ayrıntılarını ekleyebilir, ancak marka sesinin, sosyal medyanın ve reklamcılığın kişilerle nasıl konuştuğunu da göz önünde bulundurmalıdır.

Kişiler, UX olmayan çalışanların "Eh, ben bu şekilde seviyorum" veya "CEO bu şekilde seviyor" cümlelerinden uzaklaşmalarına yardımcı olur. Bu hedef müşteriler için tasarım yapıyoruz ve siz veya CEO'nuz kişilere uymuyorsanız, o zaman UX ego veya kişisel tercihlerden etkilenmez. UX müşteri odaklı kalmalıdır.

Bilgi mimarisi hiyerarşiler, yapı ve sınıflandırmalarla ilgilidir. Bu, site gezintisi olabilir veya ürünlerin bir e-Ticaret veritabanında nasıl sınıflandırıldığı olabilir. Müşterilerin kategorilere, meta verilere ve filtrelere göre ürünleri kolayca bulmasını sağlamak istiyoruz.

Bazen deneyim tasarımı olarak da adlandırılan etkileşim tasarımı , çoğu insanın UX'i hayal ettiğinde düşündüğü şeydir. Bunlar tel kafesler ve prototipler, tasarımların ve kavramların planlarıdır. Bunlar süreç akışlarını, düzenleri, menüleri, etkileşimleri, yolları, seçimleri ve çok daha fazlasını gösterir.

UX prototipleri, hayata geçirilen tel çerçeveler gibidir. Tıklanabilir, etkileşimli dijital maketlerdir. Kod yazmak zorunda değiliz; bunları hızlı bir şekilde oluşturmamıza yardımcı olan bir yazılımımız var. Daha gerçekçi prototipler arayan şirketler, koşullu mantık, değişkenler, mobil kaydırma hareketleri, sürükleyip bırakma ve her türlü olay tetikleyicisine sahip olduğundan Axure kullanıyor. Hemen hemen her tür cihaz için prototip oluşturabilirsiniz.

UX prototiplemesi şu amaçlarla yapılır:

• beyin fırtınası
• işbirliği yap
• yinele
• Çözümleri keşfedin
• Yatırımcılara satış konuşması (yeni başlayanlar için)
• Çözümün hedef kitle(ler) ile iyi bir bağlantı kurup kurmadığını görmek için prototipi test edin.
• Geliştiricilere veya diğer ekip arkadaşlarına, genellikle belge sayfalarına göre tercih edilen (ve tıklanabilir model olmayan) etkileşimli bir model sunun.

Şimdi, UX işlemi sırasında ve mühendislik bir kod satırı yazmadan önce gerçekleşen, kullanılabilirlik testi olarak da adlandırılan kullanıcı testine gidiyor. Fikir ve uygulamanın hedef müşteriler için harika olduğundan emin olmak için kavramları ve tasarımları test etmelisiniz.

Kullanıcı testi, herhangi bir kusuru ortaya çıkaracak ve UX'e fikirleri yineleme şansı verecek ve bu noktada mühendisliğin inşa etmesi veya yeniden inşa etmesi için hiçbir şey olmadığı için ucuzdur.

UX'in mühendisliğe teslim etmeden önce testler yapmasının 5 temel nedeni vardır:

1. Mühendisliğin zamanını ve kaynaklarını en iyi şekilde kullanmak. Test katılımcılarının mühendisler tarafından oluşturulan bitmiş bir ürünü görmelerini istiyorsanız, onu hatalar için oluşturmanız ve test etmeniz gerekir. UX testi gerekli değişiklikleri gün ışığına çıkarırsa, geliştiricilerin yeniden oluşturması ve QA'nın yeniden test etmesi gerekir. UX testi kavramın daha büyük bir başarısızlığını gösterdiyse, bu, herhangi bir yerde sona erecek bir kod olmadığı için mühendisliğin zamanının tamamen boşa harcandığı anlamına gelebilir. Konseptin yeniden düşünülmesi, yeniden tasarlanması ve yeni bir şekilde test edilmesi gerekecekti.
2. Sahne arkasını yineleyin. Şirketler sadece inşa ettiklerinde, sadece gönderin, üzerinde yineleyin ve tekrar kurup sevk edin, bu, müşterilerin çeşitli versiyonları gördüğü anlamına gelir. Devam eden işi görüyorlar ve yapılan sosisi izliyorlar. Bu genellikle, müşterilerin gelişen bir sistemi yeniden öğrenmeye devam etmelerini gerektiren sinir bozucu ve kafa karıştırıcı bir deneyimdir. UX sürecinde perde arkasını tekrarlamak ve testçilere bunun bir prototip veya tanıtım versiyonu olduğu konusunda net olmak daha iyidir.
3. İzleme ve ölçme. Yeni bir konsept canlı olarak yayınlanırsa, UX araştırmacılarının insanların onu kullanmasını izlemenin, onlara sorular sormanın ve bir şeyin hazır olup olmadığını veya başka bir yinelemeye ihtiyaç duyup duymadığını belirlemek için UX'in ihtiyaç duyduğu geri bildirim türünü almanın iyi bir yolu yoktur. UX her zaman nedenini ve niteliğini bilmek ister ve sadece ne veya kaç tane olduğunu değil. Kullanıcılar nasıl harcıyor, dönüştürüyor, etkileşim kuruyor vb.? Uygun UX testinden kaçınmak, sorunları veya müşterinin sorunlu noktalarını teşhis etmeyi ve düzeltmeyi zorlaştırır.
4. UX testi kendini öder. UX testi büyük bir masraf değildir. Bazı üçüncü taraf test araçları, test katılımcısı başına 100 doların altında ister, bazıları ise minimum yıllık binlerce dolar taahhüt gerektirir. Şirketin yazılım geliştirme süreci için genel bütçesi ve erken test geri bildiriminin önemi göz önüne alındığında, bunlar çok büyük harcamalar değil. Kullanıcı testi turları neredeyse her zaman daha az maliyetlidir ve programcıların geri almamız veya yeniden oluşturmamız gerekebilecek bir şeyi inşa etmesini sağlamaktan daha hızlı hareket eder.
5. Kullanıcı testi argümanları çözer. Şirketiniz, UX uzmanlarının ürünün nasıl tasarlandığına dair nihai kararı vermesine izin vermiyorsa, neyin oluşturulup piyasaya sürüleceğine dair farklı fikirler olduğunda UX ürün, mühendislik veya bir paydaşla çelişiyor olabilir. müşteri. Ya da UX'in iki güçlü fikri varsa ve hangisinin müşterilerle daha iyi bağlantı kurduğunu merak ediyorsa? Buradaki çözüm, kullanıcı testidir.

UX kavramları prototipleyebilir. Özellikle fikirler ve ekip üyeleri arasında zaten uzlaşmalar bulabiliyorsanız, rekabeti en iyi iki tasarıma indirgemek en iyisidir. Bu, UX'in ne istediğini, hangi ürünün beğendiğini, mühendislik başkanının neyi sevdiğini, scrum master'ın iyi bir fikir gibi göründüğünü düşündüklerini ve CEO'nun hayat arkadaşının neyi sevdiğini test etmeyeceğimiz anlamına gelir.

Kullanıcı testi, müşterilerin sesini yükseltmesini sağlar ve özellikler veya ürün için doğru yönü bulmanıza yardımcı olur. Takımlara, hangi fikrin en fazla müşteri memnuniyetini getireceğini herkese söyleyen kesin nicel ve nitel veriler sağlayarak tartışmaları çözer.

Kullanıcıyı dahil etmeden kullanıcı merkezli tasarım değildir. Bu, tahmin etmek, varsaymak veya "sadece göndermek" yerine gerçek veya arketipsel müşterilerle araştırıp test ettiğimiz anlamına gelir. "Az önce gönderdiğimiz" şeyin, kullanıcı testi yoluyla incelendiğinden ve harika bir fikrin mükemmel bir uygulaması olduğundan emin olmalıyız.

UX Atlatıldığında veya Azaltıldığında Ne Olur?

Skype kısa süre önce, Snapchat'e daha çok benzemeyi amaçlayan 2017 yeniden tasarımının başarısız olduğunu duyurdu. Kullanıcılar yeni özellikleri istemedi, ihtiyaç duymadı veya beğenmedi. Geri tepme, Skype'ın 2018'de Skype'ı yeniden tasarlayacaklarını duyurmasına yetecek kadar büyüktü. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

UX uzmanları, süreçlerinin birçok adımında bu özelliklerin istenmeyen veya başarısız olabileceğini biliyorlardı. Hedef kullanıcılarla yapılan araştırmalar, Skype'ın Snapchat olmasını istemediklerini çabucak ortaya çıkarabilirdi. Projeyi bitirmek veya bu erken noktada döndürmek, Skype'a milyonlarca dolar artı kötü basın ve müşteri yabancılaşmasından tasarruf sağlayabilirdi.

UX araştırması atlanmış olsa bile, kullanıcılar üzerinde bir UX prototipinin test edilmesi, müşterilerin Skype'ın bu yönde ilerlemesini istemediklerini açıkça ortaya koyabilirdi. UX hala sürecinden geçerken, mühendislik henüz bir satır kod yazmadı. Bu, basitliği ve mühendisliğin yapması gerekmeyen işleri kutlayarak muazzam bir zaman, para ve insan kaynağı tasarrufu sağlayabilirdi.

Çevik UX Süreci

Çevik manifesto ilkelerini hatırlayın. En yüksek önceliğiniz, değerli yazılımlar oluşturarak müşteri memnuniyetidir. (UX) çalışanlarına, işi yapacaklarına güvenerek ihtiyaç duydukları ortamı ve desteği verin. Yapılmayan iş miktarını maksimize edin. İyi tasarıma sürekli dikkat, çevikliği artırır.

İlerleyen projeler, uygun araştırma, tasarım ve testlerin başlayabilmesi için UX'e büyük bir pist vermelidir. UX'i başlangıç ​​toplantınıza davet etmeyin ve son tel çerçevelerin birkaç gün içinde teslim edilmesi gerektiği talebiyle onları şaşırtmayın. Bu UX değil.

Buna, insanları korkutmak ve bunun uzak durmamız gereken bir şey olduğunu ilan etmek için tasarlanmış bir terim olan Big Design Up Front (BDUF) olarak bakmayın. Bir proje veya özellik büyük veya yeni olduğunda, UX'in kullanıcı merkezli tasarım sürecinin tümü olmasa da çoğu arasında geçiş yapması gerekir. UX için, daha büyük bir özellik için mümkün olan en küçük parça, kullanıcının iş akışı veya sürecidir. Daha küçük bir şey tasarlar ve test edersek, gerçek kullanıcı deneyiminin büyük resmini alamama riskini alırız.

Örneğin, kullanıcıların kayıt olduğu ve satın aldığı bir akış tasarlıyorsak, sadece şifre seçim alanları tasarlayıp mühendisliğe gönderemeyiz. UX küçük parçalar halinde çalışsaydı, tüm süreç ne zaman test edilirdi? Tüm akışı test etmeden kullanıcının tüm akışa tepkisini bilemeyiz… bu da kullanılabilirlik testine geçmeden önce tüm akışın tasarlanması gerektiği anlamına gelir.

Özelliklerin, hikayelerin veya düzeltmelerin küçük olduğu durumlarda, UX uygulayıcıları kullanıcı merkezli tasarım sürecinin bir alt kümesini yapabilir ve daha hızlı çalışabilir. UX her zaman ellerinden geldiğince hızlı gidecektir, ancak harika bir UX uzmanı, yapılan işin kalitesinden ödün vermemek için elinden gelen her şeyi yapacaktır. Hızlı ve iyi savaşında, UX her zaman hızlıya karşı iyiyi seçecektir… ve siz de yapmalısınız.

Bütçeler ve zaman çizelgeleri, UX'in hızlı geri bildirim almasını ve yinelemesini engelleyen şeydir. UX uygulayıcıları, müşteriler için gerçekten neyin işe yaradığını tasarlamayı hedefleyerek her zaman geri bildirim ve ürünü geliştirme şansı ister. UX uygulayıcılarını portföy yönetimi ve planlaması kadar erken bir zamanda getirmek, UX'in ihtiyaç duyacakları zamanı ve bütçeyi tahmin etmesine olanak tanır; bunlar daha sonra sürprizler veya çatışma nedenleri olmamalıdır.

Bir UX Uygulayıcısı Çevik Ekibin Bir Parçasıdır

UX Designer'ınızı Agile ekibine yerleştirin. Onları planlama, stand-up, retro ve UX'in tartışılabileceği her toplantıyı yayınlamaya davet edin. UX görevlerinin gerektireceği zamanlama konusunda hiçbir sürpriz olmaması için, UX'in sürüm planlaması sırasında zamanlarını tahmin etmesine izin verin. Onlarsız karar vermeyin. UX takım arkadaşınız toplantıyı kaçırdıysa, onları yüz yüze, sohbet, e-posta veya şirketinizin kullandığı herhangi bir yöntemle bulana kadar bekleyin.

JIRA'da veya kullandığınız herhangi bir hata izleme sisteminde UX takım arkadaşınıza sorular, belirsizlikler veya hatalar atayın. UX sorunlarının diğer sorunlarla aynı sistemde olduğundan emin olun; Diğer her şey için VersionOne kullanıyorsanız UX sorunlarını Trello panosuna atmayın.

UX uzun pistine sahip olduktan sonra, bu özellik veya ürün için gerekliyse, en iyi uygulama UX'in mühendislikten 2 veya daha fazla Sprint olması. UX sizinle birlikte koşabilir. Birikmiş iş yığınına bol miktarda teknoloji hikayesi veya teknik borcun sabitlenmesi alın. Bu şekilde, UX'in yaratıcı ve döngüsel süreci gecikirse veya daha fazla sprint gerektiriyorsa, geliştiriciler gerçekten çevik olabilir. UX'i beklemek yerine, ürünün veya mühendisliğin öncelik verdiği bazı düşük asılı meyvelere geçebilirler.

Ayrıca kaynak bulma, tahsis ve personel alımını da göz önünde bulundurun. Projenin boyutuna bağlı olarak, bir UX tasarımcısına en fazla 3 proje atayın. Test ve analiz de yapan ayrı, uzman UX araştırmacılarınız varsa, en fazla 3 UX tasarımcısına bir araştırmacı atayın. UX uygulayıcınız T-şekilli olarak biliniyorsa, yani araştırma, test etme ve diğer UX alt uzmanlık alanlarında da nitelikli ve mükemmelse, o zaman çok fazla projeye atanarak yanlışlıkla bir darboğaz olmadığından emin olun.

Ölçüm Sonuçları

Müşteri memnuniyeti olmadan müşterileriniz olmayabilir. UX'i entegre ederek süreçlerinizi iyileştirmenin nasıl olumlu değişiklikler yaptığını belirlemek için müşteri memnuniyeti ölçümlerini kullanabilirsiniz.

• Daha az şikayet
• Daha iyi uygulama incelemeleri
• Daha yüksek uygulama derecelendirmeleri
• Daha az destek bileti
• Daha az çağrı merkezi araması
• Sosyal gönderilerin daha olumlu semantiği
• Daha fazla uygulama yükleme, daha az kaldırma
• AOV (ortalama sipariş değeri) artışı
• Daha yüksek dönüşüm oranı

Pazara sunma süresi ve düzeltmeler arasındaki süre gibi istenen DevOps hedeflerini de ölçebilirsiniz. UX devriminizden önce ve sonra hikayeler, projeler ve destanların piyasaya çıkması ne kadar sürer? Geliştirici zaman tahminlerinin, hikayelerden çalışmaya veya şu anda ne yapıyorsanız yapın, tahminlerini temel alacakları UX tasarımlarını sonlandırdıklarında daha doğru olması muhtemeldir.

UX planları sağlıyorsa ve bunlar takip ediliyorsa, sürpriz değişiklikleri ve yeniden oluşturmaları azaltarak mühendisliğin daha az iş yapmasını umuyoruz. Daha önce daha iyi UX tasarımı, daha sonra daha az düzeltme.

Çevik UX Kendi Maliyetinden Fazlasını Ödeyen Bir Yatırımdır

Birçok proje yöneticisi, UX'i kaldırılabilecek veya azaltılabilecek bir bütçe sınırı olarak görür ve işe alım yöneticileri, UX görevlerini başka bir rolle birleştirme fikrinden heyecan duyar. Ancak giderek daha fazla şirket, eğitimli ve deneyimli UX uzmanları tarafından yürütülen uygun bir UX sürecine yatırım yapmanın yerini hiçbir şeyin alamayacağını öğreniyor.

The Lean Startup'ın yazarı Eric Ries, "Ya kendimizi kimsenin istemediği bir şeyi inşa ederken bulursak? Bu durumda, zamanında ve bütçe dahilinde yapmamızın ne önemi vardı?” Kuruluşunuz Yalın metodolojisini kullanmıyor olsa bile, uyarı yine de geçerlidir. Müşteri için doğru olanı inşa etmeyi, müşteri memnuniyetini artırmayı ve müşteri değeri yüksek özellikler geliştirmeyi amaçladığımızda DevOps'un arzu ettiği sonuçlar bunu yansıtıyor.

Müşterinizi tanımak, müşterinizi sürece dahil etmek ve gerçek ihtiyaç ve tercihlerini oluşturmak, nihayetinde zaman çizelgelerinden, bütçelerden, çerçevelerden ve araçlardan daha önemlidir. Doğru fikirlerin doğru uygulamalarını oluşturursanız, gelirin orada olacağına güvenin.