Brief by evilfactorylabs

Brief by evilfactorylabs • Untuk obrolan makan siangmu seputar dunia pemrograman. Terbit sebelum jam 13.37 WIB setiap hari Senin & Selasa.

Mengukur yang layak diukur dalam membuat aplikasi

Tentang DX, UX, dan apa yang harus & mengapa perlu diukur?

Sebagai seorang Programmer yang membuat & mengembangkan aplikasi, tentu kita menginginkan aplikasi yang dibuat "terasa" bermanfaat, cepat & mudah digunakan, serta menyenangkan untuk dibuat.

Ada 2 fase yang biasanya dilalui ketika mengembangkan sebuah aplikasi: Build time & Compile time. Yang berarti, ada 2 jenis "pengalaman" yang akan dirasakan baik dari sisi pengembang ataupun disisi pengguna, yang dikenal dengan Developer Experience (DX) & User Experience (UX).

Sebelum kita membahas tentang angka, mari kita bahas sedikit tentang UX dan DX, alasan mengapa kita harus peduli dengan itu, dan apa dampaknya untuk kita.

Developer Experience

Developer Experience atau DX adalah tentang pengalaman seorang pengembang ketika mengembangkan sebuah aplikasi. Pengalaman pengembang ini bisa mencakup banyak kegiatan, yang biasanya topik intinya adalah tentang Produktivitas.

Lihat, bagaimana ketika menggunakan Ruby On Rails bisa membuat "Blog engine" dalam waktu ~30 menit. Juga, yang sudah "batteries included" yang singkatnya jika kamu ingin memiliki fitur dari mengirim email, menggunakan WebSocket, dsb itu sudah disediakan oleh Rails, yang mana yang perlu kita lakukan adalah tinggal meng-konfigurasinya saja, bukan membuatnya dari awal.

Yang intinya, kamu bisa lebih produktif ketika menggunakan Rails, sehingga bisa lebih fokus disisi bisnisnya daripada disisi engineering nya dan bisa merilis fitur lebih cepat kepada pengguna.

Selain itu, kepopuleran React bukanlah tanpa alasan. React (dan frontend framework lainnya yang menggunakan pendekatan komponen) membuat pengalaman baru dalam membuat UI yang mana lebih produktif & fun. Dengan menggunakan pendekatan komponen, UI bisa memiliki state nya sendiri yang juga ter-isolasi sehingga lebih terprediksi dan tidak membuat frustasi.

Juga, biasanya beberapa framework menyediakan Developer Tools untuk membuat pengembang menjadi lebih produktif lagi, seperti React & Vue devtools yang memudahkan pengembang dalam debugging, mengubah state, sampai time-travelling sehingga tidak perlu menghabiskan banyak waktu untuk menguji banyak skenario yang ada.

Ya, 2 kasus diatas adalah sedikit gambaran tentang "sesuatu" yang memiliki DX yang bagus. Sesuatu tersebut bisa berbentuk framework, library, dsb. Pengembang bisa jadi lebih produktif, seperti daripada fokus di "optimasi performa" dalam rendering UI, pengembang yang menggunakan React bisa lebih fokus dalam membuat UI yang enak dipandang & nyaman digunakan karena proses optimasi tersebut sudah dilakukan sedikit oleh React.

Singkatnya, jika kamu menggunakan sesuatu yang mana membuatmu tidak produktif dalam "men-deliver" nya kepada pengguna akhir—alias menjadi penghambat, pemblokir, kurang menyenangkan, dsb—bisa diasumsikan bahwa sesuatu yang kamu gunakan tersebut tidak memiliki DX yang bagus.

User Experience

User Experience atau UX adalah tentang pengalaman pengguna. Hal-hal yang berkaitan dengan apa yang dialami oleh pengguna terkait sesuatu yang kamu buat & kembangkan, itu termasuk dalam bidang UX.

Aplikasi lambat? Atau sulit digunakan? Hmm tulisan kurang kontras? Dsb pada dasarnya adalah bagian dari UX, karena UX bukan hanya tentang meng-eksploitasi psikologi pengguna demi meningkatkan nilai terhadap bisnis.

Perancang UX menjadi pekerjaan yang lumayan laku saat ini, karena para penggiat bisnis sudah merasakan keuntungannya terhadap peningkatan nilai bisnis yang dilakukan oleh seorang perancang UX.

Meskipun cakupan UX ini lumayan luas—bukan hanya sekedar membuat prototype atau mockup—tapi pekerjaan perancang UX untuk sekarang relatif banyak berurusan dengan yang sudah disebut tersebut mungkin karena "title" pekerjaannya sering disandingkan dengan UI alias biasanya adalah UI/UX Designer.

