ทำไอเดียให้เห็น ทดสอบ และประเมินได้ ก่อนเริ่มพัฒนา
งานออกแบบชิ้นแรกที่เราส่งมอบ ไม่ได้เป็นชุดภาพหน้าจอนิ่ง ๆ อีกต่อไป แต่เป็นต้นแบบ (prototype) ที่คลิกใช้งานได้จริง
ฟังดูเหมือนเป็นการเปลี่ยนแปลงเล็ก ๆ แต่ในทางปฏิบัติ มันช่วยย้ายเรื่องที่คุยกันยากที่สุดในโปรเจกต์ซอฟต์แวร์ เช่น จะเกิดอะไรขึ้นเมื่อยังไม่มีข้อมูล เมื่อระบบทำงานผิดพลาด หรือเมื่อผู้ใช้สองบทบาทต้องมีสิทธิ์ต่างกัน จากเดือนที่สาม มาอยู่ในสัปดาห์แรก
หลายปีที่ผ่านมา ลูกค้าต้องดู wireframe แล้วจินตนาการส่วนที่เหลือเอาเอง หน้าจอหนึ่งอาจดูชัดเจนในงานพรีเซนต์ แต่ยังซ่อนคำถามสำคัญเอาไว้ คำถามเหล่านั้นมักโผล่ขึ้นมาหลังจากเริ่มพัฒนาไปแล้ว ซึ่งเป็นช่วงที่การแก้ไขมีค่าใช้จ่ายสูง
ที่ Manao Software เราใช้เครื่องมือที่มี AI ช่วย เพื่อเปลี่ยนความต้องการ (requirements) ทางธุรกิจ และไอเดียตั้งต้น ให้กลายเป็นต้นแบบที่สร้างด้วยโค้ด ซึ่งลูกค้าและทีมพัฒนาของเราสามารถลองใช้ได้ตั้งแต่วันแรก ๆ ของโปรเจกต์
AI-first ไม่ได้แปลว่า AI เป็นผู้ตัดสินใจเรื่องการออกแบบ แต่หมายถึงเราใช้ AI ตั้งแต่ช่วงต้น เพื่อสำรวจทางเลือกต่าง ๆ ทำให้สมมติฐานของเรามองเห็นได้ และสร้างสิ่งที่จับต้องได้ให้ทุกคนตั้งคำถามและโต้แย้งได้
และ AI ก็ไม่ได้มาแทนการทำวิจัย ถ้าโปรเจกต์ไหนต้องมีการสัมภาษณ์ ลงพื้นที่ หรือทดสอบการใช้งานกับผู้ใช้จริง ขั้นตอนเหล่านั้นก็ยังอยู่ในกระบวนการเหมือนเดิม
AI ช่วยให้เราเปลี่ยนไอเดียที่ยังไม่ชัด ให้กลายเป็นสิ่งที่ทดสอบได้เร็วขึ้น แต่การตัดสินว่าทางออกนั้นถูกต้องหรือไม่ ยังเป็นหน้าที่ของคน
“ถ้าทำได้เร็วขนาดนั้น จะมีเวลาคิดรายละเอียดพอไหม?”
คือคำถามแรกที่เรามักได้ยิน และเป็นคำถามที่สมเหตุสมผล
คำตอบตรง ๆ คือ AI ช่วยลดเวลาในการผลิตงาน ไม่ได้ลดเวลาในการคิด เมื่อก่อนส่วนที่ช้าคือการวาดหน้าจอ ตอนนี้ส่วนที่ช้าคือการตั้งโจทย์ให้ถูก ถ้าโจทย์คลุมเครือ AI จะสร้างคำตอบที่ดูเนี้ยบ แต่ตอบผิดโจทย์ได้ภายในเวลาประมาณสี่นาที และมันดูน่าเชื่อถือพอที่จะไม่มีใครสังเกตเห็นตอนรีวิว
ดังนั้นการคิดไม่ได้ลดลง แต่ย้ายมาอยู่ช่วงต้นมากขึ้น และมีน้ำหนักมากขึ้น เพราะสมมติฐานที่ผิด ตอนนี้แพร่กระจายได้เร็วกว่าเดิมมาก
กระบวนการแบบเส้นตรงมีปัญหาตรงไหน
กระบวนการ UX/UI แบบเดิมเดินไปทางเดียว คือ วิจัย wireframe ออกแบบละเอียด (high-fidelity) ทำต้นแบบ ส่งต่อ พัฒนา
แต่ละขั้นตอนแสดงให้เห็นผลิตภัณฑ์เพียงบางส่วน wireframe แสดงโครงสร้าง หน้าจอแบบละเอียดแสดงทิศทางด้านภาพ ส่วนต้นแบบก็เชื่อมเฉพาะบางหน้าจอเข้าด้วยกัน ลูกค้าต้องจินตนาการส่วนที่เหลือเอง และผู้เกี่ยวข้องอาจอนุมัติหน้าจอนิ่ง ๆ ไปโดยที่ยังไม่เข้าใจว่ามันจะทำงานอย่างไร
การเปลี่ยนแปลงก็มีต้นทุนสูงเช่นกัน เมื่อความต้องการเปลี่ยน นักออกแบบต้องแก้หน้าจอ สถานะต่าง ๆ และลิงก์ในต้นแบบด้วยมือ ในไฟล์ขนาดใหญ่ เป็นเรื่องง่ายที่จะลืมแก้บางจุด ทิ้งเวอร์ชันเก่าไว้ หรือทำให้ flow สองอันที่เกี่ยวข้องกันเริ่มไม่ตรงกัน
เราทำงานเป็นรอบ ไม่ใช่เส้นตรง
กระบวนการของเราเป็นรอบที่ทำซ้ำ 6 ขั้นตอน ลำดับขั้นตอนคงที่ แต่ความลึกขึ้นอยู่กับแต่ละโปรเจกต์
กระบวนการของเราคือวงรอบต่อเนื่องของการเสนอ รีวิว และปรับปรุง ไม่ใช่การส่งต่องานไปทางเดียว
1. ตั้งโจทย์ให้ชัด
ก่อนจะสร้างอะไรขึ้นมา เราต้องชัดเจนก่อนว่า:
- ผู้ใช้คือใคร และเขาต้องการทำอะไรให้สำเร็จ
- ผู้ใช้มีข้อมูลอะไรอยู่แล้วบ้าง
- มีกฎทางธุรกิจอะไรที่เกี่ยวข้อง
- มีข้อจำกัดทางเทคนิคอะไรที่เรารู้อยู่แล้ว
- ควรเกิดอะไรขึ้นเมื่อขั้นตอนสำเร็จ หรือล้มเหลว
ถ้าลูกค้ายังไม่แน่ใจเรื่อง flow เราจะไม่รอ เราจะสร้างสมมติฐานอย่างเป็นระบบจากความต้องการ บริบททางธุรกิจ และความต้องการของผู้ใช้ที่มีอยู่ แล้วเปลี่ยนเป็นข้อเสนอในรูปแบบต้นแบบที่คลิกได้
เป้าหมายไม่ใช่การทำเป็นว่าเรารู้คำตอบทุกข้อแล้ว แต่เพื่อให้ทุกคนเห็นความคิดของเรา ลูกค้าและทีมภายในจะได้ช่วยแก้ไขให้ถูกต้อง
2. สร้างต้นแบบที่ใช้งานได้จริง
เราสร้างต้นแบบระดับกลาง (mid-fidelity) ที่คลิกใช้งานได้จริง ไม่ใช่แค่กล่องสี่เหลี่ยมนิ่ง ๆ โดยต้นแบบจะแสดง:
- การนำทางและการโต้ตอบจริง
- สถานะตอนไม่มีข้อมูล ตอนกำลังโหลด และตอนเกิดข้อผิดพลาด
- การแจ้งเตือนเมื่อกรอกข้อมูลผิด และหน้ายืนยันการทำรายการ
- การจำลองบทบาทและสิทธิ์ของผู้ใช้
- เส้นทางทางเลือก และกรณีพิเศษต่าง ๆ
ในโปรเจกต์ที่มีขั้นตอนการทำงานซับซ้อน เราสามารถสร้างทิศทางที่ทดสอบได้ภายในไม่กี่วันแรก มันยังไม่ใช่งานออกแบบที่เสร็จสมบูรณ์ แต่เป็นสิ่งที่มีสาระพอให้ถกเถียงกันได้
3. วิจารณ์งานตัวเองก่อนนำเสนอ
ความเร็วไม่ได้รับประกันคุณภาพ ก่อนที่งานจะถึงมือลูกค้า นักออกแบบจะถามตัวเองว่า:
- ลำดับความสำคัญของข้อมูลบนหน้าจอชัดเจนไหม
- flow นี้สมเหตุสมผลสำหรับผู้ใช้ไหม
- แสดงข้อมูลมากเกินไปในครั้งเดียวหรือเปล่า
- ภาษาที่ใช้เข้าใจง่ายไหม
- ปุ่มหรือการกระทำที่สำคัญมองเห็นชัดไหม
- ครอบคลุมกรณีพิเศษหลัก ๆ แล้วหรือยัง
- สิ่งนี้แก้ปัญหาทางธุรกิจได้จริงไหม
ขั้นตอนนี้คือจุดที่วิจารณญาณด้านการออกแบบทำหน้าที่เป็นด่านตรวจคุณภาพ AI เสนอรูปแบบที่คุ้นเคยได้ แต่ไม่เข้าใจองค์กรของลูกค้า แรงกดดันที่เขาเจอ ผู้ใช้ของเขา หรือเป้าหมายระยะยาว หน้าที่ของเราคือตั้งคำถามกับผลลัพธ์แรก ปรับปรุงให้ดีขึ้น และบางครั้งก็ต้องปฏิเสธสิ่งที่ดูเหมือนเสร็จแล้ว
4. ปรับปรุงโดยอิงจากเอกสารทางธุรกิจจริง
เราไม่ได้สร้างตัวเลือกสวย ๆ หลายแบบแล้วให้ลูกค้าเลือกเอาสักแบบ แต่เราปรับปรุงต้นแบบทีละรอบ โดยอิงจากสิ่งที่ลูกค้าใช้อยู่จริง เช่น แบบฟอร์ม รายงาน สเปรดชีต เอกสารขั้นตอนการทำงาน กฎการอนุมัติ ภาพหน้าจอของระบบปัจจุบัน และตัวอย่างข้อมูลเข้าและข้อมูลออกจริง
นี่คือสิ่งที่ทำให้ผลิตภัณฑ์ไม่กลายเป็นแดชบอร์ดทั่ว ๆ ไปอีกอันหนึ่ง
ในโปรเจกต์ล่าสุด ซึ่งเป็นระบบใบอนุญาตทำงาน (permit-to-work) ให้ลูกค้าในภาคอุตสาหกรรม เราเริ่มจากกองเอกสารขั้นตอนการทำงาน และรายการความต้องการที่ยังไม่ครบ โดยยังไม่มีเส้นทางการใช้งานของผู้ใช้ (user journey) ที่สมบูรณ์ เราเปลี่ยนสิ่งเหล่านั้นให้เป็น flow ที่ใช้งานได้จริง ครอบคลุม 27 หน้าจอ และ 6 บทบาทผู้ใช้ ซึ่งนักวิเคราะห์ธุรกิจ นักออกแบบ และนักพัฒนา สามารถรีวิวร่วมกันได้
เมื่อทุกคนมองเห็นกระบวนการได้ชัด ทีมก็พบตรรกะที่ขาดหายไป ความไม่ชัดเจนว่าใครเป็นผู้อนุมัติ และกรณีพิเศษที่ยังไม่ได้จัดการ ทั้งหมดนี้ก่อนเริ่มพัฒนา ต้นแบบจึงไม่ได้เป็นแค่งานออกแบบอีกต่อไป แต่กลายเป็นเครื่องมือร่วมกันในการทำความเข้าใจธุรกิจ
5. คอมเมนต์ลงบนต้นแบบโดยตรง
การรีวิวเกิดขึ้นบนตัวต้นแบบเลย แบบเดียวกับที่ลูกค้าคุ้นเคยกับการคอมเมนต์ใน Figma คือแปะโน้ตลงบนหน้าจอ ชิ้นส่วน หรือการโต้ตอบที่ต้องการพูดถึงโดยตรง
6. เตรียมพร้อมสำหรับการพัฒนา
ต้นแบบที่ใช้งานได้ ยังไม่ใช่โค้ดส่วนหน้า (front-end) ที่พร้อมใช้งานจริง ยังต้องให้ทีมวิศวกรรมตรวจสอบเรื่องความเป็นไปได้ ความปลอดภัย การเข้าถึงสำหรับทุกคน (accessibility) ประสิทธิภาพ การรองรับการขยายตัว และการดูแลรักษาในระยะยาว
แต่มันให้ข้อมูลกับนักพัฒนามากกว่าหน้าจอนิ่ง ๆ อย่างมาก นักพัฒนาเห็นว่าระบบควรทำงานอย่างไร ทดสอบการเชื่อมต่อระหว่างขั้นตอนได้ มองเห็นรูปแบบที่นำกลับมาใช้ซ้ำได้ และพบสถานะที่ขาดหายไปได้เร็วขึ้น
บางส่วนของต้นแบบอาจใช้เป็นจุดเริ่มต้นของการพัฒนาจริงได้ ขึ้นอยู่กับเทคโนโลยีที่ใช้ โดยทีมวิศวกรรมเป็นผู้ตัดสินใจว่าส่วนไหนนำกลับมาใช้ ส่วนไหนต้องเสริมให้แข็งแรงขึ้น หรือส่วนไหนต้องสร้างใหม่
ระบบการออกแบบ (Design System) เริ่มต้นในโค้ด
ตอนนี้เราพัฒนาชิ้นส่วนพื้นฐาน (components) ตั้งแต่ช่วงออกแบบ เช่น ปุ่ม ช่องกรอกข้อมูล ตาราง การ์ด รูปแบบเมนูนำทาง และสถานะต่าง ๆ ของหน้าจอ ทั้งหมดถูกสร้างเป็นชิ้นส่วนที่ทำงานได้จริง ระหว่างที่ยังสำรวจประสบการณ์การใช้งานอยู่ แทนที่จะอยู่แค่ในไฟล์ออกแบบแยกต่างหาก
วิธีนี้ทำให้เราทดสอบการแสดงผลบนหน้าจอขนาดต่าง ๆ ระยะห่าง สถานะ และการโต้ตอบได้เร็วขึ้น และทำให้นักออกแบบกับนักพัฒนาพูดภาษาเดียวกันเรื่องชิ้นส่วนต่าง ๆ ก่อนเริ่มพัฒนา
มันยังเปลี่ยนต้นทุนของการปรับแก้ด้วย ในกระบวนการที่อิงหน้าจอ ความต้องการที่เปลี่ยนไปหนึ่งข้อ หมายถึงต้องแก้หลายหน้าจอ หลายสถานะ และหลายลิงก์ในต้นแบบ แม้แต่ไฟล์ Figma ที่ดูแลอย่างดี ก็ยังสะสมการแก้ไขเฉพาะจุด ชิ้นส่วนที่ถูกแยกออกจากต้นฉบับ และหน้าจอที่ถูกลืมไว้ แต่เมื่อใช้ชิ้นส่วนโค้ดร่วมกัน การเปลี่ยนปุ่ม ช่องกรอกข้อมูล รูปแบบตาราง สถานะการตรวจสอบข้อมูล หรือการทำงานของเมนูนำทาง จะมีผลกับทุกจุดพร้อมกันในครั้งเดียว
แต่ก็ยังต้องมีคนรีวิวอยู่ดี เพราะการแก้ไขอย่างเป็นระบบอาจถูกต้องในทางเทคนิค แต่ผิดในบางบริบท ความแตกต่างคือ นักออกแบบใช้เวลาน้อยลงกับการตรวจว่าแก้ครบทุกหน้าจอหรือยัง และใช้เวลามากขึ้นกับการพิจารณาว่าทางออกที่ปรับแล้วใช้ได้จริงหรือไม่
ระบบการออกแบบที่สมบูรณ์ต้องมีมากกว่าโค้ด ต้องมีหลักการ มาตรฐานการเข้าถึง เอกสารประกอบ การกำกับดูแล และผู้รับผิดชอบที่ชัดเจน ชิ้นส่วนในต้นแบบเป็นเพียงจุดเริ่มต้นของคลังชิ้นส่วนสำหรับใช้งานจริง ไม่ได้มาแทนที่มัน
Figma ยังมีบทบาทสำคัญ
AI-first ไม่ได้แปลว่าเลิกใช้ Figma
Figma ยังเป็นเครื่องมือที่เหมาะสำหรับ:
- การจัดองค์ประกอบภาพอย่างละเอียด
- การสื่อสารแบรนด์และการกำหนดทิศทางงานศิลป์
- หน้าเว็บการตลาดที่เน้นตัวอักษรเป็นหลัก
- การวางแผนการเคลื่อนไหว (motion) ที่ซับซ้อน
- การทดลองด้านภาพบนพื้นที่ทำงานที่ยืดหยุ่น
- เอกสารการออกแบบสำหรับทีมที่ลูกค้าดูแลเอง
ต้นแบบที่สร้างด้วยโค้ดจะเหมาะกว่า เมื่อโจทย์คือขั้นตอนการทำงาน ตรรกะทางธุรกิจ การโต้ตอบ และการทำความเข้าใจเรื่องเทคนิคตั้งแต่ช่วงต้น ส่วน Figma จะเหมาะกว่า เมื่อสิ่งที่ต้องส่งมอบคือการควบคุมภาพอย่างแม่นยำ เราเลือกเครื่องมือตามโจทย์
ต้นแบบที่ดีขึ้น ทำให้ประเมินงานได้แม่นขึ้น
ข้อเสนอโครงการ (proposal) อธิบายผลิตภัณฑ์ผ่านตัวหนังสือ รายการฟีเจอร์ และสมมติฐาน แต่ถึงเอกสารจะละเอียดแค่ไหน แต่ละคนก็อ่านแล้วเข้าใจไม่เหมือนกัน ลูกค้านึกภาพไว้แบบหนึ่ง ขณะที่คนในทีมพัฒนาอาจนึกภาพไว้อีกแบบ
ช่องว่างนี้จะเห็นก็ต่อเมื่อโปรเจกต์เริ่มไปแล้ว ในรูปของขั้นตอนการทำงานที่เพิ่มขึ้น สถานะที่ขาดหายไป บทบาทผู้ใช้ที่ไม่ได้วางแผนไว้ หรือความซับซ้อนทางเทคนิคที่มากกว่าที่คาด ซึ่งทำให้ขอบเขตงานบานปลาย เลื่อนกำหนดเวลา และทำให้ลูกค้าต้องจ่ายเงินเพิ่ม
ต้นแบบที่ใช้งานได้จริงช่วยปิดช่องว่างนี้ก่อนจะเซ็นใบประเมินราคา ทีมพัฒนาของเราสามารถระบุสิ่งที่ต้องพึ่งพากัน กฎที่ซับซ้อน สถานะที่ขาดหายไป และความเสี่ยงในการส่งมอบ ในช่วงที่ยังมีเวลาคำนวณราคา และชิ้นส่วนที่นำกลับมาใช้ซ้ำได้ ก็ช่วยให้เห็นว่างานส่วนหน้าจริง ๆ มีหน้าตาเป็นอย่างไร
ไม่มีการประเมินช่วงแรกไหนที่จะขจัดความไม่แน่นอนทั้งหมดในโปรเจกต์ซอฟต์แวร์ที่ซับซ้อนได้ แต่ต้นแบบที่ทุกคนเห็นร่วมกันช่วยลดส่วนเผื่อที่เราต้องบวกไว้สำหรับความต้องการที่ยังไม่ชัด และลดความเสี่ยงที่ขอบเขตงานจะขยายเพราะสมมติฐานที่ไม่มีใครตรวจสอบตั้งแต่ต้น
เป้าหมายไม่ใช่การสัญญาว่าโปรเจกต์ซอฟต์แวร์จะไม่มีการเปลี่ยนแปลงเลย แต่คือการทำให้การตัดสินใจสำคัญ ๆ มองเห็นได้มากขึ้น ก่อนที่ลูกค้าจะตัดสินใจลงทุนเต็มจำนวน
งานยากยังอยู่ แค่ย้ายไปอยู่จุดใหม่
AI ไม่ได้ทำให้ส่วนที่ยากของการออกแบบผลิตภัณฑ์หายไป แต่มันย้ายส่วนที่ยากไปอยู่ที่อื่น
เวลาในการผลิตงานไม่ใช่ข้อจำกัดหลักอีกต่อไป ข้อจำกัดในตอนนี้คือ:
- การตั้งโจทย์ให้ถูก
- การได้ข้อมูลทางธุรกิจและข้อมูลผู้ใช้ที่ถูกต้อง
- การตั้งคำถามกับผลงานที่ดูสวยแต่ไม่มีความลึก
- การรักษาวินัยในการใช้ชิ้นส่วนและระบบการออกแบบ
- การดึงคนที่ใช่เข้ามามีส่วนร่วมตั้งแต่ช่วงต้น
- การใช้วิจารณญาณของมนุษย์
สิ่งที่เราได้มานั้นเป็นของจริง ทั้งการมีสิ่งที่จับต้องได้ให้ลูกค้าและทีมพัฒนาดูตั้งแต่สัปดาห์แรก การเปลี่ยนความต้องการที่ยังไม่ครบ ให้เป็นประสบการณ์ที่ทุกคนตั้งคำถามได้ การคิดเรื่องระบบการออกแบบตั้งแต่ช่วงออกแบบ แทนที่จะรอหลังส่งต่องาน และการประเมินงานที่อิงหลักฐาน แทนการตีความ
สิ่งที่ไม่เปลี่ยนคือ ใครเป็นผู้ตัดสินใจ AI ช่วยให้ทำงานเร็วขึ้น และทำให้การปรับแก้เป็นระบบมากขึ้น แต่นักออกแบบ ลูกค้า และทีมพัฒนา ยังคงเป็นผู้ตัดสินว่าทางออกนั้นชัดเจน รับผิดชอบ มีคุณค่า และคุ้มค่าที่จะสร้างหรือไม่
มาคุยกันว่าการพัฒนาซอฟต์แวร์ที่มี AI ช่วย จะเร่งโปรเจกต์ถัดไปของคุณได้อย่างไร ติดต่อ Manao Software
