Alur kerja berorientasi dokumen: model data dan pola UI

Apa yang membuat aplikasi berorientasi dokumen

Sebuah aplikasi disebut berorientasi dokumen ketika dokumen itu sendiri adalah produk yang dibuat, ditinjau, dan diandalkan pengguna. Pengalaman dibangun di sekitar file seperti PDF, gambar, scan, dan struk, bukan di sekitar form di mana file hanyalah lampiran.

Dalam alur kerja berorientasi dokumen, orang melakukan pekerjaan nyata di dalam dokumen: mereka membukanya, memeriksa apa yang berubah, menambahkan konteks, dan memutuskan langkah berikutnya. Jika dokumen tidak bisa dipercaya, aplikasi berhenti berguna.

Kebanyakan aplikasi berorientasi dokumen membutuhkan beberapa layar inti di awal:

• Inbox untuk upload baru, item yang ditugaskan, dan apapun yang butuh perhatian
• Tampilan detail dokumen dengan pratinjau, metadata, komentar, dan riwayat
• Alur review untuk menyetujui, menolak, atau meminta perubahan
• Area ekspor atau bagi untuk menyerahkan ke sistem lain

Masalah muncul cepat. Pengguna mengupload struk yang sama dua kali. Seseorang mengedit PDF dan mengupload ulang tanpa menjelaskan alasan. Scan tidak punya tanggal, vendor, atau pemilik. Minggu kemudian, tak ada yang tahu versi mana yang disetujui atau alasan keputusannya.

Aplikasi berorientasi dokumen yang baik terasa cepat dan dapat diandalkan. Pengguna seharusnya bisa menjawab pertanyaan ini dalam beberapa detik:

• Apakah ini versi terbaru, dan siapa yang mengubahnya?
• Bisakah saya mempratinjaunya segera tanpa mengunduh?
• Apa isinya, dijelaskan dalam beberapa field sederhana yang bisa saya filter?
• Dalam status apa dokumen ini sekarang, dan aksi apa yang diharapkan?

Kejelasan itu datang dari definisi. Sebelum membangun layar, putuskan apa arti “versi”, “pratinjau”, “metadata”, dan “status” di aplikasi Anda. Jika istilah itu kabur, Anda akan mendapat duplikat, riwayat yang membingungkan, dan alur review yang tidak sesuai pekerjaan nyata.

Konsep inti yang perlu dimodelkan sebelum membangun UI

UI sering terlihat sederhana (daftar, viewer, beberapa tombol), tetapi model data yang memegang beban. Jika objek inti tepat, riwayat audit, pratinjau cepat, dan persetujuan yang dapat diandalkan jadi lebih mudah.

Mulailah dengan memisahkan “record dokumen” dari “konten file.” Record adalah apa yang dibicarakan pengguna (Invoice dari ACME, struk taksi). Konten adalah byte (PDF, JPG) yang mungkin diganti, diproses ulang, atau dipindahkan tanpa mengubah apa arti dokumen di dalam aplikasi.

Sekumpulan objek praktis untuk dimodelkan:

• Dokumen: entri stabil yang dicari, diberi komentar, dan disetujui pengguna
• File: blob tersimpan (PDF/gambar) dengan size, checksum, key penyimpanan, dan MIME type
• Versi: snapshot dokumen pada titik waktu tertentu, menunjuk ke satu atau beberapa File
• Pratinjau: aset turunan (thumbnail, gambar halaman pertama, ekstrak teks) terkait ke File atau Versi
• Metadata: field terstruktur (merchant, total, tanggal) plus output ekstraksi mentah dan confidence
• Status: state bisnis kerja saat ini (needs review, approved, rejected)

Tentukan apa yang mendapat ID yang tak berubah. Aturan berguna: Document ID hidup selamanya, sementara File dan Pratinjau dapat digenerasi ulang. Versi juga perlu ID stabil, karena orang merujuk ke “bagaimana tampilannya kemarin” dan Anda butuh jejak audit.