Singkatnya, jika kamu (seorang pengguna) merasakan "ketidaknyamanan" dalam menggunakan suatu aplikasi, berarti UX tersebut kurang bagus. Tidak nyaman ketika membaca artikel pada suatu situs berita karena halamannya dipaginasi? Tidak nyaman dengan "indikator" titik merah pada suatu aplikasi? Tidak nyaman dengan popup yang ngagetin? Thanks to UX Designer (and business people), karena itu akan meningkatkan traffic, open rate, dan angka lainnya yang mereka miliki.

Apa yang ingin 'kita' capai?

Ya, produktivitas adalah omong kosong jika kita tidak memiliki tujuan. Jika kamu mendapatkan saran dari siapapun itu (termasuk your Lead & VP) dalam menggunakan suatu teknologi demi alasan "produktivitas", jika mereka tidak memiliki jawaban "apa yang ingin dicapai dari produktivitas tersebut?", mungkin mereka hanya termakan oleh omongan orang lain. Atau hanya mengikuti tren.

Pencapaian adalah tentang ukuran, sebuah kondisi dimana sesuatu telah berhasil berada dikondisi tertentu. Jika pencapaian kamu adalah bangun tidur jam 07 pagi dalam seminggu, dan dalam seminggu tersebut kamu sudah berhasil melakukannya, ya, selamat! Kamu sudah mencapai sesuatu yang sudah kamu pilih.

Kembali ke pembahasan, UX & DX adalah tentang pencapaian. Tentang sesuatu yang diukur. Tentang hasil yang diinginkan. Pertanyaan nya, apa saja yang ingin dicapai? Mungkin kamu sudah tau jawabannya apa, jika belum, silahkan lanjut membaca tulisan ini.

Pengukuran

Disini kita bagi menjadi 2 fokus: Di build/development time dan di runtime. 2 fase tersebut sedikit mencerminkan antara UX & DX namun lebih dari sisi seorang pengembang.

Biasanya proses pengukuran ini susah-susah-gampang, kita terlalu terobsesi mengukur sesuatu yang bahkan mungkin sebenarnya tidak penting-penting amat untuk kebutuhan kita. Disini saya akan mencoba membahas sesuatu yang bisa diukur yang semoga masuk ke bagian "measure what matters" yang tapinya bukan sedang membahas tentang OKR.

So here we go.

Developer Experience

TL;DR:

  • Number of release
  • Build time
  • Error numbers

Number of release

Ingat kalau DX adalah tentang produktivitas? Ya, semakin cepat untuk merilis sesuatu berarti developer semakin produktif dalam mengembangkan sesuatu termasuk membuat fitur baru; Memperbaiki bug, dan melakukan "bersih-bersih" terhadap hal-hal yang bersifat internal (ya, melakukan bersih-bersih kode contohnya).

Lihat bagaimana Rails membantu kamu untuk mengembangkan fitur menjadi lebih cepat, atau Dtrace yang membuat investigasi untuk memory leaks menjadi lebih menyenangkan, dan juga Docker yang membuat provisioning menjadi lebih mudah.

Yang maksudnya, ketika kita ber-investasi pada sesuatu berarti kita mengharapkan hasil yang lebih baik dari apa yang sudah kita investasi tersebut. Ya, ROI. Salah satu "ukuran" yang bisa digunakan dalam ber-investasi pada sesuatu seputar DX adalah Time to Release.

Jika ketika menggunakan Rails malah proses rilis menjadi lebih lambat dari sebelumnya, selamat, kamu sudah ber-investasi pada sesuatu yang salah (at least untuk organisasimu).

Dan ya, time is money, right?

Build time

Lihat, bagaimana pengembang PHP lebih produktif dari pengembang Java karena tidak ada proses build yang memakan lumayan banyak waktu? Jika sekali build memakan waktu 20 detik, dan pengembang pada hari itu membuat 12 function, jika setiap selesai membuat 1 function dia melakukan build, 240 detik/4 menit dihabiskan hanya untuk menunggu build.

Dan ya, kondisi diatas terlihat kurang realistis, bukan? Itu hanya gambaran saja menggunakan angka yang sekecil-kecilnya. Bayangkan jika memiliki 666 unit tests, dan lihat berapa waktu yang dihabiskan hanya untuk menunggu unit tests selesai di-eksekusi?

Ya, kondisi diatas bisa diselesaikan salah satunya dengan incremental build ataupun test, tapi itu menjadi bagian implementasi. Memiliki build time yang relatif cepat salah satu menjadi faktor bahwa tool tersebut memiliki DX yang bagus. Ada yang ingat dengan komik dari XKCD dibawah?

https://xkcd.com/303/

