นำกระบวนการออกแบบที่ดีขึ้นมาสู่องค์กรของคุณ

ในฐานะนักออกแบบและนักวิจัยด้านประสบการณ์ผู้ใช้ (UX) ข้อร้องเรียนที่พบบ่อยที่สุดที่เราได้ยินจากผู้ใช้คือ:

“ทำไมพวกเขาไม่คิดว่าฉันต้องการอะไร”

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

ผลที่ได้คือการออกแบบที่ไม่ดีซึ่งเป็นอุปสรรคต่อประสิทธิภาพการผลิต ตัวอย่างเช่น ประสิทธิภาพในการดูแลสุขภาพถูกขัดขวางโดยเวชระเบียนอิเล็กทรอนิกส์ (EMR) ข้อร้องเรียนเกี่ยวกับระบบซอฟต์แวร์เหล่านี้มีจำนวนมาก Dr. Steven Ugent แพทย์ผิวหนังจากบอสตันและศิษย์เก่าของ Yale Medical School ก็ไม่มีข้อยกเว้น

ตั้งแต่ปี 2010 Dr. Ugent ใช้ระบบ EMR สองระบบ: ก่อนปี 2010 เขาทำงานเสร็จทันท่วงทีเวลา 5:15 น. ทุกวัน เนื่องจากเขาและเพื่อนร่วมงานเริ่มใช้ EMR เขามักจะทำงานเพิ่มอีกครึ่งชั่วโมงถึง 1.5 ชั่วโมงในตอนเย็น “ฉันไม่รู้จักแพทย์คนใดที่พอใจกับระบบเวชระเบียนของพวกเขา สิ่งที่บ้าก็คือฉันมีประสิทธิภาพมากขึ้นเมื่อฉันใช้ปากกาและกระดาษ”

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

ด่วนสรุปปัญหาด้วย EMR อย่างกระชับ:

“คนที่ออกแบบ [ระบบ EMR] ไม่เข้าใจเวิร์กโฟลว์ของฉัน ถ้าเป็นเช่นนั้นพวกเขาจะออกแบบระบบที่แตกต่างออกไป”

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

“ทำไมฉันจึงไม่พบสิ่งที่ต้องการ”

“ทำไมพวกเขาถึงทำให้มันยากจัง”

“ทำไมฉันต้องสร้างล็อกอินเมื่อฉันต้องการซื้อผลิตภัณฑ์นี้ ฉันให้เงินพวกเขา ยังไม่พอเหรอ?”

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

1. ความซับซ้อน
2. Next-Release Syndrome
3. เวลาไม่เพียงพอสำหรับการออกแบบซ้ำ
4. มอบอำนาจการควบคุมให้กับผู้ค้าภายนอก

1. ความซับซ้อน

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

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

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

ตามที่ Jeff Horvath, Ph.D., ที่ปรึกษา UX ที่มีประสบการณ์มากมายในด้านการดูแลสุขภาพ อธิบายว่า: “ข้อกำหนดเหล่านี้เพิ่มลำดับความสำคัญสองสามประการให้กับความเข้มงวดในการเขียนโปรโตคอลการทดสอบ การตั้งค่าการทดสอบ การรวบรวมข้อมูล การวิเคราะห์ การควบคุมคุณภาพ และ ได้รับการอนุมัติให้ดำเนินการวิจัยเป็นอันดับแรก” ตัวอย่างเช่น การทดสอบความสามารถในการใช้งานรอบเดียวเพิ่มขึ้นจากหกสัปดาห์ (กรอบเวลาที่เหมาะสมสำหรับการทดสอบความสามารถในการใช้งานมาตรฐาน) เป็นหกเดือน และนั่นคือ การทดสอบการใช้งานรอบเดียว บ่อยครั้ง จำเป็นต้องมีการทดสอบสองรอบขึ้นไป

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

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

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

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

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

สารละลาย

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

เมื่อทำการทดสอบความสามารถในการใช้งาน นักวิจัยด้านประสบการณ์ผู้ใช้จะต้องดำเนินการสามขั้นตอนเพื่อจัดการความซับซ้อนที่เกี่ยวข้องกับระเบียบข้อบังคับของ FDA:

