Cara Meluncurkan Fitur Baru Tanpa Menyakiti Pengguna Setia

“Jadilah gesit; rilis lebih awal; sering rilis.” Kami tahu latihannya. Tetapi apakah secara strategis bijaksana untuk terus meluncurkan fitur secara sering? Terutama setelah produk yang Anda bangun mencapai ukuran tertentu, Anda mungkin tidak ingin mengambil risiko integritas aplikasi Anda dengan setiap rilis minor baru.

Hal terburuk yang dapat terjadi pada produk Anda adalah bahwa pengguna setia, pelanggan yang telah menggunakan satu fitur kecil itu secara konsisten selama bertahun-tahun, tiba-tiba tidak dapat menggunakannya dengan cara yang sama nyamannya. Perubahan mungkin lebih memberdayakan pengguna, tetapi pengalaman menjadi kurang mudah. Frustrasi dan kecemasan memasuki media sosial dengan cepat dan tiba-tiba, dan tekanan pada dukungan pelanggan untuk merespons secara bermakna dan tepat waktu meningkat setiap menit. Tentu saja, kami tidak ingin meluncurkan fitur baru hanya untuk menyadari bahwa fitur tersebut sebenarnya merugikan pengguna setia.

Bacaan Lebih Lanjut di SmashingMag: Tautan

• Bagaimana Kami Mulai Merilis Fitur Dua Kali Lebih Cepat
• Daftar Periksa Peluncuran Situs Web – 15 Pemeriksaan Penting Sebelum Anda Tayang
• Pendekatan yang Berpusat pada Pengguna Untuk Desain Web Untuk Perangkat Seluler
• Cara Meluncurkan Apa Pun

Kami dapat mencegahnya dengan menjadi lebih strategis saat meluncurkan versi baru produk kami. Dalam artikel ini, kita akan melihat strategi desainer produk dan teknisi front-end untuk menguji dan menerapkan fitur secara menyeluruh sebelum merilisnya ke seluruh basis pengguna, dan bagaimana menghindari masalah UX agar tidak muncul di jalan.

Sebelum menyelami strategi pengujian yang sebenarnya, mari kita mundur dan memeriksa kesalahpahaman umum tentang bagaimana fitur baru dirancang, dibangun, dan akhirnya diterapkan.

Kesalahpahaman Fitur Baru

Setiap kali fitur baru untuk produk yang sudah ada dirancang, fokus utamanya biasanya pada bagaimana tepatnya fitur itu harus diintegrasikan ke dalam antarmuka yang ada. Untuk mencapai konsistensi, desainer kami akan sering melihat pola yang ada dan menerapkan bahasa desain yang sudah ada untuk membuat fitur baru ini cocok dengan UI. Namun, masalah sering terjadi bukan karena komponen tidak bekerja sama secara visual, melainkan karena menjadi membingungkan atau ambigu ketika digabungkan dengan cara yang tidak terduga .

Mungkin salinan antarmuka ambigu di area situs web yang terkait tetapi jauh, atau hasil dari dua fitur yang digunakan secara aktif pada saat yang sama masuk akal dari perspektif teknis tetapi tidak sesuai dengan harapan pengguna atau memiliki implikasi kinerja utama dan merugikan UX .

Faktanya, dalam desain, banyak kombinasi inilah yang sangat sulit untuk diprediksi dan ditinjau secara menyeluruh. Salah satu cara untuk mendekati masalah saat sudah dalam proses desain adalah dengan mempertimbangkan outlier — gunakan kasus ketika ada kemungkinan salah. Bagaimana tampilan profil pengguna jika nama pengguna sangat panjang? Apakah ikhtisar email yang belum dijawab masih terlihat jelas ketika selusin label kotak masuk digunakan? Akankah filter baru masuk akal bagi pengguna yang baru saja mendaftar dan hanya memiliki beberapa email di kotak masuk mereka?

Merancang Pencilan: Tumpukan Antarmuka Pengguna

