Agile UX: วิธีผสมผสาน UX และการออกแบบผลิตภัณฑ์เข้ากับ Agile

DevOps มักถูกกำหนดให้เป็นกระบวนการ การดำเนินงาน วิธีการ เครื่องมือ และวัฒนธรรมที่ล้อมรอบการพัฒนาซอฟต์แวร์และระบบของบริษัท

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

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

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

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

Agile ไม่ค่อยฝึกฝนเกี่ยวกับ UX หรือการทำงานกับผู้เชี่ยวชาญ UX

ทีมวิศวกรจำนวนมากมักพบว่า UX นั้นไม่เป็นระเบียบและทำงานร่วมกันได้ยาก UX นั้นดูไม่ค่อยเป็นแบบ Lean และ Agile หลายๆ รสชาติก็ไม่รวมข้อมูลเฉพาะเกี่ยวกับวิธีการทำงานกับ UX วิธีการแบบ Agile บางอย่างแนะนำเป็นพิเศษว่าเจ้าของผลิตภัณฑ์ที่อธิบายคุณลักษณะนั้น "ดีพอ"

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

การขาดการอธิบาย UX และกระบวนการของพวกเขาจากการฝึกอบรมและหนังสือแบบ Agile ทำให้ทีมชั้นนำทั่วโลกแยกหรือลดการมีส่วนร่วมของนักออกแบบผลิตภัณฑ์ผู้เชี่ยวชาญ

• เมื่อคุณคิดผิดว่า UX แค่วาดกล่องบนหน้า มันง่ายที่จะถือว่า "ฉันทำงานนั้นได้" เช่นเดียวกับผู้เข้ารับการคัดเลือก American Idol หลายคนแน่ใจว่าพวกเขาเป็นนักร้องที่เก่งที่สุดในโลก ผู้จัดการผลิตภัณฑ์และวิศวกรส่วนใหญ่ประเมินตนเองว่ายอดเยี่ยมใน UX ซึ่งปกติแล้วหมายความว่าพวกเขาเชื่อว่าพวกเขาเก่งในการวางหน้าจอ แต่เนื่องจากบทความนี้จะอธิบายสิ่งที่เข้าสู่งาน UX จริงๆ คุณจะเห็นว่าผู้เชี่ยวชาญ UX จะไม่เห็นนักพัฒนาที่สร้างไวร์เฟรมเป็นคนที่ควรได้รับงาน UX อย่างไร
• Books on Scrum แนะนำว่าหากผู้เชี่ยวชาญ UX กลายเป็นคอขวด เธอควรฝึกบทบาทที่ไม่ใช่ UX เพื่อทำงานของเธอ การตัดสินใจประเภทนี้มักไม่ค่อยแนะนำเกี่ยวกับบทบาทอื่นๆ ในการพัฒนาซอฟต์แวร์ ไม่มีใครอยากให้นักพัฒนาที่ไม่ได้รับการฝึกฝนหรือไม่มีประสบการณ์มาเขียนโค้ด แม้กระทั่งหลังจาก bootcamp หรืออ่านหนังสือเกี่ยวกับการเขียนโปรแกรม เราไม่เคยแนะนำว่าหากนักพัฒนากลายเป็นคอขวด เธอควรฝึกอบรมผู้จัดการโครงการให้ทำการเข้ารหัส
• การจ้างผู้จัดการที่เข้าใจผิดคิดว่า UX เป็นงานด้านศิลปะ (UI) จ้างศิลปินให้ทำงาน UX ไม่มีความเหลื่อมล้ำทางการศึกษาระหว่างปริญญาใน UX และใน UI พรสวรรค์ตามธรรมชาติมักไม่ทับซ้อนกัน คนที่เก่งด้าน UX อาจเป็นศิลปินที่น่าสงสาร และในทางกลับกัน การจ้างงานสำหรับ “UX/UI” มักจะมอบศิลปินที่ยอดเยี่ยมให้กับคุณโดยมีประสบการณ์ UX ความเชี่ยวชาญ กระบวนการ หรือการศึกษาเพียงเล็กน้อย

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

ความสำคัญของการรวมผู้เชี่ยวชาญ UX ผู้เชี่ยวชาญใน Agile

ในช่วงปลายปี 2018 บริษัทที่ปรึกษาด้านการจัดการ McKinsey & Company ได้ตีพิมพ์รายงาน “The Business Value of Design” ซึ่งเป็นรายงานเกี่ยวกับการวิจัยที่พวกเขาทำกับบริษัทมากกว่า 300 แห่ง

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

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

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

