เวิร์กโฟลว์มุ่งเน้นเอกสาร: โมเดลข้อมูลและรูปแบบ UI

อะไรที่ทำให้แอปมุ่งเน้นเอกสาร

แอปจะถือว่ามุ่งเน้นเอกสารเมื่อเอกสารเป็นผลิตภัณฑ์ที่ผู้ใช้สร้าง ตรวจทาน และพึ่งพา ประสบการณ์ถูกสร้างขึ้นรอบไฟล์อย่าง PDF รูปภาพ สแกน และใบเสร็จ—not around a form where a file is just an attachment.

ในเวิร์กโฟลว์ที่มุ่งเน้นเอกสาร ผู้คนทำงานจริงภายในเอกสาร: เปิดดูว่าอะไรเปลี่ยน เพิ่มบริบท และตัดสินใจว่าจะทำอย่างไรต่อไป หากเอกสารไม่ไว้วางใจได้ แอปก็หยุดมีประโยชน์

แอปมุ่งเน้นเอกสารส่วนใหญ่ต้องมีหน้าจอหลักไม่กี่หน้าในตอนแรก:

• กล่องจดหมายสำหรับการอัปโหลดใหม่ รายการที่มอบหมาย และสิ่งที่ต้องได้รับความสนใจ
• มุมมองรายละเอียดเอกสารที่มีตัวอย่าง เมตาดาต้า ความเห็น และประวัติ
• กระบวนการตรวจสอบเพื่ออนุมัติ ปฏิเสธ หรือขอให้แก้ไข
• พื้นที่ส่งออกหรือแชร์เพื่อส่งต่อไปยังระบบอื่น

ปัญหาจะปรากฏอย่างรวดเร็ว ผู้ใช้จะอัปโหลดใบเสร็จซ้ำสองคน คนหนึ่งแก้ไข PDF แล้วอัปโหลดใหม่โดยไม่อธิบาย เหตุการณ์สแกนไม่มีวันที่ ไม่มีผู้ขาย และไม่มีเจ้าของ ผ่านไปหลายสัปดาห์ก็ไม่มีใครรู้ว่าเวอร์ชันไหนได้รับการอนุมัติหรือการตัดสินใจมาจากอะไร

แอปมุ่งเน้นเอกสารที่ดีรู้สึกเร็วและเชื่อถือได้ ผู้ใช้ควรตอบคำถามเหล่านี้ได้ในไม่กี่วินาที:

• นี่คือเวอร์ชันล่าสุดหรือไม่ และใครเป็นคนเปลี่ยนแปลง?
• ฉันสามารถดูตัวอย่างทันทีโดยไม่ต้องดาวน์โหลดได้ไหม?
• มันคืออะไร อธิบายในฟิลด์ง่าย ๆ ที่ฉันสามารถกรองได้?
• ตอนนี้มันอยู่ในสถานะไหน และคาดหวังการกระทำอะไร?

ความชัดเจนนี้มาจากคำนิยาม ก่อนสร้างหน้าจอ ให้ตัดสินใจว่า “เวอร์ชัน”, “ตัวอย่าง”, “เมตาดาต้า” และ “สถานะ” หมายความว่าอย่างไรในแอปของคุณ หากคำพวกนี้ไม่ชัดเจน คุณจะได้สำเนาซ้ำ ประวัติสับสน และกระบวนการตรวจสอบที่ไม่ตรงกับงานจริง

แนวคิดหลักที่ควรออกแบบก่อนสร้าง UI

UI มักดูเรียบง่าย (รายการ ตัวดูไฟล์ ปุ่มไม่กี่ปุ่ม) แต่โมเดลข้อมูลนั้นแบกรับภาระ หากอ็อบเจ็กต์หลักถูกต้อง ประวัติการตรวจสอบ ตัวอย่างที่เร็ว และการอนุมัติที่เชื่อถือได้จะง่ายขึ้นมาก

เริ่มจากการแยกระหว่าง “ระเบียนเอกสาร” กับ “เนื้อหาไฟล์” ระเบียนคือสิ่งที่ผู้ใช้พูดถึง (บิลจาก ACME ใบเสร็จแท็กซี่) เนื้อหาคือไบต์ (PDF, JPG) ที่อาจถูกแทนที่ ประมวลผลซ้ำ หรือลงที่อื่นโดยไม่เปลี่ยนความหมายภายในแอป

