ข้อมูลเบื้องต้นเกี่ยวกับ UX

คำแนะนำทีละขั้นตอนเกี่ยวกับพื้นฐานของการออกแบบ UX

Mustafa Kurtuldu

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

คู่มือนี้ยืมแนวคิดมาจากวิธีการ Design Sprint ที่หลายทีมใน Google ใช้เพื่อแก้ปัญหาและเอาชนะความท้าทายต่างๆ เช่น รถยนต์ขับเคลื่อนอัตโนมัติและ Project Loon

ข้าวหลามตัดคู่

ขั้นตอนการทำงานนี้อิงตามสิ่งที่แวดวง UX เรียกว่า Double Diamond ซึ่งเป็นที่นิยมโดย British Design Council โดยทีมของคุณจะแยกกันเพื่อทำความเข้าใจแนวคิดผ่านการวิจัย จากนั้นจึงรวมตัวกันเพื่อกำหนดความท้าทาย แยกกันเพื่อร่างแนวคิดเป็นรายบุคคล แชร์แนวคิด ตัดสินใจเลือกแนวทางที่ดีที่สุด ทดสอบ และตรวจสอบความถูกต้อง

โมเดลกระบวนการออกแบบ "Double Diamond" ที่ริเริ่มโดย British Design Council มีขั้นตอนที่เกี่ยวข้องกับระยะต่างๆ ของโปรเจ็กต์ ได้แก่ ทำความเข้าใจ กำหนด แยกแยะ ตัดสินใจ สร้างต้นแบบ และตรวจสอบ

การเตรียมความพร้อม

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

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

นี่คือตัวอย่างผลิตภัณฑ์จริงที่ฉันเคยทำในอดีต

• ออกแบบระบบเพื่อจัดการการรักษาและการดูแลติดตามผลของผู้ป่วยที่มีภาวะเท้าปุก

• สร้างแอปที่ลดความซับซ้อนของระบบการเงินที่ซับซ้อนและลดให้เหลือเฉพาะสิ่งที่จำเป็น

• ออกแบบแอปบนอุปกรณ์เคลื่อนที่ที่สอดคล้องกันในแพลตฟอร์มต่างๆ โดยไม่ลดทอนเอกลักษณ์ของแบรนด์

กำลังอัปเดตคำชี้แจงการโต้แย้ง

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

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

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

กำลังตรวจสอบปัญหา

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

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

การสัมภาษณ์ภายในกับผู้มีส่วนเกี่ยวข้อง

การสัมภาษณ์ผู้มีส่วนเกี่ยวข้องจะช่วยให้คุณค้นพบข้อมูลเชิงลึกเกี่ยวกับบริษัทหรือทีมได้

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

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

Lightning Talk

Lightning Talk คือการนำเสนอสั้นๆ ที่ใช้เวลาเพียงไม่กี่นาที

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

• เป้าหมายของธุรกิจ
• ความท้าทายของโปรเจ็กต์จากมุมมองของนักเรียน (อาจเป็นด้านเทคนิค การรวบรวมข้อมูลการวิจัย การสร้างการออกแบบ ฯลฯ)
• การศึกษาวิจัยผู้ใช้ที่คุณมีอยู่ในปัจจุบัน

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

การสัมภาษณ์ผู้ใช้

การสัมภาษณ์ผู้ใช้เป็นวิธีที่ยอดเยี่ยมในการเรียนรู้เกี่ยวกับปัญหาของบุคคลในงานหนึ่งๆ

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

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

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

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

การวิจัยภาคสนามด้านชาติพันธุ์วรรณนา

การสังเกตผู้ใช้ในสภาพแวดล้อมตามธรรมชาติเป็นวิธีที่ยอดเยี่ยมในการทำความเข้าใจวิธีที่ผู้ใช้แก้ปัญหาของตนเอง

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

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

กำลังรวบรวมข้อมูลทั้งหมด

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

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

แผนที่โปรเจ็กต์

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

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

แผนผังโปรเจ็กต์จะแสดงขั้นตอนหลักๆ สำหรับผู้ใช้หรือผู้เล่นแต่ละรายในขั้นตอน

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

การสร้างโครงร่างและสตอรีบอร์ด

Crazy 8s

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

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

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

Crazy 8s เป็นวิธีที่ยอดเยี่ยมในการรวบรวมไอเดียทั้งหมดไว้ในหน้าเดียว

ตอนนี้คุณต้องออกแบบอย่างละเอียดโดยอิงตามสิ่งที่ได้เรียนรู้

ปรับแต่งการออกแบบ

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

สร้างสตอรีบอร์ดของไอเดีย

สตอรีบอร์ดเกี่ยวข้องกับการรวมภาพสเก็ตช์และไอเดียของคุณเข้าเป็นขั้นตอนที่ครอบคลุม

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

การสร้างต้นแบบ

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

ต้นแบบต้องมีความสมจริงมากพอที่จะน่าเชื่อถือ

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

ทดสอบความสามารถในการใช้งานของการออกแบบ

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

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

คำถามที่คุณควรถามตัวเอง

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

สิ่งที่คุณต้องค้นหาคือ

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

ทบทวนการออกแบบและการทดสอบอีกรอบ

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

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

สร้างเลย

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

เราขอย้ำว่าการหาข้อมูลให้มากที่สุดเท่าที่จะทำได้ก่อนที่จะทุ่มเทแรงกายแรงใจและเวลาไปกับสิ่งที่อาจไม่ใช่โซลูชันที่เหมาะสมนั้นสำคัญมาก

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