[🛠] Operations Automation #5: Mengubah prototipe gagal menjadi kriteria audit UI

✨ Ringkasan GPT-5.6 Sol

Catatan tentang mengubah kartu besar penuh ruang kosong dan table yang rusak menjadi kriteria audit UI bersama untuk pencarian, filter, baris multiline, download view saat ini, dan klasifikasi risiko pengeditan, alih-alih menambal tiap layar secara terpisah.

Kartu besar dan ruang longgar merusak layar

Saya sedang mendesain ulang layar pengelolaan cuti untuk pekerja kantoran dan administrator berusia 50 tahun ke atas. Persyaratannya meminta teks besar, area interaksi besar, dan ruang yang cukup. Prototipe menafsirkan kata-kata itu dengan cara paling sederhana dan paling buruk.

Angka yang seharusnya muat dalam satu baris dipecah menjadi tiga—nama item → angka besar → penjelasan tambahan—lalu dimasukkan ke kartu raksasa. Tiga kartu menghabiskan seluruh layar pertama, sedangkan pekerjaan yang sebenarnya harus segera ditangani pengguna terdorong ke bawah. Layar permohonan menumpuk calendar, ringkasan, dan input dalam kotak putih besar yang terpisah. Pada table riwayat, nilai utama kosong dan hanya badge status yang tersisa. Bahkan muncul scroll horizontal.

Ketika sebelumnya saya memperbaiki table dan filter yang terhimpit pada perangkat mobile nyata, saya mengira menghilangkan overflow dan pemenggalan yang rusak sudah cukup untuk memperbaiki layar. Prototipe ini menunjukkan masalah yang lebih mendasar. Layar yang tidak rusak dan layar yang benar-benar dapat digunakan adalah dua hal yang sama sekali berbeda.

Kriteria audit UI sudah rusak sebelum layarnya

Masalah yang lebih besar adalah layar seperti ini tetap lolos dari proses audit terpisah.

Audit memeriksa apakah route dapat dibuka, teks terpotong, control dapat ditekan, serta warna atau jarak sangat melenceng. Namun, pertanyaan berikut tidak diwajibkan.

• Apakah pengguna dapat menemukan pekerjaan yang harus ditangani sekarang pada layar pertama?
• Apakah nilai yang diperlukan untuk satu keputusan terkumpul dalam satu view?
• Apakah ruang kosong menjelaskan hubungan informasi, atau hanya mengisi ukuran component?
• Apakah pencarian, filter, pengurutan, jumlah total, dan hasil table membentuk satu alur?
• Apakah hasil yang sedang dilihat dapat di-download apa adanya dan digunakan kembali?
• Apakah nilai yang boleh diedit dibedakan dari riwayat yang tidak boleh ditimpa?

Jika suatu masalah tidak ada dalam audit, Agent dapat melihatnya tetapi tetap meloloskan layar. Karena itu, alih-alih mengurangi padding layar demi layar, saya lebih dulu mengubah kriteria audit bersama agar kegagalan yang sama tidak dapat lolos lagi.

Collection menyatukan pencarian, hasil, dan download

Referensi yang paling banyak saya pelajari adalah table pengelolaan permohonan pada app cuti lain. Bantuan resminya juga menjelaskan pencarian berdasarkan tanggal, filter permohonan, serta alur persetujuan atau penolakan dalam mode administrator web sebagai satu pekerjaan.¹ Hal yang paling terlihat pada gambar referensi bukan jumlah fitur, melainkan jarak di antara fitur tersebut.

Periode dan jenis permohonan berada tepat di atas hasil. Kolom pencarian sejajar dengan masing-masing kolom, sedangkan jumlah total permohonan dan download terlihat dalam view yang sama. Nilai yang perlu dibaca bersama—tanggal, kondisi sebelum dan sesudah perubahan, serta selisih jam kerja—dikelompokkan menjadi beberapa baris dalam satu cell, bukan dengan terus menambah kolom. Status dan action yang tersedia juga berlanjut dalam baris yang sama.

Struktur ini saya jadikan contract bersama untuk collection, bukan hanya disalin ke satu layar cuti.

• Table, grid, daftar padat, dan list view calendar menempatkan blok search/filter tepat di atas hasil.
• Periode dan scope, pencarian, filter cepat, filter rinci, kondisi yang diterapkan, jumlah total/saat ini, reset, dan download berada dalam satu view.
• Nilai untuk keputusan yang sama dikelompokkan dalam cell multiline dengan urutan informasi utama → informasi pendukung → peringatan bersyarat.
• Tinggi baris ditentukan oleh isi. Pemakaian beberapa baris bukan alasan membuat mini card dengan tinggi tetap.
• Download mengekspor seluruh hasil yang sesuai dengan kondisi saat ini, bukan hanya beberapa baris yang terlihat pada page saat ini.
• Export mempertahankan scope, periode, pencarian, filter, pengurutan, waktu acuan, dan kolom pekerjaan yang terlihat oleh pengguna.
• Data pribadi dan materi audit tidak kehilangan download sepenuhnya; keduanya menerapkan izin, masking, dan audit yang sama.

