มีแนวคิดทั่วไปในหมู่ผู้ใช้ทางธุรกิจและลูกค้าจำนวนมากว่าเมื่อดูเสร็จสมบูรณ์เกือบจะเสร็จสมบูรณ์ อย่างที่คุณน่าจะรู้ว่านี่เป็นเรื่องจริง หนึ่งสามารถทำให้มันดูดี แต่ไม่มีแบ็กเอนด์และผู้ใช้บางคนคิดว่าการทำให้มันดูดีคือ 80% ของงานไม่ใช่ 20% ( หรืออีก 80% )
นักพัฒนาจำนวนนับไม่ถ้วนสามารถเล่าเรื่องราวสยองขวัญเกี่ยวกับเรื่องนี้ได้โดยการจำลองหน้าเว็บที่ทำใน Microsoft Word โดยใช้ภาพหน้าจอของเครื่องมืออื่นและลูกค้าพูดว่า "แล้วคุณเกือบจะทำเสร็จแล้ว"
คุณต้องเร่งความเร็วเพื่อให้ชิ้นส่วนทั้งหมดเสร็จสิ้นเมื่อทำงานเสร็จ การพยายามทำแบ็กเอนด์ทั้งหมดก่อนจากนั้นส่วนหน้าทั้งหมดจะทำให้ผู้ใช้คิดว่าคุณไม่ได้ทำอะไรและถามว่าทำไมคุณถึงได้รับเงินเมื่อไม่มีอะไรมาแสดง ในอีกทางหนึ่งส่วนหน้าก่อนและคุณจะพบว่าผู้ใช้มีการเปลี่ยนแปลงที่ต้องเร่งรีบและใช้เวลาทั้งหมดของเรา
กรณีที่เลวร้ายที่สุดกับ 'หนึ่งก่อนและอีกกรณีหนึ่ง' คือเมื่อคุณไปถึงอีกส่วนหนึ่งคุณจะพบว่ามันไม่เหมาะกับการออกแบบเลย
ดังนั้นสร้างทั้ง แสดงความคืบหน้าในส่วนหน้าทำให้ส่วนหลังทำงานกับสิ่งที่คุณกำลังสร้าง ในหลายกรณีมันเป็นความคิดที่ดีที่จะส่งมอบงานบิลด์ที่เพิ่มขึ้นและตรวจสอบให้แน่ใจว่าคุณกำลังทำสิ่งที่ลูกค้าต้องการ (นี่คือ Agile) การใช้เวลานานเกินไปโดยไม่ต้องมี 'ความก้าวหน้าที่มองเห็นได้' อาจส่งผลกระทบต่อความสัมพันธ์กับลูกค้า (สำหรับทั้งสองกรณีของ 'ทุกอย่างดูเสร็จสิ้น' และ 'ไม่มีอะไรทำจนกว่าจะถึงจุดจบ' - ยากสำหรับลูกค้าที่จะเห็นกรอบการเขียน การทดสอบหน่วยหรือการฆ่าเชื้อข้อมูลตามความคืบหน้า)
Joel เขียนเกี่ยวกับเรื่องนี้ในThe Iceberg Secret เปิดเผย :
ข้อพิสูจน์ที่สำคัญสอง หากคุณแสดงหน้าจอที่ไม่ใช่โปรแกรมซึ่งมีส่วนต่อประสานกับผู้ใช้ที่สวยงาม 100% พวกเขาจะคิดว่าโปรแกรมเกือบเสร็จแล้ว
ผู้ที่ไม่ใช่โปรแกรมเมอร์กำลังดูหน้าจอและเห็นพิกเซล และถ้าพิกเซลดูเหมือนพวกเขาสร้างโปรแกรมที่ทำอะไรพวกเขาคิดว่า "โอ้ว้วมันยากแค่ไหนที่จะทำให้มันใช้งานได้จริง"
ความเสี่ยงครั้งใหญ่ที่นี่คือถ้าคุณเยาะเย้ย UI ครั้งแรกน่าจะเป็นเพื่อให้คุณสามารถสนทนากับลูกค้าได้ทุกคนจะคิดว่าคุณเกือบจะเสร็จแล้ว และเมื่อคุณใช้ปีหน้าทำงาน "ภายใต้ผ้าห่ม" เพื่อพูดไม่มีใครจะเห็นสิ่งที่คุณกำลังทำจริง ๆ และพวกเขาจะคิดว่ามันไม่มีอะไร
นี่คือการย้ำอีกครั้งในโพสต์บล็อกอย่าทำให้ดูตัวอย่างเสร็จแล้วซึ่งมีกราฟที่เป็นประโยชน์นี้:
โดยทั่วไปแล้วตัวเลือกสองตัวเลือกนี้จะแสดงถึง 'ทำ UI' (จากนั้นความคาดหวังก็คือคุณจะทำเสร็จในไม่ช้า) และ 'รับแบ็กเอนด์เสร็จสิ้น' (จากนั้นลูกค้าก็กังวลว่าคุณจะพลาดกำหนดเวลา)
สิ่งที่ 'ทำ' มีลักษณะควรตรงกับวิธีที่ 'ทำ' สิ่งที่เป็น
นักพัฒนาซอฟต์แวร์ทุกคนมีประสบการณ์นี้หลายครั้งในอาชีพการงาน แต่เครื่องมือการเผยแพร่บนเดสก์ท็อปนำไปสู่อาการปวดหัวแบบเดียวกันสำหรับนักเขียนเทคโนโลยี - หากคุณแสดงร่างที่หยาบซึ่งถูกฟอนต์และจัดรูปแบบอย่างสมบูรณ์แบบพวกเขาเห็นว่าทำได้มากกว่าที่คุณต้องการ เราต้องการการจับคู่ระหว่างที่เราอยู่และที่อื่น ๆ ที่เรารับรู้
บทความนี้ยังนำเสนอประเด็นสำคัญเกี่ยวกับประเภทของข้อเสนอแนะที่คุณได้รับด้วยระดับ doneness ที่แตกต่างกันของส่วนต่อประสานผู้ใช้ หากคุณมีบางอย่างที่ดูสมบูรณ์คุณน่าจะได้รับคำติชมเกี่ยวกับ "คุณสามารถเปลี่ยนแบบอักษร" ได้มากกว่า "เค้าโครงนี้ใช้งานไม่ได้มีแท็บจำนวนมากเกินไป"
สำหรับผู้ที่ต่อสู้กับสิ่งนี้ในโลก Java Swing มีรูปลักษณ์ที่เรียกว่าNapkinซึ่งทำให้ UI นั้นดูไม่สมบูรณ์ (แม้ว่าจะเป็น)
กุญแจสำคัญในที่นี้คือการทำให้มันดูไม่เสร็จ การมี UI ดูเสร็จสมบูรณ์เป็นสัญญาณให้กับผู้ใช้ทางธุรกิจจำนวนมากว่าแอปพลิเคชันเสร็จสมบูรณ์ (แม้ว่าจะเป็นหน้าแบบสแตติกเพียงไม่กี่หน้าโดยไม่มีตรรกะใด ๆ อยู่ด้านหลัง
อ่านเพิ่มเติม (และลิงก์จากบทความ):
