การผงาดขึ้นของ ‘Model Designer’: บทบาทของดีไซน์ในผลิตภัณฑ์ AI กำลังเปลี่ยนไป

• Barron Webster ผู้มีประสบการณ์ด้าน การออกแบบผลิตภัณฑ์ AI มากกว่า 8 ปี กำลังทำหน้าที่ ‘Model Designer’ คนแรกของโลกที่ Figma ซึ่งสะท้อนการเกิดขึ้นของ ตำแหน่งงานลูกผสมรูปแบบใหม่ ที่ดีไซเนอร์ทำงานร่วมกับ LLM โดยตรง
• งานหลักของ Model Designer คือ ชดเชยข้อจำกัดของ foundation model และนำ เครื่องมือและวิธีคิดใหม่ ๆ สำหรับการออกแบบฟีเจอร์ AI เข้าสู่องค์กรออกแบบ
• ต่างจากการออกแบบ UI แบบเดิม การออกแบบผลิตภัณฑ์ AI ต้อง สร้างต้นแบบพฤติกรรมของโมเดลก่อน แล้วจึงค่อยออกแบบ UI ไม่เช่นนั้นมีความเสี่ยงที่จะได้ UI สำหรับกรณีที่ดูสมบูรณ์แบบแต่ไม่สอดคล้องกับการทำงานจริง
• การสร้างระบบประเมินผล (Evals) เป็นหัวใจของการควบคุมคุณภาพผลิตภัณฑ์ AI และจำเป็นต้องมีเครื่องมือที่ช่วยให้ดีไซเนอร์ปรับแต่งและรันเคสประเมินได้ในวงจรฟีดแบ็กที่รวดเร็ว
• ในยุค AI ดีไซเนอร์จำเป็นต้องเข้าใจโครงสร้างอินพุตและเอาต์พุตของโมเดลอย่างลึกซึ้ง และมี ความสามารถในการมองเห็นภาพรวมของทั้งระบบ ไม่ใช่เป็นเพียงผู้สร้าง UI แต่ต้องเป็นผู้มีส่วนร่วมในการตัดสินใจ

---

แนะนำ Barron Webster

• เป็นดีไซเนอร์ที่ มีส่วนร่วมอย่างลึกซึ้งกับผลิตภัณฑ์ AI มากว่า 8 ปี และมีมุมมองที่มองทะลุวัฏจักรความ hype ได้
• เคยร่วมออกแบบ Teachable Machine ที่เปิดตัวในปี 2017 ที่ Google Creative Lab ซึ่งเป็นเครื่องมือแรกที่เปิดให้ผู้บริโภคฝึกโมเดล AI ได้
• หลังจากนั้นทำงานด้านฟีเจอร์ AI ที่ Replit และมีส่วนช่วยให้สตาร์ตอัปเติบโตจนเป็นยูนิคอร์น
• ล่าสุดเข้าร่วม Figma ในตำแหน่ง Model Designer คนแรกของโลก

บทบาทของ Model Designer

• สังกัดทีมวิจัย AI ของ Figma และมีภารกิจหลัก 2 อย่าง
  • แก้ปัญหาในสถานการณ์ที่ ต่อให้ดึงประสิทธิภาพจาก foundation model ได้มากที่สุดแล้วก็ยังไม่พอ
  • เนื่องจากข้อมูลของ Figma อยู่ในฟอร์แมตเฉพาะที่เป็นกรรมสิทธิ์ ซึ่ง foundation model จัดการได้ไม่ดี จึงต้องเข้ามาอุดช่องว่างนี้
• นำ เครื่องมือใหม่และวิธีคิดแบบ AI-first เข้าสู่องค์กรออกแบบ
  • Figma เป็นบริษัทขนาดใหญ่และดีไซเนอร์จำนวนมากยังไม่มีประสบการณ์ออกแบบประสบการณ์ AI
  • การออกแบบฟีเจอร์ AI แตกต่างจากการออกแบบผลิตภัณฑ์แบบดั้งเดิม
• เป้าหมายคือสร้างเครื่องมือที่ช่วยให้ดีไซเนอร์ สร้างต้นแบบแก่นของฟีเจอร์ AI ได้ตั้งแต่ต้นกระบวนการ โดยไม่ต้องกลายเป็นวิศวกร
  • หากออกแบบ UI ของฟีเจอร์ที่ยังไม่เคยได้สัมผัสจริง มีความเสี่ยงที่จะสร้าง UI สำหรับกรณีสมบูรณ์แบบที่ไม่ตรงกับพฤติกรรมจริงของระบบ