ชุดอ็อบเจ็กต์เชิงปฏิบัติที่ควรออกแบบ:

• Document: ระเบียนคงตัวที่ผู้ใช้ค้นหา แสดงความคิดเห็น และอนุมัติ
• File: บล็อบที่เก็บ (PDF/รูป) พร้อมขนาด เช็คซัม คีย์เก็บ และ MIME type
• Version: สแนปช็อตของเอกสารในช่วงเวลา ชี้ไปยัง File หนึ่งหรือหลายไฟล์
• Preview: ทรัพยากรที่ได้จากการประมวลผล (รูปย่อ ภาพหน้าหนึ่ง ข้อความที่สกัด) ผูกกับ File หรือ Version
• Metadata: ฟิลด์มีโครงสร้าง (merchant, total, date) บวกผลการสกัดดิบและความเชื่อมั่น
• Status: สถานะธุรกิจปัจจุบันของงาน (needs review, approved, rejected)

ตัดสินใจว่าอะไรได้ ID ที่ไม่เปลี่ยนแปลง กฎที่มีประโยชน์คือ: Document ID อยู่ตลอดไป ขณะที่ Files และ Previews สามารถสร้างใหม่ได้ เวอร์ชันก็ต้องมี ID คงที่ด้วย เพราะคนอ้างถึง “หน้าตาเมื่อวาน” และคุณต้องการร่องรอยการตรวจสอบ

แบบจำลองความสัมพันธ์อย่างชัดเจน Document มีหลาย Versions แต่ละ Version อาจมีหลาย Previews (ขนาดหรือฟอร์แมตต่างกัน) ซึ่งทำให้หน้ารายการโหลดข้อมูลตัวอย่างขนาดเล็กได้เร็ว ขณะที่หน้ารายละเอียดโหลดไฟล์เต็มเมื่อจำเป็น

ตัวอย่าง: ผู้ใช้อัปโหลดภาพใบเสร็จยับ คุณสร้าง Document เก็บ File ต้นฉบับ สร้าง Preview รูปย่อ และสร้าง Version 1 ต่อมา ผู้ใช้ส่งสแกนที่ชัดกว่า นั่นกลายเป็น Version 2 โดยไม่ทำลายคอมเมนต์ การอนุมัติ หรือการค้นหาที่ผูกกับ Document

การจัดการเวอร์ชัน: เก็บประวัติโดยไม่ให้ยุ่งเหยิง

ผู้คนคาดหวังว่าเอกสารจะเปลี่ยนแปลงเมื่อเวลาผ่านไปโดยไม่ “เปลี่ยนเป็น” รายการใหม่ วิธีที่ง่ายที่สุดคือแยกตัวตน (Document) จากเนื้อหา (Version และ Files)

เริ่มด้วย document_id ที่คงที่ที่ไม่เปลี่ยน แม้ผู้ใช้จะอัปโหลด PDF เดิม แทนที่ภาพเบลอ หรืออัปโหลดสแกนแก้ไข มันควรยังเป็นระเบียนเอกสารเดียว คอมเมนต์ การมอบหมาย และบันทึกตรวจสอบจะผูกกับ ID ที่ทนทานนี้อย่างเรียบร้อย

ถือว่าทุกการเปลี่ยนแปลงที่มีความหมายเป็นแถว version ใหม่ แต่ละเวอร์ชันควรจับว่าใครสร้างและเมื่อไร รวมถึงพอยน์เตอร์การเก็บ (file key, checksum, size, page count) และผลพลอยได้ (ข้อความ OCR รูปภาพตัวอย่าง) ที่ผูกกับไฟล์นั้นโดยเฉพาะ หลีกเลี่ยงการ “แก้ไขในที่เดียว” มันดูง่ายในตอนแรกแต่ทำลายการติดตามและทำให้บั๊กแก้ยาก

เพื่อการอ่านที่เร็ว เก็บ current_version_id บน document หน้าจอส่วนใหญ่ต้องการแค่ “ล่าสุด” ดังนั้นคุณไม่ต้องเรียงเวอร์ชันทุกครั้งที่โหลด เมื่อต้องการประวัติ ให้โหลดเวอร์ชันแยกต่างหากแล้วแสดงไทม์ไลน์ที่ชัดเจน

