วิธีป้องกันฟีเจอร์คืบคลานด้วย User Story Best Practices
เผยแพร่แล้ว: 2022-03-11เป็นส่วนหนึ่งของการเล่าเรื่องเกี่ยวกับผลิตภัณฑ์ดิจิทัลที่ใหญ่ขึ้น การทำงานกับเรื่องราวของผู้ใช้ตลอดกระบวนการออกแบบช่วยให้นักออกแบบมุ่งเน้นที่การปรับปรุง UX เรื่องราวของผู้ใช้ที่เขียนอย่างชัดเจนสามารถช่วยให้ผู้คนเป็นศูนย์กลางของกระบวนการออกแบบ เอาใจใส่กับกลุ่มเป้าหมายของผลิตภัณฑ์ และสร้างแนวคิดที่เหมาะกับชีวิตของผู้คนมากขึ้น
บ่อยแค่ไหนที่นักออกแบบผลิตภัณฑ์พบว่าตัวเองอยู่ในสถานการณ์ "วางเกวียนไว้ข้างหน้าม้า" ที่เป็นที่เลื่องลือ? เมื่อโปรเจ็กต์เริ่มต้นขึ้น เราจะหารายละเอียดทางเทคนิคและวิธีที่เราจะนำเสนอ มีการกำหนดกรอบงานการพัฒนา กำหนดอุปกรณ์เป้าหมาย กำหนดขนาดหน้าจอ จากนั้นทีมงานจะเข้าสู่การสร้างโซลูชัน สุ่มเพิ่มคุณสมบัติผลิตภัณฑ์
ในระหว่างกระบวนการนี้ เราสร้างสิ่งประดิษฐ์ UX อย่างบ้าคลั่ง: บอร์ดอารมณ์ แผนผังเว็บไซต์ ขั้นตอนของผู้ใช้ บุคลิก และแผนที่เอาใจใส่ เป็นต้น เรือบรรทุกแต่แล่นโดยไม่มีหางเสือหรือแผนที่ อยู่มาวันหนึ่งเราตื่นขึ้นและพบว่า " ทำไมเราจึงสร้างผลิตภัณฑ์นี้ เราจะกำหนดคุณลักษณะของผลิตภัณฑ์อย่างไร และเราจะจัดลำดับความสำคัญอย่างไร ”
การโทรปลุกแบบคลาสสิก
“ฟีเจอร์คืบคลาน” ที่น่ากลัวกำลังย่องเข้ามาใกล้ใต้จมูกของเรา
โชคดีที่มีมาตรการรับมือ เป็นกลยุทธ์การออกแบบที่เรียกว่า เรื่องราวของผู้ใช้
เรื่องราวของผู้ใช้เป็นเทคนิคการออกแบบร่วมกันสำหรับทีมผลิตภัณฑ์ นำมาใช้จากวิธีการพัฒนาซอฟต์แวร์ Agile โดยทั่วไปแล้วทีม Agile จะเน้นไปที่การบรรลุเป้าหมายเล็กๆ ในระหว่างการวิ่ง พวกเขาเน้นที่ความเร็ว วัตถุประสงค์ และผลลัพธ์ แทนที่จะเป็นเอกสารประกอบที่ครอบคลุม ดังนั้นแนวคิดของเรื่องราวของผู้ใช้
สำหรับทีม Agile ส่วนใหญ่ เรื่องราวของผู้ใช้เป็นสื่อหลักในการส่งมอบซอฟต์แวร์เพิ่มเติม พันธมิตรเปรียว
เรื่องราวของผู้ใช้คืออะไร?
เรื่องราวของผู้ใช้อธิบายบางสิ่งที่ผู้ใช้ต้องการทำให้สำเร็จ เรื่องราวของผู้ใช้สามารถช่วยนักออกแบบและทีมพัฒนาให้จดจ่อกับความต้องการของผู้ใช้ แทนที่จะมัวแต่หมกมุ่นอยู่กับการเพิ่มคุณสมบัติผลิตภัณฑ์
เรื่องราวของผู้ใช้นั้นสั้น เฉพาะเจาะจง และมุ่งเน้นเป้าหมาย เป็นคำสั่งหนึ่งประโยคที่มีกรอบจากมุมมองของผู้ใช้ซึ่งมีโครงสร้างดังต่อไปนี้:
“ ในฐานะที่เป็น (ประเภทผู้ใช้) ฉันต้องการ (เป้าหมาย) เพื่อที่ฉันจะได้ (ได้รับผลประโยชน์) ”
เรื่องราวของผู้ใช้ช่วยให้ทีมสามารถสนทนาเกี่ยวกับโครงการได้ดีขึ้นตลอดกระบวนการพัฒนา ช่วยป้องกันการคืบคลานของคุณลักษณะ เนื่องจากการทำงานกับคุณลักษณะเหล่านี้ช่วยให้เกิด ความเข้าใจร่วมกันว่าทีมกำลังพยายามสร้างอะไรและเพราะเหตุใด
หากมีหลักการใดที่ศักดิ์สิทธิ์สำหรับผู้ที่อยู่ในด้านการออกแบบส่วนต่อประสานผู้ใช้และการโต้ตอบระหว่างมนุษย์กับคอมพิวเตอร์ แสดง ว่าผู้ใช้ของคุณทราบ Don Norman ผู้ร่วมก่อตั้งและอาจารย์ใหญ่กิตติคุณ Nielsen Norman Group
การจัดแนวเรื่องราวของผู้ใช้ระหว่างการออกแบบและ Agile
เรื่องราวของผู้ใช้เป็นแนวคิดที่นักพัฒนาเข้าใจ ไม่ว่าจะเป็นช่วงเริ่มต้นของโครงการหรือระหว่างการพัฒนาผลิตภัณฑ์ นักออกแบบสามารถทำงานร่วมกับนักพัฒนาได้อย่างมีประสิทธิภาพมากขึ้นโดยการทำงานกับเรื่องราวของผู้ใช้ สามารถวางแผนคุณลักษณะของผลิตภัณฑ์ร่วมกัน เพิ่มประสิทธิภาพการพัฒนา และชี้แจง ผลลัพธ์ที่ทีมควรมุ่งเน้น
ที่กล่าวว่า นักออกแบบหลายคนไม่สมัครรับแนวคิดที่ว่า Agile และ UX สามารถเล่นด้วยกันได้ดี ความเชื่อมั่นอย่างหนึ่งคือแรงกระตุ้นและไทม์ไลน์ที่แตกต่างกันทั้งสองไม่สอดคล้องกัน เรื่องราวของผู้ใช้ไม่เข้ากับกระบวนการออกแบบแบบองค์รวมในทันที เนื่องจากในการพัฒนา จุดเน้นอยู่ที่วงจรการส่งมอบในระยะสั้น แนวคิดอีกประการหนึ่งคือเรื่องราวของผู้ใช้ไม่เพียงพอต่อแนวทางการออกแบบ—ขาดมุมมองที่พิจารณาภาพรวม: ความสมบูรณ์ของประสบการณ์ผู้ใช้
ความเชื่อเหล่านี้ใช้ได้ในระดับหนึ่ง แต่ยัง เข้าใจผิด
มาล้างแอร์กัน ประการแรก นักออกแบบต้องตระหนักว่าการทำงานกับเรื่องราวของผู้ใช้เป็น กระบวนการออกแบบร่วมกัน แม้ว่าอาจไม่สอดคล้องกับ Agile sprints ในด้านการพัฒนาอย่างสมบูรณ์ แต่ก็สามารถเป็นส่วนหนึ่งของ กระบวนการออกแบบแบบอะซิงโครนัสที่ครอบคลุมมากขึ้นเมื่อทำงานร่วมกับนักพัฒนา เรื่องราวของผู้ใช้ยังช่วยให้ทีมที่อยู่ในสถานที่ต่างๆ ทำงานร่วมกันได้ง่ายขึ้นอีกด้วย
ประการที่สอง เรื่องราวของผู้ใช้เป็นส่วนหนึ่งของการออกแบบที่เน้นมนุษย์เป็นศูนย์กลางและเน้นกิจกรรม แทนที่จะมุ่งเน้นไปที่การเพิ่มคุณลักษณะของผลิตภัณฑ์มากขึ้นเรื่อย ๆ ซึ่งเป็น "คุณลักษณะที่คืบคลาน" ที่เป็นที่เลื่องลือ - เรื่องราวของผู้ใช้ทำให้เป็นจริง เรื่องราวของผู้ใช้อยู่เบื้องหลังทุกกิจกรรมที่ผู้คนทำ ซึ่งประกอบด้วยงาน ซึ่งจะเป็นชุดของการกระทำ เป็นผลให้ผลิตภัณฑ์ได้รับการพัฒนาโดยมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับกิจกรรมของผู้ใช้ การทำงานกับเรื่องราวของผู้ใช้เข้ากันได้ดีกับความพยายามแบบองค์รวมในการออกแบบประสบการณ์ผู้ใช้ที่น่าพึงพอใจ
เรื่องราวของผู้ใช้สำหรับการทดสอบผลิตภัณฑ์และการวัด UX
เรื่องราวของผู้ใช้ระบุไว้อย่างชัดเจนให้พลังในด้านต่างๆ ของการออกแบบผลิตภัณฑ์ที่ยอดเยี่ยม การทบทวนเรื่องราวของผู้ใช้เป็นระยะๆ และตรวจสอบว่าเป้าหมายของผู้ใช้นั้นสามารถทำได้หรือไม่— การทดสอบการยอมรับ สำหรับเรื่องราวของผู้ใช้หนึ่งๆ—จะช่วยให้ทีมผลิตภัณฑ์สามารถดำเนินการได้
ธุรกิจมักใช้เวลาและเงินเป็นจำนวนมากในการสร้างผลิตภัณฑ์ที่ลูกค้าไม่ต้องการหรือไม่ต้องการ ทำให้สิ้นเปลืองทั้งเวลาและทรัพยากร ผลิตภัณฑ์อาจมีเจตนาดี แต่ล้มเหลวเนื่องจากไม่ได้ระบุความต้องการที่สามารถระบุได้ในลักษณะที่ผู้บริโภคเข้าใจ
โดยผู้ใช้ทดสอบผลิตภัณฑ์กับผู้มีโอกาสเป็นลูกค้า ทีมผลิตภัณฑ์สามารถเข้าใจ ได้ว่าผลิตภัณฑ์สามารถแก้ปัญหาความต้องการที่ระบุได้อย่างชัดเจน หรือไม่ เป็นวิธีวัดความสำเร็จ การสร้างและทดสอบต้นแบบโดยอิงจากเรื่องราวของผู้ใช้ที่กำหนดไว้อย่างดี นักออกแบบสามารถวัดเวลาที่งานเสร็จสิ้นและอัตราความสำเร็จได้ ไม่เพียงแต่ในช่วงเริ่มต้นของการออกแบบผลิตภัณฑ์แต่ตลอดวงจรชีวิตการพัฒนาผลิตภัณฑ์ ในการทำเช่นนั้น ทีมงานสามารถดูได้ว่าผลิตภัณฑ์ดีขึ้นและดีขึ้นในการตอบสนองความต้องการของลูกค้า หรือไม่
นอกจากนี้ สามารถใช้เรื่องราวของผู้ใช้เพื่อกำหนดผลลัพธ์ UX (ประเมินโดยเมตริกความสำเร็จของ UX) และช่วยนักออกแบบตรวจสอบวิวัฒนาการของผลิตภัณฑ์ด้วยเมตริกความคืบหน้าของ UX
- ผลลัพธ์ UX จะ ซิงค์ทุกคนกับสิ่งที่กำลังสร้างขึ้น
- เมตริกความสำเร็จของ UX จะบอกทีมเมื่อพวกเขาบรรลุผลสำเร็จ
- เมตริกความคืบหน้าของ UX ช่วยให้ทีมติดตามและประเมินความคืบหน้าไปพร้อมกันได้
วิธีสร้างเรื่องราวของผู้ใช้ที่ยอดเยี่ยม
การสร้างเรื่องราวของผู้ใช้เริ่มต้นด้วยบุคลิกที่กลั่นจากข้อมูลเชิงลึกของการวิจัยผู้ใช้ ความเข้าใจอย่างลึกซึ้งเกี่ยวกับบุคลิกจะช่วยให้นักออกแบบสร้างเรื่องราวที่มีความหมายซึ่งเชื่อมโยงกับเป้าหมายของผู้ใช้ที่ใหญ่ขึ้น ในกระบวนการนี้ สามารถเปิดเผยความต้องการของผู้ใช้ที่ไม่ได้รับการตอบสนอง และสร้างการเล่าเรื่องเกี่ยวกับผลิตภัณฑ์ (เรียกว่า Epics in Agile)
นักออกแบบสามารถนำการเล่าเรื่อง UX จำนวนมาก ขับเคลื่อนโดยบุคคลและเป้าหมายของผู้ใช้ และแบ่งออกเป็นส่วนเล็กๆ: เรื่องราวของผู้ใช้ ตัวอย่างเช่น สมมติว่าเรากำลังทำงานกับแอปธนาคารบนมือถือ เป้าหมาย ของ Epic คือ "การจัดการเงินในขณะเดินทาง" เป้าหมายผู้ใช้ที่ใหญ่กว่านี้สามารถแบ่งออกเป็นเรื่องราวของผู้ใช้ที่มีขนาดเล็กลงได้ เช่น:
- ในฐานะเจ้าของธุรกิจ ฉันต้องการฝากเงินมือถือเพื่อประหยัดเวลา
- ในฐานะเจ้าของธุรกิจ ฉันต้องการสมัครสินเชื่อระหว่างเดินทางเพื่อรับเครดิตเร็วขึ้น
- ในฐานะเจ้าของธุรกิจ ฉันต้องการตรวจสอบบัญชีของฉันด้วยแอปเพื่อควบคุมการเงินของฉัน
เราจะมากับเรื่องราวของผู้ใช้ดังกล่าวได้อย่างไร โดยใช้เทคนิคการวิจัย UX ที่หลากหลาย เช่น การสร้างเงา (เทคนิคการสังเกต) การศึกษาไดอารี่ และการสัมภาษณ์ผู้ใช้ หรืออีกทางหนึ่ง นักออกแบบสามารถใช้การวิเคราะห์ผลิตภัณฑ์เพื่อระบุรูปแบบของพฤติกรรมผู้ใช้และแสดงโครงสร้างพื้นฐานที่ขับเคลื่อนรูปแบบเหล่านั้น

