Worker Journey Research

เส้นทางการทำงานของหัวหน้าคนงานก่อสร้างไทย

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

ตัวอักษรใหญ่ คำสั่งสั้น แจ้งเตือนชัด ใช้ได้ตอนสัญญาณหลุด เน้นตัดสินใจเร็ว

1. บริบทผู้ใช้และเป้าหมายของเดโม

ผู้ใช้หลัก

หัวหน้าคนงาน / โฟร์แมน

อายุประมาณ 40-60 ปี ดูแลคนงานหลายชุด เดินตรวจไซต์ตลอดวัน ต้องจำว่าใครมา ใครหาย ใครย้ายโซน และงานไหนเสี่ยงช้า

ข้อจำกัดหน้างาน

กลางแจ้ง เสียงดัง เวลาน้อย

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

ผลลัพธ์ที่ต้องการ

รู้สถานะคนและงานทันที

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

หลักคิดสำหรับ UI: ทุกหน้าต้องตอบได้ใน 5 วินาทีว่า “วันนี้ใครอยู่ไซต์, ใครรับงานอะไร, อะไรต้องรีบแก้”

2. Daily timeline: ตั้งแต่เช็กอินเช้าถึงปิดงานรายวัน

06:30

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

07:00

คนงานเข้าไซต์ / ยืนยันตัวตน คนงานสแกน QR แตะชื่อ หรือให้โฟร์แมนเช็กแทนเมื่อโทรศัพท์ไม่มี ระบบต้องรองรับการเช็กอินเร็วทีละหลายคน พร้อมสถานะ “รอยืนยัน”, “เข้าแล้ว”, “เข้าแทนโดยหัวหน้า”

07:30

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

09:30

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

12:00

พักเที่ยง / ตรวจคนยังอยู่ไซต์ โฟร์แมนต้องรู้ว่ามีคนออกไปซื้อของ กินข้าวนอกไซต์ หรือย้ายไปช่วยอีกโซน ระบบควรแยก “ออกชั่วคราว” กับ “ออกจบวัน” เพื่อไม่ให้ปิดงานผิด

14:30

ปรับแผนรอบบ่าย เมื่องานล่าช้า โฟร์แมนย้ายคนจากงานเสร็จแล้วไปช่วยจุดเสี่ยง ระบบต้องแสดงผลกระทบก่อนยืนยัน เช่น “ย้าย 2 คนจากโซน A จะทำให้งาน A เหลือ 1 คน”

17:00

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

3. Scenario flows ที่ควรเดโม

Scenario A

คนงานเข้าไซต์ปกติและรับงานทันที

1เช็กชื่อ

แตะชื่อหรือสแกน QR เห็นชื่อเล่นและรูปใหญ่

2เลือกทีม

ระบบแนะนำทีมจากทักษะและงานค้างเมื่อวาน

3ยืนยันงาน

หัวหน้าชุดรับงานพร้อมเวลาเริ่มและพื้นที่

4ติดตาม

แดชบอร์ดเห็นว่าใครอยู่โซนไหนแบบตัวเลขใหญ่

Scenario B

คนขาดตอนเช้า ต้องจัดงานใหม่

1แจ้งขาด

ระบบขึ้นเตือน “ทีมปูนขาด 3 คน” สีแดง

2ดูผลกระทบ

งานเทพื้นเสี่ยงช้า 2 ชม. ถ้าไม่เติมคน

3โยกคน

เลือกคนที่มีทักษะใกล้เคียงจากงานที่ไม่เร่ง

4แจ้งทีม

ส่งคำสั่งสั้นถึงหัวหน้าชุดและบันทึกเหตุผล

Scenario C

คนงานออกไซต์กลางวัน

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

Scenario D

ปิดวันแล้วพบว่ายังมีคนไม่เช็กเอาต์

ระบบแสดงรายชื่อค้างออกเป็นกลุ่มใหญ่ พร้อมปุ่มโทรหรือยืนยันแทน ต้องบันทึกว่าใครเป็นคนยืนยัน เพื่อใช้ตรวจสอบภายหลัง

4. Edge cases และสิ่งที่ระบบต้องไม่ทำให้หน้างานหยุด

