โดยปกติหลังจากเสร็จสิ้นการออกแบบเว็บความไม่รู้ของนักออกแบบจะถูกเปิดเผยและวิพากษ์วิจารณ์ พวกเขาออกจากงานหนักในการสร้างเว็บโค้ดให้กับโปรแกรมเมอร์ ปรากฏการณ์นี้ไม่เพียง แต่เกิดขึ้นในอุตสาหกรรมการพัฒนาเครือข่าย แต่ยังอยู่ในอุตสาหกรรมซอฟต์แวร์และการพัฒนาเกมด้วย
ความจริงที่โหดร้ายคือ: ความก้าวหน้าในการพัฒนาอาจหยุดนิ่งเนื่องจากนักออกแบบ เพื่อให้มีประสิทธิภาพที่ดีที่สุดนักออกแบบไม่เพียง แต่จำเป็นต้องวาด แต่ยังต้องสามารถทำได้! ในบทความนี้ฉันต้องการแบ่งปันเหตุผลบางอย่างกับผู้อ่านว่าทำไมนักออกแบบจำเป็นต้องเรียนรู้วิธีการเขียนโค้ด
ด้วยความประทับใจที่ชัดเจนว่าผลิตภัณฑ์ขั้นสุดท้ายจะถูกนำไปใช้อย่างไรนักออกแบบจะมีแนวคิดที่ใช้งานได้จริงมากขึ้น ในฐานะที่เป็นส่วนหนึ่งของกระบวนการพัฒนานักออกแบบมีหน้าที่รับผิดชอบในการสร้างความมั่นใจว่าการออกแบบของพวกเขาสามารถถ่ายโอนไปยังสื่อเครือข่ายได้อย่างราบรื่นในขณะเดียวกันก็คำนึงถึงการใช้งานความชัดเจนของเว็บและความสามารถในการใช้งาน เว็บไซต์ที่ใช้งานง่ายไม่เพียง แต่มีตรรกะลำดับการเรียกดูที่เรียบง่ายและชัดเจน แต่ยังให้ข้อมูลทั้งหมดที่ผู้ใช้ต้องการโดยไม่ปรากฏว่าก้าวร้าวหรือยุ่ง วิธีเดียวที่จะรู้ว่าเค้าโครงเว็บเป็นไปได้คือการเรียนรู้วิธีการสร้างหน้าเว็บด้วยตัวคุณเอง
ในเกือบทุกผลิตภัณฑ์ที่เป็นอิสระของการออกแบบและการใช้งานกลุ่มออกแบบและกลุ่มการดำเนินงานไม่เคยพบกับความคาดหวังของผู้อื่นโดยเฉพาะอย่างยิ่งผลิตภัณฑ์ที่ไม่มีตัวตนเช่นเว็บไซต์ซอฟต์แวร์และเกม นี่มักจะเกิดจาก การประนีประนอมร่วมกันระหว่างความคาดหวังของผลิตภัณฑ์และความเป็นไปได้ของผลิตภัณฑ์ ซึ่งในปัจจุบันดูเหมือนจะยากที่จะรวมกันอย่างสมบูรณ์ วิธีแก้ปัญหาคือ: นักออกแบบควรพยายามออกแบบการดำเนินงานเพื่อหลีกเลี่ยงความสับสนความเข้าใจผิดและข้อมูลที่ผิดในการสื่อสาร
การออกแบบในทางปฏิบัติไม่ควรแน่นอน ฉันหมายความว่าการออกแบบควรมีความยืดหยุ่นและเป็นมิตรสามารถปรับเปลี่ยนเพื่อตอบสนองข้อ จำกัด ทางเทคนิคของระบบโดยไม่บิดเบือนความหมายแฝงดั้งเดิม การเปลี่ยนแปลงซ้ำ ๆ แต่จำเป็นสามารถทำได้โดยนักออกแบบดั้งเดิมเท่านั้น นักออกแบบ/นักพัฒนาสามารถมีประสิทธิภาพมากกว่านักพัฒนาที่ย้ำการออกแบบให้กับนักออกแบบสำหรับการเปลี่ยนแปลง และมีแรงเสียดทานระหว่างนักออกแบบและนักพัฒนา - ที่จริงแล้วมันมักจะเป็นกรณี
ฉันมักจะคิดว่าซอฟต์แวร์เครือข่ายหรือการพัฒนาเกมเป็นวงออเคสตราในขณะที่นักออกแบบเป็นนักแต่งเพลงและนักพัฒนาเป็นตัวนำของวงออเคสตรา ลองนึกภาพว่าการเป็นคนเดียวกันจะเป็นอย่างไร? ซิมโฟนีจะน่าทึ่งมีเสน่ห์และเป็นของแท้! มันไม่เพียง แต่เป็นผลงานชิ้นเอกของอาจารย์เท่านั้น แต่ยังเป็นคำสั่งของเขาเอง!
บทบาทพร้อมกันของนักออกแบบในฐานะโปรแกรมเมอร์หมายความว่าความคืบหน้าของการออกแบบและการเข้ารหัสนั้นต่อเนื่องหากไม่พร้อมกัน ผลที่ได้คือการทำให้วงจรการพัฒนาสั้นลง - ใครไม่สนใจประสิทธิภาพ?
นักออกแบบสมัยใหม่จำเป็นต้องปรับปรุงความสามารถในการรักษาคุณค่าส่วนบุคคล การมีชุดทักษะนั้นยังห่างไกลพอ เรามักจะต้องสวมใส่ชื่อที่แตกต่างกัน: นักออกแบบนักพัฒนาส่วนหน้าผู้เขียนบทความและผู้จัดการโครงการ
โดยการเรียนรู้ที่จะตระหนักถึงการออกแบบของคุณเองแทนที่จะทำให้การออกแบบเป็นเด็กกำพร้าในมือของนักพัฒนา - คุณเพิ่มคุณค่าของคุณเอง ท้ายที่สุดแล้วมันจะไม่เจ็บที่จะพูดถึงทักษะการออกแบบและการเข้ารหัสในประวัติย่อของคุณ ในทางตรงกันข้ามในยุคของการปรับโครงสร้างวิกฤตการณ์ทางการเงิน (ดู: การปลดพนักงานครั้งใหญ่) และการลดการใช้จ่ายหนึ่งสามารถเน้นความสำคัญของบุคคลโดยไม่ต้องถูกไล่ออก
อย่างไรก็ตามถึงแม้จะมีเหตุผลมากมายที่จะสนับสนุนนักออกแบบในการเรียนรู้ที่จะเขียนโค้ด แต่ก็ยังมีเสียงคัดค้านที่นี่
อ้างถึงบทความที่ถกเถียงกันโดย Lukas Mathis นักออกแบบไม่ใช่โปรแกรมเมอร์ ( หมายเหตุ 1)
หากนักออกแบบใช้การออกแบบของเขาเองเขาจะอยู่ภายใต้เป้าหมายที่แตกต่างกันสองประการ: รหัสเรียบร้อยและประสบการณ์การใช้งานที่ดี เป้าหมายทั้งสองนี้ขัดแย้งกัน หากคุณต้องการใช้งานการออกแบบของคุณเองคุณจะประนีประนอมกับคุณภาพของรหัสอย่างหลีกเลี่ยงไม่ได้ซึ่งไม่เอื้อต่อการออกแบบแบบโต้ตอบ
นักออกแบบที่ใช้การออกแบบของตัวเองต้องเผชิญกับปัญหาสองประการ: พวกเขารู้ว่าแนวคิดใหม่ที่ยอดเยี่ยมจะสร้างรหัสยุ่งเหยิงและพวกเขาก็รู้ว่ารหัสที่มีอยู่จะถูกรบกวนหากประสบการณ์ผู้ใช้ดีขึ้น ทั้งสองมีความขัดแย้งเพราะประสบการณ์ของผู้ใช้อยู่ในรายละเอียดเล็ก ๆ น้อย ๆ ที่ทำลายรหัสในที่สุดที่จะสับสนโดยไม่สามารถแบกรับได้
นี่เป็นการสรุปท่าทางที่ยากลำบากโดยนักสอนการพัฒนาเว็บ พวกเขาล้าสมัยและสนับสนุนการวาดเส้นแบ่งระหว่างการออกแบบและการพัฒนา เห็นได้ชัดว่า นักออกแบบสร้างขึ้นสำหรับมนุษย์และนักพัฒนาที่สร้างขึ้นสำหรับเครื่องจักร ดังนั้นนักออกแบบ UX ควรออกแบบส่วนต่อประสานผู้ใช้ที่เป็นไปได้มากที่สุดและให้นักพัฒนาทำการตัดสินใจการเขียนโปรแกรมที่เป็นไปได้มากที่สุด ในขณะที่สิ่งนี้สมเหตุสมผลความพยายามของฉันในการค้นหาแรงบันดาลใจจากรหัสจบลงด้วยความล้มเหลวเมื่อฉันกำลังศึกษาส่วนต่อประสานผู้ใช้ ในระยะสั้นมันมีประโยชน์มากขึ้นที่จะมีแนวคิดที่ถูกต้องเกี่ยวกับเทคโนโลยีและข้อ จำกัด ความพร้อมใช้งานในใจของคุณ
ในที่สุดขนาดของโครงการที่พัฒนาแล้วอาจกำหนดบทบาทของนักออกแบบและนักพัฒนาในท้ายที่สุด แอปพลิเคชันขนาดเล็กสามารถควบคุมได้โดยผู้จัดการโครงการ ( หมายเหตุ 2) ในขณะที่ระบบขนาดใหญ่ต้องต้องการความสามารถระดับมืออาชีพที่แตกต่างกัน!
หมายเหตุ 1 Mathis-Lukas-Designers ไม่ใช่โปรแกรมเมอร์-ลงนามในรหัส
หมายเหตุ 2 Spolsky-Joel-Describes ตำแหน่งที่เรียกว่า Designer และ Programmer-How เพื่อเป็นผู้จัดการโปรแกรมบนซอฟต์แวร์
ผู้เขียน John Urban เป็นนักเรียนปีที่สองที่มหาวิทยาลัยแคลิฟอร์เนียวิชาเอกวิทยาศาสตร์คอมพิวเตอร์
ข้อความภาษาอังกฤษต้นฉบับ