ตอนนี้ฉันออกแบบด้วย Claude มากกว่า Figma แล้ว
(blog.janestreet.com)- เปลี่ยนจากเวิร์กโฟลว์การออกแบบที่ใช้เอกสารสเปกและ mockup ใน Figma มาเป็นการสร้าง ฟีเจอร์ต้นแบบ ที่ใช้งานได้จริงจากไอเดียในหัวโดยตรง
- เดิมเคยสงสัยใน LLM อย่าง Copilot, Cursor, Gemini แต่หลังเข้าร่วม Jane Street ก็รู้สึกได้ว่า การมี AI ช่วยเป็นสิ่งจำเป็น
- Claude อนุญาตให้ทำซ้ำได้ฟรีและแทบไม่จำกัด ต่อให้เปลี่ยนใจ 50 ครั้งก็ไม่บ่น ทำให้ปรับรายละเอียดอย่าง ปุ่ม Submit, คีย์ลัด, ข้อความประกอบ ได้สะดวก
- แม้นักออกแบบก็สามารถสร้าง proof of concept (POC) ที่ทำงานได้จริง ได้ด้วยตัวเองเหมือนวิศวกร เพื่อให้คนอื่นลองใช้และประเมินได้โดยตรง
- วิธีนี้นำไปสู่ โมเดลการทำงานร่วมกันแบบใหม่ ที่ตัดงานประกอบระหว่างทางออกไป และทุ่มความพยายามทั้งหมดให้กับผลลัพธ์จริง
เปลี่ยนจากความสงสัยใน LLM
- เคยสงสัยใน LLM มานาน และผิดหวังกับผลลัพธ์แทบทุกครั้งที่ใช้
- ปีที่แล้วลองใช้ Copilot และ Cursor เพื่อแก้เกมที่ทำเอง แต่ทั้งคู่ก็สร้างการเปลี่ยนแปลงที่ใช้งานได้จริงไม่ได้
- ที่ทำงานก่อนหน้าเคยใช้ Gemini ทำโครงร่าง product brief และ wireframe แต่สุดท้ายก็ทิ้งทั้งหมด
- สิ่งที่ลองใช้ LLM มักเป็นงานที่ตัวเองทำได้ดีอยู่แล้ว และผลลัพธ์ก็แย่กว่าทำเอง
- หลังเข้าร่วม Jane Street เมื่อฤดูร้อนที่ผ่านมา จึงรู้สึกว่าการมี AI ช่วยเป็นสิ่งจำเป็น
- เพราะมีหลายเรื่องใหม่และยังไม่ถนัด เช่น OCaml และ Bonsai
- สิ่งที่น่าประหลาดใจที่สุดคือ แม้แต่ เวิร์กโฟลว์การออกแบบ ซึ่งเป็นด้านที่ตัวเองถนัดที่สุดก็ยังเปลี่ยนไป
เวิร์กโฟลว์ที่ยึดต้นแบบเป็นศูนย์กลาง
- แทนที่จะเขียนเอกสารสเปก ทำ mockup ใน Figma เขียนข้อเสนอ หรือรีวิวการ implement กับนักพัฒนา ก็ลงมือสร้าง ฟีเจอร์ต้นแบบ ที่ทำสิ่งที่ตั้งใจไว้ได้จริงโดยตรง
-
ลำดับการทำงานจริง
- เขียนปัญหาและข้อเสนอเป็นข้อความ
- เปิด editor แล้วรัน build, server และ Claude โดยใช้คำอธิบายที่เขียนไว้เป็น prompt
- ทำให้ฟังก์ชันพื้นฐานใช้งานได้ก่อน เพื่อพิสูจน์ความเป็นไปได้
- วนซ้ำเท่าที่ต้องการ
- push การเปลี่ยนแปลงเข้า development environment แล้วรับฟังความเห็นจากผู้ใช้
- ส่ง feature ที่มีหน้าตาและพฤติกรรมตามที่ตั้งใจไว้ (คำนี้ในบริษัทนี้เทียบได้กับ pull request)
- ต้นแบบที่อยู่ใน codebase จริงดีกว่า mockup และเอกสารในแทบทุกด้าน
กรณีศึกษาต้นแบบ JSQL input
- ไม่นานมานี้ได้สร้างต้นแบบที่เพิ่มการทำ LLM prompting ให้กับ JSQL input
- JSQL คือ SQL dialect ภายในที่ใช้กับเครื่องมือสำหรับผู้ใช้หลายประเภท
- มันใช้งานได้จริง และได้ใช้ ทดสอบ และอยู่กับมันอยู่หลายวัน
- Claude เปิดให้ทำซ้ำได้ฟรีและแทบไม่จำกัด ต่อให้เปลี่ยนใจเป็นครั้งที่ 50 หรือขอแก้เล็กน้อยก็ไม่เป็นปัญหา
- ปรับ ปุ่ม Submit เพิ่มคีย์ลัด แก้ข้อความ ปรับ prompt เพิ่มข้อความยืนยันแบบ generative
- หากเป็นที่ทำงานก่อนหน้า การปรับปรุงเหล่านี้อาจต้องใช้การวนกลับไปมาระหว่างวิศวกรรมและการออกแบบหลายวันถึงหลายสัปดาห์ หรืออาจไม่เกิดขึ้นเลย
- ความพยายามทั้งหมดถูกใช้ไปกับการปรับปรุง ผลลัพธ์จริง ไม่ใช่งานประกอบอย่างการสร้างคอมโพเนนต์ใน Figma หรือจัดรูปแบบเอกสาร
กระบวนการที่เวิร์กโฟลว์นี้ลงตัว
- การมาถึงวิธีนี้ใช้เวลาอยู่พอสมควร
- ช่วงแรกหลังเข้าร่วม ใช้ AI แค่กับงานเล็ก ๆ อย่าง แก้บั๊กจุกจิกด้าน UX
- สำหรับไอเดียที่ใหญ่กว่านั้นก็ยังใช้ Figma และเอกสารเหมือนเดิม และถ้าลองทำด้วย Claude ก็มักล้มเหลว
- ในช่วงสองเดือนที่ผ่านมา สถานการณ์ที่ต้องเอื้อมมือไปหา Figma ลดลงอย่างมาก
- จากการผสมกันของการพัฒนาโมเดล ความชำนาญของตัวเอง และการเลือกขอบเขตงานที่เหมาะสม ทำให้ AI ใช้กับงานใหญ่ได้ด้วย
- นอกจาก JSQL prompt แล้ว ยังมีต้นแบบอีกหลายชิ้นที่เกี่ยวกับเครื่องมือสำหรับผู้ใช้ data model และการเปลี่ยนแปลงไลบรารี ซึ่งบางชิ้นมี diff มากกว่า 2000 บรรทัด
- บางครั้งออกแบบใน Figma ก่อนแล้วค่อย implement เป็นต้นแบบแบบ interactive หรือในบางแอปใหม่ก็ข้าม Figma ไปเลย แล้ววนซ้ำงาน visual design ด้วย Claude ตั้งแต่ต้น
พลังที่มอบให้กับนักออกแบบ
- วิศวกรเมื่อมีไอเดียก็สร้าง proof of concept ที่ใช้งานได้เองโดยตรง แต่ฝั่งนักออกแบบมักต้องโน้มน้าวคนอื่น
- ไอเดียอย่าง "การทำ LLM prompting โดยตรงใน JSQL input" ตอนเริ่มต้นนั้นแม้แต่ความเป็นไปได้ก็ยังไม่ชัดเจน หากขอให้ใครสักคนทำต้นแบบให้ก็อาจกลายเป็นการเสียเวลา
- และมันอาจเป็นข้อเสนอที่ไม่ได้ตอบโจทย์ความต้องการของผู้ใช้อย่างชัดเจนด้วย
- เมื่อใช้ Claude ทำให้ไอเดียเกิดขึ้นจริง คนอื่นก็ประเมินได้ง่ายขึ้นมากเพราะลองใช้ได้ด้วยตัวเอง
โจทย์ของวิธีรีวิว
- ข้อเสียคือ reviewer จะได้รับ ฟีเจอร์ที่เสร็จแล้ว
- จึงเกิดคำถามว่าเขาจะได้มีส่วนร่วมกับตัวฟีเจอร์จริง ๆ หรือแค่ตรวจโค้ด
- คล้ายกับในงานออกแบบที่ PM ให้ wireframe ที่ละเอียดมากมาแล้วบอกให้ "ทำให้มันดูดีอย่างเดียว"
- ฝั่งข้อเสนอจึงควรพยายามทำให้ชัดเจนและครบถ้วนที่สุด แต่ก็ยังอยากให้เพื่อนวิศวกร ช่วยวนซ้ำในพื้นที่การออกแบบ ร่วมกันเหมือนตอนดู mockup ใน Figma
-
วิธีแก้ในตอนนี้
- มองฟีเจอร์ในอีกแบบหนึ่ง และเขียนคำแนะนำสั้น ๆ ประกอบคำอธิบาย
- ต้นแบบคือ เอกสารข้อเสนอที่มีชีวิต, โค้ดเป็นของใช้ชั่วคราว และบทบาทของ reviewer คือให้ feedback เรื่องการออกแบบและประสบการณ์ผู้ใช้
- สุดท้าย reviewer จะรับช่วงไอเดียไป implement ใน feature แยกต่างหาก โดยอ้างอิงต้นแบบ แต่ เป็นเจ้าของ production code เองโดยตรง
- อะไรที่สมเหตุสมผลและให้ความรู้สึกที่ดีนั้นยังอยู่ระหว่างการค้นหา
ความกังวลและความตึงเครียดที่คุ้นเคย
- มีความกลัวว่าการออกแบบด้วย Claude อาจทำให้หลุดออกจากการคิดที่ยืดหยุ่นและสร้างสรรค์ แล้วติดอยู่กับ การคิดแบบวนซ้ำ ที่จำกัดอยู่ในผลลัพธ์ซึ่งเชื่อว่า Claude สร้างได้
- สิ่งนี้อาจใช้ได้ดีกับเครื่องมือที่โตเต็มที่และเปลี่ยนแปลงแบบค่อยเป็นค่อยไป แต่เมื่อทำสิ่งใหม่จริง ๆ ก็อาจทำให้พลาดไอเดียบางอย่าง
- นี่เป็นความตึงเครียดที่คุ้นเคย และเชื่อมโยงกับบทถกเถียงในปี 2011 เรื่อง "นักออกแบบควรเขียนโค้ดหรือไม่"
- ผู้วิจารณ์ในเวลานั้นมองว่าเมื่อเริ่มเขียนโปรแกรมแล้ว จะเปลี่ยนไอเดียครั้งใหญ่ได้ยากขึ้น
- แต่เพราะชอบทั้งการทำเว็บไซต์และการเขียนโปรแกรม จึงยังเขียนโค้ดต่อไป
- เมื่อเฟรมเวิร์กฝั่งฟรอนต์เอนด์อย่าง React กลายเป็นเรื่องทั่วไป และงานพัฒนาซับซ้อนขึ้น จึงเลือกเดินสู่ความเชี่ยวชาญเฉพาะทาง
- โปรเจกต์ส่วนตัวยังคงทำด้วย React และมันช่วยให้สื่อสารกับนักพัฒนาได้ดีขึ้น
- แต่เวลางานส่วนใหญ่ก็ถูกใช้ไปกับ Figma และเอกสาร
- หากเข้าร่วม Jane Street ก่อนยุค LLM ก็น่าจะจมลึกกับ Figma มากกว่านี้
- แม้จะมีประสบการณ์กับ JavaScript อยู่บ้าง แต่ OCaml และ Bonsai เป็นของใหม่ทั้งหมด จึงอาจรู้สึกว่าการมีส่วนร่วมเชิงเทคนิคอยู่ไกลเกินเอื้อม
- แต่ตอนนี้กลับได้มาสร้างผลลัพธ์จริงอีกครั้ง รู้สึกว่าการได้กลับสู่สื่อนั้นเป็นเรื่องน่าตื่นเต้น และรับรู้ถึงอิสระที่มากขึ้นในการลองทำอะไรก็ได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ฝั่งธุรกิจมักเอา ทางแก้ ที่ตัวเองคิดขึ้นมาแล้วมาเสนอราวกับเป็นข้อกำหนด และส่วนใหญ่ก็เป็นอะไรคล้ายเครื่อง Rube Goldberg จนต้องคุยกันเพื่อทำ reverse engineer ถึงจะไปถึงความต้องการที่แท้จริงได้
ต่อจากนี้น่าจะยิ่งเอาทางแก้ที่ “พร้อมแล้ว” และ “ใช้งานได้” มาให้ดู และจะยิ่งไม่เปิดรับการคุยเรื่องการออกแบบและสถาปัตยกรรมในภาพรวม
น่าจะกลายเป็นแนว “ก็สร้างแบบนี้ก็จบไม่ใช่เหรอ เกือบเสร็จแล้วทำไมยังต้องใช้เวลา X คน-ชั่วโมงอีก?”
ข้อเสียคือฝั่งธุรกิจไม่เข้าใจว่าทำไมเอาแอปนั้นขึ้น production ตรง ๆ ไม่ได้
แรงกดดันแบบ “AI ทำให้ไปได้เร็วขึ้นนี่” จะยิ่งมากขึ้น และสุดท้ายคงขึ้นอยู่กับพลวัตองค์กรที่ดีหรือไม่ดี
ข้อดีคือไอเดียถูกตรวจสอบละเอียดกว่าการสเก็ตช์บนกระดาษแนปกิ้นมาก
Claude น่าจะถามถึงกรณีขอบเขตและการตัดสินใจด้านการออกแบบไปแล้ว และมีโอกาสสูงว่าถึงจุดหนึ่งจะมีการระบุชัดว่า “อย่าไปสนใจส่วนนั้น ให้สมมติไปก่อน” หรือ “ลองใช้มาสองสามครั้งแล้ว interaction แบบนี้ไม่เวิร์ก เปลี่ยนให้หน่อย”
ตอนนี้แรงกดดันแบบ “มีปัญหาอะไร ก็ deploy ไปสิ” ยังแรง โง่ และบั่นทอนกำลังใจ จนแทบเป็นผลเสียล้วน ๆ แต่ถ้ามันนิ่งขึ้นแล้วก็อาจกลายเป็นผลดีสุทธิสำหรับโปรเจกต์ในอนาคต
โดย การแก้เล็กน้อย นั้นคือพวกปัญหาเลย์เอาต์พังถ้าหน้ากว้างเบราว์เซอร์ไม่ใช่ 1920px พอดี, ฟิลเตอร์กับการเรียงลำดับที่บางครั้งทำงานไม่ถูกต้อง, หรือค่าที่เปลี่ยนแล้วไม่อัปเดตในแอปอย่างถูกต้องหลังจากบาง action
ไม่ว่าปัญหาจะเป็นอะไร ฝั่งธุรกิจก็มักคิดว่าตัวเองทำไปแล้ว 95% และประเมินล่วงหน้าว่า “ถ้าเป็นนักพัฒนาฝีมือดีคงแก้ได้แป๊บเดียว”
ผู้คนจะคุ้นกับผลลัพธ์ที่ตัวเองมีอยู่ แล้วรับการเปลี่ยนแปลงในมิกซ์ใหม่จากมืออาชีพได้ยากขึ้น
แม้จะมี PM, CSM, TAM ที่มีเซนส์ในการแปลปัญหาลูกค้าให้เป็นฟีเจอร์ผลิตภัณฑ์ที่ใช้งานง่าย แต่ถ้าข้ามขั้นการนิยามปัญหาไป แล้วปล่อยให้องค์กรฟังก์ชันอื่นไปสร้างทางแก้ ก็มักกลายเป็นหายนะที่สิ้นเปลืองทั้งวิศวกรรมและทรัพยากรอื่นอย่างมาก
ถ้ามีใครเอาทางแก้มาให้ ก็เสี่ยงมากที่จะใช้เวลาหลายเดือนสร้างซอฟต์แวร์ที่ deploy ใช้งานจริงได้ แล้วค่อยพบว่าลูกค้าไม่ชอบ มันแก้ปัญหาไม่ได้ หรือสร้างปัญหาใหม่ขึ้นมา
ไม่ใช่ที่ที่ฉันทำงานอยู่ตอนนี้ แต่เป็นที่เก่า และมันถูกเอาขึ้น production ทั้งที่มีปัญหา ข้อมูลสูญหาย และปัญหาความปลอดภัย
เท่าที่รู้ Jane Street เป็นนักลงทุนของ Anthropic ดังนั้นก็ควรคำนึงถึงจุดนั้นด้วย
ยังมีเรื่องที่ในเดือนกรกฎาคม 2025 หน่วยงานกำกับหลักทรัพย์อินเดีย SEBI กล่าวหาว่า Jane Street ใช้นิติบุคคลหลายแห่งในการ ปั่นตลาด และสั่งห้ามเข้าถึงตลาดด้วย
ถ้ามีถุงเงินก้อนใหญ่ ก็คงต้องมีแดชบอร์ดเยอะอยู่แล้ว
ในกรณีนี้นักออกแบบดูเหมือนกำลังใช้วิธีที่ผิด และเหมือนตกอยู่ในภาวะ หลงใหลความเป็นวิศวกร ที่อยากทำ prototype ให้ลึกและสมจริงที่สุด
แต่นั่นไม่ใช่ส่วนที่สำคัญที่สุดของงานออกแบบ
สิ่งที่สำคัญที่สุดคือการสร้างสิ่งที่ถูกต้อง
คำถามอย่าง “ทำไมต้องมีช่องกรอก JSQL? จริง ๆ แล้วต้องการอะไร? มีวิธีอื่นไหม?” มักแก้ได้ดีกว่าด้วยการสเก็ตช์ปากกากับกระดาษ การประชุม การสังเกต และการถกเถียง
ดีกว่าการตีกรอบแคบเร็วเกินไปไปยังดีไซน์แบบใดแบบหนึ่ง แล้วจมอยู่กับการคุยว่าปุ่มควรอยู่ซ้ายหรือขวา หรือรายละเอียดการทำงานของ LLM ควรเป็นแบบไหน
แน่นอนว่านั่นอาจเป็นสิ่งที่พวกเขาอยากให้คุณคิดพอดีก็ได้
บางทีก็เห็นแบบนี้
ตอนนี้ LLM ยังมองไม่พ้นการทำซ้ำแบบเดิม ๆ ดังนั้นฉันต้องเป็นคนคิดนอกกรอบแล้วถามว่า “ถ้ามองจากมุมนี้ล่ะ?” ถึงจะเกิดแนวทางการออกแบบใหม่ขึ้นมาแบบฉับพลัน
บางครั้งต้องทำ flowchart เพื่อช่วยให้ LLM มองเลยขั้นตอนปัจจุบันของตัวเองไปได้
จากประโยคที่ว่า “Claude ให้การทำซ้ำฟรีไม่อั้นและไม่บ่น แม้ว่าฉันจะเปลี่ยนใจเป็นครั้งที่ 50 หรือขอแก้เล็กน้อย” นี่คือไม่ได้จ่ายค่า Claude เหรอ?
สตูดิโอดีไซน์เล็ก ๆ ก็คล้ายกัน และบ่อยครั้งก็ไม่ได้คิดรายชั่วโมงแบบนักพัฒนา
ฉันตอบตรง ๆ ว่าฉันออกแบบได้แย่มาก และยังมีปัญหาในการต่อยอดจาก design system ด้วย
มันยากมากที่จะไปให้ถึงจุดที่ดูโอเค และระหว่างทางเกือบตลอดก็ทำให้มันแย่ลง
นักออกแบบที่สัมภาษณ์อยู่กลับรับเรื่องนี้เป็นการส่วนตัวแล้วไล่บี้ฉัน
ก่อนหน้านั้นก็เคยเจอคล้ายกัน
นักออกแบบไม่ชอบการถูกถามไม่หยุดว่ามันควรหน้าตาเป็นอย่างไร และอยากส่งต่องานแบบครั้งเดียวจบ
แม้แต่ในเอเจนซีการตลาดและโฆษณา ฉันก็ต้องสู้ตลอดเพื่อขอตัวอย่างว่าของที่ไม่ได้อยู่ในสเปกดีไซน์ควรหน้าตาเป็นอย่างไร
ไม่ได้บอกว่าฉันถูก แต่สำหรับฉันนี่เป็น จุดตาย ใหญ่เลย
ดังนั้นพอได้ยินคำว่า “ฟรี, ไม่อั้น, ไม่บ่น” สิ่งที่ฉันนึกถึงก่อนเงินคือเวลาและความอดทน
Bolt ที่ฉันใช้ทำ prototype ไม่เคยโกรธ
มันอาจไม่ได้สร้างดีไซน์ที่ดีที่สุด แต่ก็ดีกว่าสิ่งที่ฉันทำเองได้มาก และพอเสร็จแล้วค่อยให้ดีไซเนอร์ตัวจริงทำให้ดีขึ้นอีกก็ได้
ก่อนถึงจุดนั้นฉันก็ไม่ต้องกังวลว่าจะทำให้ใครโมโห
เคยใช้ Claude Design กับงานฟรอนต์เอนด์
หน้าตาและความรู้สึกของผลลัพธ์ออกมาดีพอใช้ แต่ดีไซน์มักดูคล้าย ๆ กันบ่อย และโดยรวมก็ตาม แพตเทิร์นสูตรสำเร็จ ของเว็บสมัยใหม่
เลยสงสัยว่ามีใครเคยใช้มันลองทำอะไรที่สร้างสรรค์แบบไม่เป็นขนบบ้างไหม
ตอนนี้ใช้เวลาไปประมาณ 3 สัปดาห์แล้วและยังไม่เสร็จ แต่ก็น่าจะพอเห็นภาพ
เหมือนที่ตลอด 10 ปีที่ผ่านมาเรามี SaaS boilerplate ตอนนี้ก็มี LLM boilerplate ที่เรียนรู้มาจากอินเทอร์เน็ตเหมือนกัน
ถึงอย่างนั้นถ้าลงมือปรับแต่งมากพอ ก็ยังทำอะไรก็ได้อยู่ดี
มันน่าสนใจตรงที่ถ้าให้ข้อกำหนด มันจะทำตามได้ แต่ถ้าไม่ให้ทิศทาง มันจะเลือกทางที่ปลอดภัย
ถ้าคุณจะประเมินทั้งสุนทรียะของผลลัพธ์และประสบการณ์ผู้ใช้·คอนเทนต์ แต่แทบไม่ให้พรอมป์ต์ด้านสุนทรียะเลย สุดท้ายก็จะได้แค่ค่าเริ่มต้นแบบปลอดภัย
มันทำดีไซน์แนวสำเนา bootstrap/tailwind ได้เก่ง แต่ต้องตั้งใจผลักให้พ้นจากจุดนั้น
สำหรับเว็บเพจเรียบ ๆ ตอนนี้ผมเริ่มให้ สไตล์ภาพลักษณ์ เป็นจุดโฟกัสเดียวของการวนทำซ้ำช่วงแรก
แค่สั่งให้ชัดเจนว่าอยากให้ดูไม่มาตรฐาน และยกตัวอย่างสไตล์เว็บไซต์ที่ต้องการก็พอ
ถ้าขลุกอยู่กับมันสักหน่อยก็จะรู้สึกสร้างสรรค์ขึ้นอีกนิด แต่ก็ต้องทำ งานพรอมป์ต์
นักออกแบบที่ได้รับความเคารพมากและมีประสบการณ์สูงหลายคนแนะนำมันให้ผม และตอนนี้พวกเขาก็แทบจะทำต้นแบบใน Claude เกือบทั้งหมด แล้วถ้าชอบค่อยไปเก็บรายละเอียดใน Figma
ถ้าตั้งแต่แรกขอ UI ทั่วไปโดยไม่ให้พรอมป์ต์เรื่องสไตล์แบบละเอียด ก็เป็นเรื่องธรรมดาที่จะได้ ดีไซน์ทั่วไป ออกมา
ข้อดีตรงนี้คือทำให้นักออกแบบได้เรียนรู้การเขียนโค้ด
ผมรู้สึกแปลกมาตลอดที่นักออกแบบมาช่วยกำหนดซอฟต์แวร์ทั้งที่ไม่รู้ว่าซอฟต์แวร์ถูกสร้างขึ้นอย่างไร
อนึ่ง ผมเองก็เป็นนักออกแบบ
เพียงแต่ว่าการออกแบบด้วยโค้ดเป็นแนวทางแบบ เทคโนโลยีนำหน้า
ถ้ามองว่าเป้าหมายของการออกแบบคือการหล่อหลอมผลลัพธ์ให้สอดคล้องกับเป้าหมายของมนุษย์ ก็อาจมองได้ว่าการไม่เริ่มจากกฎอันเข้มงวดของโค้ดจะดีกว่า
ไม่ใช่เพราะมันให้ผลลัพธ์ที่ดูสวยกว่า แต่เพราะในแง่การผลักความคิดไปข้างหน้า ปากกากับกระดาษก็ยังเอาชนะได้ยาก
ตอนนี้แทบจะเขียนโค้ดด้วยเสียงได้แล้ว ผมเลยกลับมาสู่ vibe coding และการสร้างผลิตภัณฑ์อีกครั้ง ซึ่งดีมากจริง ๆ
หัวหน้าของผมยังคงพยายามทำความเข้าใจสถานการณ์ใหม่นี้อยู่ แต่ดูเหมือนว่าการแบ่งบทบาทแบบเก่ากำลังเริ่มตายไป
ผมคิดว่าการอยู่ตรงจุดตัดของสองฝั่งคือจุดที่ดีที่สุดในตอนนี้
รู้สึกเหมือนทั้งชีวิตผมเตรียมพร้อมมาเพื่อช่วงเวลานี้
สำหรับนักออกแบบ มันน่าจะคล้าย Figma ที่ดูผลลัพธ์แล้วแก้ไขด้วยภาษาแทนการใช้ตัวแก้ไขแบบภาพ
ภรรยาของผมเป็นผู้จัดการผลิตภัณฑ์ที่ FAANG และทีมของเธอกำลังพึ่งพา AI อย่างมากเพื่อ vibe coding ชิ้นส่วนซอฟต์แวร์ที่แต่เดิมคงทำกันด้วย Word หรือ Excel
พวกเขาไม่ได้เรียนโค้ด และไม่เคยมองโค้ดเลยแม้แต่วินาทีเดียว
แนวทางที่ว่า “ต้นแบบคือเอกสารข้อเสนอที่มีชีวิต ทิ้งโค้ดได้ และหน้าที่ของผู้รีวิวคือให้ฟีดแบ็กด้านการออกแบบและประสบการณ์ผู้ใช้
สุดท้ายผู้รีวิวจะรับช่วงไอเดียนั้นไปแล้วนำไปทำเป็นฟีเจอร์แยกต่างหาก โดยดูต้นแบบเป็นข้อมูลอ้างอิง แต่เป็นเจ้าของโค้ดโปรดักชันด้วยตัวเอง” ช่วยแก้ปัญหาที่ผมเจอในทุก POC ได้
เป็นวิธีที่ดีมากจริง ๆ
เวลาจัดการประเด็นเฉพาะของผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง มันเรียกว่า “เอกสารข้อเสนอ” ได้ง่าย
แต่ก็ยังมีนักออกแบบจำนวนมากที่ใช้ Figma เพื่อกำหนดและดูแล design system ครอบคลุมทั้งผลิตภัณฑ์และแพลตฟอร์ม และในกรณีนั้น Figma คือแหล่งข้อมูลจริงหลัก
ทีมของเราก็ทำแบบนี้เหมือนกัน และผมเป็นวิศวกรฟรอนต์เอนด์ แต่พูดตามตรงว่าผมคิดถึง วิธีแบบเก่า มาก
พอข้อกำหนดที่เขียนไว้ถูกแทนที่ด้วยต้นแบบที่ทำงานได้ ตอนนี้ก็เกิดภาระทางความคิดเพิ่มขึ้น เพราะต้องอ่านโค้ดเพื่อแยกว่าอะไรคือการเปลี่ยนแปลงที่ตั้งใจไว้ และอะไรคือสัญญาณรบกวนที่ควรทิ้ง
ต้องรับ PR ที่ถูกสร้างขึ้นมาแล้วมาตัดสินใจว่าจะปรับต่อเฉพาะที่จำเป็น หรือจะสร้างใหม่ตั้งแต่ต้น ซึ่งไม่ว่าทางไหนก็มีแรงเสียดทาน
บางครั้งก็มีการเปลี่ยนแปลงที่ไม่ได้ตั้งใจถูกสร้างมาจำนวนมาก ผมเสียเวลาเขียนใหม่ย้ายมันเข้าไป แล้วภายหลังก็ได้ยินว่า “อ๊ะ ขอโทษครับ อันนั้นไม่ได้ตั้งใจจะเปลี่ยน”
ผมเข้าใจเรื่องการให้อำนาจมากขึ้นนะ แต่ก็ดึงเอาความสนุกส่วนหนึ่งจากงานแบบเดิมไป แล้วเปลี่ยนมันให้กลายเป็นเรื่องปวดหัว
ฝั่งดีไซน์และโปรดักต์ใช้ Claude มาช่วย vibe ออกแบบ·เขียนโค้ดฟีเจอร์หรือประสบการณ์ และทำต้นแบบได้เร็ว เพื่อนำไปให้ลูกค้าเห็นและรับฟีดแบ็กโดยใช้เวลาวิศวกรรมให้น้อยที่สุด
ยอดเยี่ยมมาก
แต่สิ่งที่อาจน่าแปลกใจก็คือ โดยรวมแล้วมันไม่ได้ช่วยให้ปล่อยของได้เร็วขึ้นมากนัก
ผมคิดว่าเป็นเพราะเราสูญเสีย การคิด ไปในกระบวนการ
การคิดจำนวนไม่น้อยตอนนี้ถูกเอาต์ซอร์ซให้โมเดลภาษา
มันคอยฉาบกลบช่องว่างในพรอมป์ต์ และเติมพฤติกรรมที่ไม่ได้ระบุไว้ด้วยภาพหลอน
สิ่งที่เมื่อก่อนเราจะหยุดคิดอย่าง “อันนี้ไม่ค่อยเข้ากัน”, “จะสื่อไอเดียนี้ยังไงดี”, “กรณีนี้จะเกิดอะไรขึ้น” หายไปหมด และรายละเอียดพวกนั้นก็ถูกเลื่อนไปหลังจากสร้างเสร็จแล้ว
แน่นอนว่าเรายังปรับปรุงกระบวนการและทบทวนวิธีใช้เทคนิคใหม่นี้ให้ดีขึ้นได้ แต่ถ้าถามว่าดีกว่าเมื่อก่อนหรือเปล่า ผมก็ไม่แน่ใจ
กำลังเสื่อมความนิยม
ตอนนี้คนแบ็กเอนด์ก็ทำฟรอนต์เอนด์กันแล้ว
นั่นเป็นความเข้าใจผิด
คุณไปไล่ดูแอสเซมบลีที่คอมไพเลอร์สร้างขึ้นไหม? ไม่ดู
แล้วทำไมถึงต้องมานั่งดูโค้ดนี้ด้วยล่ะ?
เราแค่ยกระดับ ชั้นนามธรรม ขึ้นไปอีกขั้น
ฉันก็ใช้แนวทางแบบเดียวกันบ่อยมาก
แม้แต่ก่อนมี AI ก็ทำแบบนี้ด้วยมืออยู่แล้ว
เริ่มจากนั่งกับผู้ใช้โดยมีแค่ปากกาและกระดาษ จากนั้นก็ทำ POC หรือเดโมฝั่งฟรอนต์เอนด์อย่างรวดเร็ว ให้ผู้ใช้ได้ลองจับลองใช้ แล้วปรับไปเรื่อย ๆ จนกว่าจะทำงานได้ตามที่ต้องการ
สำหรับฉัน การทำเดโมฟรอนต์เอนด์แบบเร็ว ๆ ด้วยโค้ดโดยไม่เน้นคุณภาพระดับ production มักจะเร็วกว่าการสร้างปฏิสัมพันธ์ที่แม่นยำใน Figma อยู่แล้ว
เพราะสามารถโต้ตอบได้อย่างสมบูรณ์ จึงจับกรณีขอบเขตด้านประสบการณ์ผู้ใช้ได้มากกว่ามาก
ตอนนี้ด้วย Claude Code ความเร็วในการสร้างต้นแบบที่ทำมาเพื่อทิ้งก็เร็วขึ้นอีก แต่ก็ไม่ถึงกับต่างมหาศาล
เพราะ 80% ของงานทั้งหมดคือเวลาที่ใช้คุยกับผู้ใช้และคิดว่ามันควรทำงานอย่างไร ดังนั้น Claude จึงช่วยลดอีก 20% ที่เหลือลงได้ประมาณครึ่งหนึ่งเมื่อเทียบกับการลงมือทำเองอย่างรวดเร็ว
เวอร์ชันแรกออกมาเร็วขึ้น แต่ถ้ายังเข้าใจไม่ครบ การวนซ้ำกลับช้าลง
Edwin, ดีใจที่เห็นคุณโพสต์บทความนี้
จำได้ว่าเราเคยทำแฮ็กกาธอนด้วยกันราว ๆ ปี 2012/2013
ความสามารถในการไปถึงต้นแบบที่ใช้งานได้เร็วขึ้นนั้นทรงพลังมาก แม้ว่าจะมีแรงยั่วใจให้นำไอเดียที่ยังไม่สมบูรณ์ไปปล่อยใช้งานตรง ๆ ก็ตาม
ข้อกำหนดด้านการออกแบบและประสบการณ์ผู้ใช้จะได้ประโยชน์อย่างมากเมื่อก้าวข้ามสตอรีบอร์ดและไวร์เฟรม ไปสู่การได้ลองแตะและสัมผัสโฟลว์จริง