Membawa Proses Desain yang Lebih Baik ke Organisasi Anda

Sebagai desainer dan peneliti pengalaman pengguna (UX), keluhan paling umum yang kami dengar dari pengguna adalah:

“Mengapa mereka tidak memikirkan apa yang saya butuhkan?”

Faktanya, banyak organisasi memiliki tim yang berdedikasi untuk memberikan apa yang dibutuhkan pengguna dan pelanggan. Semakin banyak pengembang perangkat lunak yang ingin bekerja dengan desainer UX untuk membuat kode antarmuka yang akan digunakan dan dipahami pelanggan. Masalahnya adalah bahwa proyek perangkat lunak yang kompleks dapat dengan mudah terjebak dalam prioritas yang bersaing dan kebingungan tentang apa yang harus dilakukan selanjutnya.

Hasilnya adalah desain yang buruk yang menghambat produktivitas. Misalnya, efisiensi dalam perawatan kesehatan terhambat oleh rekam medis elektronik (electronic medical record/EMR). Keluhan tentang sistem perangkat lunak ini sangat banyak. Tak terkecuali Dr. Steven Ugent, dokter kulit yang berbasis di Boston dan alumnus Yale Medical School.

Sejak 2010, Dr. Ugent telah menggunakan dua sistem EMR: Sebelum 2010, ia menyelesaikan pekerjaan tepat pukul 5:15 setiap hari. Sejak dia dan rekan-rekannya mulai menggunakan EMR, dia biasanya bekerja setengah jam hingga 1,5 jam di malam hari. “Saya tidak tahu ada dokter yang senang dengan sistem rekam medis mereka. Hal gilanya adalah saya jauh lebih efisien saat menggunakan pena dan kertas.”

Sistem EMR kikuk, tidak fleksibel, dan sulit untuk disesuaikan. Ugent, misalnya, tidak dapat menyematkan foto langsung ke catatan grafiknya. Sebagai gantinya, dia harus membuka folder dengan foto tahi lalat dan kemudian membuka folder lain untuk melihat teksnya. Pengaturan ini sangat merepotkan bagi dokter kulit yang sangat bergantung pada foto saat merawat pasien.

Ugent secara ringkas meringkas masalah dengan EMR:

“Orang-orang yang mendesainnya [sistem EMR] tidak memahami alur kerja saya. Jika mereka melakukannya, mereka akan merancang sistem yang berbeda.”

Dokter tidak sendirian dalam frustrasi mereka dengan perangkat lunak kikuk. Konsumen dan profesional di seluruh dunia membuat keluhan serupa:

“Mengapa saya tidak dapat menemukan apa yang saya butuhkan?”

"Mengapa mereka membuatnya begitu sulit?"

“Mengapa saya harus membuat login ketika saya hanya ingin membeli produk ini. Aku memberi mereka uang. Apakah itu tidak cukup?”

Kontributor utama perangkat lunak kikuk adalah proses desain yang cacat. Dalam artikel ini, kami akan menguraikan empat masalah proses desain dan menjelaskan cara mengatasinya.

1. Kompleksitas
2. Sindrom Rilis Berikutnya
3. Waktu Tidak Cukup Untuk Iterasi Desain
4. Menyerahkan Kontrol Kepada Vendor Luar

1. Kompleksitas

Skala, banyak pemangku kepentingan, dan kebutuhan akan kode yang canggih adalah di antara banyak faktor yang berkontribusi pada kompleksitas proyek perangkat lunak besar.

Namun, kadang-kadang diabaikan adalah hukum dan peraturan yang kompleks. Misalnya, asuransi sangat diatur di tingkat negara bagian, menambah lapisan kompleksitas bagi perusahaan asuransi yang beroperasi di banyak negara bagian. Bank dan serikat kredit tunduk pada peraturan sementara utilitas harus mematuhi undang-undang lingkungan negara bagian dan federal.