การย้อนกลับเป็นแค่การเปลี่ยน pointer แทนที่จะลบอะไร ให้ตั้ง current_version_id กลับไปเป็นเวอร์ชันเก่า มันเร็ว ปลอดภัย และเก็บประวัติ

เพื่อให้ประวัติเข้าใจง่าย ให้บันทึกเหตุผลที่แต่ละเวอร์ชันมีอยู่ ฟิลด์ reason เล็ก ๆ ที่สม่ำเสมอ (บวกบันทึกเพิ่มเติมถ้าจำเป็น) ป้องกันไทม์ไลน์ที่เต็มไปด้วยการอัปเดตลึกลับ เหตุผลที่พบบ่อยได้แก่ การแทนที่การอัปโหลด, ทำความสะอาดสแกน, แก้ไข OCR, การปิดบัง, และการแก้ไขเพื่ออนุมัติ

ตัวอย่าง: ทีมการเงินอัปโหลดภาพใบเสร็จ แทนที่ด้วยสแกนที่ชัดกว่า แล้วแก้ OCR ให้จำนวนรวมอ่านได้ ทุกขั้นตอนเป็นเวอร์ชันใหม่ แต่เอกสารยังคงเป็นรายการเดียวในกล่องจดหมาย หากการแก้ OCR ผิด การย้อนกลับเป็นคลิกเดียวเพราะคุณแค่สลับ current_version_id

ตัวอย่างและรูปย่อที่ยังเร็วและเชื่อถือได้

ในเวิร์กโฟลว์มุ่งเน้นเอกสาร ตัวอย่างมักเป็นสิ่งที่ผู้ใช้โต้ตอบมากที่สุด ถ้าตัวอย่างช้าหรือผิดพลาด แอปทั้งแอปรู้สึกพัง

ทำให้การสร้างตัวอย่างเป็นงานแยก ไม่ใช่สิ่งที่หน้าการอัปโหลดต้องรอ บันทึกไฟล์ต้นฉบับก่อน คืนการควบคุมให้ผู้ใช้ แล้วสร้างตัวอย่างในพื้นหลัง วิธีนี้ทำให้ UI ตอบสนองและการลองใหม่ปลอดภัย

เก็บขนาดตัวอย่างหลายขนาด ขนาดเดียวไม่พอ: รูปย่อตัวเล็กสำหรับรายการ, ภาพกลางสำหรับมุมมองแยก, และภาพเต็มหน้าสำหรับการตรวจสอบละเอียด (แยกหน้าสำหรับ PDF)

ติดตามสถานะ preview อย่างชัดเจนเพื่อให้ UI รู้ว่าจะแสดงอะไร: pending, ready, failed, และ needs_retry ป้ายชื่อควรเป็นมิตรกับผู้ใช้ใน UI แต่เก็บสถานะให้ชัดเจนในข้อมูล

เพื่อให้การเรนเดอร์เร็ว เก็บค่าที่ได้จากการประมวลผลไว้กับระเบียน preview แทนการคำนวณซ้ำทุกครั้ง ฟิลด์ทั่วไปรวมถึง page count, preview width และ height, rotation (0/90/180/270), และ “หน้าที่ดีที่สุดสำหรับรูปย่อ” แบบเลือกได้

ออกแบบให้รองรับไฟล์ช้าและยุ่ง: PDF สแกน 200 หน้า หรือภาพใบเสร็จที่ยับอาจกินเวลาประมวลผล ใช้การโหลดแบบก้าวหน้า: แสดงหน้าพร้อมเมื่อหน้านั้นพร้อม แล้วเติมส่วนที่เหลือตามมา

ตัวอย่าง: ผู้ใช้ส่งภาพใบเสร็จ 30 รูป รายการจะแสดงรูปย่อเป็น “pending” แล้วการ์ดแต่ละใบจะเปลี่ยนเป็น “ready” เมื่อการตัวอย่างเสร็จ ถ้าบางไฟล์ล้มเหลวเนื่องจากไฟล์เสีย พวกมันยังคงมองเห็นได้พร้อมปุ่ม retry แทนที่จะหายไปหรือบล็อกทั้งชุด