1. ผู้ดูแล (ผู้ที่ทำการทดสอบความสามารถในการใช้งาน) จะต้องให้ความสนใจเป็นพิเศษ ตัวอย่างเช่น หากการสแกนด้วย MRI ต้องการให้ช่างเทคนิคปฏิบัติตามขั้นตอนที่เข้มงวดในขณะที่ใช้ซอฟต์แวร์ที่เกี่ยวข้อง ผู้ควบคุมต้องสังเกตอย่างรอบคอบเพื่อพิจารณาว่าผู้เข้าร่วมปฏิบัติตามคำแนะนำในจดหมายหรือไม่ ถ้าไม่เช่นนั้น งานจะถูกจัดระดับเป็นความล้มเหลว หมายความว่าทั้งการออกแบบส่วนต่อประสานและเอกสารที่เกี่ยวข้องจะต้องแก้ไข
2. ผู้ดูแลยังต้องติดตามการโทรที่ปิด ตัวอย่างเช่น ผู้เข้าร่วมอาจเริ่มทำตามขั้นตอนที่ไม่เป็นระเบียบ ค้นหาข้อผิดพลาด และกู้คืนโดยทำตามลำดับที่เหมาะสม องค์การอาหารและยาพิจารณาว่าสิ่งนี้ใกล้จะพลาด และผู้ดำเนินรายการต้องรายงานเรื่องนี้
3. ผู้ดำเนินรายการต้องประเมินความรู้ของผู้เข้าร่วมด้วย เธอเชื่อหรือไม่ว่าเธอทำตามลำดับที่ถูกต้อง? ความเชื่อนี้ถูกต้องหรือไม่?

2. ซินโดรมรุ่นถัดไป

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

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

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

วิธีแก้ไข: ปฏิเสธความคิดแบบ Fix-It-Next-Time

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

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

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

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

3. เวลาไม่เพียงพอสำหรับการออกแบบซ้ำ

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

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

วิธีแก้ปัญหา: Design Spikes

โซลูชันหนึ่งมาจากโลกแห่งการเข้ารหัส ในบทความของเขา “การปรับ UX ขนาดใหญ่ให้เข้ากับการพัฒนาที่คล่องตัว” Damon Dimmick เสนอแนวคิดเกี่ยวกับการออกแบบที่แหลมคม “ฟองแห่งเวลาที่ช่วยให้นักออกแบบสามารถมุ่งเน้นไปที่ปัญหา UX ที่ซับซ้อนได้” สิ่งเหล่านี้เข้ากับเฟรมเวิร์ก Scrum โดยแทนที่การวิ่งปกติชั่วคราว

การออกแบบเดือยมีข้อดีหลายประการ:

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

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

4. พึ่งพาผู้ขายมากเกินไป

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

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

ขณะทำงานที่บริษัทนี้ในฐานะนักออกแบบ UX ฉันมักจะพบกับไดนามิกนี้:

ผู้จัดการ : “เฮ้ เอริค ช่วยประเมินซอฟต์แวร์เคลมที่เราวางแผนจะซื้อได้ไหม? เราแค่ต้องการให้แน่ใจว่ามันทำงานตามที่ตั้งใจไว้”

ฉัน : “ได้ ฉันจะส่งข้อมูลเบื้องต้นให้คุณภายในสิ้นสัปดาห์”

ผู้จัดการ : “เยี่ยม”

สัปดาห์ต่อมา:

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

ฉัน : “ใช่ ฉันคิดว่าปัญหาเหล่านี้จะเพิ่มความเครียดและเวลาในการดำเนินการในศูนย์เรียกร้องค่าสินไหมทดแทน ฉันค่อนข้างกังวลเพราะงานก่อนหน้าของฉันกับทีมของ Janet แสดงให้เห็นว่าตัวแทน Claims Center มีความเครียดสูงอยู่แล้ว”

ผู้จัดการ : “ดีมากที่รู้ ฉันเพิ่งส่งเช็คไป ฉันจะขอให้ผู้ขายแก้ไขปัญหาก่อนที่จะจัดส่ง”

ฉัน (กรีดร้องอยู่ข้างใน): “อ๊ากกกกกก!”

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

สถานการณ์นี้ไม่เพียงแต่เกิดขึ้นซ้ำแล้วซ้ำอีกในบริษัทนั้นเท่านั้น แต่ฉันได้เห็นมันตลอดอาชีพ UX ของฉัน

สารละลาย

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

บทสรุป

ในงานชิ้นนี้ เราได้ระบุอุปสรรคทั่วไปสี่ประการในการออกแบบคุณภาพและการแก้ปัญหาที่เกี่ยวข้อง:

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

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