Produk dan perangkat lunak perawatan kesehatan yang tunduk pada peraturan FDA menawarkan tantangan yang lebih besar. Masalahnya bukan karena peraturan itu tidak masuk akal. Keselamatan adalah yang terpenting. Masalahnya adalah waktu, anggaran, dan perencanaan yang diperlukan untuk memenuhi persyaratan FDA.

Seperti yang dijelaskan oleh Jeff Horvath, Ph.D., konsultan UX dengan pengalaman luas dalam perawatan kesehatan: “Persyaratan ini menambahkan beberapa urutan besarnya pada ketelitian untuk menulis protokol pengujian, pengaturan pengujian, pengumpulan data, analisis, kontrol kualitas, dan mendapatkan persetujuan untuk melakukan penelitian sejak awal.” Misalnya, satu putaran pengujian kegunaan melompat dari enam minggu (kerangka waktu yang wajar untuk tes kegunaan standar) menjadi enam bulan. Dan itu dengan satu putaran pengujian kegunaan . Seringkali, dua atau lebih putaran pengujian diperlukan.

Tingkat ketelitian ini merupakan peringatan bagi perusahaan yang baru bekerja dengan FDA. Lebih dari sekali, Horvath telah menghadapi percakapan yang sulit dengan klien yang tidak siap untuk perpanjangan waktu dan anggaran tambahan yang diperlukan untuk memenuhi persyaratan FDA. Sulit, tapi perlu. "Membayar untuk teliti," kata Horvath. Pada tahun 2018 FDA menyetujui hanya 11% dari pengiriman pra-pasar.

Tuntutan pada peneliti, perancang, dan pengembang lebih tinggi untuk perangkat lunak perawatan kesehatan yang membutuhkan kepatuhan FDA daripada produk perangkat lunak tradisional. Sebagai contoh:

• Peneliti UX hanya dapat melakukan satu atau dua sesi uji kegunaan per hari dibandingkan dengan lima hingga enam sesi per hari yang lebih umum untuk perangkat lunak standar.
• Desainer UX harus tetap memperhatikan setiap aspek interaksi pengguna dengan perangkat lunak. Bahkan satu interaksi yang membingungkan dapat menyebabkan seorang dokter melakukan kesalahan yang dapat membahayakan kesehatan pasien. Untuk alasan yang sama, desainer UI harus menggambar antarmuka yang tetap setia pada setiap interaksi.
• Kerangka waktu yang lebih lama untuk pengujian desain dan kegunaan berarti bahwa upaya pengkodean pengembang harus direncanakan dengan hati-hati. Pengembang yang terampil dan bermaksud baik sering kali ingin mengubah kode segera setelah informasi baru tersedia. Meskipun pendekatan ini dapat bekerja dalam organisasi yang dipraktikkan dengan baik dalam iterasi yang cepat, pendekatan ini membawa risiko saat merancang dan mengkodekan sistem yang kompleks.

Kegagalan untuk mengelola kompleksitas dapat berakibat fatal seperti yang terjadi ketika Danielle McCray dirawat di Rumah Sakit Memorial Tallahassee saat dia akan melahirkan. Untuk meringankan ketidaknyamanannya, petugas kesehatan menghubungkannya ke mesin analgesia yang dikendalikan pasien, pompa infus yang dapat diprogram.

Delapan jam kemudian McCray dinyatakan meninggal karena overdosis morfin. Faktor utama dalam tragedi ini adalah desain pompa infus yang digunakan untuk memberikan obat. Pompa membutuhkan 27 langkah pemrograman. Kegagalan untuk mengatasi kompleksitas tersebut dengan merancang antarmuka pengguna yang lebih intuitif berkontribusi pada kematian yang tidak perlu.

Larutan

Solusinya adalah dengan mengakui dan mengatasi kompleksitas. Hal ini terdengar logis. Namun, seperti dijelaskan di atas, peraturan FDA yang rumit sering kali mengejutkan para pemimpin perusahaan. Penolakan tidak berhasil. Gagal merencanakan berarti organisasi Anda kemungkinan akan jatuh ke dalam 89% pengajuan pra-pasar yang ditolak FDA pada tahun 2018.