เมตาดาต้า: เก็บอะไรและทำให้ใช้งานได้อย่างไร

เมตาดาต้าทำให้กองไฟล์กลายเป็นสิ่งที่ค้นหา จัดเรียง ตรวจสอบ และอนุมัติได้ มันช่วยให้คนตอบคำถามง่าย ๆ ได้เร็ว: นี่คืออะไร? มาจากใคร? ใช้ได้ไหม? ควรทำอะไรต่อ?

วิธีปฏิบัติที่ดีเพื่อเก็บเมตาดาต้าให้สะอาดคือแยกตามที่มาของมัน:

• System metadata: ชื่อไฟล์ ขนาด MIME type page count เวลาอัปโหลด checksum
• Extracted metadata: ข้อความ OCR ฟิลด์ที่ตรวจจับได้ (merchant, date, total) ค่าบาร์โค้ด/QR
• User-entered metadata: การแก้ไข ป้าย ข้อบันทึก การจัดหมวดหมู่ ความเห็นของผู้อนุมัติ

การแยกกลุ่มเหล่านี้ป้องกันข้อถกเถียงภายหลัง หากจำนวนรวมผิด คุณจะเห็นว่ามาจาก OCR หรือการแก้ไขของคน

สำหรับใบเสร็จและใบแจ้งหนี้ ชุดฟิลด์เล็ก ๆ ที่ใช้สม่ำเสมอให้ประโยชน์ (ชื่อเดียวกัน รูปแบบเดียวกัน) ฟิลด์หลักที่ใช้บ่อยคือ vendor, date, total, currency, และ document_number เก็บให้เป็น optional ก่อน ผู้คนอัปโหลดสแกนบางส่วนและภาพเบลอ และการบล็อกกระบวนการเพราะขาดฟิลด์เดียวจะชะลอเวิร์กโฟลว์ทั้งหมด

ถือค่ายังไม่ทราบเป็นสถานะสำคัญ ใช้สถานะชัดเจนเช่น null/unknown บวกเหตุผลเมื่อมีประโยชน์ (ขาดหน้า อ่านไม่ได้ ไม่ใช้) วิธีนี้ช่วยให้เอกสารเคลื่อนไปข้างหน้าได้ในขณะที่ยังบอกผู้ตรวจดูว่าสิ่งใดต้องการความสนใจ

นอกจากนี้เก็บแหล่งที่มาและความเชื่อมั่นสำหรับฟิลด์ที่สกัดได้ แหล่งอาจเป็น user, OCR, import, หรือ API ความเชื่อมั่นอาจเป็นคะแนน 0-1 หรือชุดเล็ก ๆ เช่น high/medium/low ถ้า OCR อ่าน “$18.70” ด้วยความเชื่อมั่นต่ำเพราะตัวเลขสุดท้ายเลอะ UI สามารถไฮไลต์และขอการยืนยันอย่างรวดเร็ว

เอกสารหลายหน้าให้ตัดสินใจเพิ่มอีกเรื่อง: อะไรเป็นของทั้งเอกสาร vs ของหน้าหนึ่ง ค่า totals และ vendor มักเป็นของเอกสาร ขณะที่บันทึก per-page การปิดบัง การหมุนหน้า และการจำแนกต่อหน้ามักอยู่ระดับหน้าต่อหน้า

สถานะที่สอดคล้องกับงานจริง

สถานะตอบคำถามหนึ่งข้อ: “เอกสารนี้อยู่ในกระบวนการขั้นไหน?” ทำให้มันเล็กและน่าเชื่อถือ หากคุณเพิ่มสถานะใหม่ทุกครั้งที่ใครขอ คุณจะจบด้วยฟิลเตอร์ที่ไม่มีใครเชื่อถือได้

ชุดสถานะธุรกิจที่ปฏิบัติได้และแมปกับการตัดสินใจจริง:

• Imported: ไฟล์มีอยู่ แต่ยังไม่ได้ตรวจสอบ
• Needs review: ต้องให้คนยืนยันฟิลด์สำคัญหรือความอ่านได้
• Approved: พร้อมใช้งานลงต่อ (จ่าย เก็บ เผยแพร่ หรือส่งออก)
• Rejected: ใช้ไม่ได้ พร้อมเหตุผล
• Archived: เก็บเพื่อบันทึก ออกจากงานปัจจุบัน