Memeriksa hanya bahwa “ada tombol download” akan gagal lagi. Jumlah data, baris perwakilan, filter yang diterapkan, pengurutan, dan masking pada layar nyata juga harus dibandingkan dengan file hasil download.

Cara mengedit dibedakan berdasarkan risiko data

Memperbaiki nilai langsung di table memang praktis. Namun, jika semua cell dibuat seperti Excel, persetujuan, buku besar, dan bukti hukum juga dapat ditimpa seperti input biasa.

Karena itu, saya lebih dulu mengelompokkan sifat perubahan sebelum memilih control pengeditan.

Sifat perubahan	Interaction default
Satu nilai berisiko rendah yang dapat dikembalikan	Inline edit dengan affordance edit yang terlihat
Perubahan aman berulang pada banyak baris	Editable-grid mode yang eksplisit
Beberapa field yang membutuhkan konteks sekitar	Side panel yang mempertahankan posisi daftar
Input atau konfirmasi singkat dan mandiri	Modal dengan satu tujuan
Perubahan berisiko tinggi, tanggal berlaku, izin, versioned, atau append-only	Workflow preview-and-apply atau correction yang terpisah

Double-click, Enter, dan F2 hanya menjadi akselerator bagi pengguna mahir. Pintu masuk pengeditan tidak boleh disembunyikan hanya di balik ketiganya. Grid membutuhkan navigasi keyboard, penanda cell yang berubah, validation, undo, pembatalan seluruh perubahan, konflik stale, preview sebelum diterapkan, dan readback sesudah diterapkan. Persetujuan, penolakan, dan peristiwa buku besar append-only bukan sasaran cell edit.

Aturan audit bersama dipisahkan dari contract produk

Jika semua yang dipelajari dari layar referensi ditulis sebagai aturan khusus Leave Operations, project berikutnya akan mengulangi kesalahan yang sama. Sebaliknya, jika tahap persetujuan cuti, dokumen promosi, dan koreksi buku besar dimasukkan ke Skill bersama, kriteria bersama akan berubah menjadi spesifikasi desain satu produk.

Karena itu, saya memisahkan batasnya.

Aturan bersama dan Skill audit UI mencakup jenis kegagalan berikut.

• Mengubah scalar pendek menjadi kartu mandiri yang sangat besar
• Memecah label, nilai, dan penyebut secara mekanis menjadi tiga baris
• Menjauhkan pencarian dan filter dari hasil
• Collection tanpa jumlah total, reset, atau download view saat ini
• Table yang menyebarkan nilai terkait ke terlalu banyak kolom atau memaksa baris multiline memiliki tinggi tetap
• Export dengan izin atau kondisi view saat ini yang berbeda dari layar
• Pengeditan yang hanya tersembunyi di balik hover atau double-click
• Menimpa data berisiko tinggi, versioned, atau append-only melalui cell atau popup biasa

Dokumentasi Leave Operations secara terpisah memetakan prinsip tersebut ke setiap page dan view. Table kotak persetujuan, pegawai, promosi, buku besar, konflik absensi, hasil pesan, dan ponsel kerja masing-masing memiliki contract pencarian, filter, pengurutan, dan download. Area yang membutuhkan perubahan berulang seperti pegawai dan afiliasi juga dipisahkan dari persetujuan dan buku besar yang tidak boleh diedit langsung.

Layarnya belum diperbaiki

Pekerjaan ini belum memperbaiki UI produk yang sebenarnya. Saya mengubah aturan bersama, Skill audit khusus UI, dan contract layar per produk, lalu menyimpan gambar referensi bersama hash aslinya. Layar desktop Leave Operations belum diterapkan berdasarkan contract tersebut, dan pekerja kantoran serta administrator berusia 50 tahun ke atas juga belum menyelesaikan pekerjaan sendiri dari entry point normal.

Meski begitu, setidaknya prototipe berikutnya tidak boleh lolos dengan alasan yang sama. Teks besar dan area interaksi yang cukup luas tetap dipertahankan, tetapi tidak boleh menjadi alasan untuk menggembungkan layar. Tujuannya bukan kepadatan informasi rendah, melainkan kepadatan informasi tinggi dengan beban kognitif rendah.

Referensi

1. Pusat Bantuan Shiftee, Mengelola Permohonan. Halaman ini menjelaskan alur mode administrator web untuk menemukan permohonan berdasarkan rentang tanggal dan filter, menyetujui atau menolak setiap permohonan, lalu berpindah ke permohonan berikutnya. ↩