Saat melakukan uji kegunaan, peneliti pengalaman pengguna harus mengambil tiga langkah untuk mengelola kerumitan yang terkait dengan peraturan FDA:

1. Moderator (orang yang menjalankan tes kegunaan) harus sangat perhatian. Misalnya, jika pemindaian MRI mengharuskan teknisi untuk mengikuti urutan langkah yang ketat saat menggunakan perangkat lunak terkait, moderator harus mengamati dengan cermat untuk menentukan apakah peserta mengikuti instruksi pada surat tersebut. Jika tidak, tugas tersebut dinilai sebagai kegagalan yang berarti bahwa desain antarmuka dan dokumentasi terkait akan memerlukan modifikasi;
2. Moderator juga harus melacak panggilan dekat. Misalnya, seorang peserta mungkin awalnya melakukan langkah-langkah yang tidak berurutan, menemukan kesalahan, dan memulihkan diri dengan mengikuti urutan yang benar. FDA menganggap ini nyaris celaka, dan moderator harus melaporkannya;
3. Moderator juga harus menilai pengetahuan peserta. Apakah dia percaya bahwa dia telah mengikuti urutan yang benar? Apakah keyakinan ini akurat?

2. Sindrom Rilis Berikutnya

Salah satu faktor dalam kegagalan untuk mengakui kompleksitas adalah pola pikir fix-it-later yang kita sebut sindrom rilis berikutnya. Bug perangkat lunak tidak menjadi masalah karena “kami akan memperbaikinya di rilis berikutnya.” Penekanan pada kecepatan di atas kualitas dan keamanan membuatnya terlalu mudah untuk menunda penyelesaian masalah yang sulit.

Siapa pun yang terlibat dalam desain dan pengembangan produk harus mengatasi sindrom rilis berikutnya. Dua contoh membuat intinya:

• Kami menemukan kelemahan desain yang serius dengan perangkat lunak pelacakan perawatan kesehatan klien. Perusahaan memilih untuk merilis perangkat lunak tanpa mengatasi masalah ini. Tidak mengherankan, pelanggan tidak senang.
• Kami melakukan tes kegunaan untuk serikat kredit besar yang berbasis di AS. Para peserta adalah penasihat keuangan berpengalaman. Pengujian mengungkapkan kelemahan desain yang serius termasuk ikon status yang membingungkan, tombol dengan tujuan yang tidak jelas, dan tautan yang hampir tersembunyi yang mencegah peserta menampilkan data penting. Ingat, jika pengguna tidak melihatnya, itu tidak ada. Ketika kami melaporkan temuan tersebut, tanggapannya adalah: “Kami akan memperbaikinya di rilis berikutnya.” Seperti yang diharapkan, aplikasi web tidak diterima dengan baik. Tanggapan dari pengguna termasuk: “Mengapa Anda meminta kami untuk meninjau aplikasi jika Anda tidak berniat membuat perubahan?”

Solusi: Tolak Mentalitas Fix-It-Next-Time

Solusinya adalah mengatasi masalah desain yang serius sekarang. Kedengarannya langsung. Namun, bagaimana Anda meyakinkan pembuat keputusan untuk mengubah pola pikir “perbaiki nanti” yang sudah mengakar?

Kuncinya adalah mengalihkan pembicaraan tentang pencapaian dari penyampaian produk ke nilai yang diciptakan. Misalnya, tim yang meluangkan waktu untuk merevisi desain berdasarkan riset pengguna cenderung melihat reaksi pelanggan yang lebih baik dan, seiring waktu, meningkatkan loyalitas pelanggan.

Perkuat kasus dengan menggunakan data kuantitatif untuk menunjukkan kepada pengambil keputusan hubungan langsung antara riset pengguna dan peningkatan pendapatan serta pengalaman pelanggan yang positif.