เก็บ “processing” ไว้นอกสถานะธุรกิจ OCR กำลังทำงานและการสร้าง preview คือสิ่งที่ระบบกำลังทำ ไม่ใช่สิ่งที่คนควรทำต่อ จัดเก็บเหล่านั้นเป็นสถานะการประมวลผลแยกต่างหาก

นอกจากนี้แยกการมอบหมายออกจากสถานะ (assignee_id, team_id, due_date) เอกสารหนึ่งอาจถูกอนุมัติแต่ยังมอบหมายให้ติดตามผล หรือต้องการการตรวจสอบแต่ยังไม่มีเจ้าของ

บันทึกประวัติสถานะ ไม่ใช่แค่ค่าปัจจุบัน บันทึกง่าย ๆ เช่น (from_status, to_status, changed_at, changed_by, reason) ให้ประโยชน์เมื่อมีคนถามว่า “ใครปฏิเสธใบเสร็จนี้และเพราะเหตุใด?”

สุดท้าย ตัดสินใจว่าการกระทำใดทำได้ในแต่ละสถานะ เก็บกฎให้เรียบง่าย: Imported ไปยัง Needs review ได้; Approved เป็นแบบอ่านอย่างเดียวเว้นแต่สร้างเวอร์ชันใหม่; Rejected เปิดใหม่ได้แต่ต้องเก็บเหตุผลเดิม

รูปแบบ UI สำหรับรายการ มุมมองรายละเอียด และกระบวนการตรวจสอบ

เวลาส่วนใหญ่ใช้ในการสแกนรายการ เปิดหนึ่งรายการ แก้ฟิลด์ไม่กี่อย่าง แล้วไปต่อ UI ที่ดีทำให้ขั้นตอนเหล่านั้นเร็วและคาดเดาได้

สำหรับรายการเอกสาร ให้ถือว่าแต่ละแถวเป็นสรุปเพื่อให้ผู้ใช้ตัดสินใจโดยไม่ต้องเปิดทุกไฟล์ แถวที่ชัดเจนจะแสดงรูปย่อเล็ก ๆ ชื่อชัดเจน ฟิลด์สำคัญไม่กี่อัน (merchant, date, total) ป้ายสถานะ และสัญญาณเตือนเมื่อมีสิ่งต้องสนใจ

มุมมองรายละเอียดให้สงบและอ่านง่าย เลย์เอาต์ทั่วไปคือภาพตัวอย่างทางซ้ายและเมตาดาต้าทางขวา พร้อมควบคุมแก้ไขข้างฟิลด์แต่ละอัน ผู้ใช้ควรซูม หมุน และเปลี่ยนหน้าโดยไม่เสียตำแหน่งในฟอร์ม หากฟิลด์ถูกสกัดจาก OCR ให้แสดงระดับความเชื่อมั่นเล็ก ๆ และถ้าเป็นไปได้ ไฮไลต์พื้นที่ต้นทางบนตัวอย่างเมื่อโฟกัสฟิลด์

เวอร์ชันทำงานได้ดีสุดแบบไทม์ไลน์ ไม่ใช่ dropdown แสดงว่าใครเปลี่ยนอะไรและเมื่อไร และให้ผู้ใช้เปิดเวอร์ชันอดีตในโหมดอ่านอย่างเดียว หากมีการเปรียบเทียบ ให้เน้นความแตกต่างของเมตาดาต้า (จำนวนเปลี่ยน ผู้ขายแก้ไข) แทนการบังคับเปรียบเทียบพิกเซลต่อพิกเซลของ PDF

โหมดตรวจสอบควรเพิ่มประสิทธิภาพสำหรับความเร็ว โฟลว์คีย์บอร์ดแรกสำหรับการคัดแยกมักเพียงพอ: การอนุมัติ/ปฏิเสธอย่างเร็ว แก้ไขฟิลด์ทั่วไปอย่างรวดเร็ว และกล่องคอมเมนต์สั้น ๆ สำหรับการปฏิเสธ

สถานะที่ว่างก็สำคัญเพราะเอกสารมักอยู่ระหว่างการประมวลผล แทนที่จะเป็นกล่องว่าง อธิบายสิ่งที่เกิดขึ้น: “กำลังสร้างตัวอย่าง”, “OCR กำลังทำงาน”, หรือ “ประเภทไฟล์นี้ยังไม่มีตัวอย่าง”