อนาคตของเครื่องมือออกแบบ AI

• เครื่องมือที่คาดหวังมากที่สุดคือ สิ่งที่ช่วยให้ดีไซเนอร์ปรับแต่งและรันเคสประเมินได้ในวงจรฟีดแบ็กที่รวดเร็ว
  • หากฟีเจอร์ AI ใช้งานไม่ได้ในไฟล์ Figma ก็ควรเพิ่มเป็นเคสทดสอบได้ทันที
  • ควรปรับ system prompt หรือลองเปลี่ยนโมเดลอื่นได้ทันที
• ปัญหาปัจจุบันคือวงจรฟีดแบ็กช้าเกินไป
  • หัวใจของเครื่องมือออกแบบที่ดีทั้งหมดคือการกำจัดหรือลดวงจรฟีดแบ็ก
  • งานส่วนใหญ่ในการสร้างชุดประเมินยังเป็นงานทำความสะอาดข้อมูลด้วยมือ
• กำลังคิดด้วยว่าจะทำให้ฟีเจอร์ AI ของ Figma แตกต่างได้อย่างไร
  • เพราะเป็นแพลตฟอร์มออกแบบ จึงคาดหวังผลลัพธ์ที่ ออกแบบมาได้ดีกว่า Claude Code หรือ Cursor
  • กลยุทธ์การประเมินแบบเจาะจงและการหา ตัวแทนของความเป็นดีไซน์ที่ดี คือกุญแจสำคัญ
  • นี่ก็เป็นคำถามเชิงปรัชญาในระดับโรงเรียนศิลปะด้วย

ประสบการณ์เริ่มต้นกับ AI ของ Barron

• วิชา RISD Computer Utopias ช่วงปี 2014-2015: เป็นยุคก่อน LLM ตอนที่งานวิจัยแมชชีนเลิร์นนิงยังเน้นตัวจำแนกประเภท
  • โมเดลจำแนกภาพน่าสนใจที่สุด และเป็นตัวขับเคลื่อน Snapchat face filter หรือ Google Image Search
  • ประเด็นหลักในเวลานั้นคือ content moderation และระบบแนะนำ
  • เป็นยุคทองของ Facebook, Twitter และ Cambridge Analytica ซึ่ง การถือกำเนิดของฟีดแบบอัลกอริทึม ได้สร้างวัสดุใหม่สำหรับการออกแบบ
• Google Creative Lab ช่วงปี 2016-2018: ทำงานกับ Google Lens, Google Assistant, Teachable Machine
  • แทบทุกโปรเจกต์เกี่ยวข้องกับการนำความก้าวหน้าของโมเดลมาใช้
  • ใช้โมเดลเพื่อ จัดระเบียบหรือใส่คำอธิบายให้คอนเทนต์เดิม ไม่ใช่เพื่อสร้างข้อความ
  • เคยโปรโมตกรณีของเกษตรกรปลูกแตงกวาชาวญี่ปุ่นที่ใช้ TensorFlow จำแนกแตงกวา

ประสบการณ์ที่ Replit

• ทำงานมากกว่า 3 ปี โดยเริ่มในช่วงที่ยังไม่มีฟีเจอร์ AI เลย และรับหน้าที่ประเมินแนวทางการนำ AI มาใช้
• เมื่อโมเดลดีขึ้นต่อเนื่อง ก็ต้องค้นหาวิธีเพิ่มฟีเจอร์ AI ที่ ทั้งใช้ความสามารถใหม่และยังเชื่อถือได้
• เริ่มจากฟีเจอร์แบบเรียกใช้งานด้วยตนเองพื้นฐาน เช่น เลือกโค้ดแล้วให้ AI อธิบาย หรือสร้างโค้ดลงในไฟล์เดิม
• หลังปล่อยแต่ละฟีเจอร์ วงจรความคาดหวังของผู้ใช้ก็สูงขึ้นซ้ำ ๆ
  • อนุญาตให้สร้าง code snippet → ผู้ใช้ต้องการทั้งไฟล์/ทั้งโปรเจกต์
  • สร้างทั้งชุดได้ → ผู้ใช้ต้องการแก้ไขเฉพาะจุด
  • แก้ไขเฉพาะจุดได้ → ผู้ใช้ต้องการเริ่มใหม่ทั้งหมดตั้งแต่ต้น
