ความลับในการสร้างต้นแบบที่เร็วขึ้น? วางใจทีมผู้เชี่ยวชาญของเรา

แนวคิดเกี่ยวกับผลิตภัณฑ์จำนวนมากเริ่มต้นด้วยคำถามง่ายๆ ว่า ผู้คนจะใช้สิ่งนี้หรือไม่ การเปลี่ยนแนวคิดดังกล่าวให้เป็นต้นแบบที่ใช้งานได้อาจทำได้ยากกว่าที่คาดไว้ ทีมมักจะใช้เวลามากเกินไปในการหารือเกี่ยวกับคุณลักษณะ การเปลี่ยนแปลงการออกแบบ หรือการสร้างชิ้นส่วนที่ไม่ช่วยในการตรวจสอบผลิตภัณฑ์ ฉันช่วยให้ธุรกิจต่างๆ ย้ายจากแนวคิดเริ่มต้นไปสู่ต้นแบบที่ชัดเจนและทดสอบได้ ผ่านการวางแผนที่มุ่งเน้น การออกแบบเชิงปฏิบัติ และการพัฒนาที่มั่นคง ต้นแบบไม่จำเป็นต้องมีคุณสมบัติที่วางแผนไว้ทุกอย่าง ต้องแสดงให้เห็นว่าเส้นทางของผู้ใช้หลักทำงานอย่างไร ## เริ่มต้นด้วยเป้าหมายผลิตภัณฑ์ ฉันเริ่มต้นด้วยการถามว่าต้นแบบต้องพิสูจน์อะไรบ้าง เป้าหมายอาจเป็น: - ทดสอบกระบวนการจอง - แสดงแดชบอร์ดใหม่แก่นักลงทุน - ตรวจสอบว่าผู้ใช้เข้าใจแอปมือถือหรือไม่ - นำเสนอแนวคิดการบริการแก่พันธมิตรทางธุรกิจ - รวบรวมข้อเสนอแนะก่อนการพัฒนาอย่างเต็มรูปแบบ ขั้นตอนนี้จะทำให้โครงการมุ่งเน้น ต้นแบบที่สร้างขึ้นสำหรับการทดสอบโดยผู้ใช้อาจต้องมีหน้าจอที่คลิกได้ ต้นแบบที่สร้างขึ้นสำหรับการตรวจสอบด้านเทคนิคอาจต้องใช้ข้อมูลการทำงานและการเชื่อมต่อระบบขั้นพื้นฐาน แนวทางที่ถูกต้องขึ้นอยู่กับคำถามที่คุณต้องตอบ ## เปลี่ยนแนวคิดให้เป็นกระแสผู้ใช้ที่ชัดเจน แนวคิดในช่วงแรกๆ จำนวนมากมีรายการคุณลักษณะมากมาย ผู้ใช้อาจไม่ต้องการทั้งหมดในระหว่างการทดสอบครั้งแรก ฉันช่วยจัดระเบียบแนวคิดให้เป็นขั้นตอนง่ายๆ: 1. ใครใช้ผลิตภัณฑ์? 2. พวกเขาประสบปัญหาอะไร? 3. ควรดำเนินการอย่างไร? 4. พวกเขาควรได้รับผลลัพธ์อะไร? 5. ข้อเสนอแนะใดที่จะแสดงให้เห็นว่าโฟลว์ใช้งานได้หรือไม่? ตัวอย่างในทางปฏิบัติคือแพลตฟอร์มการจองคลินิก ต้นแบบแรกอาจต้องการเพียงการลงชื่อเข้าใช้ของผู้ป่วย การค้นหาแพทย์ ช่วงเวลาที่ว่าง การยืนยันการจอง และรายละเอียดการนัดหมาย เครื่องมือการชำระเงิน คุณสมบัติสมาชิก และการตั้งค่าบัญชีที่ซับซ้อนสามารถรอจนกว่าเส้นทางการจองหลักจะได้รับการทดสอบ แนวทางนี้ช่วยให้ทีมมีบางสิ่งที่เป็นประโยชน์ในการตรวจสอบโดยไม่ทำให้บิลด์ในช่วงแรกมีขนาดใหญ่เกินไป ## เลือกรูปแบบต้นแบบที่เหมาะสม เป้าหมายที่ต่างกันต้องการรายละเอียดที่ต่างกัน ต้นแบบที่มีความเที่ยงตรงต่ำสามารถช่วยทดสอบโครงสร้างของผลิตภัณฑ์ได้ อาจใช้เลย์เอาต์ที่เรียบง่าย แผนผังหน้าจอคร่าวๆ และการนำทางขั้นพื้นฐาน ต้นแบบที่มีความเที่ยงตรงสูงสามารถแสดงสไตล์ภาพ พฤติกรรมตอบสนอง แบบฟอร์ม และรายละเอียดการโต้ตอบได้ อาจเหมาะสำหรับการสัมภาษณ์ผู้ใช้ การนำเสนอการขาย หรือการทบทวนผู้มีส่วนได้ส่วนเสีย ต้นแบบการทำงานประกอบด้วยองค์ประกอบการทำงาน เช่น: - การส่งแบบฟอร์ม - การเข้าสู่ระบบของผู้ใช้ - การค้นหาและการกรอง - การจัดเก็บข้อมูลพื้นฐาน - การเชื่อมต่อ API - การอนุญาตบัญชี - รูปแบบที่เหมาะกับอุปกรณ์ ฉันไม่แนะนำให้สร้างระบบที่ใช้งานได้เต็มรูปแบบเมื่อการออกแบบที่คลิกได้สามารถตอบคำถามเดียวกันได้ ต้นแบบที่มีขนาดเล็กมักจะทำให้ข้อเสนอแนะเข้าใจง่ายขึ้น ## ให้การออกแบบและการพัฒนาเชื่อมโยงกัน การตัดสินใจออกแบบส่งผลต่อเวลาในการพัฒนา ข้อจำกัดในการพัฒนายังสามารถกำหนดรูปแบบการออกแบบได้ ทีมของฉันตรวจสอบทั้งสองด้านของโครงการก่อนเริ่มงาน เราพิจารณาเส้นทางของผู้ใช้ โครงสร้างหน้าจอ ความต้องการทางเทคนิค กระแสข้อมูล และความเสี่ยงที่อาจเกิดขึ้น ซึ่งจะช่วยลดการเปลี่ยนแปลงล่าช้าที่เกิดจากรายละเอียดที่ขาดหายไป ตัวอย่างเช่น บริการจัดส่งอาจต้องการแผนที่สด การติดตามผู้ขับ ข้อความจากลูกค้า และการอัปเดตคำสั่งซื้อ ต้นแบบสามารถแสดงกระบวนการสั่งซื้อและหน้าจอสถานะโดยไม่ต้องเชื่อมต่อกับระบบติดตามแบบเรียลไทม์ ทีมงานสามารถทดสอบว่าลูกค้าเข้าใจการอัพเดทสถานะหรือไม่ก่อนลงงานด้านเทคนิคเพิ่มเติม การแยกประเภทดังกล่าวทำให้ต้นแบบมีประโยชน์โดยไม่ทำให้มีขนาดใหญ่เกินความจำเป็น ## สร้างจากจุดตรวจสอบเล็กๆ ต้นแบบจะปรับปรุงได้ง่ายขึ้นเมื่อทีมตรวจสอบเป็นระยะ โครงการทั่วไปอาจเป็นไปตามเส้นทางนี้: - กำหนดเป้าหมายผู้ใช้หลักและผลิตภัณฑ์ - เลือกคุณสมบัติหลัก - จัดทำแผนผังการเดินทางของผู้ใช้ - สร้างโครงสร้างหน้าจอแรก - สร้างการออกแบบภาพ - พัฒนาปฏิสัมพันธ์หลัก - ตรวจสอบต้นแบบกับทีมของคุณ - ทดสอบกับผู้ใช้กลุ่มเล็กๆ - บันทึกคำติชมและเลือกการเปลี่ยนแปลงถัดไป ฉันเก็บคำติชมที่เชื่อมโยงกับเป้าหมายเดิม คำขออาจฟังดูมีประโยชน์แต่ยังคงเบี่ยงเบนความสนใจจากการทดสอบหลัก เมื่อสิ่งนี้เกิดขึ้น ฉันถามว่าการเปลี่ยนแปลงนี้ช่วยให้ผู้ใช้ทำงานหลักให้สำเร็จหรือช่วยให้ทีมเรียนรู้สิ่งใหม่ได้หรือไม่ ## ทำงานร่วมกับทีมที่สื่อสารได้ชัดเจน ความเร็วไม่ได้เกิดจากการข้ามการสื่อสาร มันมาจากการลดความสับสน คุณควรรู้: - ทีมกำลังสร้างอะไร - มีฟีเจอร์ใดบ้างที่รวมอยู่ - ข้อมูลใดบ้างที่ทีมต้องการจากคุณ - เมื่อคุณสามารถตรวจสอบงานได้ - วิธีบันทึกคำติชม - การเปลี่ยนแปลงใดที่อาจส่งผลต่อขอบเขตที่วางแผนไว้ ฉันชอบการอัปเดตที่สั้นและสม่ำเสมอมากกว่าการประชุมระยะยาวโดยไม่มีผลลัพธ์ที่ชัดเจน รายการงานที่แชร์ ลิงก์ต้นแบบที่เรียบง่าย และคำติชมที่เป็นลายลักษณ์อักษรสามารถช่วยให้ทุกคนมีแนวทางเดียวกันได้ คุณยังมีบันทึกการตัดสินใจที่ชัดเจนอีกด้วย ซึ่งจะช่วยได้เมื่อมีหลายคนเกี่ยวข้องกับงานผลิตภัณฑ์ การออกแบบ การตลาด หรือเทคโนโลยี ## ใช้คำติชมก่อนการพัฒนาอย่างเต็มรูปแบบ ต้นแบบช่วยให้ผู้ใช้มีสิ่งที่พวกเขาสามารถตอบสนองได้ ซึ่งมักจะสร้างผลตอบรับที่ดีกว่ารายการฟีเจอร์หรือการนำเสนอ ในระหว่างการทดสอบ ฉันมองหาสัญญาณต่างๆ เช่น: - ผู้ใช้ไม่พบการดำเนินการถัดไป - ป้ายกำกับไม่ชัดเจน - แบบฟอร์มขอข้อมูลมากเกินไป - รู้สึกว่ากระบวนการใช้เวลานานกว่าที่คาดไว้ - ผู้ใช้เข้าใจผลลัพธ์ของผลิตภัณฑ์ผิด - คุณสมบัติที่ร้องขอไม่สามารถแก้ปัญหาหลักได้ ความคิดเห็นบางรายการไม่จำเป็นต้องมีการเปลี่ยนแปลงการออกแบบ ผู้ใช้รายหนึ่งอาจชอบสีอื่น ในขณะที่ผู้ใช้หลายคนอาจไม่พบปุ่มเดียวกัน ฉันช่วยแยกความชอบส่วนตัวออกจากปัญหาการใช้งานซ้ำๆ ## เลือกเครื่องมือตามโครงการ เครื่องมือควรสนับสนุนเป้าหมาย ไม่ใช่ควบคุมมัน เครื่องมือออกแบบอาจเพียงพอสำหรับแนวคิดที่สามารถคลิกได้ กรอบงานเว็บอาจเหมาะกับต้นแบบที่ใช้เบราว์เซอร์ซึ่งจำเป็นต้องมีการโต้ตอบการทำงาน วิธีการข้ามแพลตฟอร์มอาจช่วยได้เมื่อจำเป็นต้องดูแนวคิดทั้งบนอุปกรณ์เคลื่อนที่และเดสก์ท็อป ตัวเลือกอาจขึ้นอยู่กับ: - วัตถุประสงค์ของต้นแบบ - ระดับการโต้ตอบที่คาดหวัง - ข้อมูลโครงการที่มีอยู่ - อุปกรณ์เป้าหมาย - ความจำเป็นสำหรับการพัฒนาในอนาคต - ทักษะของทีม - ความต้องการด้านงบประมาณและการบำรุงรักษา ฉันอธิบายตัวเลือกเหล่านี้เป็นภาษาธรรมดา เพื่อให้คุณสามารถตัดสินใจได้จริงโดยไม่ต้องมีพื้นฐานทางเทคนิค ## สิ่งที่คุณได้รับ การส่งมอบโครงการสามารถกำหนดได้ตามความต้องการของคุณ ซึ่งอาจรวมถึง: - ไดอะแกรมการไหลของผู้ใช้ - โครงร่าง - การออกแบบหน้าจอที่ตอบสนอง - ลิงก์ต้นแบบที่คลิกได้ - คุณสมบัติการทำงานขั้นพื้นฐาน - ไฟล์การออกแบบ - บันทึกทางเทคนิค - ผลการทดสอบโดยผู้ใช้ - แผนที่แนะนำสำหรับขั้นตอนผลิตภัณฑ์ถัดไป มีการตกลงขอบเขตที่แน่นอนก่อนเริ่มการพัฒนา สิ่งนี้จะช่วยให้คุณมีมุมมองที่ชัดเจนว่าต้นแบบสามารถแสดงให้เห็นอะไรได้บ้าง และสิ่งใดที่เหลืออยู่นอกโครงการปัจจุบัน ต้นแบบที่เร็วขึ้นไม่ได้เป็นเพียงเวอร์ชันที่เล็กลงของผลิตภัณฑ์สำเร็จรูปเท่านั้น เป็นวิธีที่มุ่งเน้นในการทดสอบแนวคิด เปิดเผยจุดอ่อน และสร้างความเข้าใจร่วมกันระหว่างผู้ที่เกี่ยวข้อง เมื่อฉันทำงานร่วมกับทีมผลิตภัณฑ์ ฉันจะมุ่งเน้นไปที่คำถามเบื้องหลังการสร้าง: เราต้องเรียนรู้อะไรจากต้นแบบนี้ คำถามนั้นเป็นแนวทางเกี่ยวกับฟีเจอร์ การออกแบบ เครื่องมือ และแผนการทดสอบ ช่วยให้ทีมใช้เวลากับหลักฐานที่เป็นประโยชน์ แทนที่จะสร้างหน้าจอที่ไม่สนับสนุนการตัดสินใจที่ชัดเจน แบ่งปันแนวคิดเกี่ยวกับผลิตภัณฑ์ ผู้ใช้เป้าหมาย และเป้าหมายหลักของคุณ เราสามารถสร้างต้นแบบตามเส้นทางของผู้ใช้หลัก และกำหนดเส้นทางปฏิบัติตั้งแต่แนวคิดไปจนถึงผลิตภัณฑ์ที่ทดสอบได้

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

