ตอนนี้ฉันออกแบบด้วย Claude มากกว่า Figma แล้ว

• เวิร์กโฟลว์การออกแบบกำลังย้ายจากการผ่านเอกสารสเปกและม็อกอัปใน Figma เพื่อตรวจทานการพัฒนา ไปสู่การสร้าง ฟีเจอร์ต้นแบบ ที่ทำงานได้จริงในโค้ดเบส
• Copilot, Cursor และ Gemini ทำได้ไม่ดีอย่างที่คาดในงานอย่างการแก้เกม บรีฟผลิตภัณฑ์ และไวร์เฟรมที่เดิมทีถนัดอยู่แล้ว แต่ในสภาพแวดล้อม OCaml และ Bonsai ที่ต้องเรียนรู้ใหม่ การช่วยเหลือจาก AI กลายเป็นองค์ประกอบจำเป็น
• กระบวนการแบบ ยึดการลงมือทำจริงเป็นศูนย์กลาง เริ่มจากส่งปัญหาและข้อเสนอเป็นพรอมต์ แล้วต่อด้วยการทำฟังก์ชันพื้นฐาน การปรับแก้ซ้ำ การปล่อยขึ้นสภาพแวดล้อมพัฒนา การตรวจสอบความเห็นผู้ใช้ และการส่ง feature
• ต้นแบบที่เพิ่ม LLM prompting เข้าไปในช่องกรอก JSQL ทำให้มีการขัดเกลาปุ่ม คีย์ลัด ข้อความ พรอมต์ และข้อความยืนยันหลายรอบ โดยทุ่มแรงไปกับ ผลลัพธ์ที่ใช้งานได้จริง แทนคอมโพเนนต์ Figma หรือรูปแบบเอกสาร
• นักออกแบบสามารถทำไอเดียให้อยู่ในรูปที่ใช้งานได้จริงด้วยตัวเองมากขึ้น แต่ต้นแบบที่ดูเหมือนฟีเจอร์เสร็จแล้วก็นำมาซึ่งโจทย์ใหม่เรื่องวิธีมีส่วนร่วมในการรีวิวและ การสำรวจเชิงสร้างสรรค์

---

จากความรู้สึกหมดศรัทธาใน LLM สู่เครื่องมือช่วยที่ขาดไม่ได้

• ตลอดเวลาที่ผ่านมา ทุกครั้งที่ใช้ LLM มักผิดหวังกับผลลัพธ์ และเมื่อเอา LLM ไปใช้กับงานที่ตัวเองถนัด ก็พบว่าคุณภาพต่ำกว่าทำเองเสมอ
• เคยใช้ Copilot และ Cursor เพื่อแก้เกมที่ทำไว้เมื่อปีก่อน แต่ทั้งคู่ก็สร้างการแก้ไขที่ใช้งานได้จริงไม่ได้ ส่วนที่ทำงานก่อนหน้านั้นก็เคยลองใช้ Gemini ทำโครงบรีฟผลิตภัณฑ์และสร้างไวร์เฟรม แต่สุดท้ายก็ทิ้งทั้งหมด
• หลังเข้าร่วม Jane Street เมื่อฤดูร้อนที่ผ่านมา มีหลายอย่างต้องเรียนรู้ใหม่ และเพราะเทคโนโลยีอย่าง OCaml กับ Bonsai ยังไม่คุ้นเคย การช่วยเหลือจาก AI จึงมีบทบาทจำเป็นอย่างมาก
• การเปลี่ยนแปลงครั้งใหญ่คือ AI ได้เปลี่ยนแม้กระทั่งเวิร์กโฟลว์การออกแบบที่เคยมั่นใจที่สุด

ต้นแบบบนโค้ดเบสจริง แทน Figma และเอกสาร

• แทนที่จะเขียนเอกสารสเปก ทำม็อกอัปใน Figma เขียนข้อเสนอ และคุยกับนักพัฒนาเพื่อตรวจทานการพัฒนา กลายเป็นการสร้างฟีเจอร์ต้นแบบที่ทำสิ่งในหัวให้เกิดขึ้นอย่างแม่นยำ
• ขั้นตอนจริงคือเขียนข้อความอธิบายปัญหาและข้อเสนอ จากนั้นเปิด build, server และ Claude ใน editor แล้วใช้คำอธิบายที่เขียนไว้เป็นพรอมต์
  • ทำให้ฟังก์ชันพื้นฐานทำงานก่อนเพื่อดูความเป็นไปได้ แล้วค่อยปรับแก้ซ้ำได้ตามต้องการ
  • นำการเปลี่ยนแปลงขึ้นสภาพแวดล้อมพัฒนา ขอความเห็นจากผู้ใช้ แล้วส่ง feature ที่มีหน้าตาและพฤติกรรมตามต้องการ
  • ที่ Jane Street คำว่า feature คือขั้นตอนที่เทียบได้กับ pull request
