Design Engineer ทำไมถึงเป็นตำแหน่งที่น่าจับตามอง

A sketch-style drawing depicting the challenge of design handoff. On the left, a Designer in a beret is conceptualizing the process thought bubble showing a series of rectangular screens and handing over a UI blueprint. On the right, an Engineer in a hard hat receives the blueprint but is thinking of a more complex code structure thought bubble showing two rectangles with incomplete, dashed arrows. This illustrates the communication gap between the visual representation and its technical implementation.

ในช่วงที่ UX เริ่มหางานยากขึ้น ส่วน Dev ก็โดน AI ไล่จี้มาติดๆ แต่ในวิกฤตนี้ ตำแหน่งที่กำลังเบิกบานอย่าง Design Engineer กลับน่าสนใจมากขึ้นเรื่อยๆ ครับ แล้วทำไมตำแหน่งนี้ถึงกลายเป็นจิ๊กซอว์ชิ้นสำคัญ? คุณ Raphael Salaja ที่เป็น Design Engineer ที่ Warp เค้ามาเล่าให้ฟังที่งาน MIT Startup Week ครับ

ใน UX Community ผมจะพูดกับเพื่อนๆ ว่า “คนที่ออกแบบซอฟต์แวร์ต้องเข้าใจการพัฒนาซอฟต์แวร์” เพื่อให้เราออกแบบได้สุด และในขณะเดียวกัน “นักพัฒนาที่เข้าใจการสื่อสารกับมนุษย์” ก็จะสร้างของที่ตอบโจทย์คนใช้ได้ดีที่สุดเช่นเดียวกัน

พอได้ดูวิดีโอนี้แล้วโดนใจมากครับ ผมเลยขอหยิบเอาประเด็นสำคัญมาขยายต่อเป็น 3 ข้อครับ

1. คุณภาพงานมักจะไปหายไปตอนที่ส่งต่องาน (Handoff)

แผนภาพเปรียบเทียบการส่งต่องานแบบมี Design Engineer กับไม่มี Design Engineer. ด้านซ้ายแสดงการส่งต่องานที่มี Design Engineer ที่ทำให้การสื่อสารระหว่าง Designer และ Developer ราบรื่นและเข้าใจตรงกัน โดยมีเส้นตรงจาก Designer ไปยัง Design Engineer และจาก Design Engineer ไปยัง Developer. ด้านขวาแสดงการส่งต่องานที่ไม่มี Design Engineer ที่ทำให้เกิดความซับซ้อนและความเข้าใจผิดระหว่าง Designer และ Developer โดยมีเส้นที่ยุ่งเหยิงและไม่ตรงกันระหว่าง Designer และ Developer. ข้อความใต้ภาพด้านซ้ายระบุว่า "ตรงไปตรงมา เพราะเข้าใจทั้งหน้าบ้านและหลังบ้าน" ข้อความใต้ภาพด้านขวาระบุว่า "แบ่งงานกันทำ ความซับซ้อนเพิ่มขึ้นเรื่อยๆ".

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

แต่ถ้าจะให้ Designer ใส่รายละเอียดให้ครบถ้วน ต้นทุนในการใส่รายละเอียดก็สูงมาก พอรายละเอียดไม่ครบ รอยต่อตอนส่งมอบงานจึงกลายเป็นจุดที่คุณภาพของงานถูกลดทอนลง (ในวิดีโอใช้คำว่า “Where quality goes to die”)

แต่ Design Engineer ไม่มีปัญหานี้เพราะเขาทำงานได้ทั้งฝั่ง Code และ Design สามารถสวมหมวกทั้งสองใบได้พร้อมกัน ทำให้เข้าใจมุมมองของทั้งสองฝั่งอย่างครบถ้วน ที่สำคัญคือ ต้นทุนในการ Handoff จะหายไปเลยครับ

2. เมื่อ UI ไม่สะท้อนโครงสร้างข้อมูล… ความซับซ้อนก็ตามมา️

A drawing comparing the flow of data (Data) from the backend to the user interface (UI). It's split into two parts: Top Part: Shows a simple and direct system where Data A flows to UI A and Data B flows to UI B directly. The Thai text below states "ตรงไปตรงมา เพราะเข้าใจทั้งหน้าบ้านและหลังบ้าน" (Straightforward, because both frontend and backend are understood). Bottom Part: Shows a complex and inefficient system where Data C, D, and E are passed through processing modules F and G, creating intertwined dependencies and redundant data flows with UI A and UI B. The Thai text below states "แบ่งงานกันทำ ความซับซ้อนเพิ่มขึ้นเรื่อยๆ" (Competing tasks, complexity increases continuously). This illustrates the problem of not designing the data structure together from the beginning.

เมื่อ Designer ไม่เข้าใจโครงสร้างการเก็บข้อมูล (ไม่เข้าใจ Database) หน้าจอ UI ที่ออกแบบมาจะไม่สะท้อนการเก็บข้อมูลจริง ทำให้มีโอกาสสูงมากที่ผู้ใช้จะเดาการทำงานของระบบผิด และเกิดความคาดหวังที่คลาดเคลื่อนไปจากที่ระบบเป็นจริงๆ เช่น คิดว่ากดตรงนี้น่าจะได้สิ่งนั้น หรือคาดหวังว่าพอแก้ตรงนี้แล้วมันจะไปเปลี่ยนข้อมูลอีกที่นึงด้วยเลย แต่พอทำแล้วไม่ได้เป็นตามที่หวัง ผู้ใช้ก็จะงง และเกิดความไม่พอใจได้ครับ

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

3. การใส่ “Taste” และ “Craftsmanship” ลงไปในงานจริง

