เลือกจากความหมาย ไม่ใช่เลือกจากรูปทรง
รูปทรงมีไว้ช่วยให้คนอ่านแยกบทบาทของ Node ได้เร็ว แต่ข้อความใน Node ยังเป็นตัวอธิบายหลัก ถ้าใช้รูปเพชรกับกิจกรรมธรรมดา คนอ่านจะมองหาหลายคำตอบทั้งที่ไม่มี ดังนั้นให้ถามก่อนว่า Node นี้เริ่มงาน ทำงาน ถามเงื่อนไข หรือจบงาน
เมื่อทีมตกลงชุดสัญลักษณ์แล้วควรใช้ความหมายเดียวกันทั้ง Flow และมี Legend เมื่อใช้ชนิดเฉพาะทาง การผสมมาตรฐานหลายชุดโดยไม่อธิบายทำให้รูปมากขึ้นแต่ข้อมูลไม่ได้ชัดขึ้น
ชุดสัญลักษณ์จำเป็นสำหรับ Flow ส่วนใหญ่
ชุดเล็กด้านล่างครอบคลุมงานอนุมัติ คู่มือ และ Troubleshooting ส่วนใหญ่ได้ ก่อนเพิ่มชนิดใหม่ควรตรวจว่าความหมายต่างจากชุดนี้จริงหรือไม่
| บทบาท | ความหมาย | แนวทางเขียน |
|---|---|---|
| Start | เหตุการณ์ที่ทำให้ Flow เริ่ม | ได้รับคำขอ |
| Process | กิจกรรมที่เปลี่ยนสถานะงาน | ตรวจหลักฐาน |
| Decision | คำถามที่มีหลายผลลัพธ์ | หลักฐานครบหรือไม่ |
| End | ผลลัพธ์หรือการส่งมอบ | ส่งผลอนุมัติแล้ว |
| Connector | ลำดับหรือคำตอบ | ครบ / ต้องแก้ |
เมื่อไรจึงควรใช้สัญลักษณ์เฉพาะ
Document เหมาะเมื่อการสร้างหรือรับเอกสารเป็นผลสำคัญ ไม่ใช่เพียงมีเอกสารประกอบ Data Store เหมาะกับ System Flow ที่ต้องสื่อการอ่านหรือเขียนข้อมูล แต่ไม่ควรใช้แทนทุกตารางฐานข้อมูล
สำหรับคู่มือ Interactive อาจใช้ Warning, Screenshot, Link และ Note เพื่อบอกวิธีนำเสนอเนื้อหา ชนิดเหล่านี้ไม่จำเป็นต้องแทนมาตรฐาน Process Diagram ทุกครั้ง เพราะเป้าหมายคือช่วยผู้อ่านทำตามอย่างปลอดภัย
- ใช้ Warning เมื่อมีความเสี่ยงหรือข้อควรหยุดอ่าน
- ใช้ Screenshot เมื่อการระบุตำแหน่งด้วยข้อความไม่พอ
- ใช้ Link เมื่อขั้นตอนคือการไปยังแหล่งข้อมูล ไม่ใช่การฝังเนื้อหาทั้งหมด
กติกาความสม่ำเสมอที่สำคัญกว่าจำนวนสัญลักษณ์
กำหนดทิศทางหลักหนึ่งแบบ วางข้อความบนลูกศรทุกเส้นที่ออกจาก Decision และหลีกเลี่ยงเส้นตัดกัน ถ้าพื้นที่เริ่มแน่น ให้แยก Subflow หรือคู่มือย่อยแทนการลดตัวอักษรจนอ่านไม่ได้
สุดท้ายให้คนที่ไม่ได้วาด Flow ลองอ่าน ถ้าเขาอธิบาย Trigger, ผลลัพธ์ และกรณียกเว้นได้ตรงกัน แสดงว่าสัญลักษณ์ทำหน้าที่สื่อความหมายแล้ว