Agile UX: Cara Menggabungkan UX dan Desain Produk ke dalam Agile

DevOps sering didefinisikan sebagai proses, operasi, metodologi, alat, dan budaya yang melingkupi pengembangan perangkat lunak dan sistem perusahaan.

Tetapi teknik tidak beroperasi dalam ruang hampa. Cetak biru, ide, desain, dan konsep berasal dari spesialis desain produk yang memutuskan tata letak, alur, dan interaktivitas. Ini adalah individu dan tim non-teknik yang berbagi tujuan dan hasil yang diinginkan DevOps.

DevOps lebih dari sekadar bagaimana pengembang terhubung dengan TI, bagaimana infrastruktur dikelola, dan bagaimana kerangka kerja dapat ditingkatkan. Ini tentang mengenali berapa banyak tim yang benar-benar terlibat dalam proses pengembangan perangkat lunak, bagaimana peran dan pekerjaan mereka saling terkait, dan menemukan cara yang lebih baik untuk memastikan semua orang ada di meja.

Pengembang dan arsitek teknik ingin terlibat ketika produk dan tim kreatif merancang perangkat lunak atau sistem. Tapi di mana itu dalam definisi DevOps saat ini? Produk, UX, dan tim kreatif ingin tetap terlibat selama proses rekayasa namun begitu banyak metodologi yang mengecualikannya. Ini adalah silo tua yang perlu kita hancurkan.

Pelanggan Anda hanya melihat pengalaman pengguna (UX) Anda. Mereka tidak melihat berapa banyak pengembang yang Anda miliki atau apakah Anda Agile atau Lean. Mereka tidak tahu alat DevOps mana yang digunakan. UX perusahaan Anda adalah produknya, dan itu dapat membuat atau menghancurkan Anda. Mereka bertanya-tanya siapa yang membuat sampah ini. Dengan begitu banyak persaingan dan orang-orang senang untuk mencopot pemasangan aplikasi atau meninggalkan situs web, apakah Anda akan mendapatkan kesempatan kedua dengan pelanggan yang meninggalkan Anda?

Agile Jarang Melatih UX atau Bekerja dengan Spesialis UX

Banyak tim teknik sering kali menganggap UX tertutup dan sulit untuk diajak berkolaborasi. UX tampaknya tidak Lean dan banyak rasa Agile mengecualikan spesifik tentang cara bekerja dengan UX. Beberapa pendekatan Agile secara khusus menyarankan bahwa pemilik produk yang menjelaskan fitur adalah "cukup baik."

SAFe Agile membuat kesalahan dengan memutuskan bahwa cara terbaik untuk menyelesaikan UX siloing adalah dengan mengecualikannya sepenuhnya. SAFe “memberdayakan tim Agile” untuk melakukan “Lean UX” mereka sendiri. Karena semakin banyak perusahaan memahami nilai menggabungkan spesialis UX dan proses UX penuh, SAFe menuju ke arah yang salah.

Tidak adanya penjelasan UX dan prosesnya dari pelatihan dan buku Agile telah menyebabkan tim di seluruh dunia mengecualikan atau meminimalkan keterlibatan desainer produk spesialis.

• Ketika Anda salah membayangkan bahwa UX hanya menggambar kotak di halaman, mudah untuk berasumsi "Saya bisa melakukan pekerjaan itu." Seperti banyak peserta audisi American Idol yang yakin bahwa mereka adalah penyanyi terbaik di planet ini, sebagian besar manajer produk dan insinyur menilai dirinya hebat di UX. Ini biasanya berarti mereka percaya bahwa mereka hebat dalam membuat layar. Tetapi karena artikel ini menjelaskan apa yang sebenarnya masuk ke dalam pekerjaan UX, Anda akan melihat bagaimana spesialis UX tidak akan melihat pengembang yang menjadikan gambar rangka sebagai seseorang yang harus diberi tugas UX.
• Buku-buku tentang Scrum menyarankan bahwa jika seorang spesialis UX menjadi hambatan, dia harus melatih peran non-UX untuk melakukan pekerjaannya. Jenis keputusan ini jarang disarankan tentang peran lain dalam pengembangan perangkat lunak; tidak ada yang ingin pengembang yang tidak terlatih atau tidak berpengalaman untuk melakukan pengkodean, bahkan setelah bootcamp atau membaca buku tentang pemrograman. Kami tidak akan pernah menyarankan bahwa jika seorang pengembang menjadi hambatan, dia harus melatih manajer proyek untuk melakukan beberapa pengkodean.
• Mempekerjakan manajer yang salah percaya bahwa UX adalah pekerjaan artistik (UI) mempekerjakan seniman untuk melakukan pekerjaan UX. Tidak ada tumpang tindih pendidikan antara gelar di UX dan di UI. Bakat alami seringkali tidak tumpang tindih; seseorang yang hebat di UX mungkin seniman yang buruk dan sebaliknya. Mempekerjakan untuk "UX/UI" sering kali memberi Anda seniman hebat dengan pengalaman, keahlian, proses, atau pendidikan UX minimal.