Bagaimana tepatnya kita bisa mendesain outlier setelah kita mengidentifikasinya? Strategi yang baik adalah mempelajari status antarmuka pengguna yang berbeda. “User interface stack”, sebuah ide yang diperkenalkan oleh Scott Hurff, serbaguna dan rumit, dan ketika kami mendesain antarmuka kami, biasanya tidak cukup untuk membuat mockup pixel-sempurna di Photoshop, Sketch atau HTML dan CSS — kami harus mempertimbangkan berbagai kasus dan status tepi: status kosong, status pemuatan, status parsial, status kesalahan, dan status ideal. Ini tidak sesederhana yang mungkin kita pikirkan.

Status kosong tidak harus kosong — kami dapat menggunakan pekerja layanan untuk memberikan pengalaman offline yang lebih baik kepada pengunjung biasa. Status parsial tidak harus rusak — kami dapat meningkatkan pengalaman dengan gambar yang rusak dan JavaScript yang rusak melalui peningkatan progresif.

Keadaan ideal mungkin berbeda secara signifikan dari maket "hasil sempurna" kami — karena preferensi pengguna khusus dan pilihan browser pengguna; beberapa konten dan font web mungkin tidak ditampilkan karena konfigurasi browser, misalnya.

Jadi, lanskapnya, seperti biasa, rumit, berbelit-belit, dan tidak dapat diprediksi, dan kita tidak dapat membuat risiko kesalahan dapat diabaikan, tetapi ini tidak berarti bahwa kita tidak dapat meminimalkan risiko secara efektif. Dengan menjelajahi outlier dan seluruh tumpukan antarmuka pengguna sejak awal, kami dapat mencegah masalah UX umum pada tahap desain awal. Namun, itu tidak menjadi lebih mudah di sisi teknis.

Efek Kupu-Kupu Dalam Penerapan

Bahkan perubahan kecil cenderung mengarah pada reaksi berantai, memperkenalkan bug di area dan situasi yang tampaknya sama sekali tidak terkait. Alasan utama untuk ini adalah banyaknya variabel yang memengaruhi pengalaman pengguna tetapi itu di luar kendali kami. Kami tahu cara kami menggunakan browser, tetapi itu tidak berarti kami tahu lebih banyak tentang konteks di mana pengguna memilih untuk melihat situs web yang kami buat tanpa lelah dan secara menyeluruh.

Sekarang, sementara perubahan kecil seperti padding pada tombol atau textarea yang ditingkatkan secara progresif mungkin tidak tampak seperti masalah besar, kami cenderung meremehkan dampak dari perubahan kecil atau fitur mengkilap ini dalam skala besar. Setiap kali kita membuat keputusan desain atau pengembangan, perubahan itu memang berdampak pada sistem kompleks yang sedang kita bangun, terutama karena komponen yang kita bangun tidak pernah berdiri sendiri.

Kenyataannya adalah bahwa kita tidak pernah hanya membuat tombol, kita juga tidak pernah hanya menulis fungsi JavaScript baru — tombol dan fungsi milik keluarga komponen atau pustaka, dan semuanya beroperasi dalam pengaturan tertentu, dan mereka tak terhindarkan terhubung ke yang lain. bagian dari sistem dengan properti mereka atau dengan ruang lingkup mereka atau dengan nama mereka atau dengan konvensi tidak tertulis tim.

Koneksi "diam" yang hampir tidak terlihat ini adalah alasan mengapa meluncurkan fitur itu sulit, dan mengapa memprediksi konsekuensi luas dari perubahan sering kali terbukti menjadi latihan dalam penglihatan yang tajam. Itulah mengapa sebaiknya hindari ketergantungan yang tidak perlu sejauh mungkin, baik dalam CSS atau JavaScript — mereka tidak akan membantu Anda dengan pemeliharaan atau debugging, terutama jika Anda mengandalkan perpustakaan yang tidak sepenuhnya Anda pahami .

