วิธีที่นักพัฒนาส่วนหน้าสามารถช่วยเชื่อมช่องว่างระหว่างนักออกแบบและนักพัฒนา

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

หลายครั้งที่นักพัฒนาดูเหมือนจะมีชื่อเสียงที่ไม่ดีในเรื่องเทคนิคมากเกินไปและเมินเฉยเมื่อต้องคำนึงถึงรายละเอียดที่ทีมออกแบบคิดขึ้นมา ตามบทความของ Andy Budd “ […] นักพัฒนาจำนวนมากอยู่ในตำแหน่งเดียวกันเกี่ยวกับการออกแบบ – พวกเขาแค่ไม่รู้” ในความเป็นจริง (ตามที่ Paul Boag ชี้ให้เห็น) “นักพัฒนา [ต้อง] ตัดสินใจในการออกแบบตลอดเวลา”

ในบทความนี้ ฉันจะให้คำแนะนำที่เป็นประโยชน์สำหรับนักพัฒนาส่วนหน้าเพื่อหลีกเลี่ยงความยุ่งยากและเพิ่มประสิทธิภาพการทำงานเมื่อทำงานร่วมกับคู่โฆษณาที่สร้างสรรค์

มองผ่านสายตาของดีไซเนอร์

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

ไม่กี่สัปดาห์ต่อมา คุณจะได้รับอีเมลจากนักพัฒนาซอฟต์แวร์ที่ระบุว่า:

“มีการตั้งค่าไซต์การแสดงละคร นี่คือลิงค์ คุณช่วย QA ได้ไหม”

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

การค้นหาเหตุผล

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

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

เนื่องจาก การสื่อสาร และการ ส่งมอบ เป็นประเด็นสำคัญสองประเด็นที่สำคัญมาก เรามาดูกันดีกว่า

การสื่อสารคือกุญแจสำคัญ

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

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

การส่งมอบจากการออกแบบสู่การพัฒนา

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

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

Comps การออกแบบแบบเรียบและแบบคงที่นั้นดีสำหรับการแสดงด้านกราฟิกและเลย์เอาต์ของเว็บไซต์ แต่เห็นได้ชัดว่าขาดการโต้ตอบและแอนิเมชั่นที่เหมาะสม การขอต้นแบบหรือการสาธิตการทำงานของแอนิเมชั่นที่ซับซ้อนจะสร้างวิสัยทัศน์ที่ชัดเจนขึ้นเกี่ยวกับสิ่งที่ต้องสร้างขึ้นสำหรับทุกคนที่เกี่ยวข้อง

ทุกวันนี้ มีเครื่องมือสร้างต้นแบบมากมายที่นักออกแบบสามารถใช้เพื่อจำลองโฟลว์และการโต้ตอบในระดับความเที่ยงตรงที่แตกต่างกัน Javier Cuello อธิบายวิธีเลือกเครื่องมือสร้างต้นแบบที่เหมาะสมสำหรับโครงการของคุณในบทความที่ครอบคลุม

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

แล้วถ้าข้อจำกัดเหล่านี้ทำให้เกิดข้อขัดแย้งระหว่างนักออกแบบและนักพัฒนาล่ะ?

ค้นหาการประนีประนอมและสร้างความรู้ร่วมกัน

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

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

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

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

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

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

“เราใช้วิธีแก้ปัญหานั้นเพื่อค้นหาการประนีประนอมในโครงการ A เราสามารถใช้สำหรับโครงการนี้ด้วยได้หรือไม่”

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

นักออกแบบคาดหวังว่าส่วนหน้าจะดู (และใช้งานได้) เหมือนการออกแบบของพวกเขา

ไฟล์การออกแบบเทียบกับ เปรียบเทียบเบราว์เซอร์

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

คิดอย่างนี้: ทุกรายละเอียดในการใช้งานของคุณซึ่งดูเหมือนกับที่ได้รับการออกแบบ จะช่วยประหยัดเวลาอันมีค่าและปวดหัวของคุณและผู้ออกแบบ และส่งเสริมให้เกิดความไว้วางใจ ไม่ใช่ทุกคนที่มีระดับความใส่ใจในรายละเอียดเท่ากัน แต่เพื่อฝึกสายตาให้สังเกตความแตกต่างของภาพ การใช้ Can't Unsee แบบสั้นๆ รอบหนึ่งอาจช่วยได้

ทำให้นึกถึงเกมที่เราเคยเล่นเมื่อนานมาแล้วที่เรียกว่า “Find it” คุณต้องค้นหาความคลาดเคลื่อนโดยการเปรียบเทียบภาพสองภาพที่ดูเหมือนคล้ายกันเพื่อให้ได้คะแนน

