สร้างต้นแบบแอปที่ใช้งานได้จริงด้วย AI แล้วนำไปให้คนลองใช้

ทำไมต้นแบบที่ใช้งานได้บอกอะไรได้มากกว่าม็อกอัป

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

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

ตัดสินใจว่าต้นแบบต้องพิสูจน์อะไร

ก่อนอธิบายอะไรก็ตาม เขียนคำถามหนึ่งหรือสองข้อที่การทดสอบต้องตอบให้ได้ วิธีนี้ทำให้งานสร้างเล็ก และการทดสอบแต่ละรอบมีจุดโฟกัส คำถามที่พบบ่อยได้แก่:

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

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

อธิบายให้ Anticode อย่างไร

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

เมื่อคุณเลือก Build it โมเดลจะเขียนแอปทั้งหมดเป็นเอกสาร HTML เดียว และคุณดูโค้ดที่ไหลเข้ามาได้ งานสร้างแอปใหม่ยังเปิดในเบราว์เซอร์แบบไม่มีหน้าจอ (headless) ที่ความกว้างของมือถือและแล็ปท็อปได้ จับภาพหน้าจอ กดทดลองทีละขั้น และส่งข้อผิดพลาดกลับไปแก้ เมื่อบริการตรวจสอบนั้นพร้อมใช้งาน

ทำส่วนที่จำลองให้ตรงไปตรงมา

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

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

การทดสอบและการปรับงานสร้าง

1. เผยแพร่ต้นแบบไปยังที่อยู่ anticode.dev แล้วส่งลิงก์ให้ผู้ทดสอบ ไม่ต้องติดตั้งอะไร
2. สำหรับผู้มีส่วนได้ส่วนเสีย ให้ส่งลิงก์รีวิวสำหรับลูกค้าแทน: เขาเปิดพรีวิวปัจจุบันได้โดยไม่ต้องมีบัญชี และแสดงความคิดเห็นที่ผูกกับแต่ละส่วนได้ ลิงก์หมดอายุหลัง 14 วันโดยค่าเริ่มต้น และคุณยกเลิกลิงก์ได้
3. หลังแต่ละรอบ ขอการเปลี่ยนแปลงด้วยคำพูดธรรมดา (“ย้ายปุ่มสลับกะไปไว้บนการ์ดกะแต่ละใบ”) การบันทึกล่าสุดถูกเก็บในประวัติเวอร์ชัน (จำนวนขึ้นกับแพ็กเกจของคุณ) คุณจึงเปิดรอบที่หนึ่งเทียบกับรอบที่สาม หรือย้อนกลับได้

สิ่งที่ต้นแบบในเบราว์เซอร์เดียวทดสอบไม่ได้

ต้องชัดเจนกับตัวเองเรื่องขอบเขต ต้นแบบในแซนด์บ็อกซ์ทำงานบนอุปกรณ์ทีละเครื่อง จึงทดสอบสิ่งเหล่านี้ไม่ได้:

• อะไรก็ตามที่เกิดระหว่างคน: การแจ้งเตือนจริง รายการที่ใช้ร่วมกัน หรือผู้ทดสอบสองคนเห็นการเปลี่ยนแปลงของกันและกัน
• การลงชื่อเข้าใช้ สิทธิ์การเข้าถึง หรือการกู้คืนบัญชีจริง
• ข้อมูลภายนอกแบบสด การชำระเงิน หรือฟีเจอร์ AI ภายในแอป (ทำได้แค่เลียนแบบด้วยคำตอบตัวอย่างที่กำหนดไว้)
• ประสิทธิภาพเมื่อมีข้อมูลจริงปริมาณมาก หรือเครือข่ายช้า

เมื่อไอเดียผ่านการทดสอบ การส่งออกเป็น Next.js คือก้าวต่อไปสู่ผลิตภัณฑ์จริง ใช้ได้กับงานสร้างแบบแอป และให้โปรเจกต์ App Router มาตรฐานใน TypeScript พร้อม Postgres ผ่าน Prisma การลงชื่อเข้าใช้ด้วยอีเมล บทบาทลูกค้าและพนักงาน และส่วนผู้ดูแลระบบ เป็นจุดเริ่มต้นที่นักพัฒนาจะต่อยอด ไม่ใช่แอปหลายผู้ใช้ที่เสร็จสมบูรณ์ และคุณพุชไปยังรีโพซิทอรี GitHub ที่เลือกได้ คู่มือการส่งออกเป็น Next.js อธิบายว่ามีอะไรอยู่ข้างใน หากคุณต้องการฟีเจอร์หลายผู้ใช้ระดับใช้งานจริงโดยไม่เขียนโค้ด เครื่องมือ no-code ที่มีแบ็กเอนด์อาจเหมาะกว่าทั้งสองทาง

คำถามที่พบบ่อย

นี่คือเครื่องมือสร้างต้นแบบแอปด้วย AI หรือเครื่องมือออกแบบ

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

ผู้ทดสอบใช้บนมือถือได้ไหม

ได้ แอปที่เผยแพร่เป็นหน้าเว็บที่ทำงานในเบราว์เซอร์มือถือ และข้อมูลที่บันทึกจะอยู่บนมือถือเครื่องนั้น

ฉันดูได้ไหมว่าผู้ทดสอบกรอกอะไรไว้

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

ต้นแบบจะกลายเป็นแอปจริงไหม

กลายเป็นจุดเริ่มต้นได้ การส่งออกเป็น Next.js เปลี่ยนเป็นโปรเจกต์ที่มีฐานข้อมูลและการลงชื่อเข้าใช้ ซึ่งนักพัฒนาต่อยอดได้