นักพัฒนา "เป็นเจ้าของ" โค้ด ดังนั้นนักออกแบบไม่ควร "เป็นเจ้าของ" ประสบการณ์ใช่ไหม

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

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

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

อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:

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

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

เพิ่มเติมหลังกระโดด! อ่านต่อด้านล่าง↓
เมื่อมีคนจำนวนมากมีส่วนร่วมในโครงการ เป็นสิ่งสำคัญมากที่จะต้องแน่ใจว่าพวกเขาเข้าใจปัญหาและแนวทางแก้ไขร่วมกัน
เมื่อมีคนจำนวนมากมีส่วนร่วมในโครงการ เป็นสิ่งสำคัญมากที่จะต้องแน่ใจว่าพวกเขาเข้าใจปัญหาและแนวทางแก้ไขร่วมกัน (เครดิตรูปภาพ: เว็บถัดไป)

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

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

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

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

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

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

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

ดังนั้น หากนักออกแบบที่ดีเคารพในทักษะและประสบการณ์ที่นักพัฒนาที่ดีนำมาสู่โต๊ะ ความเท่าเทียมกันเล็กน้อยล่ะ? หากนักออกแบบมีความสุขสำหรับนักพัฒนาที่จะ "เป็นเจ้าของโค้ด" ทำไมไม่แสดงความเคารพในระดับที่ใกล้เคียงกันและ ปล่อยให้นักออกแบบ "เป็นเจ้าของประสบการณ์" ล่ะ

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

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

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