วิธีที่นักพัฒนาส่วนหน้าสามารถส่งเสริมงานของนักออกแบบได้

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

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

ฉันเชื่อว่าเป็นงานของเรา ในฐานะนักพัฒนา UI ไม่เพียงแต่ช่วยนักออกแบบในการเดินทางเพื่อเรียนรู้วิธีการทำงานของเว็บ แต่ยังต้องทำความรู้จักกับความเป็นจริงและเรียนรู้ภาษาของพวกเขาด้วย

ทำความเข้าใจภูมิหลังของนักออกแบบ UX

นักออกแบบ UX ส่วนใหญ่ (หรือที่เรียกว่านักออกแบบเว็บไซต์หรือนักออกแบบผลิตภัณฑ์) ได้เริ่มก้าวแรกในโลกของการออกแบบผ่านเครื่องมือต่างๆ เช่น Photoshop และ Illustrator บางทีพวกเขาอาจเป็น Graphic Designers : เป้าหมายหลักของพวกเขาคือการสร้างโลโก้และเอกลักษณ์ของแบรนด์และเพื่อออกแบบเลย์เอาต์สำหรับนิตยสาร พวกเขาอาจจะเป็น นักออกแบบการตลาด ก็ได้ เช่น พิมพ์ป้ายโฆษณา ออกแบบแบนเนอร์ และสร้างอินโฟกราฟิก

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

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

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

เปิดรับวิธีคิดใหม่

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

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

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

ขยายการรับรู้ของนักออกแบบของคุณ

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

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

สอนโค้ด ไม่ใช่วิธีเขียนโค้ด

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

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

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

รวมนักออกแบบในกระบวนการพัฒนา

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

ขอให้นักออกแบบรวมคุณไว้ในกระบวนการออกแบบของพวกเขา

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

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

เราอาจใช้เครื่องมือต่างกัน แต่เราต้องพูดภาษาเดียวกัน

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

มองไกลกว่าตัวแก้ไขโค้ด

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

การใช้ระบบ UI เป็นสัญญา

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

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

ยอมรับที่มาของความจริง

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

การรักษาหนี้ภายใต้การควบคุม

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

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

การเข้าถึงไม่ได้หมายความว่าจะต้องน่าเกลียด

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

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

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

การให้ข้อเสนอแนะอันมีค่าแก่นักออกแบบ

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

ข้อเสนอแนะก่อนหน้านี้ดีกว่า

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

อธิบายแนวคิดที่เป็นนามธรรมในแง่ง่าย

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

อย่าให้สมมติฐานกลายเป็นการตัดสินใจ

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

อย่าแก้ปัญหาด้วยตัวเอง

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

แจ้งให้พวกเขาทราบเกี่ยวกับเทคนิค Graceful Degradation และ Progressive Enhancement และสร้างโซลูชันในอุดมคติและโซลูชันทางเลือกร่วมกัน ตัวอย่างเช่น เราสามารถปรับปรุงเลย์เอาต์จาก flexbox เป็น CSS Grid ซึ่งช่วยให้เราเคารพวัตถุประสงค์หลักของคุณลักษณะและในขณะเดียวกันก็ใช้เทคโนโลยีเว็บให้เกิดประโยชน์สูงสุด

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

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

คิดให้ไกลกว่ารัฐในอุดมคติ — ร่วมกัน

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

เพื่อช่วยหลีกเลี่ยงช่องว่างเหล่านี้ไม่ให้เกิดขึ้น ให้สอดคล้องกับความต้องการของนักออกแบบ:

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

การพิจารณาสถานการณ์เหล่านี้จะช่วยให้คุณประหยัดเวลาได้มากในระหว่างขั้นตอนการพัฒนา

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

โอบรับคำขอเปลี่ยนแปลง

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

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

Go Off The Record นานๆครั้ง

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

บทสรุป

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

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

การอ่านที่เกี่ยวข้อง ใน SmashingMag:

• “การออกแบบสำหรับนักพัฒนา” โดย Mason Gentry
• “การทำงานร่วมกัน: วิธีที่นักออกแบบและนักพัฒนาสามารถสื่อสารกันเพื่อสร้างโครงการที่ดีขึ้น” โดย Rachel Andrew
• “นักพัฒนาส่วนหน้าสามารถช่วยเชื่อมช่องว่างระหว่างนักออกแบบและนักพัฒนาได้อย่างไร” โดย Stefan Kaltenegger
• “พอดคาสต์ใดที่นักออกแบบเว็บไซต์และนักพัฒนาควรรับฟัง” โดย Ricky Onsman