Untungnya, untuk lebih memahami dampak perubahan, kita dapat menggunakan sumber daya seperti alat pengembang browser. Kita dapat mengukur jangkauan pemilih atau jangkauan fungsi JavaScript, dan terkadang ada baiknya untuk terus kembali ke sana selama pengembangan untuk menjaga ruang lingkup perubahan tetap lokal dan seminimal mungkin.

Ini membantu, tetapi juga hanya satu bagian dari cerita. Kami membuat asumsi, sadar dan tidak sadar, berdasarkan pengalaman kami sendiri dengan antarmuka dan kebiasaan kami sendiri — sering kali lupa bahwa asumsi mungkin (dan, karenanya, akan ) bervariasi secara signifikan dari pengguna ke pengguna. Sebagian besar aplikasi hanya memiliki satu antarmuka, tetapi antarmuka ini atau konfigurasinya dapat memiliki lusinan status — dengan tampilan yang berubah tergantung pada pengaturan dan preferensi pengguna.

Pikirkan tentang dasbor dengan kartu yang dapat disesuaikan (perangkat lunak analitik), klien email dengan tampilan "ringkas", "nyaman", dan "detail" (Gmail), antarmuka pemesanan yang berubah untuk pelanggan yang masuk dan untuk tamu, pengalaman membaca untuk orang yang menggunakan pemblokir iklan atau filter antivirus yang agresif. Efek kupu-kupu berdampak pada lebih dari sekadar basis kode; semua faktor eksternal juga dipertimbangkan, dan pengujian terhadapnya — tidak seperti pengujian unit atau QA pada umumnya — sangat sulit karena kita sering tidak tahu apa yang harus diuji.

Validasi Fitur Dan Maksimum Lokal

Kami dapat menggunakan diagnostik dan metrik untuk menentukan perubahan apa yang perlu dilakukan, tetapi dengan mengikuti data saja, Anda mungkin akan mengalami stagnasi pada apa yang kami sebut sebagai "maksimum lokal", keadaan antarmuka dengan desain yang cukup baik, tetapi sama sekali tidak memiliki inovasi karena selalu mengikuti iterasi logis yang dapat diprediksi. Saat mengerjakan proyek dan menjelajahi data, kami cenderung mengelompokkan fitur dalam empat keranjang berikut:

• Fitur rusak. . Fitur yang tampaknya rusak atau tidak efisien — tentu saja, kami perlu memperbaikinya;
• Fitur yang tidak digunakan. . Fitur yang berfungsi sebagaimana dimaksud tetapi jarang digunakan — sering kali merupakan tanda bahwa fitur tersebut harus dihapus atau sangat membutuhkan inovasi;
• Fitur penggunaan yang tidak terduga. . Fitur yang digunakan dengan cara yang sangat berbeda dari apa yang awalnya dibayangkan oleh pembuatnya — kandidat yang baik untuk penyempurnaan yang lambat dan terus-menerus;
• Fitur pekerja keras. . Fitur yang banyak digunakan dan tampaknya berfungsi sesuai rencana — dalam hal ini kami bertanya pada diri sendiri apakah ada cara untuk lebih meningkatkan UX mereka dengan menjelajahi proses iteratif yang lambat dan konsep inovatif yang sama sekali berbeda secara paralel.

Dua ember pertama sangat penting untuk menjaga antarmuka tetap berfungsi dan dapat digunakan, sedangkan dua ember terakhir sangat penting untuk membuat pengguna tetap terlibat dan senang. Idealnya, kami ingin mencapai kedua tujuan secara bersamaan, tetapi waktu, anggaran, dan batasan tim lebih diutamakan.

Namun, begitu iterasi baru atau ide baru dipilih, Anda mungkin tergoda untuk langsung mendesain atau membangun fitur baru. Tetapi bahkan sebelum memikirkan tentang bagaimana fitur akan cocok dengan antarmuka yang ada, itu adalah strategi yang baik untuk memvalidasi ide terlebih dahulu — dengan prototipe cepat dan riset pengguna. Cara umum untuk mencapai ini adalah dengan menggunakan proses berulang yang cepat, seperti sprint desain Google Ventures. Dengan mengulangi dalam beberapa hari, Anda dapat mengidentifikasi bagaimana fitur baru harus diterapkan dan/atau apakah itu berguna seperti yang Anda bayangkan pada awalnya.

