ออกแบบเมทริกซ์การอนุมัติก่อน UI: กำหนดกฎก่อนออกแบบหน้าจอ

ทำไมหน้าจอถึงล้มเหลวเมื่อไม่มีเมทริกซ์ที่ชัดเจน

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

ความสับสนนี้แสดงให้เห็นเร็วในการทำงานจริง คนส่งคำขอ ประเด็นเข้ามาในแอป แล้วคำถามแรกคือ “ส่งให้ผู้จัดการ ฝ่ายการเงิน หรือทั้งสองฝ่าย?” หน้าจอดูเสร็จแล้ว แต่เส้นทางการตัดสินใจหายไป

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

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

จากนั้นปัญหาใหญ่กว่าเกิดขึ้น: แต่ละทีมเริ่มใช้เวอร์ชันของกฎที่ต่างกัน ฝ่ายปฏิบัติการส่งคำขอไปทางหนึ่ง ฝ่ายการเงินส่งไปอีกทาง และฝ่ายสนับสนุนจัดการข้อยกเว้นต่างจาก HR แอปกลายเป็นหน้าจอร่วมสำหรับการตัดสินใจที่ไม่สอดคล้อง แทนที่จะเป็นกระบวนการร่วม

สัญญาณเตือนมักจะสังเกตได้ง่าย:

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

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

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

อะไรที่ควรแม็ปก่อนวาดวายร์เฟรม

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

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

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

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

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

เมทริกซ์ที่ใช้งานได้มักตอบคำถามพื้นฐานห้าข้อ:

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

ถ้าแม็ปคำตอบเหล่านี้ตั้งแต่ต้น งานที่เหลือจะง่ายขึ้นมาก

วิธีสร้างเมทริกซ์ทีละขั้นตอน

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

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

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

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

จากนั้นบันทึกข้อยกเว้น ขีดเวลา และสภาพสิ้นสุด รวมเคสเช่นเอกสารหาย คำขอซ้ำ ฝ่าฝืนนโยบาย และการอนุมัติที่เลยเวลา กฎยังไม่สมบูรณ์จนกว่าคุณจะรู้ว่ามันทำงานอย่างไรเมื่อสิ่งต่างๆ ผิดพลาด

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

ตัวอย่างเล็กๆ ช่วยให้ชัดเจน สมมติคำขอซื้อ: อุปกรณ์สำนักงานต่ำกว่า $200 ส่งให้หัวหน้าทีม ซอฟต์แวร์ระหว่าง $200 ถึง $2,000 ส่งให้ผู้จัดการแผนก และเกินกว่านั้นต้องมีการตรวจสอบจากฝ่ายการเงินด้วย หากแบบฟอร์มไม่เก็บจำนวนเงินและหมวดหมู่ตั้งแต่ต้น UI จะไม่สามารถส่งคำขอไปตามเส้นทางที่ถูกต้องได้

กำหนดเกณฑ์ที่คนทำตามได้จริง

เกณฑ์ทำงานได้เมื่อคนอ่านแล้วเข้าใจตรงกัน หากกฎบอกว่า “การซื้อเล็ก” หรือ “ผู้ขายความเสี่ยงสูง” คนจะตีความต่างกัน ใช้ตัวเลข วันที่ และเงื่อนไขที่ระบุชัดเจนแทน

กฎที่ชัดเจนตัวอย่าง: “ไม่เกิน $1,000 ส่งให้หัวหน้าทีม $1,001 ถึง $5,000 ส่งให้ผู้จัดการแผนก มากกว่า $5,000 ส่งให้ฝ่ายการเงินและผู้อำนวยการ” จะไม่มีใครเดาว่าคำขอควรไปไหน

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

ส่วนใหญ่ทีมต้องการชุดกฎการกำหนดเส้นทางไม่กี่รายการ ตัวอย่างทั่วไปได้แก่ช่วงวงเงิน สถานะผู้ขาย หมวดการซื้อ แผนก และความเร่งด่วน สิ่งสำคัญไม่ใช่จำนวนกฎ แต่คือทุกคนใช้กฎเดียวกันหรือไม่

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

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

ทดสอบง่ายๆ ให้คนสามคนอ่านตัวอย่างคำขอเดียวกันแล้วถามว่าควรส่งให้ใคร หากได้คำตอบต่างกัน แปลว่าเกณฑ์ยังไม่ชัดพอ

วางแผนผู้อนุมัติสำรอง ตัวแทนชั่วคราว และการยกระดับ

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

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

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

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

การยกระดับควรกำหนดตามทริกเกอร์ชัดเจน ไม่ใช่การเดา ทริกเกอร์ทั่วไปได้แก่ เวลา จำนวน ความเสี่ยง หรือข้อมูลขาดหาย ยกตัวอย่าง หากคำขอซื้อเกิน $10,000 นิ่งอยู่ 24 ชั่วโมง อาจยกระดับไปยังหัวหน้าแผนก

รักษาเส้นทางการยกระดับให้สั้น หากคนต้องใช้แผนภาพซับซ้อนเพียงเพื่อเข้าใจว่าใครจะได้รับคำขอถัดไป แสดงว่ากฎซับซ้อนเกินไป กระโดดหนึ่งหรือสองขั้นชัดเจนมักเพียงพอ

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

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

ตัวอย่างเรียบง่าย: การอนุมัติคำขอซื้อ

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

ถ้าคำขอเป็น $420 จะส่งตรงให้หัวหน้าทีม เพื่อให้การซื้อเล็กๆ เดินต่อไป คำขอ $3,200 ข้ามหัวหน้าทีมไปหาผู้จัดการแผนกเพราะผลกระทบต่อ งบประมาณมากกว่า

