ทดสอบและทําซ้ํา
การศึกษาวิจัยผู้ใช้อาจมีประโยชน์อยู่เสมอในระหว่างขั้นตอนการออกแบบ การใช้ฟีดจากผู้ใช้จริงจะช่วยค้นหาว่าสิ่งใดได้ผลและสิ่งใดไม่ได้ผล ยิ่งดําเนินการเร็วเท่าไร ก็ยิ่งดีเท่านั้น
การระบุปัญหาเป็นเรื่องยุ่งยากเมื่อคุณกําลังดื่มด่ํากับการออกแบบ จึงจําเป็นต้องมีความเห็นจากคนภายนอก ข่าวดีก็คือคุณสามารถ (และควร) ทราบข้อมูลเชิงลึกได้อย่างรวดเร็วและง่ายดายว่าการออกแบบของคุณจะได้ผลหรือไม่สําหรับผู้ใช้ก่อนที่จะเขียนโค้ดหนึ่งบรรทัด
รับความคิดเห็นเพื่อดูว่ากล่องโต้ตอบใช้งานได้หรือไม่
ใช้การทดลอง Wizard of Oz
ทําไมจึงเรียกว่า การทดลองของ Wizard of Oz (WOZ) ได้ชื่อมาจากภาพยนตร์เรื่อง The Wizard of Oz ซึ่งอ้างอิงมาว่ามีคนอยู่เบื้องหลังผ้าม่านที่ดึงผ้าพันคออยู่
ต้นแบบของออซต้นแบบคืออะไร พูดง่ายๆ ก็คือ วิธีทดสอบต้นแบบโดยไม่ได้พัฒนาซอฟต์แวร์เลย ต้นแบบ WOZ ใช้ในการประเมินฟังก์ชันการทํางานของการออกแบบ ความสามารถในการบรรลุเป้าหมายของผู้ใช้ และปรับปรุงประสบการณ์ของผู้ใช้ (UX) โดยรวม การทดลองของ WOZ นั้นให้ความรู้สึกเสมือนเป็นประสบการณ์จริง แต่เป็นการสร้างโดยการจําลองบุคคล ("วิซาร์ด") ขึ้นมา จําลองว่าซอฟต์แวร์มีพฤติกรรมอย่างไรในการผลิต ผู้เข้าร่วมอาจจะหรืออาจไม่รู้ว่ากําลังโต้ตอบกับวิซาร์ดหลังม่าน
เหตุผลที่ควรทํา ข้อได้เปรียบที่สําคัญที่สุดอย่างหนึ่งของการสร้างต้นแบบ WOZ คือคุณสามารถทดสอบการออกแบบได้โดยไม่ต้องสร้าง การทดสอบ WOZ คือผลิตภัณฑ์ต้นแบบที่ใช้งานได้ (MVP) ของต้นแบบสําหรับการทดสอบเสียง ไซต์เหล่านี้ทํางานได้ง่ายและแทบไม่ต้องทําอะไรเลย ต้นแบบอาจเป็นเรื่องง่ายโดยใช้วัตถุในชีวิตประจําวันเพื่อแสดงส่วนต่างๆ ของการออกแบบ หรืออาจเป็นรูปแบบการทํางาน (คอลเล็กชันผลิตภัณฑ์ที่มีอยู่) ที่ทํางานได้ทั้งหมด แต่ไม่ใช่ทั้งหมด ยิ่งต้นแบบต้นแบบทําได้ดีมากเท่าใด ความคิดเห็นของคุณก็จะยิ่งดีขึ้นเท่านั้น แต่ขอให้เลือกอย่างชาญฉลาดว่าจะจัดสรรเวลาให้จัดสรรเวลานี้เป็นระยะเวลาเท่าใด และต้นแบบ "ความจริง" นั้นคุ้มค่าหรือไม่
วิธีทําการทดสอบความสามารถในการใช้งาน
1) การทดสอบ WOZ ที่รวดเร็วและไม่คล่องตัว
2) การทดสอบ WOZ มาตรฐาน
เพื่อจําลองประสบการณ์ที่สมจริงที่สุด ให้จําลองบทบาทของบุคลิกภาพโดยใช้ข้อความแจ้งของบุคลิกลักษณะโดยใช้เครื่องจําลอง TTS ในคอนโซล Actions on Google Developer ดาวน์โหลดเสียงเพื่อให้พร้อมเล่นแบบออนดีมานด์
เวอร์ชันนี้ต้องการ 4 สิ่งต่อไปนี้
- สคริปต์การสนทนาที่แสดงคําแนะนําเกี่ยวกับลักษณะตัวตนหลังจากคําตอบของผู้ใช้แต่ละคน ซึ่งเหมาะกับขั้นตอนในขั้นตอนระดับสูง (หรือเวอร์ชันที่ง่ายกว่า)
- เสียงที่ดาวน์โหลดของข้อความแจ้งที่พูดทั้งหมดของบุคคล ใช้ชื่อไฟล์ที่จะช่วยให้คุณระบุไฟล์ที่ต้องการเล่นได้อย่างรวดเร็ว
- มีคนเล่น "ผู้ใช้" นั้น ผู้ใช้ที่ไม่คุ้นเคยกับการดําเนินการของคุณ
- คนที่จะเล่น "วิซาร์ด" ซึ่งควรเป็นการดําเนินการที่คุณคุ้นเคยเป็นอย่างดี
ให้วิซาร์ดเริ่มต้นการสนทนาด้วยการเล่นเสียงสําหรับคําทักทายของการดําเนินการ เช่น "ยินดีต้อนรับสู่ Launcher ของคุณสําหรับทุกเรื่องใน Google I/O เทศกาลกําลังดําเนินอยู่ในขณะนี้ คุณเป็นผู้โชคดีไหม” วิซาร์ดจะรอให้ผู้ใช้ตอบกลับโดยหวังว่าจะมีคําว่า “ใช่” หรือ “ไม่” เกิดขึ้น เมื่อผู้ใช้ตอบกลับแล้ว วิซาร์ดจะต้องหาวิธีการขั้นสูงก่อนเพื่อเลือกว่าจะเล่นข้อความไหนต่อ จากนั้นค้นหาและเล่นไฟล์เสียงที่ถูกต้อง
3) การทดสอบความสามารถในการใช้งานมาตรฐาน
แน่นอน เมื่อเริ่มสร้างการดําเนินการแล้ว คุณควรทดสอบเป็นประจําโดยใช้เครื่องจําลองการดําเนินการในActions on Google Developer Console ให้เพื่อน ครอบครัว หรือเพื่อนร่วมงานทดสอบการใช้งานด้วย!
| ไม่ว่าคุณจะใช้การทดสอบใด อย่าลืมทําสิ่งต่อไปนี้ | |
|---|---|
| เริ่มสื่อสาร | เนื่องจากเป้าหมายของคุณคือการอัปเดตดีไซน์ของคุณให้ตรงกับความต้องการของผู้ใช้จริงมากที่สุด คุณจึงอยากให้ต้นแบบ WOZ ใกล้เคียงกับความเป็นจริงมากที่สุด สิ่งที่ดูดีบนกระดาษอาจฟังดูไม่เป็นธรรมชาติหรือดูเหมือนเป็นไปอย่างเป็นธรรมชาติในการสนทนาจริง ดังนั้นโปรดตรวจสอบว่าผู้ใช้รับฟังข้อความแจ้งของคุณและพูดคําตอบของพวกเขา |
| บันทึกเซสชัน | รับสิทธิ์บันทึกเซสชันเพื่อให้คุณกลับไปฟังได้ จดบันทึกปัญหาใดๆ ที่เกิดขึ้นในระหว่างเซสชัน |
| ขอความคิดเห็น | ขอให้ผู้ใช้อธิบายประสบการณ์ด้วยคําพูด และทําได้สําเร็จหรือไม่ มีอะไรที่ทําให้พวกเขาประหลาดใจไหม พึงพอใจไหม จําไว้ว่าจุดมุ่งเน้นอยู่ที่พฤติกรรมของผู้ใช้ ไม่ใช่ความคิดเห็นของพวกเขา |
สิ่งที่คุณจะได้เรียนรู้
การเรียกใช้การทดสอบ WOZ จะช่วยให้คุณเข้าใจลักษณะการมีส่วนร่วมของผู้ใช้ในการออกแบบ คุณอาจพบว่าผู้ใช้ทําสิ่งที่แตกต่างจากที่คาดไว้ ซึ่งทําให้คุณต้องแก้ไขการออกแบบให้สอดคล้องกับความต้องการและความคาดหวังของผู้ใช้มากขึ้น
ส่วนสําคัญที่สุด: มุ่งเน้นที่ความสามารถในการใช้งานการออกแบบ (ไม่ใช่ความคิดเห็นของผู้ใช้) ทําซ้ําโดยอิงตามพฤติกรรมของผู้ใช้ และทดสอบอีกครั้งหากมีเวลา
| สิ่งที่ควรพิจารณา (และวิธีที่คุณสามารถเพิ่มบทโต้ตอบ) | |
|---|---|
| การสนทนาตามธรรมชาติ | ให้ความสําคัญกับวิธีที่ผู้ใช้จะขอสิ่งต่างๆ ตามปกติ รู้สึกว่าสามารถพูดด้วยวลีสั้นๆ ที่คล้ายกับคําหลักเท่านั้น หรือฟังดูเหมือนเป็นบทสนทนามากกว่า พวกเขารู้สึกลังเลหรือมั่นใจเวลาคุยกับตัวตนของคุณหรือไม่ โฟลวทําให้ผู้ใช้รู้สึกว่าสามารถให้ข้อมูลเพียง 1 ส่วนต่อครั้งเท่านั้น หรือส่งเสริมให้ผู้ใช้ใส่รายละเอียดหลายรายการใน 1 ประโยค |
| ความสับสนของผู้ใช้ | มองหาจุดที่ผู้ใช้ดูสับสนหรือไม่แน่ใจว่าต้องทําอะไรหรือทําอย่างไร ตรวจสอบข้อความแจ้งก่อนหน้านี้เพื่อดูว่าคุณควรอธิบายตรงไหน คํากระตุ้นการตัดสินใจชัดเจนหรือไม่ |
| การเปล่งเสียงที่ไม่คาดคิด | ผู้ใช้อาจพูดสิ่งที่คุณไม่คาดคิด จดบันทึกและเพิ่มการจัดการในการออกแบบ |
| สัญญาณของความไม่สบายใจหรือความไม่สบายใจ | ซึ่งมักเป็นสัญญาณว่าการโต้ตอบนั้นยาวเกินไป ตรวจสอบข้อความที่คุณได้รับเพื่อดูว่ากระชับได้ใจความหรือไม่ มีรายละเอียดที่สามารถละเว้นได้หรือไม่ |
| สังเกตว่าใครพูดมากที่สุด | ผู้ใช้ดูเหมือนจะเป็นผู้ควบคุมการสนทนาใช่ไหม หากไม่ คุณจะเปลี่ยนได้อย่างไร |
วิธีทดสอบการดําเนินการ
การทดสอบที่มีประสิทธิภาพจําเป็นต่อการพัฒนาซอฟต์แวร์ที่มีคุณภาพสูงและการสร้างความพึงพอใจของผู้ใช้
Aylin Altiok และ Nick Felker กล่าวถึงการดําเนินการของคุณในงาน Google I/O 2018