ขั้นตอนทีละขั้น: เวิร์กโฟลว์เรียบง่ายตั้งแต่การอัปโหลดถึงการอนุมัติ

เวิร์กโฟลว์เรียบง่ายรู้สึกเหมือน “อัปโหลด ตรวจสอบ อนุมัติ” ตอนใต้ฝาที่ทำงานได้ดีที่สุดเมื่อคุณแยกไฟล์เอง (เวอร์ชันและตัวอย่าง) ออกจากความหมายธุรกิจ (เมตาดาต้าและสถานะ)

1) การอัปโหลดลงกล่องจดหมาย

ผู้ใช้ส่ง PDF ภาพ หรือสแกนใบเสร็จและเห็นมันในรายการกล่องจดหมายทันที อย่ารอให้การประมวลผลเสร็จ แสดงชื่อไฟล์ เวลาอัปโหลด และป้ายชัดเจนเช่น “Processing” หากคุณรู้แหล่งที่มา (อิมพอร์ตอีเมล กล้องมือถือ ลากแล้ววาง) ให้แสดงด้วย

2) สร้าง Document + Version ตัวอย่างเริ่มต้นเป็น pending

เมื่ออัปโหลด สร้างระเบียน Document (สิ่งที่ยาวอายุ) และระเบียน Version (ไฟล์เฉพาะนี้) ตั้ง current_version_id เป็นเวอร์ชันใหม่ ตั้ง preview_state = pending และ extraction_state = pending เพื่อให้ UI บอกได้ว่าพร้อมแค่ไหน

มุมมองรายละเอียดควรเปิดได้ทันที แต่แสดงตัวดูสำรองและข้อความ “Preparing preview” แทนกรอบที่เสีย

3) กระบวนการพื้นหลังสร้างตัวอย่างและสกัดเมตาดาต้า

งานพื้นหลังสร้างรูปย่อและตัวอย่างสำหรับการดู (ภาพหน้าสำหรับ PDF ภาพขนาดย่อสำหรับรูปถ่าย) งานอีกตัวสกัดเมตาดาต้า (vendor, date, total, currency, document type) เมื่องานแต่ละงานเสร็จ ให้ปรับสถานะและเวลาเฉพาะของมันเพื่อให้สามารถลองใหม่เมื่อผิดพลาดโดยไม่กระทบด้านอื่น

เก็บ UI ให้กะทัดรัด: แสดงสถานะ preview, สถานะข้อมูล, และเน้นฟิลด์ที่มีความเชื่อมั่นต่ำ

4) ผู้ตรวจแก้ไขฟิลด์ เปลี่ยนสถานะ และเพิ่มหมายเหตุ

เมื่อการตัวอย่างพร้อม ผู้ตรวจแก้ไขฟิลด์ เพิ่มหมายเหตุ และย้ายเอกสารผ่านสถานะธุรกิจเช่น Imported -> Needs review -> Approved (หรือ Rejected) บันทึกว่าใครเปลี่ยนอะไรและเมื่อไร

ถ้าผู้ตรวจอัปโหลดไฟล์ที่แก้ไข มันจะกลายเป็น Version ใหม่และเอกสารจะกลับไปเป็น Needs review อัตโนมัติ

5) ระบบลงต่ออ่านเวอร์ชันปัจจุบันและเมตาดาต้าที่อนุมัติ

การส่งออก การซิงค์บัญชี หรือรายงานภายในควรอ่านจาก current_version_id และ snapshot เมตาดาต้าที่อนุมัติ ไม่ใช้ “การสกัดล่าสุด” เพื่อป้องกันไม่ให้การอัปโหลดที่ประมวลผลไม่เสร็จเปลี่ยนตัวเลข

ข้อผิดพลาดทั่วไปและกับดักที่ควรหลีกเลี่ยง

เวิร์กโฟลว์มุ่งเน้นเอกสารล้มเหลวด้วยเหตุผลธรรมดา: ทางลัดตั้งแต่ต้นกลายเป็นปัญหารายวันเมื่อคนอัปโหลดสำเนา แก้ไขความผิดพลาด หรือถามว่า “ใครเปลี่ยนนี้เมื่อไร?”