ต้นแบบที่ดีไม่จำเป็นต้องดูเสร็จ ต้องช่วยฉันตอบคำถามผลิตภัณฑ์ที่ถูกต้องก่อนที่จะใช้เวลาและเงินในการพัฒนา หลายทีมเริ่มต้นด้วยหน้าจอที่สวยงาม ฟีเจอร์ที่มีรายละเอียด และรอบการอนุมัติที่ยาวนาน หลังจากเปิดตัว พวกเขาอาจพบว่าผู้ใช้ไม่สามารถค้นหาการดำเนินการหลัก ไม่เข้าใจคุณค่าของผลิตภัณฑ์ หรือต้องการเส้นทางที่ง่ายกว่า ต้นแบบช่วยให้ฉันทดสอบประเด็นเหล่านี้ได้ตั้งแต่เนิ่นๆ เมื่อการเปลี่ยนแปลงทำได้ง่ายขึ้น ## เริ่มต้นด้วยปัญหาผู้ใช้รายหนึ่ง ฉันเริ่มต้นด้วยการเขียนประโยคที่ชัดเจน: “ผู้ใช้ของฉันต้อง ______ เพราะ ______” ตัวอย่างเช่น: “ผู้ใช้ของฉันต้องเปรียบเทียบตัวเลือกการจัดส่ง เนื่องจากการเลือกระหว่างราคาและความเร็วทำให้เกิดความสับสน” ข้อความนี้ทำให้ต้นแบบมุ่งเน้นไปที่ หากฉันพยายามแก้ไขปัญหาห้าข้อพร้อมกัน การทดสอบของผู้ใช้จะอ่านได้ยาก ฉันอาจรวบรวมความคิดเห็นมากมายโดยไม่รู้ว่าปัญหาใดส่งผลกระทบต่อผลิตภัณฑ์มากที่สุด ต้นแบบที่มุ่งเน้นสามารถครอบคลุมงานสั้นๆ เช่น - การสร้างบัญชี - การจองนัดหมาย - การเปรียบเทียบแผนบริการ - การอัปโหลดเอกสาร - การตรวจสอบสถานะคำสั่งซื้อ ## เลือกระดับรายละเอียดที่เหมาะสม แบบร่างกระดาษสามารถตอบคำถามเกี่ยวกับโครงสร้างและการไหลได้ โครงลวดที่คลิกได้สามารถแสดงให้เห็นว่าผู้คนเคลื่อนที่ไปมาระหว่างหน้าจออย่างไร ต้นแบบที่มีความเที่ยงตรงสูงสามารถช่วยทดสอบเค้าโครง ข้อความ ลำดับชั้นของภาพ และรายละเอียดการโต้ตอบได้ ฉันไม่ใช้การออกแบบภาพที่มีรายละเอียดเมื่อภาพร่างธรรมดาสามารถตอบคำถามได้ กฎที่เป็นประโยชน์คือ: - ใช้รายละเอียดต่ำเพื่อทดสอบแนวคิด - ใช้รายละเอียดปานกลางเพื่อทดสอบโฟลว์ - ใช้รายละเอียดสูงเพื่อทดสอบประสบการณ์ ซึ่งจะทำให้งานเชื่อมโยงกับการตัดสินใจที่ฉันต้องทำ นอกจากนี้ยังช่วยลดความเสี่ยงในการขัดหน้าจอที่อาจถอดออกในภายหลัง ## จัดทำแผนผังเส้นทางที่เป็นประโยชน์ที่สั้นที่สุด ฉันจดบันทึกการเดินทางของผู้ใช้ก่อนออกแบบแต่ละหน้าจอ สำหรับบริการจอง เส้นทางอาจมีลักษณะดังนี้: 1. เลือกบริการ 2. เลือกวันที่ 3. ตรวจสอบราคา 4. ยืนยันการจอง 5. รับข้อความยืนยัน เส้นทางควรมีรายละเอียดเพียงพอสำหรับผู้ใช้ในการทำงานให้เสร็จสิ้น เมนู การตั้งค่า และคุณสมบัติด้านข้างเพิ่มเติมสามารถรอได้ เมื่อฉันตรวจสอบโฟลว์ ฉันถามว่า: - ทุกหน้าจอรองรับงานหรือไม่? - ผู้ใช้รู้หรือไม่ว่าต้องทำอะไรต่อไป? - ผู้ใช้สามารถย้อนกลับไปโดยไม่สูญเสียความคืบหน้าได้หรือไม่? - ราคา วันที่ และเงื่อนไขสำคัญหาง่ายหรือไม่ - จะเกิดอะไรขึ้นเมื่อผู้ใช้ทำผิดพลาด? คำถามเหล่านี้มักจะเผยให้เห็นช่องว่างก่อนที่ต้นแบบจะไปถึงมือลูกค้า ## ใช้เนื้อหาที่ชัดเจนก่อนการขัดภาพ Lorem ipsum ซ่อนปัญหา ฉันใช้ข้อความสั้นๆ ที่สมจริงเพื่อสะท้อนถึงผลิตภัณฑ์ แทนที่จะเขียนว่า “ส่ง” ฉันอาจเขียนว่า “ส่งคำขอนัดหมาย” แทนที่จะเขียนว่า “ตัวเลือก A” ฉันอาจเขียนว่า “การจัดส่งแบบมาตรฐาน — 3 ถึง 5 วัน” ฉลากที่ชัดเจนช่วยให้ฉันทดสอบได้ว่าผู้คนเข้าใจผลิตภัณฑ์หรือไม่ พวกเขายังเปิดเผยปัญหาเค้าโครงด้วย ปุ่มที่ดูดีเมื่อมีคำสองคำอาจกลายเป็นเรื่องยากที่จะใช้กับป้ายกำกับที่ยาวและมีประโยชน์มากกว่า เนื้อหาควรตอบคำถามพื้นฐานของผู้ใช้: - นี่คืออะไร? - ฉันทำอะไรที่นี่ได้บ้าง? - จะเกิดอะไรขึ้นต่อไป? - ฉันจะจ่ายอะไร? - ฉันสามารถเปลี่ยนแปลงหรือยกเลิกการดำเนินการได้หรือไม่? ## ทดสอบกับกลุ่มเล็กๆ ฉันไม่จำเป็นต้องมีโครงการวิจัยขนาดใหญ่เพื่อค้นหาปัญหาการใช้งานขั้นพื้นฐาน ฉันสามารถขอให้คนสองสามคนที่ตรงกับกลุ่มเป้าหมายทำงานหนึ่งงานให้เสร็จโดยไม่ต้องมีคำแนะนำโดยละเอียด เซสชันง่ายๆ อาจรวมถึง: “โปรดจองบริการสำหรับวันอังคารหน้า และบอกฉันว่าคุณคาดว่าจะเกิดอะไรขึ้นหลังจากที่คุณยืนยัน” ฉันดูว่าบุคคลนั้นหยุดชั่วคราว แตะการควบคุมผิด ขอความช่วยเหลือ หรือยอมแพ้ ฉันหลีกเลี่ยงการอธิบายหน้าจอเร็วเกินไป เพราะคำอธิบายของฉันอาจซ่อนปัญหาที่ผู้ใช้ในอนาคตจะต้องเผชิญ หลังจากเซสชัน ฉันบันทึก: - งานที่พยายามทำ - จุดที่เกิดความสับสน - คำที่ผู้ใช้ใช้ - การกระทำที่ฉันคาดหวัง - การกระทำที่ผู้ใช้ทำ - การเปลี่ยนแปลงการออกแบบที่เป็นไปได้ การหยุดชั่วคราวเป็นหลักฐานที่มีประโยชน์ มีคำถามเช่น “นี่เป็นราคาสุดท้ายหรือไม่” มันบอกฉันว่าหน้าจออาจให้ข้อมูลไม่เพียงพอ ## จัดเรียงความคิดเห็นตามผลกระทบของผลิตภัณฑ์ ไม่ใช่ทุกความคิดเห็นที่ต้องมีการเปลี่ยนแปลงการออกแบบ คนหนึ่งอาจชอบสีอื่น หลายคนอาจล้มเหลวในการค้นหาการดำเนินการหลัก ปัญหาเหล่านี้ไม่ควรได้รับความสนใจเหมือนกัน ฉันจัดกลุ่มความคิดเห็นออกเป็นสามส่วน: งานล้มเหลว ผู้ใช้ไม่สามารถดำเนินการหลักให้เสร็จสิ้นได้ แรงเสียดทานของงาน ผู้ใช้สามารถทำได้ แต่เส้นทางรู้สึกช้าหรือสับสน ความชอบส่วนบุคคล ผู้ใช้แนะนำการเปลี่ยนแปลงที่ไม่ส่งผลต่อความสำเร็จของงาน ฉันจัดการกับความล้มเหลวของงานก่อนการตั้งค่าภาพ ซึ่งจะช่วยให้ทีมใช้เวลาในการออกแบบและพัฒนาในประเด็นที่ส่งผลต่อการใช้ผลิตภัณฑ์ ## สร้าง ทดสอบ และปรับแต่งในรอบสั้นๆ ฉันถือว่าต้นแบบเป็นคำถามที่ใช้งานได้ ไม่ใช่คำตอบสุดท้าย หนึ่งรอบอาจมีลักษณะดังนี้: 1. ระบุคำถามผลิตภัณฑ์หนึ่งข้อ 2. สร้างเฉพาะหน้าจอที่จำเป็นสำหรับการทดสอบ 3. ขอให้ผู้ใช้เป้าหมายทำงานให้เสร็จสิ้น 4. บันทึกการดำเนินการและความคิดเห็น 5. เปลี่ยนโฟลว์หรือเนื้อหา 6. ทดสอบเวอร์ชันที่แก้ไข ตัวอย่างเช่น แอปการเงินอาจทดสอบว่าผู้คนเข้าใจสรุปการใช้จ่ายหรือไม่ ทีมงานสามารถสร้างหน้าจอเดียวกันได้สองเวอร์ชัน หนึ่งใช้ผลรวมรายเดือนที่ด้านบน อีกอันจะแสดงรายละเอียดหมวดหมู่ก่อน เซสชันผู้ใช้สามารถเปิดเผยว่ารูปแบบใดที่ช่วยให้ผู้คนตอบว่า “เดือนนี้เงินของฉันไปอยู่ที่ไหน” การทดสอบไม่จำเป็นต้องพิสูจน์ว่าการออกแบบใดสมบูรณ์แบบ ต้องแสดงให้เห็นว่าทิศทางไหนสมควรได้รับการทำงานมากกว่านี้ ## ให้การออกแบบและการพัฒนาเชื่อมโยงกัน ต้นแบบสามารถประหยัดเวลาได้ก็ต่อเมื่อการค้นพบนั้นไปถึงผู้ที่สร้างผลิตภัณฑ์เท่านั้น ฉันแบ่งปันงานของผู้ใช้ บันทึกการทดสอบ โฟลว์หน้าจอ และคำถามปลายเปิดกับนักออกแบบ นักพัฒนา ผู้จัดการผลิตภัณฑ์ และทีมสนับสนุน การส่งมอบสั้นๆ อาจรวมถึง: - วัตถุประสงค์ของต้นแบบ - งานของผู้ใช้ที่ทดสอบ - จุดเสียดสีหลัก - การเปลี่ยนแปลงที่ได้รับอนุมัติ - คำถามที่ยังต้องการหลักฐาน - รายละเอียดที่ไม่เป็นส่วนหนึ่งของขอบเขตปัจจุบัน ซึ่งจะช่วยลดสมมติฐาน นักพัฒนาสามารถดูสาเหตุที่มีการเปลี่ยนแปลงขั้นตอนได้ ทีมสนับสนุนสามารถเตรียมพร้อมสำหรับคำถามที่อาจเกิดขึ้นหลังการเปิดตัว ## หลีกเลี่ยงทางลัดที่สร้างงานมากขึ้น แนวทางที่ดูเร็วที่สุดมักจะสร้างทุกอย่างก่อนที่จะพูดคุยกับผู้ใช้ เส้นทางดังกล่าวสามารถผลิตผลิตภัณฑ์ขัดเงาที่มีการไหลน้อยได้ ฉันพบว่าต้นแบบที่คลิกได้ง่ายมักจะให้ทิศทางที่ดีกว่าเอกสารฟีเจอร์ขนาดยาว เอกสารสามารถอธิบายสิ่งที่ผลิตภัณฑ์ควรทำ ต้นแบบช่วยให้ผู้คนตอบสนองต่อสิ่งที่พวกเขาจะทำจริงได้ เป้าหมายไม่ใช่การสร้างหน้าจอเพิ่ม เป้าหมายคือการเรียนรู้ให้มากพอที่จะตัดสินใจเลือกผลิตภัณฑ์ได้ดี กระบวนการสร้างต้นแบบที่แข็งแกร่งทำให้งานของผู้ใช้มีขนาดเล็ก คำถามที่ชัดเจน และข้อเสนอแนะใกล้เคียงกับงานออกแบบ ฉันจะดำเนินการได้เร็วขึ้นเมื่อฉันทดสอบส่วนที่มีความเสี่ยงตั้งแต่เนิ่นๆ ใช้เนื้อหาธรรมดา และเปลี่ยนเฉพาะสิ่งที่หลักฐานสนับสนุนเท่านั้น ติดต่อเราได้ที่ lingchao: mr.xu@lingchaopcb.com/WhatsApp +8613780181891

1. Steve Krug, 2000, Don't Make Me Think: A Common Sense Approach to Web Usability 2. Eric Ries, 2011, The Lean Startup: ผู้ประกอบการในปัจจุบันใช้นวัตกรรมอย่างต่อเนื่องเพื่อสร้างธุรกิจที่ประสบความสำเร็จอย่างมากได้อย่างไร 3. Jakob Nielsen, 1993, วิศวกรรมการใช้งาน 4. Jeff Gothelf และ Josh Seiden, 2013, Lean UX: การใช้ Lean หลักการปรับปรุงประสบการณ์ผู้ใช้ 5. Clayton M Christensen, Taddy Hall, Karen Dillon และ David S Duncan, 2016, รู้จักงานของลูกค้าที่ต้องทำ 6. Donald A Norman, 2013, การออกแบบสิ่งต่าง ๆ ในชีวิตประจำวัน