Mereka yang hanya melihat pada intinya akan senang untuk memangkas anggaran dengan memberikan tugas UX kepada individu yang mungkin tidak memiliki pendidikan, pengalaman, keahlian, keterampilan, atau bakat alami UX. Tapi ini picik dan dapat menyebabkan produktivitas, efisiensi, budaya, produk, dan kepuasan pelanggan yang buruk.

Pentingnya Menggabungkan Pakar UX Spesialis di Agile

Pada akhir 2018, perusahaan konsultan manajemen McKinsey & Company menerbitkan, "Nilai Bisnis Desain," sebuah laporan tentang penelitian yang mereka lakukan dengan lebih dari 300 perusahaan.

Mereka menemukan bahwa, "Desain adalah satu-satunya cara perusahaan dapat menonjol dari yang lain." Ketika pesaing memiliki set fitur yang mirip, apa yang membuat mereka menonjol? Desain terkadang dianggap hanya sebagai estetika atau apa yang membuatnya terlihat seperti merek kami. Tetapi ketika digunakan dengan, "UX," desain berarti arsitektur fitur dan keputusan yang dibuat tentang layar, langkah, alur, tata letak, proses, organisasi, dan menu.

UX adalah bagian dari proses perbaikan berkelanjutan, selalu berusaha untuk lebih memahami pengguna dan memilih serta merancang fitur dan produk yang paling sesuai dengan kebutuhan mereka, memecahkan masalah mereka, dan membawa mereka inovasi yang berarti.

McKinsey juga melaporkan bahwa, “Perusahaan harus merangkul desain secara holistik dan di awal proses daripada melihatnya sebagai alat kecil yang cocok di kemudian hari.” Tim yang berasumsi bahwa perhatian pada pengalaman pengguna adalah sesuatu yang dapat diminimalkan, dikecualikan, atau dilakukan setelah merilis produk mengambil pendekatan yang salah.

McKinsey mengumpulkan data kuantitatif dan menemukan bahwa perusahaan yang menganut desain UX menghasilkan pendapatan 32% lebih banyak dan pengembalian pemegang saham 56% lebih banyak dalam periode 5 tahun. Mendeklarasikan perusahaan Anda untuk menjadi "user-centric" tidak cukup. Anda harus berjalan dengan mengintegrasikan praktisi dan proses UX mulai dari perencanaan dan portofolio hingga pengembangan dan QA.

Proses Pengembangan Perangkat Lunak Dengan dan Tanpa UX

Jika perusahaan Anda tidak menyertakan spesialis UX dalam proses desain dan pengembangan perangkat lunak, proses Anda kemungkinan besar akan terlihat seperti gambar di bawah ini.

Seorang klien, manajer produk, CEO, atau seseorang dengan visi memberi tahu teknisi apa yang mereka inginkan. Rekayasa membangunnya, mengujinya, dan mendapatkannya di server pementasan atau produksi. Orang dengan penglihatan itu kemudian melihatnya dan, tahukah Anda, mereka tidak bahagia. Mereka menginginkan sesuatu yang berbeda atau telah berubah pikiran.

Rekayasa kemudian harus berputar kembali ke awal, mencari tahu apa yang sekarang diinginkan orang ini, membangun, menguji, dan menyilangkan jari bahwa inilah pesonanya.

