อ่านฉบับย่อ
เริ่มจากกฎตรวจความครบถ้วนแบบตายตัว ช่องข้อมูลชัด ข้อผิดพลาดมองเห็นได้ และมีคนตรวจอนุมัติ ตรวจพรีวิวกับค่าใช้จ่ายก่อนพิจารณาเผยแพร่แอป
แอปตรวจบรีฟที่มีประโยชน์ต้องแจ้งข้อมูลที่ขาดและบอกผู้ส่งว่าควรเพิ่มอะไร ไม่ควรแต่งงบประมาณ อนุมัติคำกล่าวอ้างไร้หลักฐาน หรือถือว่ากรอกครบเท่ากับแคมเปญดี ข้อกำหนดด้านล่างเป็นแผนต้นแบบขนาดเล็กสำหรับ Emergent ด้วยข้อมูลสมมติ ใช้คำสั่งที่คัดลอกได้และกรณีตรวจรับด้านล่างเป็นจุดเริ่มต้นสำหรับสร้างแอป
จำกัดขอบเขตเวอร์ชันแรก
ใช้เจ็ดช่อง ได้แก่ วัตถุประสงค์ กลุ่มเป้าหมาย งานส่งมอบ จำนวนงบประมาณ สกุลเงิน วันครบกำหนด และบทบาทผู้อนุมัติ ใช้ช่องกรอกมีโครงสร้าง แทนให้โมเดลภาษาตีความทุกอย่างจากเอกสารที่วาง กฎช่องบังคับและการตรวจตัวเลขง่าย ๆ ใช้ตรรกะแน่นอนได้ ช่องที่ขาดควรมีข้อผิดพลาดใกล้ช่องนั้น แม้กรอกครบก็ยังต้องระบุว่ารอคนตรวจ
ระบุสิ่งที่แอปไม่ตัดสิน ได้แก่ การรับรองข้อความโฆษณา สิทธิ์ภาพ ความเหมาะสมของงบ และการอนุญาตเผยแพร่ ให้เรื่องเหล่านี้อยู่ในกระบวนการตรวจแคมเปญ สำหรับงานสร้างสรรค์ ใช้ขั้นตอนบรีฟภาพ แยกต่างหาก แอปมีหน้าที่รวบรวมข้อมูลที่ผู้ทำงานต้องใช้
คัดลอกคำสั่งสร้างที่มีขอบเขตนี้
วางข้อกำหนดนี้ในบทสนทนาเว็บแอปใหม่ของ Emergent ขอให้ตัวสร้างอธิบายเส้นทางข้อมูลก่อนยอมรับบริการเพิ่ม ประเมินการล็อกอิน ฐานข้อมูล ระบบวิเคราะห์ หรือการเชื่อมโมเดลเป็นความต้องการแยก เพราะทุกอย่างเพิ่มขอบเขตต้นแบบและอาจเพิ่มค่าใช้จ่าย
สร้างเดโมหน้าเดียวชื่อ ตรวจบรีฟแคมเปญ แสดงข้อความ “สาธิตด้วยข้อมูลสมมติเท่านั้น” ให้ชัด เก็บวัตถุประสงค์ กลุ่มเป้าหมาย งานส่งมอบ งบประมาณ สกุลเงิน วันครบกำหนด และบทบาทผู้อนุมัติ ตัดช่องว่างหัวท้ายและบังคับทุกช่อง งบต้องเป็นจำนวนจำกัดที่มากกว่าศูนย์ และต้องเลือกสกุลเงินชัดเจน ปฏิเสธวันที่ก่อนวันนี้ตามวันที่ท้องถิ่นของเบราว์เซอร์ แสดงข้อผิดพลาดรายช่องและเก็บค่าที่กรอกหลังผิดพลาด เมื่อข้อมูลถูกต้อง ให้แสดงสรุปข้อความธรรมดาหัวข้อ “ข้อมูลครบ รอคนตรวจ” ห้ามสร้างค่าที่ขาด หลักฐาน ลูกค้า หรือผลลัพธ์ ใช้สถานะฝั่งไคลเอนต์เท่านั้น ไม่มีฐานข้อมูล ระบบวิเคราะห์ การเรียกโมเดลภายนอก อัปโหลดไฟล์ หรือล็อกอิน เพิ่มปุ่มรีเซ็ตและคัดลอกสรุป พร้อมผลสำเร็จหรือล้มเหลวที่เห็นได้ ห้ามเผยแพร่แอป อธิบายกฎตรวจสอบและรายชื่อไฟล์ที่แก้ไข
คำสั่งต้นฉบับนี้เป็นข้อกำหนดเริ่มต้น ไม่รับประกันพฤติกรรมที่สร้างได้ ขอป้ายกำกับที่ใช้คีย์บอร์ดได้ ลำดับ Tab ที่คาดเดาได้ และหน้าจอแคบที่ใช้งานได้ หากตัวสร้างเสนอวิธีอื่น ให้เทียบกับข้อกำหนด อย่าถือว่าพรีวิวดูดีแปลว่ากฎเดียวกันถูกนำไปใช้
เตรียมกรณีตรวจรับก่อนทดลองกด
ใช้ข้อมูลแต่งขึ้น เช่น เป้าหมาย “แนะนำคลาสสุดสัปดาห์” กลุ่มเป้าหมาย “ผู้ใหญ่ที่ลองงานอดิเรกใหม่” งานส่ง “หนึ่งภาพและหนึ่งคลิปสั้น” งบ “250” สกุล “USD” วันที่ในอนาคต และผู้อนุมัติ “เจ้าของแคมเปญ” จำนวนเงินเป็นข้อมูลสมมติ ไม่ใช่คำแนะนำราคา ใช้ชุดเดิมและเปลี่ยนทีละช่องเพื่อระบุสาเหตุของผลลัพธ์ได้
| ข้อมูลหรือการกระทำ | พฤติกรรมที่คาดหวัง |
|---|---|
| ว่างทั้งหมดหรือมีแต่ช่องว่าง | แจ้งข้อผิดพลาด ไม่มีสรุปว่าครบ |
| งบศูนย์ ติดลบ หรือข้อความ | แจ้งงบผิด คงค่าอื่นไว้ |
| วันครบกำหนดก่อนวันนี้ | แจ้งวันที่ผิดตามวันที่ท้องถิ่นที่ระบุ |
| บรีฟสมมติครบ | สรุปตรงข้อมูล ยังต้องให้คนตรวจ |
| รีเซ็ตหลังบรีฟถูกต้อง | ล้างช่องและสรุปเดิม |
| เบราว์เซอร์ไม่อนุญาตคัดลอก | แจ้งล้มเหลว ยังเลือกข้อความสรุปได้ |
ตรวจพรีวิวเหมือนผู้ใช้จริง
เอกสารพรีวิวของ Emergent แยกพรีวิวชั่วคราวจากแอปที่เผยแพร่ เปิดพรีวิวและลองทุกกรณีด้วยตนเอง ใช้คีย์บอร์ดและหน้าจอกว้างเท่าโทรศัพท์ ทำตามแนวทางทดสอบแบบผู้เยี่ยมชม โดยอธิบายการกระทำ ผลที่คาด และผลจริง แล้วทำกรณีเดิมซ้ำหลังแก้
ตรวจโค้ดที่สร้างหรือให้ผู้มีความรู้ยืนยันว่าไม่มีการเรียกเครือข่ายและการเก็บข้อมูลที่ห้ามไว้ ข้อกำหนดให้ใช้สถานะฝั่งไคลเอนต์ไม่พิสูจน์ว่าแอปไม่เก็บข้อมูลใด ๆ อย่าวางบรีฟลูกค้าจริง รายชื่อผู้ติดต่อ หรือตัวเลขธุรกิจลับในตัวสร้าง เพียงเพราะแบบฟอร์มดูไม่มีอันตราย
ตัดสินใจว่าจำเป็นต้องโฮสต์หรือไม่
ตรวจแผนเผยแพร่ ปัจจุบันและยอดบัญชีก่อนเผยแพร่ การโฮสต์มีเครดิตที่ใช้ซ้ำเป็นระยะ พรีวิวที่ทำงานได้ไม่ใช่ URL ถาวรหรือหลักฐานว่าใช้งานฟรี อ่านรายชื่อผู้ประมวลผลช่วง และเงื่อนไขความเป็นส่วนตัวก่อนใช้ข้อมูลจริง หากเก็บข้อมูลที่ส่ง ต้องออกแบบการยืนยันตัวตน ระยะเก็บ สิทธิ์เข้าถึง และการลบแยกต่างหาก
หากทำแคมเปญเป็นครั้งคราว แบบฟอร์มเจ็ดช่องอาจพอโดยไม่ต้องสร้างแอป หากทำต่อ ให้เก็บบันทึกตรวจรับลงวันที่และข้อกำหนดที่อนุมัติ เชื่อมบรีฟกับงานผลิตจริง เช่น ขั้นตอนตัดต่อวิดีโอสั้น และแยกผู้อนุมัติแคมเปญออกจากหน้าจอที่เพียงรายงานว่ากรอกครบ