Dengan sprint desain, kami memaparkan ide tersebut pada penelitian kegunaan sejak dini. Dalam metodologi Google Ventures, Anda akan menguji desain dengan lima pengguna sehari; kemudian, Anda akan mengulangi dan menjalani putaran pengujian desain baru. Alasan mengapa semua pengguna yang sama terlibat adalah karena jika Anda menguji desain yang berbeda dengan setiap pengguna hari itu, Anda tidak akan memiliki data yang valid untuk mengetahui elemen mana yang harus diubah. Anda memerlukan beberapa pengguna untuk memvalidasi satu iterasi desain.

Kami menerapkan model yang sedikit berbeda dalam sprint kami. Saat kami mulai mengerjakan fitur baru, setelah prototipe awal pertama dibuat, kami menyatukan desainer, pengembang, dan tim UX di ruangan yang sama, mengundang pengguna nyata untuk menguji, lalu mengulanginya dengan jadwal yang ketat. Pada hari pertama, penguji pertama (dua hingga tiga orang) mungkin dijadwalkan untuk wawancara 30 menit pada pukul 9.00, kelompok kedua pada pukul 11.00, yang berikutnya pada pukul 14.00, dan yang terakhir satu sekitar jam 4 sore. Di antara wawancara pengguna, kami memiliki "jendela waktu terbuka", ketika kami benar-benar mengulangi desain dan prototipe sampai pada titik tertentu kami memiliki sesuatu yang layak.

Alasan untuk ini adalah bahwa, sejak awal kami ingin menjelajahi arah yang sama sekali berbeda, terkadang bahkan berlawanan, dengan cepat; setelah kami mengumpulkan umpan balik pada antarmuka yang berbeda, kami dapat berkumpul menuju apa yang terasa seperti antarmuka "maksimum mutlak" . Kami bisa mendapatkan umpan balik yang sangat beragam pada iterasi desain yang sangat beragam dengan lebih cepat dengan cara ini. Umpan balik sebagian besar didasarkan pada tiga faktor: peta panas yang merekam klik pengguna, waktu yang dibutuhkan pengguna untuk menyelesaikan tugas, dan betapa menyenangkan pengalaman itu bagi mereka. Di akhir minggu ini, kami terus bekerja secara konsisten dengan jumlah pengguna yang lebih besar, sangat mirip dengan Google, memvalidasi desain baru secara permanen seiring berjalannya waktu.

Sejauh ini bagus, tetapi terkadang fitur baru yang tampaknya inovatif bertabrakan dengan fitur yang sudah ada, dan memiliki keduanya dalam antarmuka yang sama akan mengacaukan desain. Dalam hal ini, kami mengeksplorasi apakah salah satu opsi dapat dianggap sebagai perpanjangan dari yang lain. Jika bisa, maka kita mulai dengan mengulangi fungsi dan desainnya. Saat itulah kita harus memilih desain ulang radikal atau perubahan bertahap. Yang terakhir ini kurang berisiko dan akan menjaga pola interaksi yang akrab bagi pengguna, sedangkan yang pertama diperlukan jika perubahan penting tidak mungkin dicapai sebaliknya atau jika keuntungan dari perubahan tambahan akan terlalu dangkal.

Dalam kedua kasus tersebut, sangat penting untuk tetap fokus pada seluruh pengalaman pengguna produk, bukan pada nilai fitur tunggal dalam produk tersebut. Dan setelah Anda memilih fitur dan Anda telah merancang dan membangun prototipe pertama, saatnya untuk menguji.

Delapan Tingkat Pengujian

Nah, lalu, bagaimana kita secara efektif mencegah kesalahan dan kegagalan merayap ke lingkungan hidup yang sebenarnya? Berapa banyak pemeriksaan dan ulasan dan pengujian yang kami jalankan sebelum fitur di-deploy? Dan dalam urutan apa kita menjalankan tes ini? Dengan kata lain, seperti apa strategi pamungkas untuk meluncurkan fitur?