Jika Anda memiliki ahli UX di tim, prosesnya sangat berbeda. Orang dengan visi itu datang ke UX dengan ide, data, dan poin keluhan pelanggan. Siklus UX melalui tugas-tugas dalam proses desain yang berpusat pada pengguna dan kemudian menguji konsep-konsep ini sebelum rekayasa menulis sebaris kode. Ini memastikan bahwa produk atau fitur yang sedang kami pertimbangkan untuk dibuat adalah eksekusi yang tepat dari ide yang tepat untuk pelanggan target kami.

Pengujian mungkin menunjukkan beberapa kekurangan, yang memungkinkan UX untuk beralih dan sering menguji lagi. Setelah proses UX, Anda memiliki desain yang diperiksa sepenuhnya yang siap untuk dikirim ke rekayasa.

Jika seseorang berubah pikiran di sepanjang jalan, orang itu berbicara dengan UX daripada memasukkannya sebagai permintaan perubahan kepada pengembang. UX menjalankan interferensi selama proses mereka dan tidak ada yang dikirim ke rekayasa tanpa UX terlibat dalam desain, keputusan, dan pengujian pada pelanggan nyata atau pola dasar.

Perubahan pikiran pada saat ini bukanlah bencana karena biaya bagi seseorang untuk berubah pikiran pada saat ini adalah minimal. Rekayasa belum mengirimkan cetak biru, mereka belum memulai, dan tidak memiliki apa pun untuk dibangun kembali. UX mengulangi desain mereka dan dapat melakukan pengujian pengguna untuk memastikan bahwa ide-ide tersebut cocok dan kuat dengan basis pelanggan. Perubahan pikiran menghabiskan waktu, tetapi dampak keseluruhan pada anggaran kecil.

UX Memiliki Proses yang Diformalkan

Desain yang berpusat pada pengguna (UCD) adalah proses formal yang mencakup tugas-tugas yang mengarahkan spesialis UX untuk meneliti, mendesain, membuat prototipe, menguji pada pengguna nyata atau pola dasar, dan kemudian mengulanginya berdasarkan pembelajaran dari pengujian.

Berfokus pada beberapa area ini, kami mulai dengan persyaratan dan diskusi awal tentang fitur dan proyek. Saat UX pertama kali mendapatkan persyaratan dan informasi proyek lainnya, penting untuk segera mulai berkolaborasi. UX seharusnya TIDAK mengetahui nanti bahwa mereka telah merancang sesuatu yang tidak dapat dibangun.

Mulailah dengan membawa pekerja atau manajer UX saat manajer produk atau proyek memutuskan fitur dan prioritas. Sebuah proyek tanpa nilai bagi pengguna dapat dihapus, menghemat waktu dan uang yang tak terhitung. Di sinilah memaksimalkan jumlah pekerjaan yang tidak dilakukan ikut bermain. Produk dan Rekayasa harus mendukung UX ketika mereka membuat lebih sedikit pekerjaan untuk Rekayasa dengan mengurangi atau menghapus fitur atau seluruh proyek. Namun, terlalu sering, proyek memiliki ego yang melekat dan rekan tim sering mengecualikan UX dari percakapan awal ini sehingga proyek tersebut didanai.

Penelitian adalah bagian penting dari apa yang dilakukan UX. Ini tidak berpusat pada pengguna tanpa melibatkan pengguna. Statistik dan data kuantitatif sangat bagus, tetapi tidak ada pengganti untuk mewawancarai pengguna, memahami mereka secara mendalam, dan mendapatkan data kualitatif. UX ingin tahu alasannya dan bukan hanya apa.

Penelitian UX juga membuat rekan satu tim berada di halaman yang sama dengan menyatukan semua orang di sekitar persona, pola dasar pelanggan target. Berdasarkan wawancara dengan pengguna, kami menggabungkan apa yang kami pelajari dan meringkas semua orang menjadi 6 atau lebih sedikit persona. Apa yang memotivasi mereka? Apa yang mereka butuhkan? Di mana peluang bagi perusahaan, produk, atau layanan kita?

Penggunaan persona terbaik adalah memasukkannya ke mana-mana. Produk membayangkan fitur berdasarkan persona (dan data yang bagus). Desain UX berdasarkan persona. Tes QA sambil membayangkan mereka adalah persona ini. Pemasaran dapat menambahkan detail demografis dan lainnya, tetapi mereka juga harus mempertimbangkan bagaimana suara merek, media sosial, dan iklan berbicara kepada persona.