• มีแพตเทิร์นแบบ ลองทำฟีเจอร์ด้วยโมเดลเดิม → ถ้าไม่ได้ผลก็รอ → แล้วลองใหม่เมื่อมี foundation model รุ่นใหม่ออกมา
• ข้อจำกัดเชิงผลิตภัณฑ์ของสภาพแวดล้อมการเขียนโปรแกรม
  • ต่อให้โมเดลเขียนโค้ดเก่ง ก็ยังต้องมีวิธี แก้ไขในตำแหน่งที่ถูกต้อง
  • ก่อน Sonnet 3.5 โมเดลยังจัดการเลขบรรทัดได้ไม่ดี
  • จำเป็นต้องพัฒนาวิธีแก้เฉพาะหน้าเพื่อให้แก้ไขได้แม่นยำ ป้องกันคอนเทนต์ซ้ำ และแทนที่ฟังก์ชันได้
  • แต่งานส่วนใหญ่เหล่านี้มักหมดความจำเป็นภายใน 6 เดือนถึง 1 ปีเมื่อมีโมเดลใหม่ออกมา

กรณีเปลี่ยนไปใช้การตรวจสอบโดยผู้ใช้

• เมื่อ Replit agent สร้างไฟล์และเขียนโค้ดอัตโนมัติ ปัญหาทางเทคนิคใหญ่คือ การทดสอบแอปพลิเคชันที่ agent สร้างขึ้น
  • เช่น การตรวจสอบว่าหน้าเข้าสู่ระบบทำงานหรือไม่
• แนวทางฝั่งวิศวกรรมคือเปิด sandbox สร้างระบบจับภาพหน้าจอ แล้วส่งภาพให้โมเดลมัลติโหมดเพื่อตัดสินใจว่าจะคลิกหรือพิมพ์ตรงไหน
  • โดยแก่นแล้วคือการทำ การใช้คอมพิวเตอร์แบบกึ่งจำลองโดยโมเดล
• ข้อเสนอของ Barron และวิศวกรอีกคนคือ แสดงเว็บไซต์ให้ผู้ใช้ดูแล้วให้ลองทดสอบเอง
  • เป็นการโยนภาระการยืนยันและการทดสอบกลับไปให้ผู้ใช้ และเลี่ยงปัญหาทางเทคนิคที่ซับซ้อนทั้งหมด
• หากมีคนที่โฟกัสที่ปัญหาผู้ใช้แทนที่จะยึดติดกับปัญหาทางเทคนิค ก็สามารถข้ามหรือลดความซับซ้อนของหลายเรื่องได้

การค้นหา product-market fit

• กลยุทธ์ผลิตภัณฑ์แบบดั้งเดิมก่อนยุค AI คือวางแผนล่วงหน้า ใช้ฐานผู้ใช้เดิม และกำหนดกลยุทธ์ขยายตลาด/หมวดหมู่
• แต่จากการเปลี่ยนแปลงอย่างรวดเร็วของ AI ทำให้ กลยุทธ์ของ Replit มีลักษณะตอบสนองต่อสถานการณ์มากกว่ามาก
• มี product-market fit ที่แข็งแรงในตลาดการศึกษา โดยเฉพาะหลังการเรียนทางไกลในช่วงโควิด
• เมื่อฟีเจอร์ AI ดีขึ้นก็เกิดภาวะกลืนไม่เข้าคายไม่ออก
  • นักพัฒนาอิสระและแฮกเกอร์ชอบ AI
  • แต่ครูไม่เห็นด้วย เพราะนักเรียนอาจข้ามการเรียนพื้นฐาน
• ตอนเปิดตัว Replit agent ยังไม่ชัดเจนว่าผู้ใช้เป้าหมายคือใคร
  • แนวทาง ปล่อยฟีเจอร์แล้วดูปฏิกิริยา ประสบความสำเร็จมากกว่าการวางโปรเจกต์แบบ top-down
  • หลังเปิดตัวจึงค้นพบผู้ใช้ผ่านบทสนทนาว่าเป็นฝ่ายปฏิบัติการในบริษัทเทค ที่ต้องการเก็บข้อมูลการขายหรือสร้างแดชบอร์ด คล้ายผู้ใช้ Zapier หรือ Retool

ระบบประเมินผล (Evals)