• ฟีเจอร์ต้นแบบในโค้ดเบสจริงให้ประสบการณ์ที่ดีกว่าม็อกอัปและเอกสารแทบทุกด้าน
• ตัวอย่างล่าสุดคือต้นแบบที่เพิ่ม LLM prompting เข้าไปในช่องกรอก JSQL ซึ่งใช้งานได้จริง และถูกนำมาใช้ทดสอบด้วยตัวเองอยู่หลายวัน
  • JSQL คือ SQL dialect ภายในที่ใช้กับเครื่องมือสำหรับผู้ใช้หลายตัว
  • Claude เปิดโอกาสให้ปรับแก้แบบอิสระและแทบไร้ขีดจำกัด แม้จะเปลี่ยนใจเป็นครั้งที่ 50 หรือขอแก้จุดเล็กน้อยก็ไม่บ่น
  • มีการปรับปรุงตั้งแต่ปุ่ม Submit, คีย์ลัดคีย์บอร์ด, ข้อความ, พรอมต์ ไปจนถึงข้อความยืนยันที่สร้างขึ้น
• เวิร์กโฟลว์นี้คือการปรับปรุงที่ในที่ทำงานเดิมอาจต้องใช้เวลาหลายวันหรือหลายสัปดาห์ในการโต้กลับไปมาระหว่างวิศวกรรมกับดีไซน์ หรือไม่ก็มีโอกาสสูงที่จะไม่เกิดขึ้นเลย
• แรงที่ใส่ลงไปกับฟีเจอร์นี้จึงไม่ได้หมดไปกับผลลัพธ์ขั้นกลางอย่างการสร้างคอมโพเนนต์ใน Figma หรือจัดรูปแบบเอกสาร แต่ไปอยู่กับการปรับปรุงผลลัพธ์จริง

ขอบเขตที่ขยายขึ้นในช่วงสองเดือนที่ผ่านมา

• กว่าจะมาถึงจุดนี้ต้องใช้เวลา ช่วงแรกหลังเข้าร่วมยังใช้ AI แค่กับงานเล็ก ๆ เช่นการแก้ความขัดใจเล็กน้อยใน UX
• สำหรับไอเดียใหญ่ยังคงใช้ Figma และเอกสารอยู่ และความพยายามจะสร้างด้วย Claude ก็ยังล้มเหลว
• แต่ในช่วง 2 เดือนที่ผ่านมา จำนวนครั้งที่เปิด Figma ลดลงอย่างรวดเร็ว จากผลรวมของโมเดลที่ดีขึ้น ความชำนาญกับเครื่องมือ และการเลือกขอบเขตงานที่เหมาะสม
• AI ไม่ได้ใช้แค่กับพรอมต์ของ JSQL แต่ยังใช้กับต้นแบบอีกราว 6 ชิ้นที่เกี่ยวกับสิ่งที่ผู้ใช้มองเห็น โมเดลข้อมูล และการเปลี่ยนแปลงไลบรารี
  • ต้นแบบบางชิ้นมี diff เกิน 2000 บรรทัด
  • ยังใช้สร้างต้นแบบอินเทอร์แอ็กทีฟของแอปใหม่ที่ออกแบบไว้ใน Figma ด้วย
  • แอปใหม่บางตัวข้าม Figma ไปเลย แล้วเริ่มวนรอบงานออกแบบภาพด้วย Claude ตั้งแต่ต้น

ขยายอำนาจของนักออกแบบ และนิยามวิธีรีวิวใหม่

• วิศวกรเมื่อมีไอเดียสามารถทำ proof of concept ที่ใช้งานได้เอง แต่ฝั่งนักออกแบบมักอยู่ในโครงสร้างที่ต้องโน้มน้าวให้คนอื่นช่วยสร้างให้
• ไอเดียอย่าง “ทำ LLM prompting ได้ตรงในช่องกรอก JSQL” ยังไม่ชัดเจนตั้งแต่ต้นว่าจะทำได้จริงหรือไม่ ดังนั้นถ้าให้คนอื่นทำต้นแบบแทน ก็อาจกลายเป็นการเสียเวลา
• ข้อเสนอบางอย่างอาจยังตอบความต้องการผู้ใช้ได้ไม่ชัด และเมื่อใช้ Claude ทำไอเดียให้ออกมาเป็นรูปธรรม คนอื่นก็ประเมินได้ง่ายขึ้นเพราะสามารถลองใช้ได้โดยตรง
• ข้อเสียคือรีวิวเวอร์อาจได้รับสิ่งที่ดูเหมือนฟีเจอร์เสร็จแล้ว ทำให้ไม่ชัดว่าควรให้ความเห็นต่อฟีเจอร์นั้นหรือแค่ตรวจโค้ด
• ถ้าเทียบในแง่ดีไซน์ ก็คล้ายกับ PM ส่งไวร์เฟรมละเอียดมาแล้วบอกให้ช่วยทำให้สวยขึ้น ซึ่งไม่ใช่งานรีวิวที่สนุกนัก
• ข้อเสนอควรชัดเจนและครบถ้วน แต่ก็ต้องเป็นสิ่งที่เพื่อนร่วมงานฝั่งวิศวกรรมปฏิบัติต่อมันเหมือนม็อกอัปใน Figma คือเป็นสิ่งสำหรับวนรอบร่วมกันในพื้นที่ของการออกแบบ
• ทางออกในตอนนี้คือใส่ข้อความแจ้งสั้น ๆ ไว้ในคำอธิบาย feature
  • ต้นแบบคือเอกสารข้อเสนอที่ยังมีชีวิต
  • โค้ดสามารถทิ้งได้
  • บทบาทของรีวิวเวอร์คือให้ความเห็นด้านดีไซน์และประสบการณ์ผู้ใช้