การถือชื่อไฟล์เป็นตัวตนของเอกสารเป็นข้อผิดพลาดคลาสสิก ชื่อเปลี่ยน ผู้ใช้ส่งใหม่ และกล้องสร้างไฟล์ซ้ำอย่าง IMG_0001 ให้รหัสเอกสารคงที่และถือชื่อไฟล์เป็นป้ายเท่านั้น

การเขียนทับไฟล์ต้นฉบับเมื่อมีคนอัปโหลดการแทนที่ก็สร้างปัญหา มันดูง่าย แต่คุณจะสูญเสียประวัติและตอบคำถามพื้นฐานไม่ได้ (อะไรได้รับการอนุมัติ อะไรถูกแก้ไข อะไรส่งไป) เก็บไฟล์ไบนารีเป็นแบบไม่เปลี่ยนแปลงแล้วเพิ่มแถวเวอร์ชันใหม่

ความสับสนเรื่องสถานะสร้างบั๊กละเอียด ๆ “OCR กำลังทำงาน” ไม่เหมือนกับ “Needs review” สถานะการประมวลผลอธิบายสิ่งที่ระบบกำลังทำ สถานะธุรกิจอธิบายสิ่งที่คนควรทำต่อ เมื่อผสมกัน เอกสารจะติดอยู่ในถังผิด

การตัดสินใจ UI ก็สร้างแรงเสียดทานได้ หากคุณบล็อกหน้าจอจนกว่าจะสร้างตัวอย่าง คนจะรู้สึกว่าแอปช้าแม้ว่าการอัปโหลดจะสำเร็จ แสดงเอกสารทันทีด้วยตัวสำรองที่ชัดเจน แล้วเปลี่ยนเป็นรูปย่อเมื่อพร้อม

สุดท้าย เมตาดาต้าจะไม่น่าเชื่อถือเมื่อคุณเก็บค่าต่าง ๆ โดยไม่ระบุแหล่งที่มา หากจำนวนรวมมาจาก OCR ให้ระบุ เก็บ timestamp

รายการตรวจสอบสั้น ๆ:

• รหัสเอกสารคงที่แยกจากชื่อไฟล์
• เวอร์ชันใหม่ต่อการแทนที่ ไม่มีการเขียนทับ
• แยกสถานะธุรกิจออกจากสถานะการประมวลผล
• การโหลดตัวอย่างและรูปย่อไม่บล็อกหน้าจอ
• เมตาดาต้าระบุแหล่งที่มาและเวลา

ตัวอย่าง: ในแอปใบเสร็จ ผู้ใช้ส่งภาพชัดกว่า ถ้าคุณเวอร์ชันมัน เก็บภาพเก่า ทำเครื่องหมายว่า OCR กำลังประมวลผลใหม่ และเก็บเป็น Needs review จนกว่าคนจะยืนยันจำนวน

เช็คลิสต์ด่วนก่อนปล่อย

เวิร์กโฟลว์มุ่งเน้นเอกสารจะรู้สึก “เสร็จ” ก็ต่อเมื่อผู้คนไว้ใจสิ่งที่เห็นและกู้คืนเมื่อเกิดปัญหา ก่อนเปิดทดสอบกับเอกสารที่ยุ่งของจริง (ใบเสร็จเบลอ PDF หมุน ไฟล์ซ้ำ)

ห้าการตรวจสอบที่จับความประหลาดใจได้มากที่สุด:

• เวอร์ชันปัจจุบันชัดเจน: ทำเครื่องหมายเวอร์ชันที่ใช้งาน แสดงว่าใครเปลี่ยนเมื่อไร ใส่เหตุผลสั้น ๆ เช่น “ครอป” หรือ “อัปโหลดใหม่”
• ตัวอย่างล้มเหลวได้อย่างสุภาพ: ถ้าตัวอย่างกำลังสร้าง แสดงตัวสำรองที่มีประโยชน์ (ชื่อไฟล์ เวลาอัปโหลด จำนวนหน้า ถ้ารู้) และสถานะ pending ชัดเจน ถ้าสร้างล้มเหลว ให้แสดงข้อผิดพลาดและตัวเลือก retry
• สถานะสอดคล้องกับการกระทำ: ทุกสถานะต้องมีความหมายชัดเจนและชุดการกระทำที่จำกัด ถ้ามี Approved ให้ทำเป็นอ่านอย่างเดียว
• การแก้เมตาดาต้าไม่ลบทิ้งการสกัดเดิม: ให้ผู้ใช้แก้ OCR โดยไม่ลบค่าที่สกัดเดิม เก็บทั้งสองค่าแล้วแสดงว่าค่าไหนถูกใช้
• การกู้คืนถูกสร้างมาแล้ว: ทำให้การแก้ไขที่พบบ่อยง่าย: ย้อนกลับเป็นเวอร์ชันก่อนหน้า เรียกการสกัดใหม่ สร้างตัวอย่างใหม่