• ในช่วง 2 ปีแรกที่ Replit แทบไม่ได้ทำ eval มากนัก เพราะตอนนั้นยังไม่เป็นแนวปฏิบัติที่แพร่หลาย
• สำหรับ agent เริ่มใช้ eval มากขึ้น โดยใช้เป็น ตัวชี้วัดเพื่อการพัฒนาผลิตภัณฑ์ เป็นหลัก
  • เมื่อมีโมเดลใหม่ออกมา ก็ดูประสิทธิภาพในการประเมินงานเขียนโปรแกรมก่อนว่าจะคุ้มค่าพอให้ทดสอบแอปหรือไม่
• ที่ Sandbar ใช้เวลามากกับการเขียน eval เกี่ยวกับบุคลิกของโมเดล
  • นอกเหนือจาก eval มาตรฐานกว้าง ๆ ระดับอุตสาหกรรม การสร้าง eval เฉพาะตัวของผลิตภัณฑ์ คือรูปแบบงานออกแบบแบบใหม่
• เวิร์กโฟลว์คือ เขียน prompt → ปรับ prompt → สร้าง eval → ตรวจดูประสิทธิภาพ → ผสานกับการทดสอบด้วยมือและฟีดแบ็กเชิงอัตวิสัย
• หากไม่มี eval จะทำให้ งานตรวจสอบด้วยมือเพื่อยืนยันว่า AI ทำงานได้จริงเพิ่มขึ้นมาก
• ตัวอย่าง eval ที่ Sandbar
  • หากไม่รู้คำตอบ ต้องถาม คำถามเพื่อขอความชัดเจนที่เฉพาะเจาะจงเพียงข้อเดียว แทนที่จะหลอนคำตอบขึ้นมา
  • ห้ามถามเกินสองคำถามในครั้งเดียว
  • ต้องตอบให้กระชับอยู่เสมอ (ยกเว้นบางกรณี)

ความยากของการประเมินผล

• การประจบผู้ใช้ (Sycophancy) เป็นหนึ่งในหัวข้อที่ยากที่สุดในการเขียน eval
  • คือแนวคิดที่ว่าในบางกรณีโมเดลควรโต้แย้งผู้ใช้อย่างเหมาะสม
  • การกำหนดอัตราความล้มเหลวที่ยอมรับได้จึงกลายเป็นการตัดสินใจด้านผลิตภัณฑ์และการออกแบบ และเป็นส่วนหนึ่งของปรัชญาการออกแบบของผลิตภัณฑ์
• หลายครั้งที่ผล eval ออกมาแย่ สาเหตุไม่ใช่ ประสิทธิภาพตกลง แต่เป็นเพราะเขียน eval ผิด
  • เช่น ใน eval ที่กำหนดว่า “ต้องกระชับมาก” หากผู้ใช้บอกว่า “แม่ของฉันเสียชีวิตแล้ว” คำตอบว่า “เสียใจด้วยนะ” อาจได้คะแนนสูง แต่ไม่ใช่คำตอบที่ต้องการจริง
• โดยทั่วไป eval ใช้เพื่อ ป้องกัน regression และตรวจสอบว่าคุณสมบัติที่ต้องการยังอยู่ครบ
  • คล้าย test coverage ในงานเขียนโปรแกรม
• สิ่งที่คล้าย test-driven development (TDD) ของการเขียนโปรแกรมแบบดั้งเดิมยังพบได้น้อยในงาน AI engineering
  • คือแนวทางเขียน eval ก่อน แล้วค่อยเขียนโค้ดให้ผ่าน eval
• อาจมีอาชีพใหม่ในอนาคตอย่าง นักออกแบบ eval
  • คล้ายบทบาทของ design system ที่ออกแบบแดชบอร์ดให้ทีมเข้าใจประสิทธิภาพของ AI ได้

แนวคิดฟีเจอร์ AI ที่ Figma

• กำลังพิจารณาไอเดีย “design critique as a service”
  • ให้ AI ช่วยวิจารณ์งานออกแบบ
  • ซึ่งก่อให้เกิดคำถามที่น่าสนใจเกี่ยวกับบุคลิกของระบบนั้น