McKinsey รวบรวมข้อมูลเชิงปริมาณและพบว่าบริษัทที่นำการออกแบบ UX มาใช้สร้างรายได้เพิ่มขึ้น 32% และผลตอบแทนของผู้ถือหุ้นเพิ่มขึ้น 56% ในระยะเวลา 5 ปี การประกาศว่าบริษัทของคุณเป็น "ผู้ใช้เป็นศูนย์กลาง" นั้นไม่เพียงพอ คุณต้องเดินตามด้วยการบูรณาการผู้ปฏิบัติงาน UX และกระบวนการต่างๆ ตั้งแต่การวางแผนและพอร์ตโฟลิโอไปจนถึงการพัฒนาและ QA

กระบวนการพัฒนาซอฟต์แวร์ที่มีและไม่มี UX

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

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

วิศวกรรมต้องวนกลับมาที่จุดเริ่มต้น ค้นหาว่าตอนนี้บุคคลนี้ต้องการอะไร สร้าง ทดสอบ และไขว้นิ้วว่านี่คือเสน่ห์

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

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

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

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

UX มีกระบวนการที่เป็นทางการ

การออกแบบที่เน้นผู้ใช้เป็นศูนย์กลาง (UCD) เป็นกระบวนการที่เป็นทางการซึ่งรวมถึงงานที่นำผู้เชี่ยวชาญ UX ไปสู่การวิจัย ออกแบบ สร้างต้นแบบ ทดสอบกับผู้ใช้จริงหรือตามแบบฉบับ จากนั้นทำซ้ำตามการเรียนรู้จากการทดสอบ

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

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

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

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

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

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

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

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

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

การสร้างต้นแบบ UX ทำได้เพื่อ:

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

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

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

มีเหตุผลสำคัญ 5 ประการที่ UX ทำการทดสอบก่อนส่งมอบให้กับฝ่ายวิศวกรรม:

1. ใช้เวลาและทรัพยากรด้านวิศวกรรมให้ดีที่สุด หากคุณต้องการให้ผู้เข้าร่วมทดสอบเห็นผลิตภัณฑ์สำเร็จรูปที่สร้างโดยวิศวกร คุณต้องสร้างและทดสอบหาจุดบกพร่อง หากการทดสอบ UX ทำให้เกิดการเปลี่ยนแปลงที่จำเป็น นักพัฒนาจะต้องสร้างใหม่และ QA จะต้องทดสอบใหม่ หากการทดสอบ UX แสดงให้เห็นความล้มเหลวของแนวคิดในวงกว้าง นี่อาจหมายความว่าเวลาทางวิศวกรรมนั้นสูญเปล่าไปโดยเปล่าประโยชน์ เนื่องจากนี่ไม่ใช่โค้ดที่จะไปสิ้นสุดที่ใด แนวคิดนี้จะต้องมีการคิดใหม่ ออกแบบใหม่ และทดสอบใหม่
2. ย้ำเบื้องหลัง. เมื่อบริษัทเพิ่งสร้างมันขึ้นมา แค่ส่งมัน ทำซ้ำกับมัน และสร้างและจัดส่งอีกครั้ง ซึ่งหมายความว่าลูกค้าจะได้เห็นเวอร์ชันที่หลากหลาย พวกเขากำลังดูงานที่กำลังดำเนินการและดูการทำไส้กรอก ซึ่งมักจะเป็นประสบการณ์ที่น่าผิดหวังและสับสน ซึ่งลูกค้าต้องเรียนรู้ระบบที่กำลังพัฒนาอยู่เสมอ เป็นการดีกว่าที่จะทำซ้ำเบื้องหลังในกระบวนการ UX และให้ชัดเจนกับผู้ทดสอบว่าเป็นรุ่นต้นแบบหรือรุ่นสาธิต
3. การตรวจสอบและการวัด หากมีการเผยแพร่แนวคิดใหม่ นักวิจัย UX ไม่มีวิธีที่ดีในการดูผู้คนใช้ ถามคำถาม และรับประเภทของข้อเสนอแนะที่ UX ต้องการเพื่อพิจารณาว่ามีอะไรพร้อมหรือต้องการทำซ้ำอีกหรือไม่ UX ต้องการทราบเหตุผล เชิงคุณภาพเสมอ ไม่ใช่เพียงแค่อะไรหรือจำนวนเท่าใด ผู้ใช้ใช้จ่าย ทำให้เกิด Conversion มีส่วนร่วม ฯลฯ อย่างไร การหลีกเลี่ยงการทดสอบ UX ที่เหมาะสมทำให้วินิจฉัยและแก้ไขปัญหาหรือจุดบอดของลูกค้าได้ยากขึ้น
4. การทดสอบ UX จ่ายเอง การทดสอบ UX นั้นไม่ใช่ค่าใช้จ่ายมหาศาล เครื่องมือทดสอบของบริษัทอื่นบางรายการต้องการราคาต่ำกว่า $100 ต่อผู้เข้าร่วมการทดสอบ ซึ่งบางเครื่องมือต้องการข้อผูกมัดรายปีขั้นต่ำหลายพันดอลลาร์ สิ่งเหล่านี้ไม่ใช่ค่าใช้จ่ายจำนวนมากเมื่อพิจารณาจากงบประมาณโดยรวมของบริษัทสำหรับกระบวนการพัฒนาซอฟต์แวร์และความสำคัญของข้อเสนอแนะในการทดสอบเบื้องต้น การทดสอบโดยผู้ใช้เป็นรอบเกือบทุกครั้งมีค่าใช้จ่ายน้อยกว่าและเร็วกว่าการสร้างโปรแกรมเมอร์ให้สร้างสิ่งที่เราอาจต้องเลิกทำหรือสร้างใหม่อีกครั้ง
5. การทดสอบผู้ใช้แก้ไขข้อโต้แย้ง หากบริษัทของคุณไม่อนุญาตให้ผู้เชี่ยวชาญ UX ตัดสินใจขั้นสุดท้ายเกี่ยวกับวิธีการออกแบบผลิตภัณฑ์ คุณอาจพบว่า UX ขัดแย้งกับผลิตภัณฑ์ วิศวกรรม หรือผู้มีส่วนได้ส่วนเสียเมื่อมีแนวคิดที่แตกต่างกันเกี่ยวกับสิ่งที่ควรสร้างและเผยแพร่ไปยัง ลูกค้า. หรือจะเกิดอะไรขึ้นถ้า UX มีแนวคิดที่แข็งแกร่งสองแนวคิด และพวกเขาสงสัยว่าสิ่งใดเชื่อมโยงกับลูกค้าได้ดีกว่ากัน? วิธีแก้ปัญหาคือการทดสอบผู้ใช้

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

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

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