Sepertinya tidak perlu pembahasan lebih lanjut tentang ini karena sudah lumayan jelas, ya?

Error numbers

Meskipun ini terkait dengan UX juga, tapi sumber utama terjadinya error adalah dari seorang pengembang. Faktor yang menyebabkan ini bervariasi, bisa dari kekurang-pahaman pengembang terhadap sesuatu yang digunakan, ketoledoran pengembang, apapun.

Ya, error/bug akan selalu ada. Tapi banyak faktor yang membuat error/bug tersebut sulit untuk hadir. Salah satunya dengan menggunakan tools yang tepat, termasuk bahasa pemrograman; Library, framework.

Yang paling inti dari error numbers disini adalah tentang bagaimana error tersebut bisa sulit terjadi. Dan bila sekiranya terjadi, bagaimana agar proses "perbaikan" tersebut mudah & menyenangkan untuk dilakukan.

Kesimpulan

Bagian DX adalah tentang ber-investasi pada teknologi yang tepat sesuai dengan kebutuhan & kondisi yang dimiliki. Bagaimana cara melakukan pengukurannya, ini lumayan sulit.

Untuk Number of Release mungkin kamu bisa menggunakan bantuan CI (seperti GitLab CI), untuk Build time ini relatif (dan kamu bisa 'langsung' bertanya kepada developer yang bersangkutan), dan untuk Error numbers bisa menggunakan Error Trackers (seperti Sentry).

Atau bisa membuat tools sendiri, tapi selalu pertimbangkan biaya Membeli vs Membangun.

User Experience

TL; DR:

  • Downtime numbers
  • Performance
  • Accessibility

Downtime numbers

Siapa yang tidak frustasi ketika sedang ingin menggunakan sesuatu (misal aplikasi dompet digital) ketika digunakan malah sedang down? Sekilas ini bukanlah tugasnya seorang UX Designer, tapi ini adalah tentang pengalaman pengguna.

Beruntung bila pengguna bisa mengetahui apakah layanan sedang down atau tidak dengan melihat ke halaman Status nya—sehingga pengguna bisa tau jika misalnya sedang down, berarti masalah berada disisi layanan bukan mereka—jika tidak ada?

Bagaimana bisa seorang perancang pengalaman pengguna tidak "aware" dengan masalah ini? Yang bahkan mungkin masalah ini berdampak ke "rancangan" yang mereka buat menggunakan mockup tersebut, seperti kondisi percuma tampilan bagus & mudah digunakan, kalau gak bisa diandalkan!

It's okay kalau urusan ini adalah urusannya orang Backend, atau DevOps, atau SRE kalau memang organisasinya lumayan besar. Tapi angka ini adalah bagian fundamental terhadap "kepuasan" seorang pengguna. Ini bukan perdebatan antara menggunakan Erlang atau Rust, apalagi Docker atau Kubernetes.

Tapi tentang pengalaman yang akan dirasakan oleh pengguna, karena pengguna tidak peduli apakah lu pada pakai Docker ataupun Kubernetes, kalau nyatanya malah banyak down nya daripada up nya.

Performance

Hampir semua pengembang sudah tau (dan bosan) dengan bagian ini, namun kenyataannya memang begitulah adanya. Ya, pengguna peduli dengan performa, which is good & bad at the same time.

Performa ini mencakup:

  • Angka latensi
  • Waktu response
  • Waktu memuat
  • Angka memori yang digunakan

Latensi adalah tentang "celah" antara proses dan memuat, response adalah tentang proses tersebut diterima, memuat adalah tentang response tersebut selesai dieksekusi, dan yang terakhir adalah tentang bagaimana 3 poin tersebut berjalan.

Pengguna membuka halaman beranda, server menerima dan memproses permintaan tersebut.

Angka latensi disini bisa diambil dari DNS Query (frontend), autorisasi (backend), validasi (backend), dan waktu sampainya permintaan ke layanan yang bertanggung jawab (backend).

Waktu response ini bisa diambil dari autorisasi juga, validasi juga, database query, dan "perancangan tampilan" bila ada.

Waktu memuat ini bisa diambil dari bagaimana cara server mengirim response ke client, bagaimana client memproses dari yang sudah diberikan tersebut, dsb.

Angka memori bergantung dengan & berdasarkan proses diatas. Siapa yang tidak frustasi setelah menunggu lama permintaan malah ditambah merasakan "lama" alias berat dalam penggunaan?

Dan sekali lagi, ya, mungkin ini bukan pekerjaan nya seorang perancang pengguna, bukan? Tapi sekali lagi, ini berdampak kepada pengalaman yang dirasakan oleh pengguna.

Ingin diperjelas lagi tentang percuma tampilan bagus & mudah digunakan, kalau gak bisa diandalkan?