• ในท้ายที่สุด รีวิวย์เวอร์อาจรับช่วงไอเดียไปแล้วลงมือทำต่อใน feature แยกต่างหาก โดยอ้างอิงต้นแบบ แต่ให้รีวิวเวอร์เป็นเจ้าของ production code
• ในการทำงานจริง ตอนนี้ยังคงค่อย ๆ หาว่าอะไรสมเหตุสมผลและให้ความรู้สึกที่ดีในเวิร์กโฟลว์ใหม่นี้

ข้อจำกัดของงานวนรอบ และความรู้สึกที่ได้กลับมาสู่สื่อจริงอีกครั้ง

• การออกแบบด้วย Claude ทำให้กังวลว่าอาจถอยห่างจากวิธีคิดที่ลื่นไหลและสร้างสรรค์ และติดอยู่กับการวนรอบภายในขอบเขตของสิ่งที่คิดว่า Claude สร้างได้
• ถ้าเป็นกรณีที่การเปลี่ยนแปลงมีลักษณะเป็นการปรับซ้ำแบบเครื่องมือที่โตเต็มที่แล้วก็อาจไม่เป็นปัญหา แต่เมื่อต้องสร้างสิ่งใหม่ มีความเสี่ยงที่จะพลาดไอเดียบางอย่าง
• ย้อนกลับไปช่วงเริ่มอาชีพอย่างจริงจังในปี 2011 มีการถกเถียงเรื่อง designers should code กันมาก และฝ่ายวิจารณ์มองว่าเมื่อเริ่มเขียนโปรแกรมแล้ว จะทำการเปลี่ยนแปลงไอเดียครั้งใหญ่ได้ยาก
• ผู้เขียนชอบทั้งการทำเว็บไซต์และการเขียนโปรแกรม จึงเขียนโค้ดมาเรื่อย ๆ แต่หลังจากเฟรมเวิร์กฟรอนต์เอนด์อย่าง React กลายเป็นเรื่องทั่วไป และงานฟรอนต์เอนด์ซับซ้อนขึ้น ก็เลือกเส้นทางความเชี่ยวชาญเฉพาะด้าน
• โปรเจกต์ React ส่วนตัวช่วยให้สื่อสารกับนักพัฒนาได้ดีขึ้น แต่ในที่ทำงานกลับใช้เวลาแทบทั้งหมดอยู่กับ Figma และเอกสาร
• ถ้าเข้าร่วม Jane Street ก่อนยุค LLM ก็น่าจะยิ่งติดอยู่กับ Figma มากขึ้น และต่างจาก JavaScript ตรงที่ OCaml กับ Bonsai เป็นของใหม่ทั้งหมดจนการมีส่วนร่วมทางเทคนิคอาจดูเป็นเรื่องไกลตัว
• ตอนนี้กลับมาได้สร้างผลลัพธ์จริงอีกครั้ง ได้ทำงานภายในสื่อนั้นโดยตรง และรู้สึกว่ามีอิสระมากขึ้นที่จะลองทำอะไรก็ได้

[GN⁺]

ความคิดเห็นจาก Hacker News