A drawing showing three different UI screen designs, each with a different star rating, to teach about designing empty states. Left (1 Star): A mostly blank screen with only a header and a "+" button. The Thai text below states "ไม่ได้คิดเผื่อหน้าว่าง" (Did not think about empty state). Middle (2 Stars): A screen with a text box that says "Empty" in the middle, along with the header and "+" button. The Thai text below states "ไม่มีข้อมูลก็สื่อสารกับผู้ใช้" (Communicates with the user when there is no data). Right (3 Stars): A screen with a welcoming message that says "เริ่มใส่ข้อมูลได้ที่นี่" (Start adding data here) with an arrow pointing to the "+" button. The Thai text below states "แนะนำผู้ใช้ในทุกขั้นตอน" (Guided walkthrough in every step). This illustrates best practices for guiding the user when they encounter an empty state.

การใส่ Taste ลงไปในงานจริงก็สำคัญครับ หากส่งงานออกแบบ UX/UI ไปให้ Front-end Engineer ทั่วไปทำต่อ หลายครั้งรายละเอียดเล็กๆ น้อยๆ ก็จะหายไป ไม่ใช่ว่าเขาไม่เก่ง แต่เพราะมุมมองของเขาคือการทำให้ เหมือน และทำให้ ทำงานได้ โดยที่ไม่ได้รู้เบื้องหลังการออกแบบ (เพราะต้นทุนในการเล่าให้เข้าใจมันแพงมาก) ดังนั้นการเก็บรายละเอียดทั้งในงาน Handoff เลยเป็นเรื่องที่แพงมากเช่นเดียวกัน ตัวอย่างเช่น ถ้าไม่มีการกำหนดสเปคของ Transition มาให้ ทีมพัฒนาก็อาจจะไม่ได้ใส่ลงไปก็ได้

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

แต่สำหรับ Design Engineer เขาคือ Developer ที่มีความพิถีพิถันสูง (Craftsmanship) เขาจะเติมเต็ม Micro-interaction หรือ Transition ต่างๆ ให้สมบูรณ์แบบได้เองโดยไม่ต้องรอสเปคละเอียดยิบ เพราะเขาสามารถตัดสินใจในเรื่อง ความสวยงาม ความต่อเนื่อง ไปพร้อมกับการเขียนโค้ดได้เลยครับ

ภาพสเก็ตช์แสดงหน้าจอแอปพลิเคชันที่มีหน้าต่างแชทปรากฏอยู่ตรงกลาง. ด้านล่างของหน้าต่างแชทมีสถานะกำลังอัปโหลดรูปภาพแสดงเป็นวงกลมโหลดข้อมูลและข้อความ 'Uploading image 1 of 1...'

ลองดูตัวอย่างนึงใน app Dealdroid ครับ ตัวที่แสดงสถานะ upload ไฟล์ของตัว chat ในจุดนี้ถ้า Designer เป็นคนคิด ก็อาจจะได้ตัวแสดงสถานะที่สวยงาม แต่ก็อาจจะสร้างได้ยาก เพราะ Library ที่ Developer มี ไม่ได้มีหน้าตาแบบนั้น แต่ถ้าให้ Developer คิดเอง ก็อาจจะใช้ Library ที่มีอยู่แล้วทำให้สร้างได้ง่าย แต่ก็อาจจะแสดงผลไม่ได้อยู่ตรงกลาง หรือไม่ได้มี micro-interaction ที่ปราณีต ได้ตามที่ Library ให้มาเลย

ในทางกลับกัน Design Engineer สามารถเห็นภาพคร่าวๆ ของสิ่งที่อยากได้ก่อน แล้วเลือกใช้ Library ที่ได้ผลลัพธ์ที่ใกล้เคียงที่สุด จากนั้นก็ เริ่มปรับแต่งให้ได้ผลลัพธ์ที่สายงามและมี micro-interaction ที่ดีได้เลย ถ้าทำแล้วออกมาไม่ดี ก็สามารถกลับไปเลือก Library ตัวอื่นที่เหมาะสมกว่าได้ทันทีด้วยครับ การทำแบบนี้จะมี Agility สูงมาก เหมือนมี Developer และ Designer มานั่ง pair programming กันเลยทีเดียวครับ

สรุป

ในโลกที่ AI เริ่มสร้าง UI สวยๆ ได้ในคลิกเดียว สิ่งที่จะแยกแยะ “ผลิตภัณฑ์ที่ดี” ออกจาก “ผลิตภัณฑ์ที่พิเศษ” คือ รายละเอียดและจิตวิญญาณ ที่ใส่ลงไปครับ

UX/UI Designer คือสถาปนิกผู้วางโครงสร้างและจินตนาการความสวยงาม แต่ Design Engineer คือช่างฝีมือผู้ชำนาญ ที่นำพิมพ์เขียวนั้นมาสร้างเป็นความจริงที่จับต้องได้จริง ไม่ใช่แค่ทำให้ “เสร็จ” แต่ทำให้ “สมบูรณ์” ด้วยการใส่ Taste และ Craftsmanship ผ่านทุกบรรทัดของโค้ด เพื่อมอบประสบการณ์สุดท้ายที่ดีที่สุดให้กับผู้ใช้ครับ

คำถามที่น่าสนใจคือ เรายังต้องการ UX/UI Designer ที่ไม่เข้าใจ code หรือเรายังต้องการ Developer ที่ไม่เข้าใจการออกแบบอยู่ไหม? หรือเราควรจะพัฒนาตัวเองให้มีทักษะทั้งสองด้านอย่าง Design Engineer เพื่อตอบโจทย์ของการพัฒนาในปัจจุบัน 🤔

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

← Back to all posts

Comments