ถึงกระนั้นคุณอาจกำลังคิดว่า:

“จะเกิดอะไรขึ้นถ้าไม่มีระบบขนาดตัวอักษรและระยะห่างที่ชัดเจนในการออกแบบ”

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

เรียนรู้กฎการพิมพ์และการออกแบบขั้นพื้นฐาน

ตามที่ Oliver Reichenstein กล่าวไว้ในบทความหนึ่งของเขา 95% ของข้อมูลบนเว็บเป็นภาษาเขียน ดังนั้น วิชาการพิมพ์จึงมีบทบาทสำคัญในการออกแบบเว็บไม่เพียงแต่ในการพัฒนา การทำความเข้าใจคำศัพท์และแนวคิดพื้นฐานเกี่ยวกับการพิมพ์สามารถช่วยให้คุณสื่อสารกับนักออกแบบได้อย่างมีประสิทธิภาพมากขึ้น และยังช่วยให้คุณใช้งานได้หลากหลายมากขึ้นในฐานะนักพัฒนาอีกด้วย ฉันแนะนำให้อ่านบทความของ Oliver ในขณะที่เขาอธิบายความสำคัญของการพิมพ์บนเว็บและอธิบายคำศัพท์ต่างๆ เช่น micro- และ macro-typography

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

หากคุณต้องการขยายขอบเขตการพิมพ์ของคุณต่อไป หนังสือของ Matthew Butterick เรื่อง "Butterick's Practical Typography" อาจคุ้มค่าที่จะอ่าน นอกจากนี้ยังมีบทสรุปของกฎสำคัญของการออกแบบตัวอักษร

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

นักพัฒนาควรออกแบบหรือไม่

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

Rachel Andrew อธิบายไว้อย่างดีในบทความของเธอเรื่อง “Working Together: How Designers And Developers Can Communicate To Create Better Projects” ว่าเพื่อที่จะ ทำงานร่วมกันได้อย่างมีประสิทธิภาพมากขึ้น เราทุกคนจำเป็นต้องเรียนรู้บางสิ่งเกี่ยวกับภาษา ทักษะ และลำดับความสำคัญของเพื่อนร่วมทีมเพื่อที่เราจะได้ สามารถสร้างภาษาที่ใช้ร่วมกันและพื้นที่ที่ทับซ้อนกันของความเชี่ยวชาญ

วิธีหนึ่งที่จะทำให้มีความรู้มากขึ้นในด้านการออกแบบคือหลักสูตรออนไลน์ที่เรียกว่า "การออกแบบสำหรับนักพัฒนา" ที่นำเสนอโดย Sarah Drasner ซึ่งเธอพูดถึงหลักการออกแบบพื้นฐานและทฤษฎีสี ซึ่งเป็นพื้นที่พื้นฐานสองประการในการออกแบบเว็บ

“ยิ่งคุณเรียนรู้นอกวินัยของตัวเองมากเท่าไหร่ ก็ยิ่งดีสำหรับคุณ [... ] ในฐานะนักพัฒนา”

— Sarah Drasner

ศูนย์ภาพ

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

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

เราอยู่ในนี้ด้วยกัน

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

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

เมื่อฉันฟัง Haraldur Thorleifsson ผู้ก่อตั้งและ CEO ของ Ueno พูดในการประชุมที่ซานฟรานซิสโกในปี 2018 เขาได้นำเสนอค่านิยมหลักสองประการ:

“ไม่มีอะไรที่นี่เป็นปัญหาของคนอื่น”

“เราเก็บขยะที่เราไม่ได้ทิ้ง”

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

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

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

การสร้างความไว้วางใจระหว่างนักออกแบบและนักพัฒนา

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

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

ผลลัพธ์: สถานการณ์แบบวิน-วิน

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

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

แหล่งข้อมูลที่เกี่ยวข้อง

• “วิธีการเลือกเครื่องมือสร้างต้นแบบที่เหมาะสม” Javier Cuello
• “คู่มืออ้างอิงสำหรับวิชาการพิมพ์ในการออกแบบเว็บบนมือถือ” Suzanne Scacca
• “การพิมพ์เชิงปฏิบัติของ Butterick” Matthew Butterick
• “การทำงานร่วมกัน: วิธีที่นักออกแบบและนักพัฒนาสามารถสื่อสารกันเพื่อสร้างโครงการที่ดีขึ้น” Rachel Andrew
• “การออกแบบสำหรับนักพัฒนา” Sarah Drasner, Frontend Masters
• “การออกแบบเว็บคือการพิมพ์ 95%” Oliver Reichenstein
• “Can't Unsee” แบบทดสอบเบราว์เซอร์เพื่อฝึกความรู้สึกของคุณในการจดจำรายละเอียดภาพ