ในหน้านี้
ลองนึกถึงหน้าผลิตภัณฑ์ที่เปิดด้วยฟีเจอร์สิบสองอย่าง: Webhook ฟิลด์กำหนดเอง การควบคุมลองใหม่ บันทึกตรวจสอบ ตัวแมปภาพ และแผงกำหนดเวลา ร้านค้ากวาดตารายการแล้วยังตอบคำถามเดียวไม่ได้: คำสั่งซื้อเมื่อวานจะไปถึงระเบียนลูกค้าที่ถูกไหม
หน้านี้เป็นตัวอย่างสมมติ ความล้มเหลวคุ้นเคยเพราะรายการฟีเจอร์อธิบายเครื่องจากด้านใน ส่วนผู้อ่านเริ่มจากด้านนอกพร้อมงานที่ต้องจบ
บทสนทนาสั้นที่เก็บมาเรื่องการสื่อสารผลิตภัณฑ์ ชี้วิธีพื้นฐาน: อธิบายสิ่งที่เกิดหลังใช้แทนเริ่มจากชิ้นส่วน ไม่ได้หมายถึงซ่อนชิ้นส่วน แต่ให้เหตุผลผู้อ่านอยากตรวจมัน
ตั้งชื่อการเปลี่ยนที่คนเห็นได้
“เชื่อมข้อมูลทั้งหมด” กว้างเกินทดสอบ “ย้ายคำสั่งซื้อใหม่จาก Shopify ไปยังรายชื่อ Brevo ที่ตรงกัน” ให้ผู้อ่านมีระเบียนตรวจ มันระบุสถานะก่อน การกระทำ และสถานะหลัง
ประโยคผลลัพธ์อาจมีรูปแบบนี้:
เมื่อ เหตุการณ์นี้ เกิด ระเบียนนี้ เปลี่ยนใน ระบบนี้ เพื่อให้ คนนี้ ทำ งานต่อไปนี้ ได้
สำหรับการซิงค์ เหตุการณ์อาจเป็นอัปเดตคำสั่งซื้อ ระเบียนอาจเป็นแอตทริบิวต์รายชื่อ งานถัดไปอาจเป็นส่งข้อความเฉพาะการซื้อให้ลูกค้าที่ให้ความยินยอม คำนามแต่ละคำบังคับให้เลือก คำสั่งซื้อไหน รายชื่อไหน แอตทริบิวต์ไหน อะไรนับเป็นความยินยอม
คำถามเหล่านั้นคืองานจริง “ข้อมูลลูกค้าเป็นหนึ่งเดียว” เลี่ยงมันไป
คู่มือเชื่อมต่อ Brevo ของเรา ครอบคลุมการตั้งค่าและการแมป ถามว่าระบบใดเป็นเจ้าของแต่ละฟิลด์และตรวจผลอย่างไร หน้าผลิตภัณฑ์ให้คำตอบแรกในหนึ่งประโยค แล้วลิงก์สู่รายละเอียดเมื่อผู้อ่านต้องการ
- คำสั่งซื้อเปลี่ยนเหตุการณ์ลูกค้าเหตุการณ์ต้นทาง
- จับคู่และแมปตัวตน · ฟิลด์ · สิทธิ์สถานะปลายทาง
- ตรวจรายชื่อผลที่มองเห็น
วางหลักฐานใกล้คำสัญญา
การเขียนโดยเริ่มจากผลอาจกลายเป็นหมอกอีกแบบ “ประหยัดสิบชั่วโมงต่อสัปดาห์” ฟังดูชัดเพราะมีตัวเลข หากไม่มีงานที่วัดและค่าฐาน มันคือตัวเลขสวมชุด
ข้อโต้แย้งที่ยุติธรรมคือ “ผู้ซื้อต้องการฟีเจอร์และข้อกำหนด ประโยคผลลัพธ์ไม่บอกว่าจะใช้กับระบบฉันได้ไหม” ถูกต้อง ผลลัพธ์บอกว่าทำไมควรดู ข้อกำหนดบอกว่าควรไปต่อไหม
ใช้ห่วงโซ่หลักฐานสั้น ๆ:
| สิ่งที่ผู้อ่านต้องการ | สิ่งที่หน้าแสดงได้ |
|---|---|
| งาน | ตัวอย่างระเบียนก่อนและหลังหนึ่งรายการ |
| กลไก | ตัวกระตุ้น การแมป และปลายทาง |
| ข้อจำกัด | ออบเจ็กต์ที่รองรับ เวลา และสิทธิ์ที่ต้องมี |
| หลักฐาน | ทางทดสอบ เอกสาร หรือผลวัด |
หากอ้างว่า “คำสั่งซื้อหนึ่งรายการไปถึงรายชื่อที่ตรงกัน” ให้แสดงตัวอย่างข้อมูลเข้าและฟิลด์ปลายทางที่คาด ระบุว่าเป็นความสามารถที่มีเอกสาร เวิร์กโฟลว์สมมติ หรือผลที่วัดกับลูกค้า หลักฐานแต่ละแบบต่างกัน
สำหรับร้านที่เลือกคอนเน็กเตอร์ คู่มือคอนเน็กเตอร์ Brevo ลงรายละเอียดตัวตน สถานะซิงค์ และสิ่งที่ผิดหลังเปิดใช้ รายการฟีเจอร์มีประโยชน์ตรงนั้น คำถามคือแสดงเมื่อไร ผู้อ่านที่ยังไม่เห็นงานจะตัดสินข้อแลกเปลี่ยนไม่ได้
ฟีเจอร์เป็นวิธี ไม่ใช่ข้อแก้ตัว
ลองสองคำอธิบายของเวิร์กโฟลว์ที่เป็นไปได้เดียวกัน ทั้งคู่เป็นสมมติ
เริ่มจากฟีเจอร์: “ตัวแมปฟิลด์แบบภาพพร้อมการตั้งค่ามีรุ่น เส้นทางเหตุการณ์ และการเล่นซ้ำ”
เริ่มจากการเปลี่ยน: “อัปเดตรายชื่อที่ถูกเมื่อคำสั่งซื้อเปลี่ยน ตรวจการแมปก่อนส่งครั้งแรก และดูระเบียนใด ๆ ที่ล้มเหลว”
ข้อความที่สองอ้างแคบกว่า และสร้างภาระพิสูจน์หนักกว่า ผลิตภัณฑ์ต้องหาคนที่ถูกจริง ให้ตรวจการแมปได้ และเผยระเบียนที่ล้มเหลว ข้อความที่ดีทำให้งานที่ขาดซ่อนไม่ได้
นี่คือเหตุผลที่หน้าไม่ควรกระโดดจาก “เรามีการลองใหม่” เป็น “คุณไม่มีวันเสียคำสั่งซื้อ” การลองใหม่อาจล้มเหลว การเรียก API ที่รับแล้วอาจทิ้งฟิลด์ผิด คำสัญญาเรื่องผลต้องตรวจผล ไม่ใช่ท่องส่วนประกอบ
ต้นทุนมาก่อนผลดี: หน้าที่นำด้วยผลต้องมีคนระบุชัดว่าพฤติกรรมไหนรองรับแล้ว ไหนยังอยู่ในแผน และไหนขึ้นกับการตั้งค่าลูกค้า ยากกว่ารวมชื่อฟีเจอร์จากแผนงาน
ข้อความลบขั้นงานไม่ได้
บทความนี้ว่าด้วยคำอธิบายบนหน้าผลิตภัณฑ์ คำถามผลิตภัณฑ์อีกเรื่องคือผู้ใช้ต้องเปิดแดชบอร์ดใหม่ ให้สิทธิ์เพิ่ม หรือทำการตั้งค่าห้าขั้นก่อนเห็นผลไหม ข้อความชัดไม่ทำเวิร์กโฟลว์ยาวให้สั้น
คู่มือระบบอัตโนมัติแรกของเรา เริ่มจากกระบวนการหนึ่งและการตรวจสำเร็จหนึ่งอย่าง ใช้วินัยเดียวกันกับหน้า: เลือกงานหนึ่ง อธิบายสถานะที่เปลี่ยน และให้ผู้อ่านหาทางทดสอบได้
แล้วดูคำถามถัดไป หากผู้อ่านถามซ้ำว่า “จะเห็นผลที่ไหน” ผลลัพธ์ยังนามธรรมเกิน หากถาม “รองรับฟิลด์กำหนดเองของฉันไหม” หน้าได้ทำงานแรกแล้ว ตอนนี้เขากำลังประเมินกลไก
แสดงการเปลี่ยน แล้วแสดงส่วนที่ทำให้มันจริง
คำถามที่พบบ่อย
หน้าผลิตภัณฑ์ควรเริ่มด้วยผลลัพธ์หรือฟีเจอร์?
เริ่มด้วยการเปลี่ยนที่ผู้ใช้จำได้ จากนั้นแสดงฟีเจอร์และหลักฐานที่ทำให้เชื่อได้ ข้อกำหนดละเอียดก็ยังสำคัญต่อการประเมินและควรหาได้ง่าย
เขียนผลลัพธ์อย่างไรโดยไม่อ้างเกินหลักฐาน?
ระบุสถานะเริ่มต้น การกระทำของผู้ใช้ และผลที่สังเกตได้ แยกพฤติกรรมผลิตภัณฑ์ที่รองรับจากประโยชน์ลูกค้าในสมมติฐาน และเลี่ยงตัวเลขที่ไม่ได้วัด
การเขียนโดยเริ่มจากผลทำให้อินเทอร์เฟซง่ายขึ้นไหม?
ไม่ ข้อความอาจอธิบายผลได้ทั้งที่งานยังมีหลายขั้นเกินไป ต้องทดสอบทางไปถึงผลจริงแยกต่างหาก