Aksesibilitas

Akhirnya, ke yang lebih spesifik ke seorang perancang.

Aksesibilitas pada dasarnya adalah tentang to exclude no one. Dan sepertinya terlihat naif bila kita "merasa mencapai" untuk 2 bagian sebelumnya itu, namun sayangnya pencapaian tersebut hanya didapat (dan dirasakan) dari sebagian orang yang mungkin sedikit beruntung.

Meskipun ini tidak spesifik tentang "menulis kode", "merancang piksel", dan "membuat sistem yang dapat diandalkan" namun teknologi adalah tentang memberdayai manusia. Teknologi hadir untuk membantu (pekerjaan) manusia, semua manusia. Bukan hanya beberapa manusia.

Enggak bisa banyak berbicara tentang aksesibilitas karena belum memiliki pengalaman dan data yang pasti, tapi paragraf sebelumnya-lah yang saya yakini.

Tapi, berbicara sebagai salah satu seseorang yang sedikit beruntung, saya pun merasa "frustasi" bila suatu aplikasi memiliki panduan warna yang tidak nyaman dipandang.

Atau, melihat tulisan yang sulit dibaca.

Dan hey, siapa yang tidak frustasi (bila berbicara seputar praktik) ketika menggunakan "keyboard workflow" yang biasa digunakan, namun tidak bekerja sesuai harapan?

Yang maksudnya, bila berbicara dari sisi saya sebagai salah satu orang yang sedikit beruntung saja masih merasakan "frustasi" yang terjadi diseputar aksesibilitas, apalagi yang selain seperti saya?

It's okay aplikasi mu jarang banget down dan memiliki performa yang sangat cepat, tapi bila hanya dapat dirasakan khusus untuk beberapa orang saja, ya untuk apa? Bagian ini bisa menjadi salah satu "refleksi" terhadap sisi manusia dari teknologi.

Karena teknologi bukan hanya tentang engineering & designing. Dan angka "to exclude no one" ini bisa menjadi angka yang paling "sukses" ketika apa yang kita buat, bisa digunakan oleh semua orang. Tidak terbatas oleh ras, agama, suku, budaya, ataupun keterbatasan fisik, kognitif, mental, sensorik, dan emosional.

Kesimpulan

Bagian UX adalah bukan tentang ber-investasi pada teknologi yang tepat sesuai dengan kebutuhan & kondisi yang dimiliki. Melainkan tentang hasil dari suatu pengembangan & rancangan, terlepas dari tools yang digunakan.

Dan untuk mengukur seputar UX tidak sesulit seperti DX, karena "nilai" dari investasi terhadap UX ini langsung berdampak terhadap bisnis secara langsung.

Untuk seputar Downtime Numbers, bisa menggunakan StatusPage yang melakukan monitoring terhadap layanan dan menampilkan 'status' nya kepada pengguna.

Untuk seputar Performance, bisa menggunakan Pingdom; Datadog, atau New Relic untuk backend (atau bisa cari alternatif lain dari 3 itu) dan bisa menggunakan SpeedCurve, Calibre, atau New Relic (juga) untuk frontend.

Untuk seputar Accessibility, bisa menggunakan Lighthouse (via web.dev/measure), Tenon, dan pastinya secara manual menggunakan hatimu sendiri sebagai manusia.

Penutup

Kenapa harus peduli dengan ini? Karena inilah salah satu biaya terkait "maintenance" dalam membuat aplikasi.

Ketika kamu memutuskan untuk membuat sebuah aplikasi, beberapa hal yang disebutkan disini menjadi tanggung jawab kamu sebagai pemilik ataupun pengembang dari aplikasi tersebut.

Kita disini tidak membahas perdebatan antara "UX vs DX", "mengapa UX dan DX sulit berjalan bersama", dsb karena 2 topik tersebut masuk kebagian implementasi.

Melainkan, kita hanya membahas seputar "tradeoff" yang terjadi ketika kita menentukan sesuatu terkait UX dan DX. Dan bagaimana untuk mengetahui apakah yang dipilih & dikorbankan itu "worth" bila tidak diukur?

...Apalagi bila tidak memiliki alasan pasti dalam membuat keputusan terhadap sesuatu.

Menikmati tulisan ini?

Blog ini tidak menampilkan iklan, yang berarti blog ini didanai oleh pembaca seperti kamu. Gabung bersama Loading... yang telah membantu blog ini agar terus bisa mencakup tulisan yang lebih berkualitas dan bermanfaat!

Pendukung

Dukung Mengapa saya harus mendukung?
You've successfully subscribed to Brief by evilfactorylabs
Great! Next, complete checkout for full access to Brief by evilfactorylabs
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.