Salah satu strategi yang lebih baik untuk meluncurkan fitur diusulkan oleh Andrew Sumin, kepala pengembangan di Mail.ru, penyedia email utama di Rusia. Strategi ini tidak akan berlaku untuk setiap proyek, tetapi merupakan pendekatan yang masuk akal dan komprehensif untuk perusahaan yang melayani produk berukuran sedang dan besar kepada ribuan pelanggan.

Mari kita lihat strategi secara mendetail dan membahas delapan langkah peluncuran fitur, yang mencakup proses pengembangan produk Mail.ru:

1. uji dengan pengembang,
2. uji dengan pengguna nyata dalam lingkungan yang terkendali,
3. uji dengan pengguna di seluruh perusahaan,
4. uji dengan penguji beta,
5. uji dengan pengguna yang ikut serta secara manual,
6. split-test dan cek retensi,
7. lepaskan perlahan dan bertahap,
8. mengukur akibatnya.

Dalam kasus Mail.ru, fitur yang paling penting untuk tetap utuh tidak peduli apa yang menulis pesan (jelas). Itu adalah bagian antarmuka yang paling sering digunakan, dan membiarkannya tidak tersedia atau bekerja dengan tidak benar bahkan untuk beberapa detik akan benar-benar mustahil. Jadi, bagaimana jika kita ingin memperluas fungsionalitas area teks, mungkin dengan menambahkan beberapa fungsi pelengkapan otomatis pintar, atau penghitung, atau pratinjau samping?

1. Uji Dengan Pengembang

Semakin banyak waktu berlalu dalam pengembangan, semakin mahal untuk memperbaiki masalah. Sekali lagi, pikirkan tentang seberapa terhubung semua keputusan dalam pengembangan produk; semakin halus produk, semakin banyak keputusan yang harus dikembalikan, menghabiskan waktu dan sumber daya. Jadi, mengidentifikasi dan menyelesaikan masalah sejak dini baik dari perspektif bisnis maupun perspektif desain dan pengembangan.

Anda tidak dapat men-debug ide, jadi pengujian awal harus dilakukan selama produksi, pada prototipe pertama. Penguji pertama di Mail.ru, kemudian, adalah pengembang yang benar-benar menulis kode. Perusahaan mendorong karyawannya untuk menggunakan produk untuk komunikasi internal (dan bahkan komunikasi pribadi); jadi, pengembang dapat dianggap sebagai pengguna setia produk tersebut.

Langkah pertama cukup jelas: rancang dan bangun fitur, lalu uji, tinjau, dan luncurkan secara lokal di server pementasan. Di sinilah pengujian QA masuk, dengan alat yang komprehensif dan pelari tugas yang mencoba untuk merusak fitur dan antarmuka, berpotensi otomatis dengan alat pengujian monyet seperti Gremlins.js.

Hasilnya dipantau dan kemudian diumpankan kembali ke loop umpan balik untuk iterasi fitur berikutnya. Pada titik tertentu, pengembang akan merasa cukup percaya diri dengan build: perubahan tampaknya berfungsi seperti yang diharapkan, dan persyaratan telah dipenuhi. Saat itulah pengujian pengguna nyata dimulai.

2. Uji Dengan Pengguna Nyata di Lingkungan Terkendali

Ketika prototipe kerja pertama selesai, fitur diuji dengan pengguna sebenarnya dalam wawancara. Pelanggan diundang untuk menyelesaikan tugas, dan saat mereka melakukannya, tim UX memantau jalan buntu dan masalah yang muncul dan mengatasinya di tempat.

Namun, tidak hanya fitur baru yang sedang diuji; tujuan uji kegunaan adalah untuk memastikan bahwa fitur baru tidak memengaruhi komponen penting antarmuka, itulah sebabnya pengguna menyelesaikan tugas-tugas rutin, seperti menulis pesan dan membuka, membalas, dan menjelajahi email di kotak masuk mereka. Jika fitur baru dan fitur lama dipahami dengan baik, proses dapat dilanjutkan.