• ฝั่งธุรกิจมักเอา ทางแก้ ที่ตัวเองคิดขึ้นมาแล้วมาเสนอราวกับเป็นข้อกำหนด และส่วนใหญ่ก็เป็นอะไรคล้ายเครื่อง Rube Goldberg จนต้องคุยกันเพื่อทำ reverse engineer ถึงจะไปถึงความต้องการที่แท้จริงได้
  ต่อจากนี้น่าจะยิ่งเอาทางแก้ที่ “พร้อมแล้ว” และ “ใช้งานได้” มาให้ดู และจะยิ่งไม่เปิดรับการคุยเรื่องการออกแบบและสถาปัตยกรรมในภาพรวม
  น่าจะกลายเป็นแนว “ก็สร้างแบบนี้ก็จบไม่ใช่เหรอ เกือบเสร็จแล้วทำไมยังต้องใช้เวลา X คน-ชั่วโมงอีก?”

  • เคยเห็นแบบนี้มาแล้ว และมันถูกทำด้วย vibe coding ตั้งแต่ต้นจนจบ
    ข้อเสียคือฝั่งธุรกิจไม่เข้าใจว่าทำไมเอาแอปนั้นขึ้น production ตรง ๆ ไม่ได้
    แรงกดดันแบบ “AI ทำให้ไปได้เร็วขึ้นนี่” จะยิ่งมากขึ้น และสุดท้ายคงขึ้นอยู่กับพลวัตองค์กรที่ดีหรือไม่ดี
    ข้อดีคือไอเดียถูกตรวจสอบละเอียดกว่าการสเก็ตช์บนกระดาษแนปกิ้นมาก
    Claude น่าจะถามถึงกรณีขอบเขตและการตัดสินใจด้านการออกแบบไปแล้ว และมีโอกาสสูงว่าถึงจุดหนึ่งจะมีการระบุชัดว่า “อย่าไปสนใจส่วนนั้น ให้สมมติไปก่อน” หรือ “ลองใช้มาสองสามครั้งแล้ว interaction แบบนี้ไม่เวิร์ก เปลี่ยนให้หน่อย”
    ตอนนี้แรงกดดันแบบ “มีปัญหาอะไร ก็ deploy ไปสิ” ยังแรง โง่ และบั่นทอนกำลังใจ จนแทบเป็นผลเสียล้วน ๆ แต่ถ้ามันนิ่งขึ้นแล้วก็อาจกลายเป็นผลดีสุทธิสำหรับโปรเจกต์ในอนาคต
  • เจอเยอะมากกับงานที่เข้ามาในสภาพ “เกือบเสร็จแล้ว เหลือแค่แก้เล็กน้อยก่อนขึ้น production”
    โดย การแก้เล็กน้อย นั้นคือพวกปัญหาเลย์เอาต์พังถ้าหน้ากว้างเบราว์เซอร์ไม่ใช่ 1920px พอดี, ฟิลเตอร์กับการเรียงลำดับที่บางครั้งทำงานไม่ถูกต้อง, หรือค่าที่เปลี่ยนแล้วไม่อัปเดตในแอปอย่างถูกต้องหลังจากบาง action
    ไม่ว่าปัญหาจะเป็นอะไร ฝั่งธุรกิจก็มักคิดว่าตัวเองทำไปแล้ว 95% และประเมินล่วงหน้าว่า “ถ้าเป็นนักพัฒนาฝีมือดีคงแก้ได้แป๊บเดียว”
  • เรื่องแบบนี้เกิดบ่อยในโลกของ audio engineering มาพักใหญ่แล้ว หลังจากเพลงเดโมที่ทำที่บ้านมีคุณภาพใกล้ระดับมืออาชีพมากขึ้น
    ผู้คนจะคุ้นกับผลลัพธ์ที่ตัวเองมีอยู่ แล้วรับการเปลี่ยนแปลงในมิกซ์ใหม่จากมืออาชีพได้ยากขึ้น
  • ที่บริษัทเราก็เหมือนกัน ฝั่งธุรกิจเอาทางแก้ที่ตัวเองคิดมาเสนอเป็นข้อกำหนด ทั้งที่ส่วนใหญ่ไม่ใช่ สิ่งที่ลูกค้าต้องการ
    แม้จะมี PM, CSM, TAM ที่มีเซนส์ในการแปลปัญหาลูกค้าให้เป็นฟีเจอร์ผลิตภัณฑ์ที่ใช้งานง่าย แต่ถ้าข้ามขั้นการนิยามปัญหาไป แล้วปล่อยให้องค์กรฟังก์ชันอื่นไปสร้างทางแก้ ก็มักกลายเป็นหายนะที่สิ้นเปลืองทั้งวิศวกรรมและทรัพยากรอื่นอย่างมาก
    ถ้ามีใครเอาทางแก้มาให้ ก็เสี่ยงมากที่จะใช้เวลาหลายเดือนสร้างซอฟต์แวร์ที่ deploy ใช้งานจริงได้ แล้วค่อยพบว่าลูกค้าไม่ชอบ มันแก้ปัญหาไม่ได้ หรือสร้างปัญหาใหม่ขึ้นมา
  • มันกำลังเกิดขึ้นจริงตอนนี้
    ไม่ใช่ที่ที่ฉันทำงานอยู่ตอนนี้ แต่เป็นที่เก่า และมันถูกเอาขึ้น production ทั้งที่มีปัญหา ข้อมูลสูญหาย และปัญหาความปลอดภัย

