16 ม.ค. 2569·2 นาที
เวิร์กโฟลว์มุ่งเน้นเอกสาร: โมเดลข้อมูลและรูปแบบ UI
อธิบายเวิร์กโฟลว์มุ่งเน้นเอกสารพร้อมโมเดลข้อมูลและรูปแบบ UI ที่ใช้ได้จริงสำหรับเวอร์ชัน ตัวอย่าง เมตาดาต้า และสถานะที่ชัดเจน
อธิบายเวิร์กโฟลว์มุ่งเน้นเอกสารพร้อมโมเดลข้อมูลและรูปแบบ UI ที่ใช้ได้จริงสำหรับเวอร์ชัน ตัวอย่าง เมตาดาต้า และสถานะที่ชัดเจน
แอปจะถือว่ามุ่งเน้นเอกสารเมื่อเอกสารเป็นผลิตภัณฑ์ที่ผู้ใช้สร้าง ตรวจทาน และพึ่งพา ประสบการณ์ถูกสร้างขึ้นรอบไฟล์อย่าง PDF รูปภาพ สแกน และใบเสร็จ—not around a form where a file is just an attachment.
ในเวิร์กโฟลว์ที่มุ่งเน้นเอกสาร ผู้คนทำงานจริงภายในเอกสาร: เปิดดูว่าอะไรเปลี่ยน เพิ่มบริบท และตัดสินใจว่าจะทำอย่างไรต่อไป หากเอกสารไม่ไว้วางใจได้ แอปก็หยุดมีประโยชน์
แอปมุ่งเน้นเอกสารส่วนใหญ่ต้องมีหน้าจอหลักไม่กี่หน้าในตอนแรก:
ปัญหาจะปรากฏอย่างรวดเร็ว ผู้ใช้จะอัปโหลดใบเสร็จซ้ำสองคน คนหนึ่งแก้ไข PDF แล้วอัปโหลดใหม่โดยไม่อธิบาย เหตุการณ์สแกนไม่มีวันที่ ไม่มีผู้ขาย และไม่มีเจ้าของ ผ่านไปหลายสัปดาห์ก็ไม่มีใครรู้ว่าเวอร์ชันไหนได้รับการอนุมัติหรือการตัดสินใจมาจากอะไร
แอปมุ่งเน้นเอกสารที่ดีรู้สึกเร็วและเชื่อถือได้ ผู้ใช้ควรตอบคำถามเหล่านี้ได้ในไม่กี่วินาที:
ความชัดเจนนี้มาจากคำนิยาม ก่อนสร้างหน้าจอ ให้ตัดสินใจว่า “เวอร์ชัน”, “ตัวอย่าง”, “เมตาดาต้า” และ “สถานะ” หมายความว่าอย่างไรในแอปของคุณ หากคำพวกนี้ไม่ชัดเจน คุณจะได้สำเนาซ้ำ ประวัติสับสน และกระบวนการตรวจสอบที่ไม่ตรงกับงานจริง
UI มักดูเรียบง่าย (รายการ ตัวดูไฟล์ ปุ่มไม่กี่ปุ่ม) แต่โมเดลข้อมูลนั้นแบกรับภาระ หากอ็อบเจ็กต์หลักถูกต้อง ประวัติการตรวจสอบ ตัวอย่างที่เร็ว และการอนุมัติที่เชื่อถือได้จะง่ายขึ้นมาก
เริ่มจากการแยกระหว่าง “ระเบียนเอกสาร” กับ “เนื้อหาไฟล์” ระเบียนคือสิ่งที่ผู้ใช้พูดถึง (บิลจาก ACME ใบเสร็จแท็กซี่) เนื้อหาคือไบต์ (PDF, JPG) ที่อาจถูกแทนที่ ประมวลผลซ้ำ หรือลงที่อื่นโดยไม่เปลี่ยนความหมายภายในแอป
ชุดอ็อบเจ็กต์เชิงปฏิบัติที่ควรออกแบบ:
ตัดสินใจว่าอะไรได้ 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 แทนที่จะหายไปหรือบล็อกทั้งชุด
เมตาดาต้าทำให้กองไฟล์กลายเป็นสิ่งที่ค้นหา จัดเรียง ตรวจสอบ และอนุมัติได้ มันช่วยให้คนตอบคำถามง่าย ๆ ได้เร็ว: นี่คืออะไร? มาจากใคร? ใช้ได้ไหม? ควรทำอะไรต่อ?
วิธีปฏิบัติที่ดีเพื่อเก็บเมตาดาต้าให้สะอาดคือแยกตามที่มาของมัน:
การแยกกลุ่มเหล่านี้ป้องกันข้อถกเถียงภายหลัง หากจำนวนรวมผิด คุณจะเห็นว่ามาจาก 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 การปิดบัง การหมุนหน้า และการจำแนกต่อหน้ามักอยู่ระดับหน้าต่อหน้า
สถานะตอบคำถามหนึ่งข้อ: “เอกสารนี้อยู่ในกระบวนการขั้นไหน?” ทำให้มันเล็กและน่าเชื่อถือ หากคุณเพิ่มสถานะใหม่ทุกครั้งที่ใครขอ คุณจะจบด้วยฟิลเตอร์ที่ไม่มีใครเชื่อถือได้
ชุดสถานะธุรกิจที่ปฏิบัติได้และแมปกับการตัดสินใจจริง:
เก็บ “processing” ไว้นอกสถานะธุรกิจ OCR กำลังทำงานและการสร้าง preview คือสิ่งที่ระบบกำลังทำ ไม่ใช่สิ่งที่คนควรทำต่อ จัดเก็บเหล่านั้นเป็นสถานะการประมวลผลแยกต่างหาก
นอกจากนี้แยกการมอบหมายออกจากสถานะ (assignee_id, team_id, due_date) เอกสารหนึ่งอาจถูกอนุมัติแต่ยังมอบหมายให้ติดตามผล หรือต้องการการตรวจสอบแต่ยังไม่มีเจ้าของ
บันทึกประวัติสถานะ ไม่ใช่แค่ค่าปัจจุบัน บันทึกง่าย ๆ เช่น (from_status, to_status, changed_at, changed_by, reason) ให้ประโยชน์เมื่อมีคนถามว่า “ใครปฏิเสธใบเสร็จนี้และเพราะเหตุใด?”
สุดท้าย ตัดสินใจว่าการกระทำใดทำได้ในแต่ละสถานะ เก็บกฎให้เรียบง่าย: Imported ไปยัง Needs review ได้; Approved เป็นแบบอ่านอย่างเดียวเว้นแต่สร้างเวอร์ชันใหม่; Rejected เปิดใหม่ได้แต่ต้องเก็บเหตุผลเดิม
เวลาส่วนใหญ่ใช้ในการสแกนรายการ เปิดหนึ่งรายการ แก้ฟิลด์ไม่กี่อย่าง แล้วไปต่อ UI ที่ดีทำให้ขั้นตอนเหล่านั้นเร็วและคาดเดาได้
สำหรับรายการเอกสาร ให้ถือว่าแต่ละแถวเป็นสรุปเพื่อให้ผู้ใช้ตัดสินใจโดยไม่ต้องเปิดทุกไฟล์ แถวที่ชัดเจนจะแสดงรูปย่อเล็ก ๆ ชื่อชัดเจน ฟิลด์สำคัญไม่กี่อัน (merchant, date, total) ป้ายสถานะ และสัญญาณเตือนเมื่อมีสิ่งต้องสนใจ
มุมมองรายละเอียดให้สงบและอ่านง่าย เลย์เอาต์ทั่วไปคือภาพตัวอย่างทางซ้ายและเมตาดาต้าทางขวา พร้อมควบคุมแก้ไขข้างฟิลด์แต่ละอัน ผู้ใช้ควรซูม หมุน และเปลี่ยนหน้าโดยไม่เสียตำแหน่งในฟอร์ม หากฟิลด์ถูกสกัดจาก OCR ให้แสดงระดับความเชื่อมั่นเล็ก ๆ และถ้าเป็นไปได้ ไฮไลต์พื้นที่ต้นทางบนตัวอย่างเมื่อโฟกัสฟิลด์
เวอร์ชันทำงานได้ดีสุดแบบไทม์ไลน์ ไม่ใช่ dropdown แสดงว่าใครเปลี่ยนอะไรและเมื่อไร และให้ผู้ใช้เปิดเวอร์ชันอดีตในโหมดอ่านอย่างเดียว หากมีการเปรียบเทียบ ให้เน้นความแตกต่างของเมตาดาต้า (จำนวนเปลี่ยน ผู้ขายแก้ไข) แทนการบังคับเปรียบเทียบพิกเซลต่อพิกเซลของ PDF
โหมดตรวจสอบควรเพิ่มประสิทธิภาพสำหรับความเร็ว โฟลว์คีย์บอร์ดแรกสำหรับการคัดแยกมักเพียงพอ: การอนุมัติ/ปฏิเสธอย่างเร็ว แก้ไขฟิลด์ทั่วไปอย่างรวดเร็ว และกล่องคอมเมนต์สั้น ๆ สำหรับการปฏิเสธ
สถานะที่ว่างก็สำคัญเพราะเอกสารมักอยู่ระหว่างการประมวลผล แทนที่จะเป็นกล่องว่าง อธิบายสิ่งที่เกิดขึ้น: “กำลังสร้างตัวอย่าง”, “OCR กำลังทำงาน”, หรือ “ประเภทไฟล์นี้ยังไม่มีตัวอย่าง”
เวิร์กโฟลว์เรียบง่ายรู้สึกเหมือน “อัปโหลด ตรวจสอบ อนุมัติ” ตอนใต้ฝาที่ทำงานได้ดีที่สุดเมื่อคุณแยกไฟล์เอง (เวอร์ชันและตัวอย่าง) ออกจากความหมายธุรกิจ (เมตาดาต้าและสถานะ)
ผู้ใช้ส่ง PDF ภาพ หรือสแกนใบเสร็จและเห็นมันในรายการกล่องจดหมายทันที อย่ารอให้การประมวลผลเสร็จ แสดงชื่อไฟล์ เวลาอัปโหลด และป้ายชัดเจนเช่น “Processing” หากคุณรู้แหล่งที่มา (อิมพอร์ตอีเมล กล้องมือถือ ลากแล้ววาง) ให้แสดงด้วย
เมื่ออัปโหลด สร้างระเบียน Document (สิ่งที่ยาวอายุ) และระเบียน Version (ไฟล์เฉพาะนี้) ตั้ง current_version_id เป็นเวอร์ชันใหม่ ตั้ง preview_state = pending และ extraction_state = pending เพื่อให้ UI บอกได้ว่าพร้อมแค่ไหน
มุมมองรายละเอียดควรเปิดได้ทันที แต่แสดงตัวดูสำรองและข้อความ “Preparing preview” แทนกรอบที่เสีย
งานพื้นหลังสร้างรูปย่อและตัวอย่างสำหรับการดู (ภาพหน้าสำหรับ PDF ภาพขนาดย่อสำหรับรูปถ่าย) งานอีกตัวสกัดเมตาดาต้า (vendor, date, total, currency, document type) เมื่องานแต่ละงานเสร็จ ให้ปรับสถานะและเวลาเฉพาะของมันเพื่อให้สามารถลองใหม่เมื่อผิดพลาดโดยไม่กระทบด้านอื่น
เก็บ UI ให้กะทัดรัด: แสดงสถานะ preview, สถานะข้อมูล, และเน้นฟิลด์ที่มีความเชื่อมั่นต่ำ
เมื่อการตัวอย่างพร้อม ผู้ตรวจแก้ไขฟิลด์ เพิ่มหมายเหตุ และย้ายเอกสารผ่านสถานะธุรกิจเช่น Imported -> Needs review -> Approved (หรือ Rejected) บันทึกว่าใครเปลี่ยนอะไรและเมื่อไร
ถ้าผู้ตรวจอัปโหลดไฟล์ที่แก้ไข มันจะกลายเป็น Version ใหม่และเอกสารจะกลับไปเป็น Needs review อัตโนมัติ
การส่งออก การซิงค์บัญชี หรือรายงานภายในควรอ่านจาก current_version_id และ snapshot เมตาดาต้าที่อนุมัติ ไม่ใช้ “การสกัดล่าสุด” เพื่อป้องกันไม่ให้การอัปโหลดที่ประมวลผลไม่เสร็จเปลี่ยนตัวเลข
เวิร์กโฟลว์มุ่งเน้นเอกสารล้มเหลวด้วยเหตุผลธรรมดา: ทางลัดตั้งแต่ต้นกลายเป็นปัญหารายวันเมื่อคนอัปโหลดสำเนา แก้ไขความผิดพลาด หรือถามว่า “ใครเปลี่ยนนี้เมื่อไร?”
การถือชื่อไฟล์เป็นตัวตนของเอกสารเป็นข้อผิดพลาดคลาสสิก ชื่อเปลี่ยน ผู้ใช้ส่งใหม่ และกล้องสร้างไฟล์ซ้ำอย่าง IMG_0001 ให้รหัสเอกสารคงที่และถือชื่อไฟล์เป็นป้ายเท่านั้น
การเขียนทับไฟล์ต้นฉบับเมื่อมีคนอัปโหลดการแทนที่ก็สร้างปัญหา มันดูง่าย แต่คุณจะสูญเสียประวัติและตอบคำถามพื้นฐานไม่ได้ (อะไรได้รับการอนุมัติ อะไรถูกแก้ไข อะไรส่งไป) เก็บไฟล์ไบนารีเป็นแบบไม่เปลี่ยนแปลงแล้วเพิ่มแถวเวอร์ชันใหม่
ความสับสนเรื่องสถานะสร้างบั๊กละเอียด ๆ “OCR กำลังทำงาน” ไม่เหมือนกับ “Needs review” สถานะการประมวลผลอธิบายสิ่งที่ระบบกำลังทำ สถานะธุรกิจอธิบายสิ่งที่คนควรทำต่อ เมื่อผสมกัน เอกสารจะติดอยู่ในถังผิด
การตัดสินใจ UI ก็สร้างแรงเสียดทานได้ หากคุณบล็อกหน้าจอจนกว่าจะสร้างตัวอย่าง คนจะรู้สึกว่าแอปช้าแม้ว่าการอัปโหลดจะสำเร็จ แสดงเอกสารทันทีด้วยตัวสำรองที่ชัดเจน แล้วเปลี่ยนเป็นรูปย่อเมื่อพร้อม
สุดท้าย เมตาดาต้าจะไม่น่าเชื่อถือเมื่อคุณเก็บค่าต่าง ๆ โดยไม่ระบุแหล่งที่มา หากจำนวนรวมมาจาก OCR ให้ระบุ เก็บ timestamp
รายการตรวจสอบสั้น ๆ:
ตัวอย่าง: ในแอปใบเสร็จ ผู้ใช้ส่งภาพชัดกว่า ถ้าคุณเวอร์ชันมัน เก็บภาพเก่า ทำเครื่องหมายว่า OCR กำลังประมวลผลใหม่ และเก็บเป็น Needs review จนกว่าคนจะยืนยันจำนวน
เวิร์กโฟลว์มุ่งเน้นเอกสารจะรู้สึก “เสร็จ” ก็ต่อเมื่อผู้คนไว้ใจสิ่งที่เห็นและกู้คืนเมื่อเกิดปัญหา ก่อนเปิดทดสอบกับเอกสารที่ยุ่งของจริง (ใบเสร็จเบลอ PDF หมุน ไฟล์ซ้ำ)
ห้าการตรวจสอบที่จับความประหลาดใจได้มากที่สุด:
การทดสอบความเป็นจริงอย่างรวดเร็ว: ให้ใครสักคนตรวจใบเสร็จสามใบที่คล้ายกันและตั้งใจแก้ผิดหนึ่งรายการ ถ้าพวกเขาสามารถหาว่าเวอร์ชันปัจจุบันคืออันไหน เข้าใจสถานะ และแก้ไขข้อผิดพลาดภายในหนึ่งนาที คุณใกล้จะสำเร็จแล้ว
การเบิกค่าใช้จ่ายรายเดือนเป็นตัวอย่างชัดเจนของงานมุ่งเน้นเอกสาร พนักงานส่งใบเสร็จ จากนั้นผู้ตรวจสองคนตรวจ: ผู้จัดการ แล้วฝ่ายการเงิน ใบเสร็จเป็นผลิตภัณฑ์ ดังนั้นแอปของคุณขึ้นหรือลงกับการเวอร์ชัน ตัวอย่าง เมตาดาต้า และสถานะที่ชัดเจน
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 ที่คงตัวไว้ไม่เปลี่ยนแปลง และเก็บไบต์ไฟล์จริงเป็นอ็อบเจ็กต์ File แยกต่างหาก แล้วเพิ่ม Version เป็นสแนปช็อตที่เชื่อม Document กับไฟล์นั้นและผลลัพธ์ที่ได้ การแยกส่วนนี้ช่วยให้คอมเมนต์ การมอบหมาย และประวัติยังคงอยู่แม้ไฟล์จะถูกแทนที่
ทุกการเปลี่ยนแปลงที่มีความหมายควรเป็นเวอร์ชันใหม่ แทนการแก้ไขในที่เดียว เก็บ current_version_id บน Document เพื่อการอ่าน “ล่าสุด” ที่เร็ว และเก็บไทม์ไลน์ของเวอร์ชันเก่าไว้สำหรับการตรวจสอบและย้อนกลับ วิธีนี้ป้องกันความสับสนเรื่องสิ่งที่ได้รับการอนุมัติและเหตุผล
สร้างตัวอย่างแบบอะซิงโครนัสหลังจากบันทึกไฟล์ต้นฉบับ เพื่อให้การอัปโหลดรู้สึกทันทีและสามารถลองใหม่ได้อย่างปลอดภัย ติดตามสถานะ preview เช่น pending/ready/failed เพื่อให้ UI บอกสถานะได้ตรงไปตรงมา และเก็บขนาดหลายขนาดเพื่อให้มุมมองรายการเบาและมุมมองรายละเอียดคมชัด
เก็บเมตาดาต้าเป็นสามกลุ่ม: ระบบ (ขนาดไฟล์ ประเภท), ที่สกัดได้ (OCR และคะแนนความเชื่อมั่น), และที่ผู้ใช้ป้อน (การแก้ไข ป้าย ข้อสังเกต) ระบุแหล่งที่มาของค่าทุกค่าเพื่อให้รู้ว่าค่าได้มาจาก OCR หรือจากคน และหลีกเลี่ยงการบังคับให้กรอกทุกฟิลด์ก่อนดำเนินการต่อ
ใช้ชุดสถานะธุรกิจเล็ก ๆ ที่อธิบายสิ่งที่คนควรทำต่อ เช่น Imported, Needs review, Approved, Rejected, Archived แยกสถานะกระบวนการ (เช่น OCR กำลังทำงาน) ออกไป เพราะนั่นเป็นงานของระบบ ไม่ใช่งานของคน จัดการการมอบหมายแยกจากสถานะด้วย (assignee_id, team_id, due_date)
เก็บ checksum ของไฟล์เมื่ออัปโหลดและเปรียบเทียบค่าเพื่อค้นหาสำเนา จากนั้นเพิ่มการตรวจสอบด้วยฟิลด์สำคัญอย่าง vendor/date/total เมื่อมี เมื่อสงสัยเป็นสำเนา ให้ผู้ใช้เลือกชัดเจนว่าจะแนบกับ Document เดิมหรือทิ้ง เพื่อไม่ให้ประวัติการตรวจสอบแยกออกเป็นสำเนาหลายชิ้น
เก็บบันทึกประวัติสถานะที่มีว่าใครเปลี่ยนอะไร เมื่อไร และเพราะเหตุใด และเก็บเวอร์ชันให้อ่านได้ผ่านไทม์ไลน์ การย้อนกลับควรเป็นการเปลี่ยน pointer กลับไปหาเวอร์ชันเก่า ไม่ใช่การลบ เพื่อกู้คืนได้เร็วโดยไม่สูญเสียบันทึกตรวจสอบ
กำหนดอ็อบเจ็กต์และสถานะให้ชัดก่อน แล้วให้ UI ตามมา หากใช้ Koder.ai เพื่อสร้างแอปจากแผนในแชท ให้ระบุชัดเจนเรื่อง Document/Version/File, สถานะ preview และ extraction, และกฎสถานะ เพื่อให้หน้าจอที่สร้างตรงกับพฤติกรรมการทำงานจริง