Modelkan relasi secara eksplisit. Sebuah Document punya banyak Versi. Setiap Versi bisa punya beberapa Pratinjau (ukuran atau format berbeda). Ini menjaga layar daftar tetap cepat karena bisa memuat data pratinjau ringan, sementara layar detail memuat file penuh hanya saat diperlukan.

Contoh: pengguna mengupload foto struk yang kusut. Anda membuat Document, menyimpan File asli, menghasilkan Thumbnail Pratinjau, dan membuat Versi 1. Kemudian pengguna mengupload scan lebih jelas. Itu menjadi Versi 2, tanpa merusak komentar, persetujuan, atau pencarian yang terkait Document.

Versioning: cara menyimpan riwayat tanpa kacau

Orang mengharapkan dokumen berubah dari waktu ke waktu tanpa “berubah menjadi” item lain. Cara paling sederhana untuk mewujudkan itu adalah memisahkan identitas (Document) dari konten (Versi dan File).

Mulailah dengan document_id yang stabil dan tak berubah. Bahkan jika pengguna mengupload ulang PDF yang sama, mengganti foto buram, atau mengupload scan yang diperbaiki, itu harus tetap record dokumen yang sama. Komentar, penugasan, dan log audit menempel rapi pada satu ID yang tahan lama.

Anggap setiap perubahan bermakna sebagai baris version. Setiap versi harus merekam siapa yang membuatnya dan kapan, plus pointer penyimpanan (file key, checksum, size, jumlah halaman) dan artefak turunan (teks OCR, gambar pratinjau) yang terkait dengan file itu persis. Hindari “mengedit langsung.” Itu terlihat lebih sederhana pada awalnya, tetapi merusak keterlacakan dan membuat bug sulit dibalik.

Untuk bacaan cepat, simpan current_version_id di dokumen. Sebagian besar layar hanya butuh “yang terbaru,” jadi Anda tidak harus mengurutkan versi di setiap pemuatan. Saat perlu riwayat, muat versi secara terpisah dan tampilkan timeline bersih.

Rollback hanyalah perubahan pointer. Daripada menghapus apa pun, set current_version_id kembali ke versi lama. Ini cepat, aman, dan menjaga jejak audit tetap utuh.

Untuk menjaga riwayat dapat dipahami, catat mengapa setiap versi ada. Field kecil dan konsisten reason (plus catatan opsional) mencegah timeline penuh pembaruan misterius. Alasan umum: penggantian upload, pembersihan scan, koreksi OCR, redaksi, dan edit persetujuan.

Contoh: tim keuangan mengupload foto struk, menggantinya dengan scan lebih jelas, lalu memperbaiki OCR agar total terbaca. Setiap langkah adalah versi baru, tetapi dokumen tetap satu item di inbox. Jika perbaikan OCR salah, rollback satu klik karena Anda hanya mengganti current_version_id.

Pratinjau dan thumbnail yang tetap cepat dan andal

Dalam alur kerja berorientasi dokumen, pratinjau sering kali adalah hal utama yang diinteraksikan pengguna. Jika pratinjau lambat atau tidak stabil, seluruh aplikasi terasa rusak.

Perlakukan pembuatan pratinjau sebagai job terpisah, bukan sesuatu yang menunggu layar upload. Simpan file asli dulu, kembalikan kendali ke pengguna, lalu buat pratinjau di background. Ini menjaga UI responsif dan membuat retry aman.

Simpan beberapa ukuran pratinjau. Satu ukuran tidak pernah cocok untuk semua layar: thumbnail kecil untuk daftar, gambar menengah untuk tampilan terpisah, dan gambar halaman penuh untuk review detail (per-halaman untuk PDF).