• เท่าที่รู้ Jane Street เป็นนักลงทุนของ Anthropic ดังนั้นก็ควรคำนึงถึงจุดนั้นด้วย

  • ต้องรับฟังแบบเผื่อใจไว้เยอะมาก
    ยังมีเรื่องที่ในเดือนกรกฎาคม 2025 หน่วยงานกำกับหลักทรัพย์อินเดีย SEBI กล่าวหาว่า Jane Street ใช้นิติบุคคลหลายแห่งในการ ปั่นตลาด และสั่งห้ามเข้าถึงตลาดด้วย
  • จากที่ฉันเข้าใจ Jane Street เป็นบริษัทที่มีส่วนช่วย OCaml มาก และยังทำเว็บเฟรมเวิร์กใช้เองด้วย
    ถ้ามีถุงเงินก้อนใหญ่ ก็คงต้องมีแดชบอร์ดเยอะอยู่แล้ว
    ในกรณีนี้นักออกแบบดูเหมือนกำลังใช้วิธีที่ผิด และเหมือนตกอยู่ในภาวะ หลงใหลความเป็นวิศวกร ที่อยากทำ prototype ให้ลึกและสมจริงที่สุด
    แต่นั่นไม่ใช่ส่วนที่สำคัญที่สุดของงานออกแบบ
    สิ่งที่สำคัญที่สุดคือการสร้างสิ่งที่ถูกต้อง
    คำถามอย่าง “ทำไมต้องมีช่องกรอก JSQL? จริง ๆ แล้วต้องการอะไร? มีวิธีอื่นไหม?” มักแก้ได้ดีกว่าด้วยการสเก็ตช์ปากกากับกระดาษ การประชุม การสังเกต และการถกเถียง
    ดีกว่าการตีกรอบแคบเร็วเกินไปไปยังดีไซน์แบบใดแบบหนึ่ง แล้วจมอยู่กับการคุยว่าปุ่มควรอยู่ซ้ายหรือขวา หรือรายละเอียดการทำงานของ LLM ควรเป็นแบบไหน
  • ต่อให้ไม่ใช่นักลงทุน ฉันก็ยังไม่แน่ใจว่าควรให้ความสำคัญกับมุมมองด้านฟรอนต์เอนด์ดีไซน์ของ บริษัทเทรดเชิงปริมาณ มากแค่ไหน
  • ตอนนี้ HN ทั้งเว็บเหมือนป้ายโฆษณา AI ขนาดยักษ์ไปแล้ว
  • อาจไม่จำเป็นต้องมองแม้แต่โพสต์บล็อกที่พอน่าสนใจของพนักงานคนหนึ่งแบบ สงครามจิตวิทยา ก็ได้
    แน่นอนว่านั่นอาจเป็นสิ่งที่พวกเขาอยากให้คุณคิดพอดีก็ได้

• บางทีก็เห็นแบบนี้
  ตอนนี้ LLM ยังมองไม่พ้นการทำซ้ำแบบเดิม ๆ ดังนั้นฉันต้องเป็นคนคิดนอกกรอบแล้วถามว่า “ถ้ามองจากมุมนี้ล่ะ?” ถึงจะเกิดแนวทางการออกแบบใหม่ขึ้นมาแบบฉับพลัน
  บางครั้งต้องทำ flowchart เพื่อช่วยให้ LLM มองเลยขั้นตอนปัจจุบันของตัวเองไปได้

