ถ้าเราคิดถึงโลกแห่งการสร้าง software เรามักจะนึกถึงคนสองคนที่ต้องทำงานร่วมกันก็คือ Designer และ Developer โดยคนแรกจะออกแบบ และส่งต่อให้คนที่สองไปเขียนโค้ด
แต่บางครั้ง ทีมอาจจะต้องการ “ลูกผสม” ที่เอาบางทักษะของทั้งสองตำแหน่งนั้นมารวมกัน จึงเกิดเป็นตำแหน่งที่ค่อนข้างใหม่ที่เรียกว่า Design Technologist (DT) หรือ UX Engineer (UXE) ที่ช่วยผสานระหว่างงานดีไซน์และงานโค้ด
Design Technologist คือ ดีไซน์เนอร์ที่เขียนโค้ดได้
ความพิเศษของ designer ประเภทนี้ คือ สามารถออกแบบและเขียนโค้ดได้ในตัวเอง ซึ่งการเขียนโค้ดในที่นี้ไม่จำเป็นต้องทำได้เท่า developer (ไม่สามารถนำไปใช้ต่อได้จริงบน production) แต่ก็มากพอที่จะทำให้เกิดประโยชน์กับทีมได้ในแต่ละ phase ของการสร้าง software โดยหน้าที่หลักจะมีอยู่สามข้อ
- ก่อนสร้าง - ทำ prototype ที่สมจริง เพื่อพิสูจน์ไอเดียและเทคโนโลยี
- ขณะสร้าง - ทำ design system และ component ต่างๆ เพื่อเชื่อมระหว่าง designer และ developer
- เมื่อมีโอกาส - ทำ tool ที่ทำให้งานของ designer ง่ายขึ้น
…
1. ก่อนสร้าง - ทำ prototype ที่สมจริง เพื่อพิสูจน์ไอเดีย และข้อจำกัดทางเทคโนโลยี
ถึงแม้ designer ส่วนใหญ่จะสามารถทำ prototype ได้ด้วย design tool ที่เราใช้ (เช่น Figma หรือ Invision) แอปเหล่านี้มักจะมีข้อจำกัดที่ไม่สามารถทำ prototype ที่สมจริงได้
ยกตัวอย่างการพิสูจน์ไอเดีย: ฟีเจอร์คำนวณเงินลดหย่อนภาษี
ทีมเราอยากจะทดสอบไอเดียฟีเจอร์ที่คำนวณเงินลดหย่อนภาษีให้กับผู้ใช้ โดยเราจะให้ผู้ใช้พิมพ์รายได้ตัวเองเข้ามา จากนั้นระบบจะบอกให้ว่าควรจะลดหย่อนภาษีกี่บาท
จะเห็นว่า Prototype จะต้อง (1) มี interaction การพิมพ์ (2) มี logic การคำนวณเพื่อแสดงผล
สำหรับแอป Figma เราก็ก็จะทำคีย์บอร์ดปลอมเด้งขึ้นมา และเมื่อ user แตะที่หน้าจอ เราก็จะโชว์หน้าถัดไปที่มีการพิมพ์ไว้ให้เสร็จแล้ว ซึ่งหมายความว่า user ไม่ได้พิมพ์จริง และข้อมูลที่แสดงตอนท้ายก็จะอาจจะไม่ใช่สิ่งที่ user อยากรู้จริง ซึ่งอาจจะทำให้เราไม่ได้ insight ที่เราอยากได้จากการทดสอบ
ในกรณีนี้ DT อาจจะโค้ด prototype ด้วย เว็บเทคโนโลยี (HTML / CSS / JS) หรือใช้แอป Framer (เขียน Override หรือ สร้าง custom component) ซึ่งจะสามารถรับข้อมูลเข้ามาได้จริง และคำนวณค่าต่างๆได้ตามที่ User ใส่เข้ามา ทำให้เราได้ insight ที่ลึกขึ้น
** แต่ทั้งนี้ ไม่ได้แปลว่าทุก prototype ที่เราสร้างจะต้องสมจริงที่สุดเสมอไปนะครับ ขึ้นอยู่กับว่าเราจะทำ prototype ไปเพื่อทดสอบอะไรต่างหาก
ยกตัวอย่างการพิสูจน์เทคโนโลยี: API ข้อมูลการใช้จ่ายงบประมาณรัฐบาล
ทีมเรารู้มาว่ารัฐบาลมี API ข้อมูลให้ดึงมาใช้ ซึ่งเราพอมีไอเดียคร่าวๆว่าอยากจะ visualize ข้อมูลออกมา แต่เรายังไม่รู้ชัดเจนว่า API ให้ข้อมูลอะไรบ้าง และ framework สำหรับ data visualization ของเราใช้ได้มั้ย
ปกติแล้ว designer อาจจะขอให้ dev ช่วยแกะจาก API ออกมาให้ว่ามีข้อมูลอะไรบ้าง จากนั้นออกแบบบน Figma ว่าอยากให้ data visualize อย่างไร แล้วถึงส่งต่อให้ dev ไปหา framework และสร้างออกมา โดยถ้าสร้างไม่ได้เพราะข้อจำกัดอะไรก็จะนั่งคุยกันและปรับกันไปเรื่อยๆจนได้หน้าตาที่ต้องการ
ในกรณีนี้ DT อาจจะทำความเข้าใจ API และตัว visualization framework คร่าวๆ แล้วเริ่มโค้ด prototype ออกมาเองว่าอยากให้ทำงานอย่างไร ซึ่งเมื่อได้หน้าตาที่ต้องการแล้วก็ส่งงานต่อให้ dev เพื่อไปพัฒนาต่อให้สามารถใช้ได้จริงบน production
…
2. ระหว่างสร้าง - ทำ design system และ component ต่างๆ เพื่อเชื่อมระหว่าง designer และ developer
ปัจจุบัน design system ใน Figma (หรือ Sketch) ถือเป็นมาตรฐานการทำงานไปแล้ว โดยจะทำให้ designer สามารถทำงานกันได้อย่างรวดเร็วและมีมาตราฐานมากขึ้น แต่ไม่ว่าเราจะทำ design system ไว้ดีขนาดไหน สุดท้ายก็จะส่งต่อให้ฝั่ง developer ก็จะต้องสร้างโค้ด component library ที่เป็นโค้ดแยกต่างหากไว้อีกชุดนึงอยู่ดี ซึ่ง library ที่สร้างนั้น อาจจะไม่ตรง spec หรือ interaction บางอย่างอาจไม่เป็นอย่างที่ต้องการ ทุกครั้งจึงต้องมาเช็คงานอีกรอบว่าเป็นอย่างที่ออกแบบไว้มั้ย และแก้งานกันไป
ในกรณีนี้ DT ก็จะช่วย maintain ตัวโค้ด component library ให้เป็นไปอย่างที่ออกแบบไว้ใน design system (ทั้งรูปร่างหน้าตาและ interaction ต่างๆ) โดยจะลดเวลาในการส่งต่องานลง พร้อมทั้งได้คุณภาพที่มากขึ้นเพราะ (1) สามารถหา solution ที่ตอบโจทย์ทั้ง design และ tech ได้ด้วยตัวเอง (2) มีความละเอียดและสนใจในความสวยงามและ interaction มากกว่า developer
…
3. เมื่อมีเวลา - ทำ tool ที่ทำให้งานของ designer ง่ายขึ้น
การทำงานของ designer นั้น สามารถที่จะพัฒนาให้มีประสิทธิภาพขึ้นได้เสมอ ยกตัวอย่างเช่น designer อาจจะมีปัญหาเพื่อแก้คำใน Figma ซึ่งต้องคอยหาแต่ละหน้าจอไปเรื่อยๆแบบ manual เพราะ Figma ไม่มีฟีเจอร์ในการหาคำแบบอัตโนมัติ design technologist ก็จะเขียน Plugin ขึ้นมาชื่อว่า Find and Replace ที่ทำให้กระบวนการตรงนี้เป็นแบบอัตโนมัติมากขึ้น
หรือเมื่อ designer ต้องส่งงานเป็น png ที่มี structure ของ folder แบบเฉพาะเจาะจง และมีวันที่กำกับบนทุกชื่อไฟล์ (เช่น homepage_2021-05-31.png) แทนที่จะต้องมาทำแบบ manual ทุกครั้ง design technologist ก็จะเขียน script ที่ run เพื่อทำให้กระบวนการเป็นไปอย่างอัตโนมัติ
จากสองสถานการณ์ข้างต้น DT จะคอยสนใจปัญหาของทีม และสร้าง tool เพื่อให้กระบวนการทำงานของทีมสะดวกขึ้น และมีข้อผิดพลาดน้อยลง
…
Design Technologist / UX Engineer ดูมีประโยชน์ แต่ในไทยยังแทบไม่มี
ถ้าลองไปหาในเว็บหางาน หรือ LinkedIn ก็จะพบว่าเมื่อเทียบกับดีไซน์เนอร์ประเภทอื่นๆแล้ว DT หรือ UX engineer เป็นอาชีพที่เปิดรับค่อนข้างน้อย (6/11/2021 พบว่า ต่างประเทศมีบ้าง ส่วนประเทศไทยมีที่เดียวคือ Agoda)
แม้หลายๆบริษัทมีปัญหาในการเชื่อมงาน design และ development อยู่ แต่ด้วยความที่คนที่ทำได้ทั้งสองอย่างยังน้อย จึงทำให้บริษัทต่างๆยังไม่ได้รู้จักตำแหน่ง design technologist ดีเลยยังไม่มีใครเปิดรับ อีกอย่างตำแหน่งนี้ก็ยังไม่ mature มาก เลยขาดการโปรโมทให้เป็นที่รู้จักในวงการ design ในไทย
ชื่อตำแหน่ง (Design Technologist) ไม่ได้สำคัญเท่ากับสิ่งที่เราลงมือ (ออกแบบและเขียนโค้ด)
อ่านมาจนถึงตรงนี้ หลายๆคนน่าจะคันไม้คันมือว่าอยากเป็น DT แต่อาจรู้สึกหมดกำลังใจเพราะตำแหน่งนี้ยังไม่มีการเปิดรับในไทย
แต่ถ้าชอบ เราก็เริ่มเตรียมทักษะให้พร้อมไว้ก่อนได้เลย เช่น เริ่มเรียนโค้ดดิ้ง เริ่มสร้างอะไรของตัวเองออนไลน์ (เช่นผมโค้ด blog นี้ด้วยตัวเอง) ทำงานกับเพื่อนที่เป็น dev มากขึ้น และที่สำคัญคอยพูดถึงงานประเภทนี้ให้คนอื่นรับรู้ว่าเราอยากทำ เมื่อวันหนึ่งบริษัทต่างๆเปิดรับตำแหน่งนี้ขึ้นมา เราก็พร้อมจะไปสมัครทันที
ผมก็เป็นหนึ่งคนที่ชอบทั้งออกแบบและโค้ด ถ้าใครชอบอะไรประมาณนี้เหมือนกัน ก็ทักมาคุยกันได้ครับ เรามาพยามไปด้วยกันครับ!
…
ข้อมูลส่วนใหญ่มาจากหลายๆเว็บที่เคยอ่านมา แต่ที่สำคัญคือต้องขอบคุณพี่ตาล (Tania Udomsri) จาก Amazon ที่ช่วยแชร์ประสบการณ์ให้ฟังผ่านการ mentor
ถ้าใครสนใจในสายงานนี้ ลองขอ session การ mentor จากพี่ตาลได้บนเว็บ ADP List ครับ