Lacak state pratinjau secara eksplisit sehingga UI selalu tahu apa yang ditampilkan: pending, ready, failed, dan needs_retry. Gunakan label ramah pengguna di UI, tetapi simpan state yang jelas di data.

Agar rendering cepat, cache nilai turunan pada record pratinjau alih-alih menghitung ulang setiap kali dilihat. Field umum termasuk jumlah halaman, lebar dan tinggi pratinjau, rotasi (0/90/180/270), dan opsional “halaman terbaik untuk thumbnail.”

Rancang untuk file lambat dan berantakan. PDF scan 200 halaman atau foto struk yang kusut bisa butuh waktu untuk diproses. Gunakan pemuatan progresif: tampilkan halaman pertama yang siap segera setelah tersedia, lalu isi sisanya.

Contoh: pengguna mengupload 30 foto struk. Tampilan daftar menunjukkan thumbnail sebagai “pending,” lalu setiap kartu berubah menjadi “ready” saat pratinjau selesai. Jika beberapa gagal karena gambar korup, mereka tetap terlihat dengan aksi retry jelas daripada menghilang atau memblokir seluruh batch.

Metadata: apa yang disimpan dan bagaimana menjaganya berguna

Metadata mengubah tumpukan file menjadi sesuatu yang bisa dicari, diurutkan, ditinjau, dan disetujui. Ini membantu orang menjawab pertanyaan sederhana dengan cepat: Apa dokumen ini? Dari siapa? Valid? Apa yang harus terjadi selanjutnya?

Cara praktis menjaga metadata bersih adalah memisahkannya berdasarkan asalnya:

• System metadata: nama file, ukuran, MIME type, jumlah halaman, waktu upload, checksum
• Extracted metadata: teks OCR, field terdeteksi (vendor, tanggal, total), nilai barcode/QR
• User-entered metadata: koreksi, tag, catatan, kategorisasi, komentar approver

Bucket ini mencegah argumen kemudian. Jika jumlah total salah, Anda bisa melihat apakah itu berasal dari OCR atau edit manusia.

Untuk struk dan faktur, set kecil field yang konsisten sangat berguna (nama, format yang sama). Field jangkar umum: vendor, tanggal, total, mata uang, dan document_number. Biarkan mereka opsional dulu. Orang mengupload scan parsial dan foto buram, dan memblokir progress karena satu field hilang akan memperlambat alur kerja.

Perlakukan nilai yang tidak diketahui sebagai kelas utama. Gunakan state eksplisit seperti null/unknown, plus alasan bila berguna (halaman hilang, tidak terbaca, tidak berlaku). Itu memungkinkan dokumen bergerak maju sambil tetap menunjukkan kepada reviewer apa yang perlu perhatian.

Juga simpan provenance dan confidence untuk field yang diekstrak. Sumber bisa user, OCR, import, atau API. Confidence bisa skor 0–1 atau set kecil seperti high/medium/low. Jika OCR membaca “$18.70” dengan confidence rendah karena digit terakhir buram, UI bisa menandainya dan meminta konfirmasi cepat.

Dokumen multi-halaman memerlukan keputusan ekstra: apa yang berlaku untuk seluruh dokumen vs satu halaman. Total dan vendor biasanya milik dokumen. Catatan per-halaman, redaksi, rotasi, dan klasifikasi per-halaman seringkali disimpan di level halaman.

Status yang sesuai pekerjaan nyata

Status menjawab satu pertanyaan: “Di mana dokumen ini dalam proses?” Jaga sesedikit dan seinformatif mungkin. Jika Anda menambah status baru setiap kali seseorang minta, akhirnya Anda punya filter yang tak dipercaya siapa pun.

Set status bisnis praktis yang memetakan ke keputusan nyata:

• Imported: file ada, tapi belum diperiksa
• Needs review: manusia harus memastikan field kunci atau keterbacaan
• Approved: siap digunakan downstream (bayar, arsip, publish, atau ekspor)
• Rejected: tidak bisa digunakan, dengan alasan
• Archived: disimpan untuk catatan, keluar dari pekerjaan aktif