• จากประโยคที่ว่า “Claude ให้การทำซ้ำฟรีไม่อั้นและไม่บ่น แม้ว่าฉันจะเปลี่ยนใจเป็นครั้งที่ 50 หรือขอแก้เล็กน้อย” นี่คือไม่ได้จ่ายค่า Claude เหรอ?

  • ในที่นี้ “ฟรี, ไม่อั้น, ไม่บ่น” น่าจะหมายถึงเวลาทำงานกับโปรเจกต์ของบุคคลที่สามหรือฟรีแลนซ์ดีไซเนอร์ ที่ปกติราคาจะรวม “ร่างแรก + แก้ 1 รอบ” และหลังจากนั้นทุกการเปลี่ยนแปลงจะมีค่าใช้จ่ายเพิ่ม
    สตูดิโอดีไซน์เล็ก ๆ ก็คล้ายกัน และบ่อยครั้งก็ไม่ได้คิดรายชั่วโมงแบบนักพัฒนา
  • ในปี 2025 กำไรสุทธิ ต่อพนักงานของ Jane Street อยู่ระดับหลายล้านดอลลาร์ต่อคน โดยนับจากกำไร ไม่ใช่รายได้
  • น่าจะหมายถึง อิสระ ในการสร้างสรรค์โดยไม่ต้องใช้แรงคน มากกว่าจะหมายถึงราคาว่าฟรี
  • พอจะเกี่ยวกันนิดหน่อย ฉันเคยสัมภาษณ์งานที่มี CEO, หัวหน้านักพัฒนา และหัวหน้านักออกแบบนั่งอยู่ แล้วโดนถามคำถามคลาสสิกว่า “จุดอ่อนของคุณคืออะไร”
    ฉันตอบตรง ๆ ว่าฉันออกแบบได้แย่มาก และยังมีปัญหาในการต่อยอดจาก design system ด้วย
    มันยากมากที่จะไปให้ถึงจุดที่ดูโอเค และระหว่างทางเกือบตลอดก็ทำให้มันแย่ลง
    นักออกแบบที่สัมภาษณ์อยู่กลับรับเรื่องนี้เป็นการส่วนตัวแล้วไล่บี้ฉัน
    ก่อนหน้านั้นก็เคยเจอคล้ายกัน
    นักออกแบบไม่ชอบการถูกถามไม่หยุดว่ามันควรหน้าตาเป็นอย่างไร และอยากส่งต่องานแบบครั้งเดียวจบ
    แม้แต่ในเอเจนซีการตลาดและโฆษณา ฉันก็ต้องสู้ตลอดเพื่อขอตัวอย่างว่าของที่ไม่ได้อยู่ในสเปกดีไซน์ควรหน้าตาเป็นอย่างไร
    ไม่ได้บอกว่าฉันถูก แต่สำหรับฉันนี่เป็น จุดตาย ใหญ่เลย
    ดังนั้นพอได้ยินคำว่า “ฟรี, ไม่อั้น, ไม่บ่น” สิ่งที่ฉันนึกถึงก่อนเงินคือเวลาและความอดทน
    Bolt ที่ฉันใช้ทำ prototype ไม่เคยโกรธ
    มันอาจไม่ได้สร้างดีไซน์ที่ดีที่สุด แต่ก็ดีกว่าสิ่งที่ฉันทำเองได้มาก และพอเสร็จแล้วค่อยให้ดีไซเนอร์ตัวจริงทำให้ดีขึ้นอีกก็ได้
    ก่อนถึงจุดนั้นฉันก็ไม่ต้องกังวลว่าจะทำให้ใครโมโห