อินเทอร์เน็ตหลุดระหว่างเช็กอิน เก็บรายการไว้ในเครื่องพร้อมป้าย “รอซิงก์” ห้ามให้โฟร์แมนต้องเช็กใหม่ทั้งชุด
คนงานไม่มีโทรศัพท์หรือ QR หาย ให้โฟร์แมนค้นจากชื่อเล่น เลขท้ายบัตร หรือทีมเดิม และบันทึกว่าเช็กแทน
ชื่อซ้ำหรือจำชื่อจริงไม่ได้ ใช้รูปคนงาน ชื่อเล่น ทีม สีหมวก หรือหัวหน้าชุดช่วยยืนยัน ลดการอ่านข้อมูลยาว
มีคนใหม่เข้ามาแบบด่วน เพิ่มแบบชั่วคราวได้ก่อน โดยติดป้าย “ต้องกรอกเอกสาร” และไม่บล็อกการมอบหมายงาน
ย้ายคนผิดงาน ต้องมี undo ภายในช่วงสั้น และแสดงประวัติว่าเมื่อไหร่ ย้ายจากไหน ไปไหน
แดดจ้าทำให้มองสีไม่ชัด ห้ามพึ่งสีอย่างเดียว ต้องมีข้อความใหญ่ เช่น “ขาดคน”, “ครบแล้ว”, “รอซิงก์”
เสียงดัง รับสายหรือฟังแจ้งเตือนไม่ได้ ใช้ vibration, badge ตัวเลข, แถบสีเข้ม และข้อความสั้นแทนเสียง

5. Emotional และ cognitive load

อารมณ์ที่เกิดขึ้นระหว่างวัน

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

ภาระทางความคิดที่ระบบควรช่วยลด

จำคน
สูง

จำงานค้าง
สูง

ประเมินทักษะ
กลาง

แก้ปัญหาด่วน
สูง

ทำรายงาน
กลาง

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

6. Decision points สำคัญของหัวหน้าคนงาน

คนวันนี้พอสำหรับงานเร่งหรือไม่?

พอ: มอบหมายตามแผนและล็อกทีมหลัก

ไม่พอ: ดูงานที่เลื่อนเวลาได้ แล้วย้ายคนพร้อมเหตุผล

คนที่มาถึงมีทักษะตรงกับงานหรือไม่?

ตรง: ส่งเข้าทีมทันที ลดเวลาประชุม

ไม่ตรง: ระบบแนะนำงานสำรองและเตือนความเสี่ยงความปลอดภัย

งานนี้ต้องเพิ่มคนหรือแก้ปัญหาวัสดุก่อน?

เพิ่มคน: เลือกจากทีมที่งานเสร็จหรือไม่เร่ง

แก้วัสดุ: บันทึก blocker และส่งต่อผู้เกี่ยวข้อง

ปิดวันได้หรือยัง?

ได้: เช็กเอาต์ครบ สรุปงาน ส่งรายงาน

ยัง: ระบบชี้รายการค้าง เช่น คนยังไม่ออก งานไม่มีรูป หรือเหตุผลไม่ครบ

7. Service blueprint สำหรับเดโมระบบ

Blueprint นี้ช่วยให้ทีมแยกว่าอะไรคือสิ่งที่โฟร์แมนเห็น อะไรคือกระบวนการหลังบ้าน และจุดไหนควรทำเป็น demo interaction ให้ชัด

ช่วงงาน

เปิดไซต์ มอบหมายงาน ติดตามและปรับแผน ปิดงานรายวัน

Frontstage

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

Backstage

ตรวจสิทธิ์คนงาน ทีมเดิม และสถานะเอกสาร จับคู่ทักษะกับงาน ประเมินขาดคน บันทึกประวัติการย้ายคนและ blocker รวมเวลาเข้าออก งานเสร็จ งานค้าง และหลักฐาน

ระบบสนับสนุน

Offline queue และ sync status Rules: skill, zone, safety, priority Notification แบบไม่พึ่งเสียง Audit log และ export รายงาน

8. Before / After journey

ก่อนใช้ระบบ

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

เสี่ยงตกหล่น ใช้ความจำสูง