• จะเปิดให้เลือกท่าทีได้ เช่น สไตล์ “Dieter Rams” หรือกำหนดค่าเริ่มต้นเลยดี
• จะเน้นเรื่อง accessibility หรือปัญหาคอนทราสต์ที่ให้ฟีดแบ็กได้ค่อนข้างเป็นวัตถุวิสัย หรือจะมุ่งไปกว้างกว่านั้น
• ยังไม่ชัดว่าจะสะท้อนออกมาในประสบการณ์ผลิตภัณฑ์จริงมากน้อยแค่ไหน

ทิศทางการพัฒนาเครื่องมือ eval

• ต้องการ เครื่องมือที่ลดเวลาในการวนซ้ำเพื่อสร้าง eval
• ตอนนี้ทุกคนที่ทำงาน eval ต้องทำสิ่งพื้นฐานคล้ายกัน
  • เชื่อม mapping, format, pipeline และอินเทอร์เฟซที่เห็นผลลัพธ์ทั้งหมดได้ในที่เดียว
• เครื่องมือสำหรับข้อความค่อนข้างดีแล้ว แต่ สำหรับฟอร์แมตอื่นยังขาดแคลน
• มีแพลตฟอร์มประเมินคล้ายกันอย่าง Design Arena
  • ที่ให้คนโหวตผลลัพธ์ที่ดีที่สุดจากการทดสอบแบบ blind side-by-side
• ต้องการทำสิ่งคล้ายกันนี้ ได้โดยตรงในไฟล์ Figma
  • รวมถึงการใส่คอมเมนต์และชี้ปัญหา
  • ควรสร้างชุดทดสอบได้เร็ว รันได้ทีเดียว รับคำตอบ 100 ชุด และวนซ้ำได้ภายใน 30 วินาที
  • ตอนนี้องค์ประกอบทุกชิ้นทำงานได้แล้ว แต่ยังใช้เวลานานเกินไป

บทบาทของดีไซเนอร์ในการสร้างโมเดล

• มีประสบการณ์ทั้งสองแนวทางคือ ฝึกตั้งแต่ต้น และ fine-tuning
• ในกรณีฝึกตั้งแต่ต้น สิ่งที่ดีไซเนอร์มีส่วนช่วยมากที่สุดคือ บอกให้องค์กรเห็นว่าตรงไหนคือจุดที่ความต้องการของผู้ใช้สูงและความไม่สะดวกมากที่สุด
  • ที่ Replit เคยฝึกโมเดลเฉพาะสำหรับข้อผิดพลาดโค้ด Python แบบพื้นฐานและพบบ่อย
  • มีส่วนร่วมกับ การนิยามปัญหาและหาวิธีนำโมเดลที่ฝึกแล้วไปใช้ในผลิตภัณฑ์ มากกว่าตัวการฝึกจริง
• ในกรณี fine-tuning จะมีทั้งโมเดล ผลิตภัณฑ์ และ eval อยู่แล้ว และต้องการยกระดับประสิทธิภาพ
  • คนที่เขียน prompt เขียน eval และพูดคุยกับผู้ใช้ จะรู้ชัดที่สุดว่าผลลัพธ์ตอบสนองความคาดหวังหรือไม่
  • เมื่อ prompt engineering ไปถึงขีดจำกัดแล้ว fine-tuning คือขั้นต่อไป
• บทบาทการแปลความหลักของดีไซเนอร์คือ การจดจำสมมติฐานของผู้ใช้
  • วิศวกรหรือดีไซเนอร์ที่ทำงานใกล้ชิดกับโมเดลมาก ๆ อาจลืมไปว่าผู้ใช้ไม่รู้รายละเอียดเหล่านี้
  • จึงต้องใช้ “ความโง่ในตัวเอง” เพื่อสื่อสารว่าผู้ใช้แบบไร้เดียงสาที่ไม่รู้คุณลักษณะของโมเดลจะลองทำอะไร และจะติดขัดตรงไหน

คำแนะนำสำหรับ AI Product Designer

• สิ่งที่ยั่งยืนและทรงอิทธิพลที่สุดคือ ลงทุนเวลาอย่างจริงจังเพื่อเข้าใจอินพุตและเอาต์พุตของโมเดลอย่างแท้จริง
  • prompt คืออะไร ข้อมูลผู้ใช้แบบใดถูกป้อนเข้าไป เรียกใช้เครื่องมืออะไรได้บ้าง มี eval แบบไหนอยู่
  • ต้องมีสัญชาตญาณว่าเมื่อปรับปุ่มหมุนเหล่านี้แล้วจะเกิดอะไรขึ้น