Jaga “processing” di luar status bisnis. OCR berjalan dan pratinjau dibuat menggambarkan apa yang sistem lakukan, bukan apa yang orang harus lakukan selanjutnya. Simpan itu sebagai state pemrosesan terpisah.

Juga pisahkan penugasan dari status (assignee_id, team_id, due_date). Dokumen bisa Approved tapi tetap ditugaskan untuk tindak lanjut, atau Needs review tanpa pemilik.

Catat riwayat status, bukan hanya nilai saat ini. Log sederhana seperti (from_status, to_status, changed_at, changed_by, reason) sangat berguna saat seseorang bertanya, “Siapa yang menolak struk ini dan mengapa?”

Terakhir, tentukan aksi yang diperbolehkan di tiap status. Buat aturan sederhana: Imported bisa pindah ke Needs review; Approved read-only kecuali versi baru dibuat; Rejected bisa dibuka kembali tapi harus menyimpan alasan sebelumnya.

Pola UI untuk daftar, tampilan detail, dan alur review

Sebagian besar waktu dihabiskan untuk memindai daftar, membuka satu item, memperbaiki beberapa field, lalu lanjut. UI yang baik membuat langkah-langkah itu cepat dan dapat diprediksi.

Untuk daftar dokumen, perlakukan setiap baris seperti ringkasan sehingga pengguna bisa memutuskan tanpa membuka tiap file. Baris kuat menampilkan thumbnail kecil, judul jelas, beberapa field kunci (merchant, tanggal, total), badge status, dan peringatan halus saat sesuatu butuh perhatian.

Pertahankan tampilan detail tetap tenang dan mudah dipindai. Tata umum: pratinjau di kiri dan metadata di kanan, dengan kontrol edit di samping tiap field. Pengguna harus bisa zoom, rotasi, dan mengganti halaman tanpa kehilangan posisinya di form. Jika field diekstrak dari OCR, tampilkan petunjuk confidence kecil, dan idealnya sorot area sumber di preview saat field difokuskan.

Versi bekerja paling baik sebagai timeline, bukan dropdown. Tampilkan siapa mengubah apa dan kapan, dan biarkan pengguna membuka versi lama dalam mode read-only. Jika Anda menawarkan perbandingan, fokus pada perbedaan metadata (jumlah berubah, vendor dikoreksi) daripada memaksakan perbandingan pixel demi pixel PDF.

Mode review harus mengoptimalkan kecepatan. Alur triase berbasis keyboard sering cukup: aksi cepat setujui/tolak, perbaikan cepat untuk field umum, dan kotak komentar singkat untuk penolakan.

Empty state penting karena dokumen sering dalam proses. Alih-alih kotak kosong, jelaskan apa yang terjadi: “Pratinjau sedang dibuat,” “OCR berjalan,” atau “Tipe file ini belum punya pratinjau.”

Langkah demi langkah: alur sederhana dari upload ke persetujuan

Alur sederhana terasa seperti “upload, cek, setujui.” Di balik layar, bekerja paling baik saat Anda memisahkan file itu sendiri (versi dan pratinjau) dari makna bisnis (metadata dan status).

1) Upload masuk ke inbox

Pengguna mengupload PDF, foto, atau scan struk dan langsung melihatnya di daftar inbox. Jangan tunggu pemrosesan selesai. Tampilkan nama file, waktu upload, dan badge jelas seperti “Processing.” Jika Anda sudah tahu sumbernya (email import, kamera mobile, drag-and-drop), tampilkan juga.

2) Buat Document + Version, pratinjau mulai sebagai pending

Saat upload, buat record Document (entitas jangka panjang) dan record Version (file spesifik ini). Set current_version_id ke versi baru. Simpan preview_state = pending dan extraction_state = pending sehingga UI bisa jujur tentang apa yang siap.

