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

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

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

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

Double Diamond

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

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

ช่วงเตรียมการ

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

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

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

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

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

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

การอัปเดตคำชี้แจงเกี่ยวกับความท้าทาย

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

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

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

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

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

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

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

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

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

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

Lightning Talk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การทำไวร์เฟรมและการทำสตอรีบอร์ด

Crazy 8s

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

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

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

Crazy 8s เป็นวิธีที่ยอดเยี่ยมในการรวบรวมไอเดียทั้งหมดไว้ในหน้าเดียว
การร่างไอเดีย 8 อย่างเป็นวิธีที่ยอดเยี่ยมในการรวบรวมไอเดียทั้งหมดไว้ในหน้าเดียว
ตอนนี้คุณต้องออกแบบโดยละเอียดตามสิ่งที่คุณได้เรียนรู้
ตอนนี้คุณต้องออกแบบอย่างละเอียดตามสิ่งที่คุณได้เรียนรู้

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

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

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

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

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

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

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

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

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

ทดสอบการใช้งานการออกแบบ

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

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

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

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

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

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

กลับไปดูการออกแบบและทำการทดสอบอีกรอบ

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

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

สร้างเลย

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

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

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