การทดสอบความเป็นจริงอย่างรวดเร็ว: ให้ใครสักคนตรวจใบเสร็จสามใบที่คล้ายกันและตั้งใจแก้ผิดหนึ่งรายการ ถ้าพวกเขาสามารถหาว่าเวอร์ชันปัจจุบันคืออันไหน เข้าใจสถานะ และแก้ไขข้อผิดพลาดภายในหนึ่งนาที คุณใกล้จะสำเร็จแล้ว

ตัวอย่างสถานการณ์และขั้นตอนถัดไปเชิงปฏิบัติ

การเบิกค่าใช้จ่ายรายเดือนเป็นตัวอย่างชัดเจนของงานมุ่งเน้นเอกสาร พนักงานส่งใบเสร็จ จากนั้นผู้ตรวจสองคนตรวจ: ผู้จัดการ แล้วฝ่ายการเงิน ใบเสร็จเป็นผลิตภัณฑ์ ดังนั้นแอปของคุณขึ้นหรือลงกับการเวอร์ชัน ตัวอย่าง เมตาดาต้า และสถานะที่ชัดเจน

Jamie ส่งภาพใบเสร็จแท็กซี่ ระบบของคุณสร้าง Document #1842 พร้อม Version v1 (ไฟล์ต้นฉบับ) รูปย่อและตัวอย่าง และเมตาดาต้าเช่น merchant, date, currency, total และคะแนนความเชื่อมั่น OCR เอกสารเริ่มที่ Imported แล้วไปเป็น Needs review เมื่อการตัวอย่างและการสกัดพร้อม

ต่อมา Jamie เผลอส่งใบเสร็จเดียวกันอีกครั้ง การตรวจจับสำเนา (file hash บวก merchant/date/total ที่คล้ายกัน) สามารถแสดงตัวเลือกชัดเจน: “ดูเหมือนซ้ำกับ #1842 แนบหรือทิ้ง” ถ้าพวกเขาแนบ ให้เก็บเป็น File อีกตัวที่เชื่อมกับ Document เดิม เพื่อให้มีเธรดการตรวจสอบเดียวและสถานะเดียว

ในระหว่างการตรวจ ผู้จัดการดูตัวอย่าง ฟิลด์สำคัญ และคำเตือน OCR เดา total เป็น $18.00 แต่ภาพชัดเจนว่าเป็น $13.00 Jamie แก้ total อย่าลบประวัติ สร้าง Version v2 ด้วยฟิลด์ที่อัปเดต เก็บ v1 ไว้ไม่เปลี่ยนแปลง และบันทึกว่า “Total corrected by Jamie”

ถ้าคุณอยากสร้างเวิร์กโฟลว์แบบนี้เร็ว ๆ Koder.ai (koder.ai) สามารถช่วยสร้างเวอร์ชันแรกของแอปจากแผนแชทได้ แต่กฎเดียวกันใช้: กำหนดอ็อบเจ็กต์และสถานะก่อน แล้วปล่อยให้หน้าจอตามมา

ขั้นตอนถัดไปเชิงปฏิบัติ:

• ร่างโมเดลข้อมูล: Document, Version, File, ExtractedField, Review, StatusHistory
• ออกแบบสองหน้าจอ: กล่องจดหมาย/รายการ (สถานะ + คำเตือน) และมุมมองรายละเอียด (ตัวอย่าง + ฟิลด์ + เวอร์ชัน)
• ทดสอบกับใบเสร็จจริงห้าชิ้นและปรับสถานะ กฎสำเนา และความเร็วการตรวจสอบ