Tampilan detail harus terbuka segera, tetapi tampilkan viewer placeholder dan pesan jelas “Mempersiapkan pratinjau” alih-alih frame rusak.

3) Pemrosesan background menghasilkan pratinjau dan mengekstrak metadata

Job background membuat thumbnail dan pratinjau yang dapat dilihat (gambar halaman untuk PDF, gambar yang diubah ukurannya untuk foto). Job lain mengekstrak metadata (merchant, tanggal, total, mata uang, tipe dokumen). Saat tiap job selesai, perbarui hanya state dan timestamp-nya supaya Anda bisa retry kegagalan tanpa menyentuh semuanya.

Jaga UI ringkas: tunjukkan state pratinjau, state data, dan sorot field dengan confidence rendah.

4) Reviewer memperbaiki field, mengubah status, menambahkan catatan

Saat pratinjau siap, reviewer memperbaiki field, menambahkan catatan, dan memindahkan dokumen melalui status bisnis seperti Imported -> Needs review -> Approved (atau Rejected). Log siapa yang mengubah apa dan kapan.

Jika reviewer mengupload file yang diperbaiki, itu menjadi Versi baru dan dokumen otomatis kembali ke Needs review.

5) Penggunaan downstream membaca versi saat ini plus metadata yang sudah disetujui

Ekspor, sinkronisasi akuntansi, atau laporan internal harus membaca dari current_version_id dan snapshot metadata yang disetujui, bukan "ekstraksi terbaru." Itu mencegah re-upload setengah-proses mengubah angka.

Kesalahan umum dan jebakan yang harus dihindari

Alur kerja berorientasi dokumen gagal karena alasan membosankan: jalan pintas awal jadi masalah sehari-hari ketika orang mengupload duplikat, memperbaiki kesalahan, atau bertanya, “Siapa yang mengubah ini dan kapan?”

Menganggap nama file sebagai identitas dokumen adalah kesalahan klasik. Nama berubah, pengguna mengupload ulang, dan kamera menghasilkan duplikat seperti IMG_0001. Beri setiap dokumen ID stabil, dan anggap nama file sebagai label.

Menimpa file asli ketika seseorang mengupload pengganti juga bermasalah. Terlihat lebih sederhana, tetapi Anda kehilangan jejak audit dan tidak bisa menjawab pertanyaan dasar nanti (apa yang disetujui, apa yang diedit, apa yang dikirim). Jadikan binary file tak dapat diubah dan tambahkan record versi baru.

Kebingungan status menciptakan bug halus juga. “OCR berjalan” tidak sama dengan “Needs review.” State pemrosesan menggambarkan apa yang sistem lakukan; status bisnis menggambarkan apa yang orang harus lakukan selanjutnya. Saat itu tercampur, dokumen bisa tersangkut di bucket yang salah.

Keputusan UI juga bisa menciptakan friksi. Jika Anda memblokir layar sampai pratinjau dibuat, orang akan merasakan aplikasi lambat meskipun upload berhasil. Tampilkan dokumen segera dengan placeholder yang jelas, lalu tukar thumbnail saat siap.

Akhirnya, metadata menjadi tidak dapat dipercaya jika Anda menyimpan nilai tanpa provenance. Jika total berasal dari OCR, katakan begitu. Simpan timestamp.

Daftar cek cepat:

• ID dokumen stabil terpisah dari nama file
• Versi baru untuk setiap penggantian, tidak ada overwrite
• Status bisnis terpisah dari state pemrosesan
• Pemuatan pratinjau dan thumbnail non-blocking
• Metadata menyertakan sumber dan timestamp

Contoh: pada aplikasi struk, pengguna mengupload foto lebih jelas. Jika Anda memversi, simpan gambar lama, tandai OCR sebagai sedang diproses ulang, dan pertahankan Needs review sampai manusia mengonfirmasi jumlah.