จะเกิดอะไรขึ้นเมื่อ UX ถูกหลีกเลี่ยงหรือลดลง

Skype เพิ่งประกาศว่าการออกแบบใหม่ในปี 2560 ซึ่งมีเป้าหมายเพื่อทำให้เหมือน Snapchat มากขึ้นนั้นเป็นความล้มเหลว ผู้ใช้ไม่ต้องการ ต้องการ หรือชอบคุณลักษณะใหม่ ฟันเฟืองนั้นใหญ่พอที่ Skype ได้ประกาศในปี 2018 ว่าพวกเขาจะออกแบบ Skype ใหม่อีกครั้ง (https://devops.icu/skypes-coming-redesign-of-their-last-redesign/)

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

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

กระบวนการ UX ที่คล่องตัว

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

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

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

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

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

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

ผู้ปฏิบัติงาน UX เป็นส่วนหนึ่งของทีม Agile

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

มอบหมายคำถาม ความคลุมเครือ หรือจุดบกพร่องให้กับเพื่อนร่วมทีม UX ของคุณใน JIRA หรือระบบติดตามจุดบกพร่องที่คุณใช้ ตรวจสอบให้แน่ใจว่าปัญหา UX อยู่ในระบบเดียวกันกับปัญหาอื่นๆ อย่าทิ้งปัญหา UX ในบอร์ด Trello หากคุณใช้ VersionOne สำหรับอย่างอื่น

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

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

การวัดผล

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

• ร้องเรียนน้อยลง
• รีวิวแอพที่ดีกว่า
• การให้คะแนนแอปที่สูงขึ้น
• ตั๋วสนับสนุนน้อยลง
• โทรคอลเซ็นเตอร์น้อยลง
• ความหมายเชิงบวกเพิ่มเติมของโพสต์โซเชียล
• ติดตั้งแอพมากขึ้น ถอนการติดตั้งน้อยลง
• AOV (มูลค่าการสั่งซื้อเฉลี่ย) เพิ่มขึ้น
• อัตราการแปลงที่สูงขึ้น

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

หาก UX ให้บริการพิมพ์เขียวและกำลังดำเนินการตาม เราหวังว่าวิศวกรรมจะทำงานน้อยลงโดยลดการเปลี่ยนแปลงที่น่าประหลาดใจและสร้างใหม่ การออกแบบ UX ที่ดีขึ้นก่อนหน้านี้ แก้ไขน้อยลงในภายหลัง

Agile UX คือการลงทุนที่มากกว่าการจ่ายเพื่อตัวเอง

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

Eric Ries ผู้เขียน The Lean Startup ถามว่า “ถ้าเราพบว่าตัวเองสร้างสิ่งที่ไม่มีใครต้องการล่ะ? ในกรณีนั้น จะเกิดอะไรขึ้นถ้าเราทำตรงเวลาและตามงบประมาณ?” แม้ว่าองค์กรของคุณจะไม่ได้ใช้วิธีการแบบ Lean คำเตือนก็ยังคงเป็นความจริง ผลลัพธ์ที่ต้องการของ DevOps สะท้อนสิ่งนี้เมื่อเราตั้งเป้าที่จะสร้างสิ่งที่ถูกต้องให้กับลูกค้า ปรับปรุงความพึงพอใจของลูกค้า และพัฒนาคุณสมบัติที่มีมูลค่าสูงต่อลูกค้า

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