Mendefinisikan ulang nilai, pada dasarnya, merupakan peningkatan proses karena menetapkan serangkaian prioritas baru yang melayani pelanggan dan kepentingan jangka panjang perusahaan Anda dengan lebih baik. Seperti yang dilaporkan McKinsey dalam The Business Value of Design: “Perusahaan-perusahaan kuartil teratas merangkul pengalaman pengguna penuh; mereka meruntuhkan penghalang internal di antara desain fisik, digital, dan layanan.”

3. Waktu Tidak Cukup Untuk Iterasi Desain

Terkait dengan sindrom rilis berikutnya adalah waktu yang tidak cukup untuk mengulangi desain berdasarkan temuan penelitian atau perubahan kebutuhan bisnis. “Kami tidak punya waktu untuk itu,” adalah ungkapan umum dari pengembang dan pemilik produk. Desainer yang bekerja di lingkungan Agile sering kali ditekan untuk menghindari "menahan" tim pengembangan.

Kecepatan pengembangan seiring, dan perangkat lunak dirilis. Kita semua telah melihat hasil dari aplikasi telepon yang membingungkan, hingga perangkat lunak rekam medis yang kikuk, hingga antarmuka pengguna yang rumit untuk penasihat keuangan yang dirujuk di atas.

Solusi: Paku Desain

Salah satu solusi datang dari dunia coding. Dalam artikelnya “Fitting Big-Picture UX Into Agile Development”, Damon Dimmick menawarkan gagasan tentang lonjakan desain, “gelembung waktu yang memungkinkan desainer untuk fokus pada masalah UX yang kompleks.” Mereka masuk ke dalam kerangka Scrum dengan sementara menggantikan sprint biasa.

Paku desain menawarkan beberapa keuntungan:

• Mereka memungkinkan tim UX untuk fokus pada masalah holistik dan menghindari terjebak dalam masalah desain granular yang terkadang ditekankan dalam satu sprint;
• Mereka menawarkan kesempatan untuk mengeksplorasi pertanyaan UX yang kompleks dari tingkat tinggi. Jika diperlukan, tim desain UX juga dapat terlibat dalam pemikiran yang berpusat pada desain kapan saja untuk menyelesaikan tantangan UX yang lebih besar;
• Dengan mengadopsi lonjakan desain, tim UX dapat memanfaatkan fleksibilitas yang sama yang digunakan tim pengembangan dalam proses tangkas dan mencurahkan waktu yang dibutuhkan untuk fokus pada masalah desain yang tidak selalu cocok dengan scrum sprint standar;
• Pengembangan yang tidak terpengaruh oleh keputusan desain dapat dilanjutkan.

Secara alami, iterasi desain sering memengaruhi bagian kode tertentu untuk situs, aplikasi, atau produk perangkat lunak. Karena alasan ini, selama lonjakan desain, kode apa pun yang kemungkinan akan terpengaruh oleh lonjakan desain tidak dapat bergerak maju. Tapi, seperti yang Dimmick nyatakan dengan jelas, "penundaan" ini kemungkinan akan menghemat waktu dengan menghindari pengerjaan ulang. Tidak masuk akal untuk menulis kode sekarang dan kemudian menulis ulang beberapa minggu kemudian setelah tim menyetujui desain yang direvisi. Singkatnya, menunda beberapa pengkodean sebenarnya menghemat waktu dan anggaran.

4. Terlalu Mengandalkan Vendor

Mengatasi kompleksitas, menolak sindrom rilis berikutnya, dan memberikan waktu untuk iterasi sangat penting untuk proses desain yang efektif. Bagi banyak perusahaan, pertimbangan lain adalah hubungan mereka dengan vendor perangkat lunak. Vendor ini memainkan peran penting, bahkan kritis, dalam pembangunan. Namun, memberi mereka terlalu banyak pengaruh membuat sulit untuk mengontrol produk Anda sendiri.