หลังใช้ระบบเดโม

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

เห็นภาพรวมเร็ว ลดการไล่ถาม

9. Task flow diagrams สำหรับออกแบบหน้าจอ

Flow 1: เช็กอินคนงานตอนเช้า

เปิดหน้า
วันนี้มีคนกี่คน

ค้น / สแกน
ชื่อใหญ่ รูปชัด

ยืนยันเข้าไซต์
ปุ่มใหญ่

เลือกทีมงาน
หรือค้างมอบหมาย

สถานะรวม
เข้าแล้ว / ขาด / รอซิงก์

Flow 2: มอบหมายงานและโยกคน

เลือกงานเร่ง
เช่น เทพื้น

ดูจำนวนที่ต้องใช้
เทียบคนที่มี

เลือกคนตามทักษะ
และทีมปัจจุบัน

ยืนยันผลกระทบ
ก่อนโยก

ส่งแจ้งเตือน
พร้อมบันทึก log

Flow 3: ปิดวัน

ดูรายการค้าง
คน / งาน / รูป

ยืนยันคนออกไซต์
หรือโทรติดตาม

สรุปงานเสร็จ
งานค้าง

แนบปัญหา
ส่งต่อพรุ่งนี้

กดปิดวัน
สร้างรายงาน

10. Validation test plan สำหรับทีมเดโม

หัวข้อทดสอบ	สถานการณ์	วิธีทดสอบ	เกณฑ์ผ่าน
อ่านกลางแดด	โฟร์แมนยืนกลางแจ้ง มองจอเร็ว	ให้หาตัวเลขคนเข้าไซต์ คนขาด และงานเสี่ยงช้า	ตอบถูกภายใน 5 วินาที โดยไม่ต้องเพ่ง
แตะด้วยถุงมือ	นิ้วใหญ่หรือใส่ถุงมือบาง	ให้เช็กอิน 10 คนและย้ายคน 2 คน	แตะผิดไม่เกิน 1 ครั้ง และมี undo เมื่อผิด
เสียงดัง	ไม่ได้ยินเสียงแจ้งเตือน	ปิดเสียง แล้วส่งเหตุการณ์คนขาดหรือขอคนเพิ่ม	ผู้ใช้สังเกตเห็นจาก badge, vibration หรือแถบเตือน
สัญญาณหลุด	เช็กอินระหว่างเน็ตอ่อน	จำลอง offline แล้วเช็กอิน 5 คน จากนั้นกลับ online	ข้อมูลไม่หาย มีสถานะรอซิงก์ และซิงก์สำเร็จ
ตัดสินใจโยกคน	ทีมหนึ่งขาดคน อีกทีมยังไม่เสร็จ	ให้เลือกว่าจะย้ายคนหรือเลื่อนงาน	ผู้ใช้เข้าใจผลกระทบก่อนยืนยัน
ปิดวัน	มีคนไม่เช็กเอาต์และงานไม่มีรูป	ให้ปิดวันจากรายการค้าง	ระบบไม่ปล่อยให้ปิดแบบข้อมูลไม่ครบโดยไม่เตือน

Measure

เวลาทำงานหลัก

เช็กอิน 10 คนควรใช้ไม่เกิน 90 วินาที และมอบหมายงาน 1 ทีมไม่เกิน 2 นาที

Observe

จุดที่ผู้ใช้ลังเล

จดว่าผู้ใช้ถามคำว่า “ต้องกดอะไรต่อ” ตรงไหน เพราะเป็นสัญญาณว่า flow ยังไม่ชัด

Debrief

คำถามหลังทดสอบ

ถามว่า “ถ้าใช้งานจริง พี่กลัวพลาดตรงไหนที่สุด” เพื่อหา risk ที่เดโมควรตอบ

11. ข้อเสนอสำหรับ scope เดโมรอบแรก

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

Demo narrative ที่แนะนำ: “เช้าวันนี้ทีมปูนขาด 3 คน แต่ต้องเทพื้นให้ทันบ่าย โฟร์แมนใช้ระบบเห็นปัญหา โยกคน แจ้งทีม ติดตามรอบบ่าย และปิดวันโดยไม่ตกหล่น”