• เคยใช้ Claude Design กับงานฟรอนต์เอนด์
  หน้าตาและความรู้สึกของผลลัพธ์ออกมาดีพอใช้ แต่ดีไซน์มักดูคล้าย ๆ กันบ่อย และโดยรวมก็ตาม แพตเทิร์นสูตรสำเร็จ ของเว็บสมัยใหม่
  เลยสงสัยว่ามีใครเคยใช้มันลองทำอะไรที่สร้างสรรค์แบบไม่เป็นขนบบ้างไหม

  • ช่วยดูเว็บพอร์ตของผมหน่อย ดูบนเดสก์ท็อปจะดีกว่า
    ตอนนี้ใช้เวลาไปประมาณ 3 สัปดาห์แล้วและยังไม่เสร็จ แต่ก็น่าจะพอเห็นภาพ
    เหมือนที่ตลอด 10 ปีที่ผ่านมาเรามี SaaS boilerplate ตอนนี้ก็มี LLM boilerplate ที่เรียนรู้มาจากอินเทอร์เน็ตเหมือนกัน
    ถึงอย่างนั้นถ้าลงมือปรับแต่งมากพอ ก็ยังทำอะไรก็ได้อยู่ดี
  • ผมก็มีประสบการณ์แบบนั้นเหมือนกัน เลยเริ่มทดสอบพรอมป์ต์และอินพุตแบบอื่น ๆ
    มันน่าสนใจตรงที่ถ้าให้ข้อกำหนด มันจะทำตามได้ แต่ถ้าไม่ให้ทิศทาง มันจะเลือกทางที่ปลอดภัย
    ถ้าคุณจะประเมินทั้งสุนทรียะของผลลัพธ์และประสบการณ์ผู้ใช้·คอนเทนต์ แต่แทบไม่ให้พรอมป์ต์ด้านสุนทรียะเลย สุดท้ายก็จะได้แค่ค่าเริ่มต้นแบบปลอดภัย
    มันทำดีไซน์แนวสำเนา bootstrap/tailwind ได้เก่ง แต่ต้องตั้งใจผลักให้พ้นจากจุดนั้น
    สำหรับเว็บเพจเรียบ ๆ ตอนนี้ผมเริ่มให้ สไตล์ภาพลักษณ์ เป็นจุดโฟกัสเดียวของการวนทำซ้ำช่วงแรก
  • แอปส่วนใหญ่ไม่ได้ต้องการความสร้างสรรค์แบบนอกขนบ
  • ผมก็คล้าย ๆ กัน
    แค่สั่งให้ชัดเจนว่าอยากให้ดูไม่มาตรฐาน และยกตัวอย่างสไตล์เว็บไซต์ที่ต้องการก็พอ
    ถ้าขลุกอยู่กับมันสักหน่อยก็จะรู้สึกสร้างสรรค์ขึ้นอีกนิด แต่ก็ต้องทำ งานพรอมป์ต์
  • ผมก็ใช้ Claude Design
    นักออกแบบที่ได้รับความเคารพมากและมีประสบการณ์สูงหลายคนแนะนำมันให้ผม และตอนนี้พวกเขาก็แทบจะทำต้นแบบใน Claude เกือบทั้งหมด แล้วถ้าชอบค่อยไปเก็บรายละเอียดใน Figma
    ถ้าตั้งแต่แรกขอ UI ทั่วไปโดยไม่ให้พรอมป์ต์เรื่องสไตล์แบบละเอียด ก็เป็นเรื่องธรรมดาที่จะได้ ดีไซน์ทั่วไป ออกมา

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

  • ผมทำงานมา 6 ปีในฐานะวิศวกรสายฟูลสแต็กและเน้นฟรอนต์เอนด์ ก่อนจะเบื่อการเขียนโค้ดด้วยมือแล้วหันไปทางดีไซน์
    ตอนนี้แทบจะเขียนโค้ดด้วยเสียงได้แล้ว ผมเลยกลับมาสู่ vibe coding และการสร้างผลิตภัณฑ์อีกครั้ง ซึ่งดีมากจริง ๆ
    หัวหน้าของผมยังคงพยายามทำความเข้าใจสถานการณ์ใหม่นี้อยู่ แต่ดูเหมือนว่าการแบ่งบทบาทแบบเก่ากำลังเริ่มตายไป
    ผมคิดว่าการอยู่ตรงจุดตัดของสองฝั่งคือจุดที่ดีที่สุดในตอนนี้
    รู้สึกเหมือนทั้งชีวิตผมเตรียมพร้อมมาเพื่อช่วงเวลานี้
  • การเข้าใจข้อจำกัดของสื่อนั้นช่วยได้ แต่ก็ไม่จำเป็นต้องรู้ทุกชั้นจนถึงระดับที่อิเล็กตรอนวิ่งอยู่ในซิลิคอน
  • ปกติแล้ว LLM มักทำให้คุณลืมการเขียนโค้ดไปเลย ดังนั้นถ้าใช้แบบนี้ ผมก็สงสัยว่าจะดีต่อการเรียนรู้จริงไหม
    สำหรับนักออกแบบ มันน่าจะคล้าย Figma ที่ดูผลลัพธ์แล้วแก้ไขด้วยภาษาแทนการใช้ตัวแก้ไขแบบภาพ
  • นี่ไม่ใช่ว่านักออกแบบกำลังเรียนโค้ด
    ภรรยาของผมเป็นผู้จัดการผลิตภัณฑ์ที่ FAANG และทีมของเธอกำลังพึ่งพา AI อย่างมากเพื่อ vibe coding ชิ้นส่วนซอฟต์แวร์ที่แต่เดิมคงทำกันด้วย Word หรือ Excel
    พวกเขาไม่ได้เรียนโค้ด และไม่เคยมองโค้ดเลยแม้แต่วินาทีเดียว
  • ต้องการนักออกแบบที่เคยทำงานใกล้ชิดกับวิศวกรและมีวิจารณญาณที่มั่นคง

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

  • บทความนั้นไม่ได้เขียนโดยคนที่หาเลี้ยงชีพด้วย Figma
    เวลาจัดการประเด็นเฉพาะของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง มันเรียกว่า “เอกสารข้อเสนอ” ได้ง่าย
    แต่ก็ยังมีนักออกแบบจำนวนมากที่ใช้ Figma เพื่อกำหนดและดูแล design system ครอบคลุมทั้งผลิตภัณฑ์และแพลตฟอร์ม และในกรณีนั้น Figma คือแหล่งข้อมูลจริงหลัก

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

  • ผมก็อยู่ในสถานการณ์คล้ายกัน
    ฝั่งดีไซน์และโปรดักต์ใช้ Claude มาช่วย vibe ออกแบบ·เขียนโค้ดฟีเจอร์หรือประสบการณ์ และทำต้นแบบได้เร็ว เพื่อนำไปให้ลูกค้าเห็นและรับฟีดแบ็กโดยใช้เวลาวิศวกรรมให้น้อยที่สุด
    ยอดเยี่ยมมาก
    แต่สิ่งที่อาจน่าแปลกใจก็คือ โดยรวมแล้วมันไม่ได้ช่วยให้ปล่อยของได้เร็วขึ้นมากนัก
    ผมคิดว่าเป็นเพราะเราสูญเสีย การคิด ไปในกระบวนการ
    การคิดจำนวนไม่น้อยตอนนี้ถูกเอาต์ซอร์ซให้โมเดลภาษา
    มันคอยฉาบกลบช่องว่างในพรอมป์ต์ และเติมพฤติกรรมที่ไม่ได้ระบุไว้ด้วยภาพหลอน
    สิ่งที่เมื่อก่อนเราจะหยุดคิดอย่าง “อันนี้ไม่ค่อยเข้ากัน”, “จะสื่อไอเดียนี้ยังไงดี”, “กรณีนี้จะเกิดอะไรขึ้น” หายไปหมด และรายละเอียดพวกนั้นก็ถูกเลื่อนไปหลังจากสร้างเสร็จแล้ว
    แน่นอนว่าเรายังปรับปรุงกระบวนการและทบทวนวิธีใช้เทคนิคใหม่นี้ให้ดีขึ้นได้ แต่ถ้าถามว่าดีกว่าเมื่อก่อนหรือเปล่า ผมก็ไม่แน่ใจ
  • จะให้ Claude Design เขียนเอกสารที่ระบุสเปกของต้นแบบอย่างครบถ้วนไปเลยไม่ได้หรือ?
  • วิธีแบบเก่านั้นเทอะทะ วงจรฟีดแบ็กยาว และทำตัวเป็นผู้เฝ้าประตูของ UI
    กำลังเสื่อมความนิยม
    ตอนนี้คนแบ็กเอนด์ก็ทำฟรอนต์เอนด์กันแล้ว
  • ตอนนี้โค้ดไม่ได้ถูกสร้างมาให้อ่านอีกต่อไป
    นั่นเป็นความเข้าใจผิด
    คุณไปไล่ดูแอสเซมบลีที่คอมไพเลอร์สร้างขึ้นไหม? ไม่ดู
    แล้วทำไมถึงต้องมานั่งดูโค้ดนี้ด้วยล่ะ?
    เราแค่ยกระดับ ชั้นนามธรรม ขึ้นไปอีกขั้น