3. Uji Dengan Pengguna di Seluruh Perusahaan

Jelas, umpan balik dari uji kegunaan mendorong pengembang untuk memperkenalkan perubahan, yang kemudian memberi umpan balik kepada penguji kegunaan, bolak-balik hingga hasilnya tampaknya memiliki nilai untuk audiens yang lebih besar. Langkah selanjutnya adalah agar fitur tersebut disorot di dalam perusahaan: Email di seluruh perusahaan dikirim untuk mendorong semua rekan kerja untuk memeriksa fitur tersebut dan mengirimkan laporan, bug, dan saran di pelacak.

Dengan pengujian, tidak ada perbedaan besar antara pengguna di departemen "jauh" di dalam perusahaan dan pengguna di alam liar. Bahkan pengguna internal tidak tahu perubahan apa yang diharapkan atau tahu persis apa yang dilakukan fitur atau bagaimana seharusnya bekerja atau terlihat seperti itu. Satu-satunya perbedaan utama adalah rekan kerja dapat diminta untuk mengirimkan umpan balik atau meninggalkan komentar dengan cepat. Saat itulah formulir pemungutan suara diperkenalkan. Penguji tidak hanya dapat bermain dengan fitur tetapi juga menambahkan komentar dan memberikan suara positif atau negatif. Voting harus dipertimbangkan terhadap strategi produk dan persyaratan bisnis, tetapi jika pengguna dengan jelas menemukan fitur yang tidak berguna atau membantu, itu adalah cara yang sederhana dan efektif untuk mengumpulkan umpan balik dan untuk menguji apakah produk berfungsi seperti yang diharapkan.

4. Uji Dengan Penguji Beta

Jika suatu fitur telah melewati pemeriksaan teknis, pemeriksaan kegunaan, dan peninjauan di dalam perusahaan, langkah logis berikutnya adalah memperkenalkannya ke beberapa segmen audiens. Namun, alih-alih meluncurkannya ke segmen pengguna secara acak, tim mengirimkan fitur untuk ditinjau di antara penguji beta — pengguna yang telah memilih untuk berpartisipasi dalam pengujian dan mengirimkan masukan untuk fitur eksperimental. Mereka dapat menurunkan atau meningkatkan fitur, serta melaporkan bug dan melakukan potongan kode.

Tetapi bagaimana Anda memilih penguji beta yang sesuai? Nah, jika Anda ingin mendorong penguji untuk merusak antarmuka, Anda mungkin fokus pada pengguna setia tingkat lanjut dengan keterampilan teknis — pengguna yang dapat memberikan detail teknis tentang bug jika perlu, dan pengguna yang mengetahui antarmuka yang ada dengan cukup baik untuk mampu mengantisipasi masalah yang mungkin dimiliki pengguna lain.

Namun, Anda memerlukan kriteria untuk menentukan apakah pengguna cukup mahir untuk menjadi penguji beta. Dalam kasus klien email, bisa jadi seseorang yang menggunakan Chrome atau Firefox (yaitu mereka tahu cara mengubah browser default mereka), yang telah membuat lebih dari tiga folder di kotak masuk mereka dan yang juga telah menginstal aplikasi seluler.

5. Uji Dengan Pengguna yang Secara Manual Ikut Serta

Hingga saat ini, pengujian telah melibatkan sejumlah pengguna, konfigurasi, dan laporan pengujian yang dapat dikelola. Namun keragaman pengguna, sistem dan konfigurasi di luar, termasuk sistem operasi, browser, plugin, pengaturan jaringan, perangkat lunak antivirus dan aplikasi yang diinstal secara lokal, dapat sedikit lebih menakutkan dalam skala.

