การออกแบบด้วยโค้ด: แนวทางการออกแบบที่ทันสมัย ​​(ความท้าทายด้านการพัฒนา)

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

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

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

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

ปัญหาเกี่ยวกับเครื่องมือออกแบบ

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

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

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

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

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

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

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

โซลูชั่น

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

นักออกแบบการเข้ารหัส

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

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

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

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

ระบบการออกแบบ

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

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

การออกแบบและการรวมรหัส

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

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

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

ผสานการออกแบบและโค้ดเข้ากับ UXPin

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

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

UXPin รองรับไลบรารีการออกแบบของส่วนประกอบ React ที่จัดเก็บไว้ในที่เก็บ git รวมถึงการผสานรวมที่แข็งแกร่งกับ Storybook ที่อนุญาตให้ใช้ส่วนประกอบจากเฟรมเวิร์กส่วนหน้ายอดนิยมเกือบทุกชนิด หากคุณต้องการทดลองใช้เอง คุณสามารถขอสิทธิ์เข้าถึงได้จากเว็บไซต์ UXPin:

• ขอเข้าถึง UXPin พร้อมเทคโนโลยีผสาน →

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

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

ในการออกแบบของคุณ คุณสามารถ ผสมผสานห้องสมุดและระบบการออกแบบได้ไม่จำกัดจำนวน นอกเหนือจากการเพิ่มไลบรารีของคุณเองแล้ว คุณยังสามารถเลือกไลบรารีโอเพนซอร์ซที่มีให้เลือกมากมาย เช่น Material Design, Fluent UI หรือ Carbon

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

หมายเหตุ : หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการสร้างการออกแบบที่ตอบสนองได้อย่างแท้จริงด้วย UXPin เราขอแนะนำให้คุณอ่านบทความนี้

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

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

ข้อดี

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

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

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

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

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

ข้อเสีย

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

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

สรุป

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

ที่ไหนต่อไป?

• UXPin Merge: การรวม Storybook
  เรียนรู้ว่าการรวม Storybook สามารถช่วยทีมผลิตภัณฑ์ของคุณและลองใช้ได้อย่างไร!
• UXPin Merge: การรวม Git
  ขอสิทธิ์เข้าถึงเพื่อดูว่าการผสานรวมกับที่เก็บ Git ทำงานอย่างไร
• วิดีโออธิบายสั้น ๆ บน UXPin Merge
  เป็นส่วนหนึ่งของ “ระบบการออกแบบเชิงโต้ตอบ: การสัมมนาผ่านเว็บกับจอห์นสัน แอนด์ จอห์นสัน”
• ออกแบบด้วยโค้ด: UXPin Merge Tutorial
  บทแนะนำเบื้องต้นเกี่ยวกับ UXPin พร้อมเทคโนโลยีผสาน
• การออกแบบที่ตอบสนองด้วย UXPin Merge
  คู่มือการสร้างต้นแบบประสบการณ์ที่ตอบสนองอย่างเต็มที่ด้วย UXPin พร้อมเทคโนโลยีผสาน