ตอนนี้ลองคำขอ $7,800 สำหรับอุปกรณ์ใหม่ ผู้จัดการแผนกยังต้องทบทวน แต่ยังไม่พอ เพราะจำนวนเงินเกิน $5,000 ฝ่ายการเงินก็ต้องตรวจสอบด้วย นี่คือที่เมทริกซ์ที่ชัดเจนช่วยได้: จำนวนเงินที่สูงขึ้นเพิ่มการควบคุมโดยไม่ต้องเดา

การขาดงานสำคัญเช่นกัน หากผู้จัดการแผนกลา คำขอไม่ควรค้างอยู่เฉยๆ ตัวแทนที่ถูกระบุจะได้รับอัตโนมัติและสามารถทำหน้าที่ตามช่วงเวลาที่กำหนด

ขีดเวลาต้องชัดเหมือนกัน หากไม่มีใครทำภายในสองวัน คำขอจะยกระดับไปยังฝ่ายปฏิบัติการ ฝ่ายปฏิบัติการจะติดตาม มอบหมายใหม่ หรือทำให้แน่ใจว่ามันไม่ขัดขวางงาน

ในตัวอย่างนี้ เมทริกซ์ตอบคำถามสำคัญไม่กี่ข้อ: จำนวนที่ขอ ใครอนุมัติตามจำนวน เมื่อฝ่ายการเงินเข้ามา ใครทดแทนตอนขาดงาน และจะเกิดอะไรขึ้นเมื่อพลาดเส้นตาย

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

ความผิดพลาดทั่วไปที่ทำให้ต้องทำงานซ้ำ

งานแก้ซ้ำส่วนใหญ่เริ่มก่อนจะวาดหน้าจอทีมเดียว ทีมเดาเส้นทางการอนุมัติ แล้วพยายามปรับ UI ให้เข้ากับกฎที่ยังไม่ถูกตกลงจริง

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

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

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

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

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

การตรวจสอบความเป็นจริงอย่างรวดเร็วช่วยจับปัญหาตั้งแต่ต้น:

• ผู้อนุมัติสองคนสามารถรับคำขอเดียวกันพร้อมกันได้ไหม?

• ความแตกต่างระหว่างการสำรองชั่วคราวกับความเป็นเจ้าของถาวรชัดเจนไหม?

• เคสด่วนหรือมีการควบคุมมีเส้นทางต่างกันไหม?

• การตัดสินใจแต่ละจุดขึ้นกับฟิลด์ที่มีอยู่แล้วหรือไม่?

• กระบวนการยังสมเหตุสมผลไหมถ้าผู้อนุมัติคนหนึ่งลาออก?

ถ้ามีคำตอบใดไม่ชัด หยุดตรงนั้น แก้เมทริกซ์ก่อนขัดเกลา หน้าจอ

การตรวจสอบด่วนก่อนออกแบบหน้าจอ

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

ทำรีวิวเร็วๆ โดยใช้ตัวอย่างจริง ขอให้คนหนึ่งอธิบายเส้นทางทั้งหมดตั้งแต่ส่งจนจบ ตรวจสอบว่าทุกผลลัพธ์ที่เป็นไปได้มีผู้อนุมัติถัดไปที่ชัดเจน ไม่ใช่แค่ทางเดินสำเร็จ พิมพ์เกณฑ์กำกวมใหม่เป็นกฎที่ชัดเจนเช่น “$1,000 หรือต่ำกว่า” หรือ “เกิน 10% ส่วนลด” ยืนยันว่ากฎสำรองและยกระดับใช้ขีดเวลาอย่างชัดเจนเช่น “หลัง 24 ชั่วโมง” หรือ “หลัง 2 วันทำการ”

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

สถานการณ์ง่ายๆ มักเผยจุดอ่อน ลองนึกคำขอซื้อ $4,800 มาถึงวันศุกร์ตอนเย็น ขณะที่ผู้อนุมัติปกติไม่อยู่ ใครรับต่อ? ระบบรอได้นานเท่าไหร่ก่อนย้าย? ถ้าผู้สำรองก็ไม่ทำอะไรอีกล่ะ? ถ้าคำตอบเหล่านี้ไม่ถูกเขียนไว้ UI จะซ่อนความสับสนแทนที่จะแก้ไขมัน

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

ขั้นตอนต่อไป: แปลงเมทริกซ์เป็นแอปใช้งานได้

เมื่อกฎชัดเจนแล้ว สร้างกระบวนการก่อนที่จะขัดเกลาหน้าจอ เริ่มจากตรรกะ ฟิลด์ข้อมูล และสถานะการอนุมัติ หากการกำหนดเส้นทางทำงาน อินเทอร์เฟซจะออกแบบได้ง่ายขึ้นมาก หากยังแก้ไขบ่อย หน้าจอสวยๆ จะซ่อนปัญหาไว้เท่านั้น

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

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

ลำดับการพัฒนาที่สมเหตุสมผลคือ:

• กำหนดฟิลด์ข้อมูลหลักและค่าสถานะ
• เพิ่มกฎการกำหนดเส้นทางสำหรับเกณฑ์ ผู้อนุมัติสำรอง ตัวแทนชั่วคราว และการยกระดับ
• สร้างหน้าจอพื้นฐานสำหรับผู้ขอและผู้อนุมัติ
• ตรวจสอบให้แน่ใจว่าทุกช่องทางใช้แหล่งความจริงเดียวกัน
• ทดสอบคำขอจริงหนึ่งรายการตั้งแต่ต้นจนจบก่อนขยายใช้งาน

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

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

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

ปรับคำและการจัดวางหลังจากนั้น เมื่อกระบวนการทำงานกับคำขอจริง หน้าจอก็ออกแบบได้ง่ายขึ้นและมีโอกาสต้องแก้ซ้ำน้อยลง