• ฉันก็ใช้แนวทางแบบเดียวกันบ่อยมาก
  แม้แต่ก่อนมี AI ก็ทำแบบนี้ด้วยมืออยู่แล้ว
  เริ่มจากนั่งกับผู้ใช้โดยมีแค่ปากกาและกระดาษ จากนั้นก็ทำ POC หรือเดโมฝั่งฟรอนต์เอนด์อย่างรวดเร็ว ให้ผู้ใช้ได้ลองจับลองใช้ แล้วปรับไปเรื่อย ๆ จนกว่าจะทำงานได้ตามที่ต้องการ
  สำหรับฉัน การทำเดโมฟรอนต์เอนด์แบบเร็ว ๆ ด้วยโค้ดโดยไม่เน้นคุณภาพระดับ production มักจะเร็วกว่าการสร้างปฏิสัมพันธ์ที่แม่นยำใน Figma อยู่แล้ว
  เพราะสามารถโต้ตอบได้อย่างสมบูรณ์ จึงจับกรณีขอบเขตด้านประสบการณ์ผู้ใช้ได้มากกว่ามาก
  ตอนนี้ด้วย Claude Code ความเร็วในการสร้างต้นแบบที่ทำมาเพื่อทิ้งก็เร็วขึ้นอีก แต่ก็ไม่ถึงกับต่างมหาศาล
  เพราะ 80% ของงานทั้งหมดคือเวลาที่ใช้คุยกับผู้ใช้และคิดว่ามันควรทำงานอย่างไร ดังนั้น Claude จึงช่วยลดอีก 20% ที่เหลือลงได้ประมาณครึ่งหนึ่งเมื่อเทียบกับการลงมือทำเองอย่างรวดเร็ว
  เวอร์ชันแรกออกมาเร็วขึ้น แต่ถ้ายังเข้าใจไม่ครบ การวนซ้ำกลับช้าลง

• Edwin, ดีใจที่เห็นคุณโพสต์บทความนี้
  จำได้ว่าเราเคยทำแฮ็กกาธอนด้วยกันราว ๆ ปี 2012/2013
  ความสามารถในการไปถึงต้นแบบที่ใช้งานได้เร็วขึ้นนั้นทรงพลังมาก แม้ว่าจะมีแรงยั่วใจให้นำไอเดียที่ยังไม่สมบูรณ์ไปปล่อยใช้งานตรง ๆ ก็ตาม
  ข้อกำหนดด้านการออกแบบและประสบการณ์ผู้ใช้จะได้ประโยชน์อย่างมากเมื่อก้าวข้ามสตอรีบอร์ดและไวร์เฟรม ไปสู่การได้ลองแตะและสัมผัสโฟลว์จริง