Desain matriks persetujuan dimulai dari ambang, penyetuju cadangan, substitusi, dan eskalasi sehingga tampilan mencerminkan jalur keputusan yang nyata.
Tampilan yang rapi bisa menyembunyikan proses yang berantakan. Jika logika persetujuan tidak ditentukan dulu, orang mungkin melihat tombol Setuju dan Tolak tapi tetap tidak tahu siapa yang harus bertindak, kapan mereka harus bertindak, atau apa yang terjadi selanjutnya.
Kebingungan itu muncul cepat dalam pekerjaan nyata. Seseorang mengajukan permintaan, itu masuk ke aplikasi, dan pertanyaan pertama adalah, 'Apakah ini ke manajer, ke keuangan, atau keduanya?' Tampilan tampak selesai, tetapi jalur keputusan hilang.
Ini terjadi karena tampilan membuat aturan terlihat lebih sederhana daripada kenyataannya. Formulir dapat menampilkan status, komentar, dan tombol aksi, tetapi tidak bisa menebak matriks persetujuan nyata di balik proses. Jika bisnis punya batasan jumlah, aturan departemen, atau delegasi sementara, UI mulai rusak saat kasus-kasus itu muncul.
Seringkali hanya diperlukan satu pengecualian untuk membuat pekerjaan keluar dari aplikasi. Mungkin umumnya persetujuan ke kepala departemen, kecuali saat permintaan mendesak, di atas jumlah tertentu, atau penyetuju sedang cuti. Jika kasus itu tidak pernah dipetakan, orang kembali ke email, chat, atau spreadsheet.
Masalah yang lebih besar muncul: tiap tim mulai menerapkan versi aturan sendiri. Operasi mengirim permintaan dengan cara satu, keuangan dengan cara lain, dan dukungan menangani pengecualian berbeda dari HR. Aplikasi menjadi layar bersama untuk keputusan yang tidak konsisten, bukan proses bersama.
Tanda-tanda peringatan biasanya mudah dikenali:
Perubahan kebijakan mengekspos kelemahan ini dengan cepat. Ketika logika tersimpan di dalam tampilan bukan dalam aturan alur kerja yang jelas, setiap perubahan ambang atau peran berubah menjadi pengerjaan ulang UI. Itu memperlambat tim, menciptakan kesalahan baru, dan membuat pengguna kehilangan kepercayaan.
Tampilan seharusnya mencerminkan jalur keputusan, bukan mendefinisikannya. Ketika matriks jelas terlebih dahulu, UI menjadi lebih sederhana, lebih stabil, dan lebih mudah digunakan.
Mulai dari logika keputusan, bukan tampilan. Matriks persetujuan yang solid dimulai sebagai tabel sederhana yang menunjukkan siapa yang bisa menyetujui apa, dalam kondisi apa, dan apa yang terjadi saat seseorang tidak tersedia. Jika logika itu kabur, antarmuka yang halus pun akan membingungkan orang.
Untuk setiap tipe permintaan, petakan tingkat persetujuan secara berurutan. Tuliskan peran yang memiliki tiap langkah dan apa yang diperbolehkan pada langkah itu: setuju, tolak, tinjau, atau minta perbaikan. Peran lebih baik daripada nama orang karena orang pindah, tim berubah, dan proses harus tetap berjalan.
Lalu tentukan aturan yang mengubah rute. Jumlah adalah pemicu yang jelas, tetapi jarang satu-satunya. Aturan alur persetujuan sering bergantung pada wilayah, departemen, jenis vendor, kategori permintaan, atau tingkat risiko. Jumlah yang sama mungkin biasa bagi satu tim dan sensitif bagi tim lain.
Ketidakhadiran juga butuh aturan. Jika penyetuju utama tidak ada, siapa yang menggantikan segera? Jika pengganti bersifat sementara, tanggal mana yang berlaku? Tanpa itu, permintaan akan berhenti karena tidak ada yang tahu siapa pemilik minggu ini.
Batas waktu sama pentingnya. Putuskan apa yang terjadi saat permintaan tidak mendapat respons. Anda bisa mengirim pengingat setelah satu hari, eskalasi setelah dua hari, dan memberi tahu operasi setelah tiga hari. Pilihan itu memengaruhi label status, notifikasi, dan tampilan antrean, jadi harus diselesaikan sebelum desain layar dimulai.
Matriks praktis biasanya menjawab lima pertanyaan dasar:
Jika Anda memetakan jawaban itu lebih awal, sisa pembangunan jadi jauh lebih mudah.
Gunakan tabel, papan tulis, atau spreadsheet. Buat sesederhana agar manajer, pemimpin tim, dan pemilik proses bisa memahaminya dalam satu kali baca.
Pertama, daftar setiap tipe permintaan yang butuh persetujuan. Jangan memaksakan semuanya ke satu alur generik jika bisnis sudah memperlakukan permintaan berbeda. Permintaan pembelian, pengembalian dana, persetujuan diskon, dan permintaan akses sering membutuhkan penyetuju, batas, dan tenggat waktu yang berbeda.
Selanjutnya, tulis penyetuju pertama dan setiap titik keputusan setelahnya. Untuk tiap tipe permintaan, catat siapa yang meninjau pertama dan apa yang terjadi setelah disetujui atau ditolak. Ikuti jalur sampai mencapai hasil akhir seperti disetujui, ditolak, dikembalikan untuk diedit, atau dibatalkan.
Setelah itu, tambahkan ambang yang mengubah rute. Di sinilah banyak tim terjebak nanti. Jika permintaan di bawah $500 ke pemimpin tim tetapi di atas $500 ke kepala departemen, tuliskan sekarang. Jika permintaan mendesak melewatkan langkah atau mengikuti jalur lebih cepat, catat juga.
Lalu rekam pengecualian, tenggat, dan keadaan akhir. Sertakan kasus seperti dokumen hilang, duplikasi, pelanggaran kebijakan, dan persetujuan yang lewat waktu. Aturan belum selesai sampai Anda tahu bagaimana perilakunya saat terjadi masalah.
Akhirnya, tinjau draf bersama orang yang hari ini menyetujui permintaan. Tanyakan di mana pekerjaan biasanya macet, di mana orang melewati langkah, dan apa yang terjadi saat penyetuju normal tidak tersedia. Kebiasaan nyata sering mengungkap aturan yang tidak pernah didokumentasikan.
Contoh kecil membuat ini jelas. Bayangkan permintaan pembelian: perlengkapan kantor di bawah $200 ke pemimpin tim, perangkat lunak antara $200–$2.000 ke manajer departemen, dan di atas itu juga perlu persetujuan keuangan. Jika formulir tidak menangkap jumlah dan kategori sejak awal, UI tidak bisa mengirim permintaan ke jalur yang tepat.
Ambang hanya bekerja jika orang bisa membacanya cepat dan membuat pilihan yang sama tiap kali. Jika aturan mengatakan 'pembelian kecil' atau 'vendor berisiko tinggi', orang akan menafsirkannya berbeda. Gunakan angka tetap, tanggal, dan kondisi bernama.
Aturan yang lebih jelas terdengar seperti ini: 'Sampai $1.000 ke pemimpin tim. $1.001 sampai $5.000 ke manajer departemen. Lebih dari $5.000 ke keuangan dan direktur.' Tidak ada yang perlu menebak ke mana permintaan masuk.
Jumlah umum digunakan, tetapi jangan jadikan itu satu-satunya pemicu jika proses Anda bergantung pada faktor lain. Pembelian perangkat lunak bernilai rendah dari vendor baru mungkin perlu pemeriksaan lebih dibandingkan pesanan lebih besar dari pemasok yang disetujui.
Sebagian besar tim hanya membutuhkan seperangkat aturan routing kecil. Contoh umum: rentang jumlah, status vendor, kategori pembelian, departemen, dan urgensi. Yang penting bukan banyaknya aturan, melainkan apakah semua orang menerapkannya sama.
Urutan aturan juga penting. Jika orang tidak tahu kondisi mana yang menang, mereka akan merutekan permintaan yang sama berbeda-beda. Pilih satu urutan dan konsisten. Anda bisa memeriksa status vendor dulu, lalu kategori, lalu jumlah—atau sebaliknya. Keduanya bekerja jika semua orang mengikuti urutan yang sama.
Juga bantu tentukan siapa yang bisa melanggar ambang, dan kapan. Tanpa itu, staf menunggu terlalu lama atau melewati proses lewat email dan chat. 'Direktur Keuangan dapat menyetujui permintaan di atas batas selama penutupan akhir bulan' berguna. 'Pimpinan senior dapat membuat pengecualian' tidak.
Uji sederhana efektif: berikan contoh permintaan yang sama ke tiga orang dan tanya ke mana harus dikirim. Jika mereka memberi tiga jawaban berbeda, ambang masih terlalu kabur.
Matriks yang kuat tidak berhenti pada penyetuju utama. Pekerjaan nyata bergerak ketika seseorang cuti, sakit, atau tidak merespons. Jika Anda tidak merencanakannya sejak awal, tampilan mungkin rapi sementara proses diam-diam macet.
Mulai dengan menamai penyetuju pengganti untuk setiap langkah penting. Ini harus orang atau peran yang punya konteks yang tepat, bukan hanya 'manajer berikutnya' secara default. Jika pemimpin keuangan menyetujui pengeluaran di atas jumlah tertentu, tentukan siapa yang mengambil alih ketika orang itu tidak tersedia.
Pengganti sementara perlu batasan. Substitusi harus diberi hak persetujuan hanya untuk periode tertentu, misalnya tanggal cuti. Itu menjaga tanggung jawab jelas dan menghindari kasus di mana seseorang mempertahankan akses persetujuan lama setelah seharusnya berhenti.
Setup sederhana harus menjawab empat hal: siapa penyetuju utama, siapa cadangan, berapa lama pengganti bisa bertindak, dan kapan permintaan naik ke rantai berikutnya.
Eskalasi harus berdasarkan pemicu yang jelas, bukan tebak-tebakan. Pemicu umum: waktu, jumlah, risiko, atau informasi yang kurang. Misalnya, jika permintaan pembelian di atas $10.000 tidak disentuh selama 24 jam, mungkin naik ke kepala departemen.
Jaga jalur eskalasi tetap pendek. Jika orang butuh diagram rumit hanya untuk tahu siapa menerima permintaan berikutnya, aturannya terlalu kompleks. Satu atau dua lompatan yang jelas biasanya cukup.
Rekam setiap keputusan juga. Simpan siapa yang menyetujui, siapa yang menggantikan, kapan serah terima terjadi, dan mengapa permintaan tereskalasi. Riwayat itu penting saat seseorang bertanya mengapa permintaan tertunda atau disetujui oleh pengganti.
Satu aturan lagi yang sering terlewat: hindari loop. Permintaan tidak boleh memantul kembali ke orang yang sudah menyetujui atau ke pengganti yang bertindak untuk orang yang sama. Periksa matriks untuk jalur melingkar sebelum membangun logika aplikasi apapun.
Bayangkan perusahaan kecil membeli kebutuhan sehari-hari. Karyawan mengajukan satu permintaan pembelian dengan item, jumlah, alasan, dan tanggal dibutuhkan. Routing digerakkan oleh aturan, bukan siapa pun yang sedang online.
Jika permintaan $420, langsung ke pemimpin tim. Itu menjaga pembelian kecil bergerak. Permintaan $3.200 melewati pemimpin tim dan ke manajer departemen karena dampak anggarannya lebih besar.
Untuk permintaan $7.800 untuk peralatan baru, manajer departemen masih meninjau, tetapi itu tidak cukup. Karena jumlah di atas $5.000, keuangan juga harus meninjau. Di sinilah matriks yang jelas membantu: jumlah yang lebih tinggi menambah kontrol tanpa menambah tebakan.
Ketidakhadiran juga penting. Jika manajer departemen cuti, permintaan tidak boleh terdiam. Pengganti bernama menerimanya otomatis dan dapat bertindak untuk periode yang ditentukan.
Batas waktu mesti jelas juga. Jika tidak ada yang bertindak dalam dua hari, permintaan naik ke operasi. Operasi bisa menindaklanjuti, menugaskan ulang, atau memastikan tidak menghambat pekerjaan.
Dalam contoh ini, matriks menjawab beberapa pertanyaan sederhana tapi penting: berapa jumlah yang diminta, peran siapa yang menyetujui tiap rentang, kapan keuangan ditambahkan, siapa menutup ketidakhadiran, dan apa yang terjadi saat tenggat terlewati.
Setelah jawaban itu ditentukan, desain layar menjadi langsung. Formulir hanya perlu data yang tepat, dan halaman permintaan hanya perlu menampilkan penyetuju saat ini, pengganti jika ada, dan apakah jam eskalasi berjalan.
Sebagian besar pengerjaan ulang dimulai sebelum satu layar pun digambar. Tim menebak jalur persetujuan, lalu mencoba memaksa UI sesuai aturan yang sebenarnya belum disepakati.
Satu kesalahan umum adalah menyalin bagan organisasi dan menyebutnya alur kerja. Itu mungkin terlihat rapi, tetapi permintaan nyata biasanya bergerak berdasarkan jumlah, risiko, lokasi, atau tipe permintaan. Jika matriks mengabaikannya, layar nanti perlu bidang tambahan, status tambahan, dan pengecualian canggung.
Masalah lain lupa kasus khusus. Permintaan mendesak, pembelian yang diatur, atau lintas-tim sering butuh rute berbeda. Jika pengecualian itu tidak dipetakan lebih awal, orang meminta jalan pintas manual, dan antarmuka dipenuhi opsi satu-kali yang membingungkan.
Tim juga bikin masalah saat memberi dua orang tugas yang sama tanpa aturan tiebreak. Jika keduanya bisa menyetujui, siapa yang bertindak dulu? Jika mereka tidak setuju, keputusan siapa yang berlaku? Tanpa jawaban, permintaan memantul dan pengguna kehilangan kepercayaan.
Aturan substitusi juga sering lemah. Pengganti harus menutupi ketidakhadiran, bukan diam-diam menjadi pemilik kedua selamanya. Saat cakupan sementara dan kepemilikan permanen bercampur, laporan jadi berantakan dan akuntabilitas hilang.
Merancang formulir sebelum routing ditetapkan menciptakan putaran pengerjaan ulang lain. Formulir mungkin tampak lengkap, tetapi setelah aturan persetujuan difinalkan, sering ditemukan field yang hilang seperti rentang jumlah, departemen, urgensi, atau flag kebijakan. Lalu tata letak, validasi, dan notifikasi semua perlu diubah.
Pemeriksaan realitas cepat membantu menangkap ini lebih awal:
Jika ada jawaban yang tidak jelas, hentikan. Perbaiki matriks sebelum memoles tampilan.
Sebelum Anda membuat sketsa form atau badge status, uji logika dalam bahasa yang sederhana. Matriks persetujuan yang baik harus mudah dijelaskan tanpa membuka diagram. Jika manajer, kepala keuangan, atau rekan operasi tidak bisa menggambarkan rute dalam sekitar satu menit, proses masih terlalu kabur untuk pekerjaan UI.
Lakukan tinjauan cepat dengan contoh nyata. Minta satu orang menjelaskan rute penuh dari pengajuan hingga keputusan akhir. Periksa bahwa setiap kemungkinan hasil punya penyetuju berikutnya yang bernama, bukan hanya jalan bahagia. Tulis ulang ambang kabur menjadi aturan tepat seperti 'sampai $1.000' atau 'lebih dari diskon 10%'. Pastikan aturan fallback dan eskalasi menggunakan batas waktu jelas seperti 'setelah 24 jam' atau 'setelah 2 hari kerja'.
Kemudian uji keterlacakan. Kelak, seseorang akan menanyakan mengapa permintaan tertunda, siapa yang menyetujui pengecualian, atau kapan pengganti turun tangan. Proses Anda harus sudah menjawab pertanyaan itu. Cap waktu, riwayat keputusan, dan perubahan status yang jelas bukan tambahan, melainkan bagian dari aturan.
Skenario sederhana biasanya mengekspos titik lemah. Bayangkan permintaan $4.800 tiba Jumat sore saat penyetuju biasa sedang tidak ada. Siapa yang menerimanya berikutnya? Berapa lama sistem menunggu sebelum bergerak? Apa yang terjadi jika backup juga tidak bertindak? Jika jawaban-jawaban itu tidak tertulis, UI hanya akan menyembunyikan kebingungan, bukan menyelesaikannya.
Saat pemeriksaan ini lulus, desain layar jadi jauh lebih mudah. Anda tak lagi menebak apa yang harus ditampilkan. Anda memberi bentuk yang jelas pada aturan yang sudah ada.
Setelah aturan jelas, bangun prosesnya sebelum Anda memoles layar. Mulai dengan logika, field data, dan status persetujuan. Jika routing berfungsi, antarmuka jadi jauh lebih mudah dirancang. Jika routing masih berubah-ubah, tampilan yang menarik cuma menyembunyikan masalah.
Versi awal yang praktis biasanya mencakup dasar: tipe permintaan, jumlah, departemen, penyetuju saat ini, status akhir, dan riwayat keputusan yang jelas. Lalu tambahkan aturan yang memindahkan permintaan maju, mengirimnya ke penyetuju pengganti, atau memicu eskalasi saat tidak ada respons tepat waktu.
Jaga tampilan pertama tetap sederhana. Pemohon harus bisa mengajukan, memeriksa status, dan menanggapi pertanyaan lanjutan. Penyetuju harus bisa meninjau, menyetujui, menolak, atau menugaskan ulang. Itu cukup untuk menguji apakah alur kerja masuk akal dalam penggunaan sehari-hari.
Urutan pembangunan yang masuk akal:
Sumber kebenaran bersama itu lebih penting dari yang banyak tim sangka. Jika mobile menampilkan satu status, panel web menampilkan yang lain, dan backend mengikuti ambang berbeda, kepercayaan cepat hilang.
Jika Anda membangun ini di AppMaster, matriks yang jelas membuat pengaturan jauh lebih mudah. Anda bisa memodelkan data, logika bisnis, dan alur persetujuan terlebih dahulu, lalu membawa proses yang sama ke backend, web, dan mobile tanpa menulis ulang aturan di alat yang berbeda.
Gunakan satu kasus nyata untuk uji pertama. Jalankan permintaan pembelian dengan ambang, penyetuju pengganti, dan eskalasi karena terlambat. Amati di mana orang ragu, data apa yang hilang, dan label status mana yang membingungkan.
Perbaiki kata dan tata letak setelah itu. Ketika proses bekerja dengan permintaan nyata, layar lebih mudah dirancang dan jauh lebih kecil kemungkinan perlu dibangun ulang seminggu kemudian.
07 Mar 2026
8 menit
20 Feb 20267 menit
27 Jan 202611 menitEksperimen dengan AppMaster dengan paket gratis.
Saat Anda siap, Anda dapat memilih langganan yang tepat.