Tentu saja, kita harus memperlakukan rekan kerja dan vendor dengan hormat dan membuat permintaan yang wajar. Namun, itu tidak berarti bahwa perlu untuk menyerahkan semua pengaruh seperti yang terjadi selama masa jabatan saya di sebuah perusahaan keuangan besar.

Saat bekerja di perusahaan ini sebagai desainer UX, saya sering menemukan dinamika ini:

Manajer : “Hei, Eric, bisakah Anda mengevaluasi perangkat lunak klaim yang akan kami beli ini? Kami hanya ingin memastikan itu berfungsi sebagaimana mestinya.”

Saya : “Tentu, saya akan mengirimkan temuan awal saya pada akhir minggu ini.”

Manajer : “Hebat”

Minggu berikutnya:

Manajer : “Terima kasih atas ulasannya. Saya melihat bahwa Anda menemukan tiga masalah serius: Sulit menemukan nomor untuk klaim yang ada, layar dengan terlalu banyak teks yang sulit dibaca, dan kesulitan untuk kembali ke layar sebelumnya saat memproses klaim baru. Itu memprihatinkan. Apakah menurut Anda masalah itu akan menghambat produktivitas?”

Saya : “Ya, saya pikir masalah ini akan meningkatkan stres dan waktu pemrosesan di Pusat Klaim. Saya cukup khawatir karena pekerjaan saya sebelumnya dengan tim Janet menunjukkan bahwa perwakilan Pusat Klaim sudah sangat tertekan.”

Manajer : “Sangat senang mengetahuinya. Saya baru saja mengirim cek. Saya akan meminta vendor untuk memperbaiki masalah sebelum mereka mengirim. ”

Saya (berteriak dalam hati): “Tidaaaaaaak!”

Manajer yang bermaksud baik ini justru melakukan hal yang salah. Dia meminta perubahan setelah mengirim cek. Tidak mengherankan bahwa vendor tidak pernah membuat perubahan yang diminta. Mengapa mereka? Mereka memiliki uang mereka.

Skenario ini tidak hanya dimainkan berulang kali di perusahaan itu, tetapi saya telah menyaksikannya sepanjang karir UX saya.

Larutan

Solusinya jelas. Jika produk vendor tidak memenuhi kebutuhan pelanggan dan bisnis, dan perubahan yang Anda minta berada dalam cakupan, jangan membayar sampai vendor membuat perubahan. Ini benar-benar sederhana.

Kesimpulan

Dalam bagian ini, kami telah mengidentifikasi empat hambatan umum untuk desain kualitas dan solusi yang sesuai:

1. Peraturan dan standar yang kompleks
   Solusinya adalah dengan mengakui dan mengatasi kompleksitas dengan merancang jadwal yang realistis dan anggaran yang cukup untuk penelitian dan desain berulang.
2. Perangkat lunak pengiriman dengan bug dengan janji untuk memperbaikinya nanti
   Solusinya adalah menghindari sindrom rilis berikutnya dan mengatasi masalah serius sekarang. Membujuk pembuat keputusan dengan mendefinisikan kembali arti nilai dalam organisasi Anda.
3. Waktu tidak cukup untuk iterasi desain
   Solusinya adalah memasukkan lonjakan desain dalam proses pengembangan tangkas. Gelembung waktu ini untuk sementara menggantikan sprint dan memungkinkan desainer untuk fokus pada masalah UX yang kompleks.
4. Terlalu mengandalkan vendor
   Solusinya adalah dengan mempertahankan leverage dengan menahan pembayaran akhir sampai vendor membuat perubahan yang diminta selama perubahan ini berada dalam lingkup proyek asli.

Solusi keempat sangat mudah. Sementara tiga yang pertama tidak mudah, mereka konkret karena dapat diterapkan langsung pada proses desain yang ada. Implementasinya tidak memerlukan reorganisasi besar-besaran atau jutaan dolar. Ini hanya membutuhkan komitmen untuk memberikan pengalaman yang lebih baik.