• อย่ากลายเป็นเพียง ผู้ทำ UI ให้กับผลลัพธ์ที่ตนเองไม่เข้าใจอย่างลึกซึ้ง
  • ถ้ามีคนบอกว่า “โมเดลให้สิ่งนี้มา คุณก็แค่ออกแบบอินเทอร์เฟซ” ก็อาจทำได้ แต่จะไม่สามารถเสนอการปรับปรุงจากอินไซต์ผู้ใช้ได้
  • และจะทำงานแบบไล่ตามการเปลี่ยนแปลงของโมเดลรุ่นถัดไปอยู่ตลอด
• ต้องเป็น ส่วนหนึ่งของการตัดสินใจ ว่าฟีเจอร์ใหม่คือสิ่งที่ต้องการจริงหรือไม่ ไม่ใช่เป็นแค่ผู้รับคำสั่ง
• สิ่งนี้อาจยากสำหรับดีไซเนอร์ที่ไม่คุ้นกับโค้ด
  • จึงอาจต้องมีอินเทอร์เฟซอย่าง Langsmith หรือเรียนรู้วิธีรันสภาพแวดล้อมนักพัฒนาได้ด้วยตัวเอง

กรณีที่สร้างผลกระทบมากที่สุด

• Replit agent: เขาช่วยโน้มน้าวทีมให้ให้ผู้ใช้เป็นผู้ตรวจสอบโดยตรงว่าแอปที่สร้างขึ้นใช้งานได้หรือไม่
  • การโฟกัสที่เส้นทางที่ง่ายที่สุดของการยืนยันโดยผู้ใช้ ช่วยประหยัดแรงไปได้มาก
• การเปิดตัว LaMDA (LLM รุ่นแรก ๆ ของ Google): ใช้เวลามากในการลองใช้โมเดลหลายรูปแบบและดูว่าอะไรทำงานดีที่สุด
  • ตอนนั้นยังไม่ได้เรียกว่า “prompting” แต่เป็นการพยายามทำให้โมเดลรับบทเป็นสิ่งอื่นและทำได้อย่างน่าเชื่อถือ
  • เดโมที่ให้คุยกับดาวพลูโตหรือดวงจันทร์ของมัน คือผลจากการ ลองผิดลองถูกมากมายจนเจอสิ่งที่ทำงานดีที่สุด
  • ถ้าไม่มีการทดลองอย่างกว้างขวางก็เลือกกลยุทธ์แบบมีหลักการไม่ได้

การ prompting ของดีไซเนอร์

• คำถามว่า “ดีไซเนอร์ควร prompt ไหม” มีธรรมชาติไม่เหมือนกับคำถามว่า “ดีไซเนอร์ควรเขียนโค้ดไหม”
• ในกรณีการเขียนโค้ด คำตอบค่อนข้างพิสูจน์หักล้างได้ เช่น สร้าง XYZ ด้วยเทคโนโลยี ABC ได้หรือไม่ ซึ่งการถามวิศวกรก็แทบเทียบเท่ากับการรู้เองโดยตรง
• แต่ พฤติกรรมของโมเดล AI มีความเป็นอัตวิสัยและละเอียดอ่อนโดยเนื้อแท้มากกว่า
  • จึงไม่มีสิ่งใดมาแทนการเข้าใจวัสดุนี้ด้วยตัวเองในระดับลึกได้

นี่ยังถือว่าเป็นงานออกแบบอยู่ไหม

• มันคือ การออกแบบพฤติกรรม ซึ่งอาจไม่สมบูรณ์แบบ และนั่นก็ไม่เป็นไร
• เป็นชุดความคิดที่ต่างจากการออกแบบ UI ที่ควบคุมทุกพิกเซลได้สมบูรณ์และให้รางวัลกับความเป๊ะ
• ยังคงมีการทำ mockup และใช้เครื่องมือออกแบบอยู่
• สร้างเคส eval ใน Figma ตรวจผลลัพธ์ แล้วแก้ส่วนที่ดูแปลก
• มีความเกือบจะเยียวยาจิตใจ คล้าย fidget spinner
  • ถ้าให้ mockup เว็บไซต์กับเวลา 30 นาที ก็จะมีความสุขกับการปรับ typography
• เป็นงานประเภทที่ ไม่มีวันจบตราบใดที่ฟีเจอร์ยังไม่ถูกถอดออก เพราะยังปรับปรุงได้เสมอ