Dalam kasus Mail.ru, langkah selanjutnya adalah meluncurkan fitur di antarmuka langsung, di belakang bendera, dan mengirim email ke segmen pengguna aktif yang lebih besar ini, menghadirkan fitur baru dan mengundang mereka untuk mengaktifkannya di akun mereka. sendiri di antarmuka, biasanya dengan tombol "Perbarui" yang mengkilap. Untuk mengukur nilai fitur bagi pengguna yang sebenarnya, tim kembali menggunakan sistem pemungutan suara, dengan beberapa petunjuk di sana-sini, pada dasarnya menanyakan pengguna apakah fitur tersebut bermanfaat atau berguna. Perhatikan bahwa perbedaan antara level ini dan level sebelumnya adalah bahwa keikutsertaan manual melibatkan audiens yang jauh lebih besar — ​​banyak di antaranya tidak teknis sama sekali, tidak seperti penguji beta.

Jadi, waktu dan koordinasi itu penting . Anda mungkin tidak akan memilih hari acak untuk mengirim email ke pengguna aktif, karena Anda ingin tim dukungan pelanggan dan pengembang tersedia saat aliran laporan bug mulai masuk. Itulah sebabnya email dikirim di awal minggu, ketika semua (atau sebagian besar) pengembang tersedia dan tim dukungan siap beraksi, setelah diberi pengarahan dan terhubung secara aktif dengan pengembang melalui Skype atau Slack. Di perusahaan yang lebih kecil, Anda bahkan dapat meminta pengembang duduk selama beberapa jam di meja dukungan untuk menyelesaikan inti masalah lebih cepat dengan berbicara langsung kepada pelanggan.

6. Uji Terpisah dan Periksa Retensi

Dalam langkah-langkah sejauh ini, kecuali untuk pengujian kegunaan, semua penguji telah menggunakan fitur baru secara sukarela. Namun, jika Anda mengaktifkan fitur secara default, tiba-tiba pengguna harus menggunakannya, dan ini adalah jenis grup yang sangat berbeda, yang belum kami uji sama sekali.

Untuk memastikan Anda tidak menghentikan kebiasaan pengguna pasif, Anda dapat melakukan pengujian terpisah dengan tiga segmen kecil pengguna dan mengukur retensi . Lagi pula, Anda ingin memastikan bahwa versi baru berfungsi setidaknya sebaik yang sebelumnya. Identifikasi aktivitas paling penting di antarmuka dan ukur tidak hanya berapa banyak waktu yang dihabiskan pengguna untuk itu sebelum dan sesudah peluncuran, tetapi juga berapa banyak waktu yang berlalu hingga mereka kembali. Dalam kasus Mail.ru, retensi mengharuskan pengguna memeriksa email mereka dan menulis pesan. Semakin sering pengguna kembali, semakin tinggi retensi, yang merupakan indikator UX yang lebih baik.

Setiap segmen mendapatkan tampilan yang sedikit berbeda , yang memungkinkan kami menguji cara menampilkan fitur baru kepada semua pengguna nanti. Untuk segmen pertama, kami menambahkan fitur baru dan memberikan tutorial cara menggunakannya. Untuk segmen kedua, kami hanya menambahkan fitur baru. Untuk segmen ketiga, kita bisa membiarkan fitur apa adanya. Untuk semua segmen ini, kami dapat menerapkan perubahan pada saat yang sama, memilih jangka waktu yang wajar untuk menjalankan pengujian, mengukur retensi, dan kemudian membandingkan hasilnya. Semakin tinggi retensi segmen, semakin besar kemungkinan desain tersebut akan dipromosikan ke semua pengguna di kemudian hari.

7. Lepaskan Perlahan dan Bertahap

Jika sebuah fitur telah mencapai titik ini, maka fitur tersebut mungkin sudah berfungsi dengan baik untuk sebagian besar audiens. Inilah saatnya Anda dapat meluncurkannya secara bertahap ke semua pengguna — dengan permintaan pemungutan suara untuk mengumpulkan umpan balik. Jika umpan baliknya sebagian besar positif, Anda dapat terus meluncurkan fitur tersebut dan pada akhirnya akan menjadi bagian integral dari antarmuka. Jika tidak, Anda akan mengevaluasi umpan balik dan kembali ke lab untuk iterasi berikutnya.