Persona membantu pekerja non-UX menjauh dari, "Yah, saya suka cara ini," atau, "CEO suka cara ini." Kami merancang untuk pelanggan target ini dan jika Anda atau CEO tidak cocok dengan persona, maka UX tidak terpengaruh oleh ego atau preferensi pribadi. UX harus tetap berfokus pada pelanggan.

Arsitektur informasi berkaitan dengan hierarki, struktur, dan taksonomi. Ini bisa berupa navigasi situs, atau bisa juga bagaimana produk dikategorikan dalam database eCommerce. Kami ingin memastikan pelanggan akan dengan mudah menemukan produk berdasarkan kategori, meta data, dan filter.

Desain interaksi , terkadang juga disebut desain pengalaman, adalah apa yang kebanyakan orang pikirkan ketika mereka membayangkan UX. Ini adalah gambar rangka dan prototipe, cetak biru desain dan konsep. Ini akan menunjukkan alur proses, tata letak, menu, interaksi, jalur, pilihan, dan banyak lagi.

Prototipe UX seperti gambar rangka yang dihidupkan. Mereka adalah mockup digital interaktif yang dapat diklik. Kita tidak perlu menulis kode; kami memiliki perangkat lunak yang membantu kami membuatnya dengan cepat. Perusahaan yang mencari prototipe yang lebih realistis menggunakan Axure karena memiliki logika bersyarat, variabel, gerakan menggesek seluler, menyeret dan menjatuhkan, dan semua jenis pemicu peristiwa. Anda dapat membuat prototipe untuk hampir semua jenis perangkat.

Pembuatan prototipe UX dilakukan untuk:

• brainstorming
• Berkolaborasi
• Pengulangan
• Jelajahi solusi
• Pitch kepada investor (untuk startup)
• Uji prototipe untuk melihat apakah solusinya terhubung dengan baik dengan audiens target.
• Berikan model interaktif kepada pengembang atau rekan tim lainnya, yang sering kali lebih disukai daripada halaman dokumentasi (dan tidak ada model yang dapat diklik).

Sekarang beralih ke pengujian pengguna , juga disebut pengujian kegunaan, yang terjadi selama proses UX dan sebelum rekayasa menulis sebaris kode. Anda harus menguji konsep dan desain untuk memastikan bahwa ide dan pelaksanaannya fantastis untuk pelanggan sasaran.

Pengujian pengguna akan mengungkap kekurangan apa pun, memberi UX kesempatan untuk mengulangi ide, yang tidak mahal pada saat ini karena tidak ada yang perlu dibangun atau dibangun kembali oleh rekayasa.

Ada 5 alasan utama UX menjalankan tes sebelum dikirim ke engineering:

1. Penggunaan waktu dan sumber daya engineering dengan sebaik-baiknya. Jika Anda ingin peserta pengujian melihat produk jadi yang dibuat oleh para insinyur, Anda harus membangun dan mengujinya untuk bug. Jika pengujian UX membawa perubahan yang diperlukan, pengembang harus membangun kembali dan QA harus menguji ulang. Jika pengujian UX menunjukkan kegagalan konsep yang lebih besar, ini mungkin berarti bahwa waktu rekayasa benar-benar terbuang sia-sia karena ini bukan kode yang akan berakhir di mana saja. Konsepnya harus dipikirkan ulang, didesain ulang, dan baru diuji.
2. Iterasi di belakang layar. Ketika perusahaan baru saja membangunnya, mengirimkannya, mengulanginya, dan membangun dan mengirimkannya lagi, ini berarti bahwa pelanggan melihat berbagai versi. Mereka melihat pekerjaan yang sedang berlangsung dan menyaksikan sosis dibuat. Ini sering kali merupakan pengalaman yang membuat frustrasi dan membingungkan yang mengharuskan pelanggan untuk terus mempelajari kembali sistem yang sedang berkembang. Lebih baik mengulangi di balik layar dalam proses UX dan menjelaskan dengan penguji bahwa ini adalah versi prototipe atau demonstrasi.
3. Pemantauan dan pengukuran. Jika sebuah konsep baru dirilis secara langsung, peneliti UX tidak memiliki cara yang baik untuk melihat orang menggunakannya, mengajukan pertanyaan kepada mereka, dan mendapatkan jenis umpan balik yang dibutuhkan UX untuk menentukan apakah sesuatu sudah siap atau memerlukan iterasi lain. UX selalu ingin tahu mengapa, kualitatif, dan bukan hanya apa atau berapa banyak. Bagaimana pengguna membelanjakan, mengonversi, menarik, dll? Menghindari pengujian UX yang tepat membuat lebih sulit untuk mendiagnosis dan memperbaiki masalah atau masalah pelanggan.
4. Pengujian UX membayar sendiri. Pengujian UX bukanlah biaya yang besar. Beberapa alat pengujian pihak ketiga menginginkan di bawah $100 per peserta pengujian, beberapa memerlukan komitmen tahunan minimum ribuan dolar. Ini bukan pengeluaran yang besar mengingat anggaran keseluruhan perusahaan untuk proses pengembangan perangkat lunak dan pentingnya umpan balik pengujian awal. Putaran pengujian pengguna hampir selalu lebih murah dan bergerak lebih cepat daripada membuat programmer membangun sesuatu yang mungkin harus kita batalkan atau bangun lagi.
5. Pengujian pengguna memecahkan argumen. Jika perusahaan Anda tidak mengizinkan spesialis UX untuk membuat keputusan akhir tentang bagaimana produk dirancang, maka Anda mungkin menemukan UX bertentangan dengan produk, teknik, atau pemangku kepentingan ketika ada berbagai ide tentang apa yang harus dibangun dan dirilis ke pelanggan. Atau bagaimana jika UX memiliki dua ide yang kuat dan mereka bertanya-tanya mana yang lebih terhubung dengan pelanggan? Solusinya di sini adalah pengujian pengguna.

UX dapat membuat prototipe konsep. Yang terbaik adalah mempersempit persaingan menjadi dua desain terbaik, terutama jika Anda sudah dapat menemukan kompromi di seluruh ide dan anggota tim. Ini berarti kami tidak menguji apa yang diinginkan UX vs apa yang disukai produk vs apa yang disukai kepala teknik vs apa yang menurut master scrum terdengar seperti ide bagus vs apa yang disukai mitra hidup CEO.

Pengujian pengguna memungkinkan pelanggan berbicara dan membantu Anda menemukan arah yang tepat untuk fitur atau produk. Ini menyelesaikan argumen dengan menyediakan tim dengan data kuantitatif dan kualitatif keras yang memberi tahu semua orang ide mana yang paling mungkin membawa kepuasan pelanggan.

Ini bukan desain yang berpusat pada pengguna tanpa melibatkan pengguna. Ini berarti bahwa kami meneliti dan menguji dengan pelanggan nyata atau pola dasar daripada menebak, berasumsi, atau "kirim saja". Kami harus memastikan bahwa apa yang kami "kirimkan" telah diperiksa melalui pengujian pengguna dan merupakan eksekusi yang sangat baik dari ide yang bagus.

Apa yang Terjadi Ketika UX Dikelola atau Dikurangi?

