วิธีการเปิดตัวคุณสมบัติใหม่โดยไม่ทำร้ายผู้ใช้ที่ภักดี

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

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag: Link

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

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

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

ความเข้าใจผิดเกี่ยวกับคุณลักษณะใหม่

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

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

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

การออกแบบค่าผิดปกติ: อินเทอร์เฟซผู้ใช้ Stack

เราจะออกแบบค่าผิดปกติได้อย่างไรเมื่อเราระบุแล้ว กลยุทธ์ที่ดีคือการศึกษาสถานะต่างๆ ของอินเทอร์เฟซผู้ใช้ “สแต็กอินเทอร์เฟซผู้ใช้” ซึ่งเป็นแนวคิดที่ Scott Hurff นำเสนอนั้นมีความหลากหลายและซับซ้อน และเมื่อเราออกแบบอินเทอร์เฟซของเรา โดยปกติไม่เพียงพอที่จะสร้างม็อคอัพที่สมบูรณ์แบบพิกเซลใน Photoshop, Sketch หรือ HTML และ CSS — เราต้องพิจารณา กรณีขอบและสถานะต่างๆ: สถานะว่างเปล่า สถานะการโหลด สถานะบางส่วน สถานะข้อผิดพลาด และสถานะในอุดมคติ สิ่งเหล่านี้ไม่ตรงไปตรงมาอย่างที่เราคิด

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

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

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

ผลกระทบของผีเสื้อในการปรับใช้

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

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

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

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

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

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

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

การตรวจสอบคุณสมบัติและ Local Maximum

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

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

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

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

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

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

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

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

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

การทดสอบแปดระดับ

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

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

มาดูกลยุทธ์โดยละเอียดและครอบคลุมแปดขั้นตอนของการเปิดตัวฟีเจอร์ ซึ่งครอบคลุมกระบวนการพัฒนาผลิตภัณฑ์ของ Mail.ru:

1. ทดสอบกับนักพัฒนา
2. ทดสอบกับผู้ใช้จริงในสภาพแวดล้อมที่มีการควบคุม
3. ทดสอบกับผู้ใช้ทั่วทั้งบริษัท
4. ทดสอบกับผู้ทดสอบเบต้า
5. ทดสอบกับผู้ใช้ที่เลือกใช้ด้วยตนเอง
6. แยกทดสอบและตรวจสอบการเก็บรักษา
7. ปล่อยช้าๆและค่อยๆ
8. วัดผลที่ตามมา

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

1. ทดสอบกับนักพัฒนา

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

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

ขั้นตอนแรกค่อนข้างชัดเจน: ออกแบบและสร้างคุณลักษณะ จากนั้นทดสอบในเครื่อง ตรวจทาน และเปิดตัวบนเซิร์ฟเวอร์การจัดเตรียม นี่คือที่มาของการทดสอบ QA ด้วยเครื่องมือที่ครอบคลุมและตัวดำเนินการที่พยายามทำให้ฟีเจอร์และอินเทอร์เฟซขัดข้อง ซึ่งอาจทำงานอัตโนมัติด้วยเครื่องมือทดสอบลิง เช่น Gremlins.js

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

2. ทดสอบกับผู้ใช้จริงในสภาพแวดล้อมที่มีการควบคุม

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

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

3. ทดสอบกับผู้ใช้ทั่วทั้งบริษัท

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

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

4. ทดสอบกับผู้ทดสอบเบต้า

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

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

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

5. ทดสอบกับผู้ใช้ที่เลือกเข้าร่วมด้วยตนเอง

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

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

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

6. แยกทดสอบและตรวจสอบการเก็บรักษา

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

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

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

7. ปล่อยช้าๆและค่อยเป็นค่อยไป

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

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

8. วัดผลที่ตามมา

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

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

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

บทสรุป

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

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