ในหน้านี้
ระเบียนรายชื่อเปิดอยู่แล้วตอนผู้ปฏิบัติงานฝ่ายขายพบรายการซ้ำ ในเวิร์กโฟลว์สมมตินี้ ระบบอัตโนมัติแก้ได้ แต่ผู้ปฏิบัติงานต้องเปิดแดชบอร์ดแยก ค้นรายชื่อเดิม แล้วกลับ CRM เพื่อตรวจผล ระบบอัตโนมัติอาจเร็ว แต่ทางอ้อมรอบมันไม่เร็ว
นี่นำไปสู่คำถามผลิตภัณฑ์ที่พลาดง่ายตอนออกแบบระบบอัตโนมัติ: ผลควรปรากฏที่ไหน
บทสนทนาที่เก็บมาเรื่องระบบอัตโนมัติในที่ทำงาน สนับสนุนให้ลงมือในระบบบันทึกข้อมูลหลักแทนขอให้ทุกคนเรียนหน้าจอใหม่ นี่เป็นสมมติฐานการออกแบบ ไม่ใช่หลักฐานว่าการทำแบบใดเพิ่มการใช้ มันมีประโยชน์เพราะเปลี่ยนหน่วยออกแบบจากหน้าจอเป็นงานที่เสร็จ
ตามระเบียน การตัดสิน และการส่งต่อ
วาดงานจริงหนึ่งงาน ระเบียนปรากฏครั้งแรกที่ไหน ใครตัดสินว่าพร้อม คนคนนั้นต้องตรวจอะไร ตรวจว่าเปลี่ยนแล้วที่ไหน นับขั้นและจุดที่ต้องคัดลอกหรือกรอกบริบทซ้ำ
ในกรณีรายชื่อซ้ำสมมติ ผู้ปฏิบัติงานเปิดระเบียนลูกค้าอยู่แล้ว คำแนะนำข้างระเบียนอาจแสดงฟิลด์ที่ขัดกันและการรวมที่เสนอ ขั้นทบทวนอยู่ใกล้การตัดสิน ผลปรากฏบนระเบียนที่อัปเดต ทางนี้อาจใช้ขั้นน้อยกว่าแดชบอร์ดใหม่ แม้แดชบอร์ดดูสะอาดกว่าในเดโม
- เปิดระเบียนงานที่ทำอยู่บริบทเดิม
- ดูข้อเสนอฟิลด์ที่ขัดกันคนตัดสิน
- อนุญาตการเปลี่ยนขอบเขตที่ถูกเงื่อนไขหลัง
- ตรวจผลระเบียนที่อัปเดต
บทสนทนาต้นทางยังแบ่งขั้นเป็นขั้นที่ควรลบ การกระทำแบบกำหนดแน่นอน การตัดสินที่ต้องใช้วิจารณญาณ และการอนุมัติของคน ตำแหน่งสำคัญต่างกันในแต่ละชนิด การอัปเดตแบบแน่นอนอาจทำงานโดยไม่มีหน้าจอให้เห็นและทิ้งสถานะชัด การรวมที่กำกวมต้องมีคำอธิบายและจุดทบทวน การกระทำที่มีผลต้องใช้อำนาจของผู้รับผิดชอบไม่ว่าอินเทอร์เฟซอยู่ไหน
คู่มือเชื่อมต่อเครื่องมือธุรกิจหลายตัวของเรา ให้ทีมกำหนดแหล่งข้อมูลหลัก การตัดสินนั้นช่วยวางปฏิสัมพันธ์: เจ้าของระเบียนมักเป็นที่ธรรมชาติให้ดูและแก้ แต่มันไม่ได้หมายความว่าทุกเครื่องมือแสดงคำอธิบายทุกอย่างที่จำเป็นได้
ผลที่ฝังอยู่ยังต้องมีร่องรอยตรวจได้
“ไม่ต้องมีอินเทอร์เฟซใหม่” อาจกลายเป็นคำขวัญซ่อนการควบคุมที่ขาด หากระบบอัตโนมัติเปลี่ยนระเบียนใน CRM ผู้ใช้ต้องรู้ว่าอะไรเปลี่ยน เพราะอะไร และระบบอื่นตรงกันหรือยัง ข้อความในหน้า “เสร็จ” บางเกินหากงานข้ามสองระบบ
การออกแบบอาจต้องมีสถานะสั้นในเครื่องมือทำงานและหน้าประวัติลึกที่อื่น สิ่งเหล่านี้ตอบคนละช่วง ผู้ปฏิบัติงานต้องลงมือกับระเบียนปัจจุบัน ผู้ดูแลอาจต้องดูงานล้มเหลว สิทธิ์ และรูปแบบข้ามบัญชี อินเทอร์เฟซที่ดีที่สุดจึงอาจมีหลายหน้า แต่ละหน้าคู่กับงาน
Tajo มีทรัพยากรกิจกรรม MCP ที่แสดงผล ขั้นตอน และเหตุการณ์ดิบที่ขยายดูได้ ภาพด้านล่างนำแนวคิดนี้ไว้ในบทสนทนาและเพิ่มแผงตรวจยืนยันที่เสนอ ผู้ปฏิบัติงานเห็นผลทันทีแล้วเปิดหลักฐานเมื่อจำเป็น เค้าโครงนี้ไม่ได้พิสูจน์ว่าใช้กับทุกแอปโฮสต์ได้
เขียนเสร็จก็ยังต้องมีหลักฐาน
การซิงค์ลูกค้าเสร็จหรือยัง
ใช้การเขียนแล้ว รอการตรวจยืนยัน
ยังไม่ได้ตรวจสถานะที่ปลายทาง
กิจกรรมการซิงค์
- รับคำขอแล้ว
- ใช้การอัปเดตแล้ว
- รอตรวจปลายทาง
การทำงานตัวอย่าง · 14:32 UTC
สิ่งที่ทราบ
- คำตอบจากผู้ให้บริการ
- รับแล้ว
- ผลการเขียน
- ใช้แล้ว
- อ่านกลับจากปลายทาง
- รอดำเนินการ
การเรียกสำเร็จไม่ได้พิสูจน์สถานะสุดท้าย
เค้าโครงที่เสนออิงฟีดกิจกรรมของ Tajo ภาพนี้เพิ่มสถานะการตรวจยืนยัน แต่ไม่ได้อ้างว่าการอ่านกลับจากปลายทางมีให้ใช้งานแล้ว
ดูกรณีสมมติที่สอง: ผู้จัดการร้านอยากรู้ว่าคำสั่งซื้อทดสอบสร้างอัปเดตลูกค้าตามตั้งใจไหม ผลสั้นใกล้คำสั่งซื้ออาจแสดงระเบียนปลายทางและสถานะ คอนโซลการเชื่อมต่อแยกอาจแสดงกฎแมปและประวัติข้อผิดพลาด คู่มือเชื่อมต่อ Brevo Shopify แนะนำตรวจรายชื่อและคำสั่งซื้อทดสอบที่ปลายทางก่อนใช้ข้อมูลซิงค์ อินเทอร์เฟซควรช่วยคนทำการตรวจนั้น ไม่ใช่แค่ประกาศว่าส่งคำขอแล้ว
ความต่างนี้กันกับดักคุ้นเคย เครื่องมืออาจเปิดง่ายแต่เชื่อยาก การแสดงเงื่อนไขปลายทางที่คนทำงานอาจมีค่ากว่าการลดคลิกจากแดชบอร์ด แต่หากแอปเดิมแสดงบริบทไม่พอ การยัดการตัดสินทั้งหมดในแจ้งเตือนเล็กอาจทำให้งานแย่
ทดสอบทางเดิน ไม่ใช่ความชอบ
วางการออกแบบทั้งสองต่อหน้าคนทำงาน: คำแนะนำในหน้าและหน้าเฉพาะ ให้กรณีเดียวกัน สังเกตว่าพวกเขาหาระเบียน เข้าใจการกระทำที่เสนอ มองเห็นข้อเสนอผิด และยืนยันผลได้ไหม นับการส่งต่อและสมมติฐานผิด ไม่ใช่แค่วินาที
แยกอำนาจจากความสะดวก ปุ่มข้างระเบียนยังต้องเคารพสิทธิ์ผู้เรียกและกฎอนุมัติของเวิร์กโฟลว์ บทความเรื่องให้ผู้เชี่ยวชาญงานออกแบบระบบอัตโนมัติ อธิบายว่าทำไมคนรู้ข้อยกเว้นควรนิยามมัน ขณะที่ระบบบังคับสิทธิ์และข้อกำหนดของข้อมูล
มีเหตุผลให้เพิ่มหน้าจอ: การวินิจฉัยข้ามระบบ การตั้งค่า การตรวจจำนวนมาก และการตรวจสอบอาจเกินสิ่งที่ CRM หรือหน้าผู้ดูแลร้านแสดง คำถามคือหน้าจอนั้นช่วยจบงานที่มันขอให้คนออกจากงานเดิมไปทำหรือไม่
เมื่อทดสอบการออกแบบ ให้รวมคนจัดการข้อยกเว้น ไม่ใช่แค่คนผ่านทางปกติ การกระทำในหน้าแบบกะทัดรัดอาจเหมาะกับระเบียนทั่วไป แต่ทิ้งเจ้าของข้อยกเว้นโดยไม่มีประวัติพอให้ตัดสิน อินเทอร์เฟซควรทำให้การส่งต่อเห็นได้พร้อมกับทำทางปกติให้สั้น
อินเทอร์เฟซคุ้มที่อยู่เมื่อรองรับการตัดสินหรือหลักฐานที่จำเป็น หากงานจบและตรวจได้ตรงที่เริ่ม อีกหน้าจอคือทางอ้อม
คำถามที่พบบ่อย
ทุกระบบอัตโนมัติต้องมีแดชบอร์ดเองไหม?
ไม่ ก่อนอื่นถามว่าผู้ใช้เห็นปัญหาและตัดสินที่ไหน ระเบียนเดิม การแจ้งเตือน หรือคิวทบทวนอาจเป็นจุดตรงกว่าในการแสดงผล
เมื่อใดอินเทอร์เฟซแยกมีประโยชน์?
ใช้เมื่อคนต้องสืบค้นข้ามระบบ ตั้งค่า กำกับ หรือดูประวัติที่เครื่องมือเดิมแสดงไม่ชัด วัดขั้นใหม่ที่มันเพิ่ม
แสดงผลในเครื่องมืออื่นแล้วไม่ต้องควบคุมหรือ?
ยังต้อง สิทธิ์ การทบทวน การตรวจสอบ และการจัดการความล้มเหลวต้องออกแบบชัด ตำแหน่งปุ่มไม่ได้มอบอำนาจเปลี่ยนระเบียน