ข้อมูลเชิงลึกที่มีคุณค่าในเวลาที่เหมาะสม: การกำหนดระดับความเที่ยงตรงของการออกแบบในอุดมคติสำหรับการทดสอบผู้ใช้

ที่ Intercom หลักการหนึ่งในการพัฒนาผลิตภัณฑ์ของเราคือการคิดการใหญ่ เริ่มต้นจากสิ่งเล็กๆ เรียนรู้อย่างรวดเร็ว

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

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

“เราพบว่าการหลีกเลี่ยงการใช้คำว่า ' การออกแบบ' เป็นการช่วยเมื่อพูดคุยกันภายในเกี่ยวกับสิ่งที่จะแสดงให้ผู้เข้าร่วมดู - เราชอบที่จะใช้ ' สิ่งกระตุ้นการวิจัย'”

คำพูดสำคัญ

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

ระบุปัญหา

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

แต่เราพบว่าการเริ่มต้นด้วยปัญหา – สิ่งที่เราพยายามเรียนรู้ – และจับคู่สิ่งนั้นกับความถูกต้องของสิ่งที่เราแสดงผู้เข้าร่วมการวิจัยในระหว่างการทดสอบผู้ใช้จะเป็นประโยชน์

ดังนั้น ในการพิจารณาความถูกต้องของการออกแบบที่ถูกต้อง คุณต้องระบุปัญหาต่อไปนี้ที่คุณกำลังพยายามแก้ไข:

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

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

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

“ในช่วงแรกๆ คุณไม่สนใจว่าพวกเขาจะโต้ตอบกับมันอย่างไร คุณสนใจว่าจะมีค่าสำหรับพวกเขาหรือไม่”

แนวคิดการทดสอบ: แนวคิดนี้มีคุณค่าหรือไม่?

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

ในระหว่างการทดสอบ คุณจะต้องยืนยันว่าผู้เข้าร่วมประสบปัญหาจริง ๆ ที่คุณพยายามจะแก้ไข แสดงแนวคิด และประเมินว่าพวกเขาคาดหวังให้แก้ปัญหาด้วยวิธีที่มีคุณค่าหรือไม่

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

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

การออกแบบระบบการทดสอบ: ผู้ใช้สามารถสร้างความเข้าใจที่ 'ดีพอ' เกี่ยวกับระบบนี้ได้หรือไม่?

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

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

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

การทดสอบการใช้งาน: ผู้คนสามารถใช้ผลิตภัณฑ์นี้ได้หรือไม่?

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

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

สรุป

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

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

ต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการทำงานร่วมกับทีมของเราหรือไม่? อ่านเกี่ยวกับค่านิยม วิธีทำงาน และบทบาทที่เปิดกว้างของเราที่นี่