Meluncurkan fitur tidak cukup, meskipun: Itu harus dikomunikasikan kepada pengguna. Cara umum untuk melakukannya adalah melalui email dan media sosial. Namun, tutorial panduan singkat yang menjelaskan nilai fitur dalam skenario kehidupan nyata mungkin juga membantu. Juga, jangan lupa untuk mengintegrasikan kotak saran untuk mengumpulkan umpan balik segera.

8. Ukur Akibatnya

Setelah fitur diluncurkan, kami dapat memantau kinerjanya dan mencoba berbagai metode untuk menarik perhatian, sehingga pengguna dapat melakukan tugas mereka dengan lebih efisien. Anda dapat melacak tugas yang paling umum atau halaman yang paling sering dikunjungi dan kemudian menampilkan sedikit catatan sebaris yang merekomendasikan cara yang sedikit lebih cerdas dan lebih cepat bagi pengguna untuk mencapai tujuan mereka, dan kemudian mengukur apakah pengguna lebih menyukai fitur baru ini atau metode biasa.

Jangan lupa untuk memberikan umpan balik kepada seluruh tim, tidak hanya pengembang atau desainer, sehingga mereka termotivasi dan terlibat dan melihat bagaimana orang menggunakan fitur yang awalnya tidak lebih dari ide kasar. Tidak ada yang lebih memotivasi daripada melihat orang-orang yang bahagia dan gembira menggunakan aplikasi persis seperti yang Anda bayangkan, atau dengan cara yang sama sekali berbeda. Ini juga akan menyuburkan pertumbuhan fitur tim berikutnya.

Proses peninjauan terlihat rumit dan menyeluruh, tetapi terkadang hanya waktu dan jaringan yang luas untuk pengujian pengguna yang akan mengungkap masalah. Misalnya, jika perubahan memengaruhi tampilan ikhtisar pesan masuk, tidak ada pengujian unit yang dapat mengungkap kesulitan yang mungkin dihadapi pengguna perangkat lunak bantu. Dalam antarmuka email, apa yang Anda ingin agar perangkat aksesibilitas dibaca terlebih dahulu: tanggal, pengirim, baris subjek, atau pesan itu sendiri? Cara Anda mengatur ulang kolom dalam ikhtisar mungkin mengubah cara pengguna memilih untuk mengakses informasi; jadi, mengizinkan mereka untuk mematikan fitur baru juga sangat penting.

Kesimpulan

Jadi, seperti apa strategi peluncuran itu? Anda bisa mulai dengan menjelajahi grafik dependensi untuk memahami seberapa jauh jangkauan perubahan Anda. Kemudian, Anda dapat menguji fitur tersebut dengan pengembang dan dengan pengguna nyata di lingkungan yang terkendali. Kemudian, Anda dapat meminta rekan kerja untuk meninjau fitur tersebut, sebelum mengirimkannya ke grup penguji beta tertentu. Terakhir, Anda dapat membuat fitur tersebut tersedia sebagai opsi bagi pengguna. Dan, sebelum mengaktifkan fitur untuk semua orang, Anda dapat menjalankan uji terpisah untuk mengetahui cara terbaik untuk memperkenalkan fitur tersebut, lalu mengukur tingkat retensi untuk tugas-tugas penting.

Jelas, penyebaran bukanlah proses linier . Sepanjang proses, Anda mungkin perlu mundur dua langkah untuk maju satu langkah — sampai Anda akhirnya memiliki kandidat rilis. Alur kerja yang dibahas di atas mungkin tampak sangat lambat dan tidak terlalu gesit, tetapi Anda secara drastis meminimalkan risiko pengguna tiba-tiba dihadapkan dengan masalah yang tidak terduga dan sebagai hasilnya memiliki pengalaman yang lebih rendah. Dalam beberapa situasi, itu mungkin sangat berharga.