Skype baru-baru ini mengumumkan bahwa desain ulang tahun 2017, yang bertujuan untuk membuatnya lebih seperti Snapchat, gagal. Pengguna tidak menginginkan, membutuhkan, atau menyukai fitur baru. Serangan baliknya cukup besar sehingga Skype membuat pengumuman 2018 bahwa mereka akan mendesain ulang Skype lagi. (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

Pakar UX akan tahu di banyak langkah proses mereka bahwa fitur-fitur ini kemungkinan besar tidak diinginkan atau gagal. Penelitian dengan target pengguna dapat dengan cepat mengungkapkan bahwa mereka tidak ingin Skype menjadi Snapchat. Membunuh proyek atau memutar pada titik awal ini dapat menghemat jutaan dolar Skype ditambah pers yang buruk dan keterasingan pelanggan.

Bahkan jika penelitian UX telah dilewati, pengujian prototipe UX pada pengguna akan memperjelas bahwa pelanggan tidak ingin Skype pergi ke arah ini. Dengan UX yang masih bergerak melalui prosesnya, engineering belum menulis sebaris kode pun. Ini bisa menghemat waktu, uang, dan sumber daya manusia yang luar biasa, merayakan kesederhanaan dan tidak perlu dilakukan oleh rekayasa kerja.

Proses UX yang gesit

Ingat prinsip-prinsip manifesto Agile. Prioritas tertinggi Anda adalah kepuasan pelanggan dengan membangun perangkat lunak yang berharga. Berikan pekerja (UX) lingkungan dan dukungan yang mereka butuhkan, percayai mereka untuk menyelesaikan pekerjaan. Maksimalkan jumlah pekerjaan yang tidak dilakukan. Perhatian terus menerus pada desain yang baik meningkatkan kelincahan.

Proyek yang bergerak maju perlu memberi UX landasan yang besar sehingga penelitian, desain, dan pengujian yang tepat dapat dimulai. Jangan undang UX ke rapat awal Anda dan kejutkan mereka dengan permintaan bahwa gambar rangka akhir harus dikirimkan dalam beberapa hari. Itu bukan UX.

Jangan lihat ini sebagai Big Design Up Front (BDUF), yang merupakan istilah yang dirancang untuk membuat orang merasa ngeri dan menyatakan bahwa ini adalah sesuatu yang harus kita hindari. Ketika sebuah proyek atau fitur berukuran besar atau baru, UX perlu menelusuri sebagian besar, jika tidak semua, proses desain yang berpusat pada pengguna. Untuk UX, bagian terkecil yang mungkin untuk fitur yang lebih besar adalah alur kerja atau proses pengguna. Jika kami merancang dan menguji sesuatu yang lebih kecil, kami menanggung risiko bahwa kami tidak mendapatkan gambaran besar tentang pengalaman pengguna yang sebenarnya.

Misalnya, jika kita mendesain alur di mana pengguna mendaftar dan membeli, kita tidak bisa hanya mendesain bidang pemilihan kata sandi dan mengirimkannya ke bagian teknik. Jika UX bekerja dalam potongan-potongan kecil, kapan seluruh proses akan diuji? Kami tidak dapat mengetahui reaksi pengguna terhadap seluruh aliran tanpa menguji seluruh aliran… yang berarti seluruh aliran harus dirancang sebelum masuk ke pengujian kegunaan.

Di mana fitur, cerita, atau perbaikan kecil, praktisi UX dapat melakukan subset dari proses desain yang berpusat pada pengguna dan bekerja lebih cepat. UX akan selalu berjalan secepat mungkin, tetapi spesialis UX yang hebat akan melakukan semua yang dia bisa untuk menghindari mengorbankan kualitas pekerjaan yang sedang dilakukan. Dalam pertempuran cepat vs baik, UX akan selalu memilih yang baik daripada yang cepat… dan Anda juga harus melakukannya.

Anggaran dan jadwal adalah yang menghalangi UX untuk mendapatkan umpan balik dan iterasi yang cepat. Praktisi UX selalu menginginkan umpan balik dan kesempatan untuk meningkatkan produk, yang bertujuan untuk merancang apa yang benar-benar berfungsi untuk pelanggan. Membawa praktisi UX sedini mungkin dalam manajemen dan perencanaan portofolio memungkinkan UX untuk memperkirakan waktu dan anggaran yang mereka perlukan; ini seharusnya tidak menjadi kejutan atau penyebab konflik.

Seorang Praktisi UX Adalah Bagian dari Tim Agile

Sematkan Desainer UX Anda di tim Agile. Undang mereka untuk merilis perencanaan, stand-up, retro, dan setiap pertemuan di mana UX mungkin dibahas. Izinkan UX untuk memperkirakan waktu mereka selama perencanaan rilis sehingga tidak ada kejutan tentang waktu yang dibutuhkan tugas UX. Jangan membuat keputusan tanpa mereka. Jika rekan tim UX Anda melewatkan rapat, tunggu hingga Anda dapat menemukannya secara langsung, melalui obrolan, email, atau metode apa pun yang digunakan perusahaan Anda.

Tetapkan pertanyaan, ambiguitas, atau bug ke rekan tim UX Anda di JIRA atau sistem pelacakan bug apa pun yang Anda gunakan. Pastikan masalah UX berada di sistem yang sama dengan masalah lainnya; jangan jatuhkan masalah UX di papan Trello jika Anda menggunakan VersionOne untuk yang lainnya.

Setelah UX memiliki landasan yang panjang, jika diperlukan untuk fitur atau produk ini, praktik terbaiknya adalah membuat UX menjadi 2 Sprint atau lebih sebelum rekayasa. UX dapat berlari bersama Anda. Dapatkan banyak cerita teknologi atau memperbaiki hutang teknologi ke dalam backlog. Dengan begitu, jika proses kreatif dan siklus UX berjalan terlambat atau membutuhkan lebih banyak sprint, pengembang dapat benar-benar gesit. Alih-alih menunggu UX, mereka dapat beralih ke beberapa buah gantung rendah yang diprioritaskan oleh produk atau teknik.

Juga pertimbangkan sumber daya, alokasi, dan staf. Bergantung pada ukuran proyek, tetapkan tidak lebih dari 3 proyek untuk satu desainer UX. Jika Anda memiliki peneliti UX ahli yang terpisah, yang juga melakukan pengujian dan analisis, tetapkan satu peneliti untuk tidak lebih dari 3 desainer UX. Jika praktisi UX Anda dikenal sebagai T-shaped, yang berarti dia juga memenuhi syarat dan sangat baik dalam penelitian, pengujian, dan sub-spesialisasi UX lainnya, maka pastikan dia tidak secara tidak sengaja menjadi hambatan dengan ditugaskan ke terlalu banyak proyek.

Mengukur Hasil

Tanpa kepuasan pelanggan, Anda mungkin tidak memiliki pelanggan. Anda dapat menggunakan metrik kepuasan pelanggan untuk menentukan bagaimana meningkatkan proses Anda dengan mengintegrasikan UX telah membuat perubahan positif.

• Lebih sedikit keluhan
• Ulasan aplikasi yang lebih baik
• Peringkat aplikasi yang lebih tinggi
• Lebih sedikit tiket dukungan
• Lebih sedikit panggilan pusat panggilan
• Semantik yang lebih positif dari posting sosial
• Lebih banyak pemasangan aplikasi, lebih sedikit pencopotan
• AOV (nilai pesanan rata-rata) meningkat
• Tingkat konversi yang lebih tinggi

Anda juga dapat mengukur sasaran DevOps yang diinginkan seperti waktu ke pasar dan waktu antar perbaikan. Berapa lama waktu yang dibutuhkan cerita, proyek, dan epos untuk sampai ke pasar sebelum dan sesudah revolusi UX Anda? Perkiraan waktu pengembang cenderung lebih akurat ketika mereka telah menyelesaikan desain UX yang menjadi dasar perkiraan mereka vs bekerja dari cerita atau apa pun yang Anda lakukan sekarang.

Jika UX menyediakan cetak biru dan itu diikuti, kami berharap teknik memiliki lebih sedikit pekerjaan dengan mengurangi perubahan mendadak dan membangun kembali. Desain UX yang lebih baik lebih awal, lebih sedikit perbaikan nanti.

Agile UX Adalah Investasi Yang Lebih dari Membayar Sendiri

Banyak manajer proyek melihat UX sebagai garis anggaran yang dapat dihapus atau dikurangi, dan manajer perekrutan merasa senang dengan gagasan menggabungkan tugas UX dengan peran lain. Namun, semakin banyak perusahaan yang belajar bahwa tidak ada pengganti untuk berinvestasi dalam proses UX yang tepat yang dilakukan oleh spesialis UX yang terlatih dan berpengalaman.

Eric Ries, penulis The Lean Startup , bertanya, “Bagaimana jika kita mendapati diri kita membangun sesuatu yang tidak diinginkan siapa pun? Kalau begitu, apa bedanya jika kita melakukannya tepat waktu dan sesuai anggaran?” Bahkan jika organisasi Anda tidak menggunakan metodologi Lean, peringatan tersebut tetap berlaku. Hasil yang diinginkan DevOps menggemakan hal ini ketika kami bertujuan untuk membangun hal yang benar bagi pelanggan, meningkatkan kepuasan pelanggan, dan mengembangkan fitur dengan nilai pelanggan yang tinggi.

Mengetahui pelanggan Anda, melibatkan pelanggan Anda dalam proses, dan membangun untuk kebutuhan dan preferensi mereka yang sebenarnya pada akhirnya lebih penting daripada jadwal, anggaran, kerangka kerja, dan alat. Percayalah bahwa jika Anda membangun eksekusi yang tepat dari ide yang tepat, pendapatan akan ada di sana.