Daftar periksa cepat sebelum rilis

Alur kerja berorientasi dokumen terasa "selesai" hanya ketika orang bisa mempercayai apa yang mereka lihat dan pulih saat terjadi masalah. Sebelum diluncurkan, uji dengan dokumen nyata yang berantakan (struk buram, PDF terrotasi, upload berulang).

Lima cek yang menangkap sebagian besar kejutan:

• Versi saat ini tak terbantahkan. Tandai versi aktif, tunjukkan siapa terakhir mengubah dan kapan, serta sertakan alasan singkat seperti “dipotong” atau “diupload ulang.”
• Pratinjau gagal dengan elegan. Jika pratinjau sedang dibuat, tampilkan placeholder berguna (nama file, waktu upload, jumlah halaman jika diketahui) dan state pending yang jelas. Jika pembuatan gagal, tampilkan error dan opsi retry.
• Status sesuai aksi. Setiap status harus punya arti jelas dan sekumpulan aksi yang diperbolehkan. Jika Approved ada, jadikan read-only.
• Edit metadata tidak menghapus ekstraksi. Biarkan pengguna memperbaiki OCR tanpa menghilangkan nilai ekstraksi asli. Simpan keduanya dan tunjukkan mana yang dipakai.
• Pemulihan dibangun-in. Buat perbaikan umum mudah: rollback ke versi sebelumnya, jalankan ulang ekstraksi, regenerasi pratinjau.

Tes realitas cepat: minta seseorang meninjau tiga struk serupa dan sengaja membuat satu perubahan salah. Jika mereka bisa menemukan versi saat ini, memahami status, dan memperbaiki kesalahan dalam waktu kurang dari satu menit, Anda mendekati selesai.

Skenario contoh dan langkah praktis berikutnya

Penggantian struk bulanan adalah contoh jelas pekerjaan berorientasi dokumen. Seorang karyawan mengupload struk, lalu dua reviewer memeriksanya: manajer, lalu finance. Struk adalah produknya, jadi aplikasi Anda hidup atau mati pada versioning, pratinjau, metadata, dan status yang jelas.

Jamie mengupload foto struk taksi. Sistem Anda membuat Document #1842 dengan Versi v1 (file asli), thumbnail dan pratinjau, serta metadata seperti merchant, tanggal, mata uang, total, dan skor confidence OCR. Dokumen mulai di Imported, lalu pindah ke Needs review setelah pratinjau dan ekstraksi siap.

Kemudian, Jamie secara tidak sengaja mengupload struk yang sama lagi. Pengecekan duplikat (hash file plus merchant/tanggal/total mirip) bisa menampilkan pilihan sederhana: “Sepertinya duplikat dari #1842. Lampirkan saja atau buang.” Jika mereka melampirkannya, simpan sebagai File lain yang terhubung ke Document yang sama sehingga Anda tetap punya satu thread review dan satu status.

Selama review, manajer melihat pratinjau, field kunci, dan peringatan. OCR menebak total $18.00, tetapi gambar jelas menunjukkan $13.00. Jamie memperbaiki total. Jangan timpa sejarah. Buat Versi v2 dengan field yang diperbarui, biarkan v1 tidak berubah, dan log “Total dikoreksi oleh Jamie.”

Jika Anda ingin membangun alur semacam ini dengan cepat, Koder.ai (koder.ai) dapat membantu menghasilkan versi pertama aplikasi dari rencana berbasis chat, tetapi aturan yang sama berlaku: definisikan objek dan state dulu, lalu biarkan layar mengikuti.

Langkah praktis selanjutnya:

• Sketsakan model data: Document, Version, File, ExtractedField, Review, StatusHistory
• Rancang dua layar: daftar inbox (status + peringatan) dan tampilan detail (pratinjau + field + versi)
• Uji dengan lima struk nyata dan iterasi pada status, aturan duplikat, dan kecepatan review