ตัวอย่างเช่น จากการสังเกตกระแสเหตุการณ์ ข้อมูลอาจแสดงว่างานหลายอย่างไม่สามารถทำให้เสร็จได้ งานเริ่มต้นขึ้น มีความคืบหน้า แต่ระบุด้วยทางออกที่ไม่คาดคิดระหว่างงาน พวกเขาไม่ได้ข้อสรุป รูปแบบดังกล่าวจะชี้ไปที่คนที่ยอมแพ้ด้วยความหงุดหงิดเนื่องจากผลิตภัณฑ์ไม่ได้ให้วิธีง่ายๆ ในการบรรลุชุดงานที่ประสาน กัน นักออกแบบ UX ที่เข้าใจได้จะมองเห็นปัญหา ตรวจสอบด้วยการวิจัยผู้ใช้เพิ่มเติม ออกแบบคุณลักษณะของผลิตภัณฑ์ที่ไม่มีประสิทธิภาพใหม่ และทดสอบการทำงานให้เสร็จสิ้นอีกครั้ง
วิธีเขียนและจัดลำดับความสำคัญเรื่องราวของผู้ใช้
ใครเขียนเรื่องราวของผู้ใช้? ตามเนื้อผ้า การเขียนเรื่องราวของผู้ใช้เป็นความรับผิดชอบของผู้จัดการผลิตภัณฑ์ในการดำเนินการพัฒนาไปพร้อมกัน (บ่อยครั้งเมื่อไม่มีนักออกแบบในทีม) อย่างไรก็ตาม เมื่อมีนักออกแบบอยู่ในทีม อาจเป็นการดีที่สุดถ้านักออกแบบเขียนถึงพวกเขา พวกเขาได้ทำการวิจัยผู้ใช้และคุ้นเคยกับบุคลิกของผู้ใช้และความต้องการมากที่สุด
ตามเทคนิคแล้ว เรื่องราวของผู้ใช้ต้องมีขนาดกะทัดรัดและน้ำหนักเบา ช่วยให้ทีมสร้างผลิตภัณฑ์ได้อย่างรวดเร็ว ดังที่ได้กล่าวไว้ก่อนหน้านี้ พวกเขาจำเป็นต้องเขียนเป็นประโยคง่ายๆ ประโยคเดียวจากมุมมองของผู้ใช้: “ ในฐานะที่เป็น (ผู้ใช้) ฉันต้องการ (ทำบางสิ่ง/เป้าหมาย) เพื่อที่ฉันจะสามารถ (บรรลุผลลัพธ์ที่ต้องการ) ”
เรื่องราวของผู้ใช้ที่สร้างขึ้นในรูปแบบดังกล่าวช่วยปรับคุณลักษณะทั้งหมดที่เพิ่มลงในผลิตภัณฑ์และให้เหตุผลเบื้องหลังการตัดสินใจออกแบบทุกครั้งในระดับแนวหน้า: " เหตุผลที่เราทำในสิ่งที่เราทำ ”
ในการเขียนเรื่องราวของผู้ใช้ที่ยอดเยี่ยม:
- ควรมีความชัดเจน จดจ่อ และนำไปปฏิบัติได้
- ควรจับเรื่องราวในแบบที่รู้สึกมีค่า
- สามารถแปลเป็นคุณลักษณะของผลิตภัณฑ์ได้
- มีการทดสอบการยอมรับ (บรรลุเป้าหมายหรือไม่)
เมื่อเขียนแล้ว เรื่องราวของผู้ใช้จะต้องจัดลำดับความสำคัญเป็นเมทริกซ์ เมทริกซ์ลำดับความสำคัญที่คุ้นเคยสำหรับผู้จัดการผลิตภัณฑ์จะช่วยให้แน่ใจว่าทีมผลิตภัณฑ์มุ่งเน้นไปที่คุณลักษณะที่มีผลกระทบมากที่สุดเป็นอันดับแรก สำหรับนักออกแบบ นี่หมายถึงการจัดลำดับความสำคัญเรื่องราวของผู้ใช้ที่ให้คุณค่าสูงสุดแก่ลูกค้า
มีหลายแง่มุมที่มีอิทธิพลต่อดัชนีลำดับความสำคัญของเรื่องราวของผู้ใช้:
- วัตถุประสงค์ทางธุรกิจ เรื่องราวของผู้ใช้ที่ส่งผลกระทบโดยตรงต่อรายได้ของบริษัทควรได้รับค่าดัชนีที่สูงกว่าค่าที่พึงประสงค์เพียงอย่างเดียว
- การพึ่งพาการทำงาน หากเรื่องราวของผู้ใช้หลายเรื่องสามารถนำมาใช้ได้หลังจากเรื่องราวใดเรื่องหนึ่งเท่านั้น เรื่องหลังจะกลายเป็นเรื่องสำคัญและได้รับค่าดัชนีที่สูงขึ้น
- เวลาพัฒนา . หากทีมนักพัฒนาประเมินเรื่องราวของผู้ใช้ว่ารวดเร็วในการนำไปใช้และจำเป็นต่อการบรรลุวัตถุประสงค์ทางธุรกิจ เรื่องราวจะได้รับค่าดัชนีที่สูงขึ้น
ประโยชน์ของเรื่องราวของผู้ใช้ในการออกแบบ
การทำงานกับเฟรมเวิร์กเรื่องราวของผู้ใช้ช่วยให้มั่นใจว่าผลิตภัณฑ์มีเฉพาะฟีเจอร์ที่ผู้ใช้ต้องการเทียบกับฟีเจอร์ที่ทีมผลิตภัณฑ์หวังว่าจะใช้ตามสมมติฐาน กล่าวอีกนัยหนึ่ง การทำงานกับเรื่องราวของผู้ใช้จะช่วยป้องกันฟีเจอร์คืบคลาน
การทำงานกับเรื่องราวของผู้ใช้มีประโยชน์หลายประการ:
- ให้ภาษาทั่วไป เรื่องราวของผู้ใช้กลายเป็นภาษากลางสำหรับทีมพัฒนาทั้งหมด ทำให้ไม่ต้องให้ความสำคัญกับโซลูชันและฟีเจอร์ แต่พวกเขาวางกรอบการอภิปรายเกี่ยวกับสิ่งที่จะต้องบรรลุ
- ส่งเสริมความร่วมมือ พวกเขากระตุ้นการทำงานร่วมกันระหว่างผู้ใช้ นักออกแบบ และทีมพัฒนา
- ทำให้เกิดความเข้าใจร่วมกัน ช่วยพัฒนาความเข้าใจความต้องการของผู้ใช้ร่วมกันโดยใช้ภาษาทั่วไป
- เพิ่มความโปร่งใส พวกเขาเพิ่มความเปิดกว้างระหว่างสมาชิกในทีมซึ่งตอกย้ำความไว้วางใจ
- มีความครอบคลุมและเหนียวแน่น การแปลข้อกำหนดของโครงการเป็นเรื่องราวของผู้ใช้นั้นค่อนข้างง่ายเพื่อจัดการกับโครงการ การดูเรื่องราวของผู้ใช้ให้ความรู้สึกที่ชัดเจนกว่า "โครงการเกี่ยวกับอะไร" มากกว่ารายการคุณลักษณะและข้อกำหนดด้านฟังก์ชัน
- ให้ความยืดหยุ่น การเข้าถึงและการจัดการ เรื่องราวของผู้ใช้มีความตรงไปตรงมาทางแนวคิดเมื่อเทียบกับเอกสารอื่นๆ และสามารถสร้างได้อย่างรวดเร็ว ผู้ใช้ยังสามารถมีส่วนร่วมในรุ่นของพวกเขา และผู้มีส่วนได้ส่วนเสียสามารถแก้ไขเรื่องราวของผู้ใช้หรือเพิ่มเรื่องราวของตนเองได้อย่างง่ายดาย
- เปลี่ยนมุมมองของโครงการ เรื่องราวของผู้ใช้เปลี่ยนมุมมองของโปรเจ็กต์จากรายการข้อกำหนดที่อาจเป็นไปได้แบบสุ่มและนามธรรม เป็นการแสดงถึงกิจกรรมที่เน้นผู้ใช้เป็นหลัก
- อำนวยความสะดวกในการส่งมอบมูลค่าสูงสุด ช่วยนำเสนอคุณลักษณะที่มุ่งเน้นลูกค้าซึ่งให้ประโยชน์สูงสุด
- ให้รายการตรวจสอบ พวกเขาเปิดใช้งานการวัดเทียบกับความสำเร็จของงาน หากผู้ใช้ทำงานไม่สำเร็จ แสดงว่าผลิตภัณฑ์ล้มเหลว
การออกแบบผลิตภัณฑ์ที่ดีขึ้นด้วย User Story Mapping
นักออกแบบไม่ควรพึ่งพาเรื่องราวของผู้ใช้เพียงลำพังเพื่อขับเคลื่อนการออกแบบผลิตภัณฑ์ —กระบวนการออกแบบผลิตภัณฑ์ที่ครอบคลุมเกี่ยวข้องกับวิธีการและสิ่งประดิษฐ์อื่นๆ มากมาย เรื่องราวของผู้ใช้ที่ผสานรวมอย่างดีควรเติมเต็มซึ่งกันและกัน เช่น ชิ้นส่วนปริศนาที่ประกอบเป็น UX ของผลิตภัณฑ์ทั้งหมด ในทางกลับกัน เรื่องราวของผู้ใช้ที่ไม่ปะติดปะต่อกันจะรบกวนความเหนียวแน่นของประสบการณ์ผู้ใช้
ปัญหาที่อาจเกิดขึ้นอื่น ๆ เมื่ออาศัยเพียงเรื่องราวของผู้ใช้เพื่อขับเคลื่อนการออกแบบ:
- ขาดบริบท (ละเลยผลลัพธ์ UX โดยรวม)
- ไม่มีความรู้สึกครบถ้วน (ไม่แน่ใจว่าครอบคลุมเป้าหมายที่ใหญ่กว่าหรือไม่)
- เรื่องราวของผู้ใช้สับสนกับกรณีการใช้งาน
- ไม่พัฒนาผลิตภัณฑ์ (เรื่องราวของผู้ใช้ไม่ได้รับการแก้ไข พวกเขามักจะเปลี่ยนไปตามกาลเวลา)
การสร้างแผนที่เรื่องราวของผู้ใช้ช่วยให้เรามุ่งความสนใจไปที่ภาพรวม ซึ่งเป็นผลิตภัณฑ์โดยรวม แทนที่จะมุ่งความสนใจไปที่เรื่องราวส่วนบุคคล เจฟฟ์ แพตตัน ผู้แต่งหนังสือ User Story Mapping
สรุป
การทำงานกับเรื่องราวของผู้ใช้ในการออกแบบช่วยวัดผลที่สำคัญที่นักออกแบบต้องการเพื่อนำเสนอผลิตภัณฑ์ที่ออกแบบมาอย่างดี วินัยในการปฏิบัติตามเฟรมเวิร์กเรื่องราวของผู้ใช้ยังหมายถึงการไม่วางองค์ประกอบการออกแบบใน UI ที่ไม่มีเรื่องราวของผู้ใช้ที่สอดคล้องกัน
ความน่าสนใจของเรื่องราวของผู้ใช้คือการที่พวกเขา ระบุความต้องการด้านฟังก์ชัน แต่ไม่ได้กำหนด วิธีการออกแบบผลิตภัณฑ์ เพื่อตอบสนองความต้องการด้านฟังก์ชันเหล่านั้น พวกเขาให้ความสำคัญกับปัญหาก่อนที่จะกำหนดแนวทางแก้ไข
นักออกแบบควรมองว่าเรื่องราวของผู้ใช้เป็นส่วนประกอบสำคัญในการออกแบบผลิตภัณฑ์ แมปเรื่องราวของผู้ใช้เพื่อสร้าง UX ที่สอดคล้องกัน และใช้แนวทางปฏิบัติที่ดีที่สุดสำหรับเรื่องราวของผู้ใช้ โดยจะป้องกันไม่ให้ฟีเจอร์คืบคลาน ช่วยให้ทีมผลิตภัณฑ์สามารถนำเสนอผลิตภัณฑ์ที่ออกแบบได้ดีขึ้น และส่งเสริมให้นักออกแบบสร้างผลิตภัณฑ์ด้วยประสบการณ์ผู้ใช้ที่น่าพึงพอใจและราบรื่น
แจ้งให้เราทราบสิ่งที่คุณคิด! โปรดแสดงความคิดเห็น ความคิดเห็น และข้อเสนอแนะของคุณด้านล่าง
• • •
อ่านเพิ่มเติมเกี่ยวกับบล็อก Toptal Design:
- พลังของ Figma เป็นเครื่องมือออกแบบ
- คู่มือฉบับสมบูรณ์สำหรับการออกแบบการแจ้งเตือน
- Make It Count – คู่มือการวัดประสบการณ์ผู้ใช้
- The Mind's Eye – ดูที่จิตวิทยาการแสดงข้อมูล