เว็บไซต์ดูเก่าไม่ได้แปลว่าต้องทำใหม่ทั้งหมด และเว็บไซต์ที่ยังดูดีอาจมีปัญหาที่กระทบงานจริงอยู่ข้างหลัง เช่น ลูกค้าส่งฟอร์มไม่สำเร็จ ทีมแก้ข้อมูลไม่ได้ หรือเพิ่มบริการหนึ่งหน้าต้องแก้หลายจุดจนผิดพลาด
การตัดสินใจควรเริ่มจากสิ่งที่เว็บไซต์ทำให้ธุรกิจไม่ได้ในตอนนี้ แล้วดูว่าปัญหาอยู่เฉพาะบางส่วนหรือฝังอยู่ในโครงสร้างที่ต้องใช้ต่อ การมีหลักฐานช่วยให้เทียบข้อเสนอได้โดยไม่เลือกจากภาพหน้าแรกเพียงอย่างเดียว
เปลี่ยนคำว่า “เว็บไม่ดี” ให้เป็นงานที่ตรวจได้
รวบรวมเหตุการณ์ที่เกิดจริง เช่น ลูกค้าหาขอบเขตบริการไม่เจอ ต้องโทรถามข้อมูลที่ควรอยู่บนเว็บ หรือทีมใช้เวลานานในการแก้เนื้อหา ระบุหน้าที่เกี่ยวข้อง ผู้ใช้ และสิ่งที่พยายามทำให้สำเร็จ
ข้อมูลผู้เข้าชมช่วยบอกว่าควรเริ่มตรวจตรงไหน แต่ยอดออกจากหน้าเพียงตัวเดียวไม่อธิบายเหตุผลเสมอไป คนอาจได้คำตอบแล้วหรือพบปัญหาก็ได้ ควรดูร่วมกับคำถามจากลูกค้า การทดสอบงาน และผลของฟอร์มติดต่อ
แนวทางศึกษาความต้องการผู้ใช้ของ GOV.UK แนะนำให้ใช้หลักฐานเดิมร่วมกับการสัมภาษณ์และสังเกตผู้ใช้ พร้อมมองความเห็นที่ยังไม่มีหลักฐานเป็นสมมติฐาน แนวคิดนี้ช่วยไม่ให้โครงการทำเว็บใหม่เริ่มจากความชอบส่วนตัวอย่างเดียว
ลองเลือกงานสำคัญให้คนที่ใกล้เคียงลูกค้าทดลอง เช่น หาบริการที่เหมาะ อ่านข้อมูลที่ต้องเตรียม และติดต่อทีม สังเกตจุดที่หยุด ไม่ต้องบอกก่อนว่าปุ่มอยู่ตรงไหน
ถ้าปัญหาอยู่ที่เนื้อหา อาจเริ่มจากเนื้อหาได้
คำอธิบายบริการไม่ชัด เมนูเรียกไม่ตรงภาษาลูกค้า หรือปุ่มติดต่ออยู่ในจุดที่หาไม่เจอ อาจแก้ได้โดยใช้ระบบเดิม ลองปรับหน้าที่มีผลต่อเส้นทางสำคัญก่อน แล้วตรวจว่าคนทำงานสำเร็จขึ้นหรือไม่
ภาพขนาดใหญ่หรือส่วนประกอบที่ไม่จำเป็นอาจเป็นปัญหาเฉพาะหน้าเช่นกัน ต้องตรวจสาเหตุจริงก่อนสรุปว่าเครื่องมือทั้งหมดช้า การเปลี่ยนแพลตฟอร์มโดยใช้รูปและการจัดโหลดแบบเดิมอาจย้ายปัญหาไปด้วย
อย่างไรก็ตาม การแก้เล็กน้อยหลายจุดจะไม่คุ้มเสมอไป หากทุกหน้ามีสำเนาเนื้อหาและรูปแบบแยกกันจนต้องแก้ซ้ำ การจัดโครงสร้างร่วมอาจจำเป็นแม้หน้าตาที่ต้องการเปลี่ยนมีไม่มาก
เมื่อข้อจำกัดอยู่ที่ระบบ ให้พิสูจน์ขอบเขต
ตรวจว่าส่วนที่ต้องทำเพิ่มติดข้อจำกัดใด เช่น ไม่สามารถแบ่งสิทธิ์ให้ทีมได้ตามงาน ไม่รองรับข้อมูลชนิดใหม่โดยต้องดัดแปลงทุกหน้า หรือไม่มีเส้นทางดูแลและอัปเดตที่รับผิดชอบได้
แยกความไม่สะดวกที่แก้ด้วยการตั้งค่าหรือฝึกใช้งานออกจากข้อจำกัดที่ต้องเปลี่ยนโครงสร้าง ขอให้ผู้ประเมินอธิบายพร้อมตัวอย่าง ไม่ใช้เพียงคำว่าเทคโนโลยีเก่าหรือใหม่เป็นเหตุผล
หากไม่มีสิทธิ์เข้าถึงโค้ด โฮสต์ หรือข้อมูลสำคัญ ให้ตรวจการส่งมอบและความเป็นเจ้าของก่อนประเมินงาน วิธีเดินต่ออาจเป็นการรวบรวมสิ่งที่มีหรือกู้การเข้าถึงตามสิทธิ์ มากกว่าตัดสินใจสร้างใหม่ทันที
เทียบทั้งสองทางเลือกด้วยขอบเขตเดียวกัน
ขอให้ข้อเสนอแบบปรับปรุงและแบบทำใหม่ตอบโจทย์เดียวกัน รวมงานเนื้อหา ฟอร์ม สองภาษา การย้ายลิงก์ และการส่งมอบ อย่าเทียบราคาปรับหน้าเดียวกับการทำทั้งระบบแล้วสรุปว่าทางใดคุ้มกว่า
ใส่ภาระช่วงเปลี่ยนผ่านลงไปด้วย ใครยังแก้เว็บเดิมระหว่างทำใหม่ เนื้อหาที่เปลี่ยนจะตามไปอย่างไร และเมื่อเปลี่ยนแล้วลิงก์ที่ลูกค้าเคยบันทึกจะเปิดไปที่ใด
กำหนดว่าข้อมูลใดต้องรักษา เช่น ประวัติบทความ รูป ไฟล์ดาวน์โหลด และคำขอที่ยังต้องทำต่อ พร้อมตรวจว่าระบบใหม่รองรับความหมายของข้อมูลเดิม ไม่ใช่เพียงนำเข้าไฟล์สำเร็จ
รวมภาระดูแลหลังเปิดใช้ในการเปรียบเทียบด้วย ทางเลือกที่ใช้แรงน้อยตอนเริ่มอาจทิ้งงานซ้ำระยะยาวไว้ ส่วนการทำใหม่ทั้งเว็บอาจเพิ่มหน้าที่ที่ทีมยังไม่พร้อมรับผิดชอบ
ใช้การทดลองเล็กเพื่อปลดข้อสงสัยใหญ่
หากยังลังเล ให้ทดลองหน้าหรือกระบวนการที่เป็นตัวแทนของปัญหา เช่น หน้าบริการที่มีเนื้อหาสองภาษาและฟอร์มจริงในสภาพทดสอบ ตรวจทั้งฝั่งลูกค้าและคนแก้เนื้อหา
ตั้งเกณฑ์ก่อนทดลอง เช่น คนหาข้อมูลที่ต้องการได้ ฟอร์มส่งถึงผู้รับผิดชอบ ทีมแก้รูปและข้อความได้โดยไม่ทำโครงสร้างเสีย และเวลาตอบสนองเหมาะกับอุปกรณ์ที่ลูกค้าใช้ หลีกเลี่ยงการตัดสินด้วยความสวยเพียงข้อเดียว
เมื่อเลือกทางแล้ว แบ่งงานตามผลที่ต้องได้และเก็บสิ่งที่ทำงานดีอยู่ ตรวจผลหลังเปลี่ยนด้วยตัวชี้วัดและโจทย์เดิม พร้อมทางแก้หากส่วนสำคัญทำงานไม่ครบ
ใช้รายการตรวจเว็บไซต์ที่ต้องรับคำถามจากลูกค้าธุรกิจ หาเส้นทางที่ควรแก้ก่อน และอ่านวิธีเขียนโจทย์กับเกณฑ์ตรวจรับเว็บ เพื่อทำให้การตัดสินใจกลายเป็นขอบเขตที่ทีมส่งมอบตรงกันได้
เว็บเดิมมีปัญหา แต่ยังไม่อยากเริ่มใหม่โดยไม่รู้เหตุผล?
Talvyn Labs ช่วยตรวจงานที่ลูกค้าและทีมทำไม่สำเร็จ แยกขอบเขตที่ควรปรับ และวางแผนทำใหม่เฉพาะเมื่อข้อจำกัดเดิมมีหลักฐานรองรับ
ประเมินทางเลือกของเว็บไซต์เดิม