ระบบการออกแบบเป็นเรื่องเกี่ยวกับความสัมพันธ์
เผยแพร่แล้ว: 2022-03-10ระบบการออกแบบมีประโยชน์อย่างเหลือเชื่อ พวกเขาให้องค์ประกอบและแนวทางที่ใช้ซ้ำได้สำหรับการสร้าง "รูปลักษณ์และความรู้สึก" ที่สอดคล้องกันในผลิตภัณฑ์ต่างๆ ด้วยเหตุนี้ ผู้ใช้จึงสามารถนำสิ่งที่ได้เรียนรู้จากผลิตภัณฑ์หนึ่งมาประยุกต์ใช้กับผลิตภัณฑ์อื่นได้ ในทำนองเดียวกัน ทีมงานสามารถนำเสนอรูปแบบที่ผ่านการทดสอบมาอย่างดีสำหรับการนำทางหรือบทวิจารณ์ ทำให้ผลิตภัณฑ์มีความน่าเชื่อถือมากขึ้น ระบบการออกแบบที่มีประสิทธิภาพสามารถแก้ปัญหาที่น่าเบื่อด้วยวิธีที่ทำซ้ำได้ เพื่อให้นักพัฒนาและนักออกแบบสามารถมุ่งเน้นไปที่การแก้ปัญหาใหม่ๆ
แต่เมื่อมีคนใช้คำว่า "ระบบการออกแบบ" ในการประชุม ฉันไม่ค่อยแน่ใจว่าจะมีปฏิกิริยาตอบสนองอย่างไร ฉันเคยเห็นความอยากรู้อยากเห็นและความตื่นเต้นในการลองวิธีทำงานแบบใหม่ แต่ฉันก็เห็นความหงุดหงิดและกังวลกับแนวคิดของระบบที่จำกัดความคิดสร้างสรรค์ของนักออกแบบ นักออกแบบบางคนโต้แย้งว่าระบบการออกแบบดูดซับความคิดสร้างสรรค์ หรือว่าเป็นวิธีแก้ปัญหาในการค้นหาปัญหา ระบบการออกแบบอาจแตกเป็นเสี่ยงๆ เมื่อเวลาผ่านไป ทำให้ทีมหยุดใช้งาน
ระบบการออกแบบจะไม่หายไปแม้ว่า มีเพียง 15% ขององค์กรที่ไม่มีระบบการออกแบบในปี 2561 จากการสำรวจครั้งเดียว ลดลงจาก 28% ของปีที่แล้ว บางทีมใช้ระบบการออกแบบขนาดใหญ่สำหรับใช้งานทั่วไป เช่น การออกแบบวัสดุของ Google ในขณะที่ทีมอื่นๆ ใช้ระบบที่เล็กกว่าและออกแบบมาเฉพาะมากกว่า เช่น Cedar ของ REI และโปรโตคอลของ Mozilla
ระบบการออกแบบควรส่งเสริมทีม ไม่ใช่จำกัดพวกเขา เพื่อให้สิ่งนั้นเกิดขึ้น เราต้องเริ่มคิดแบบองค์รวมมากขึ้น ระบบการออกแบบไม่ได้เป็นเพียงโค้ด หรือการออกแบบ หรือเอกสารประกอบเท่านั้น มันคือทั้งหมดเหล่านี้ บวกกับความสัมพันธ์ระหว่างผู้สร้างระบบและผู้ที่ใช้งานระบบ ซึ่งรวมถึงไฟล์ CSS และเอกสาร Sketch แต่ยังรวมถึงความน่าเชื่อถือ การสื่อสาร และการเป็นเจ้าของร่วมกัน ผลปรากฏว่า มีสาขาวิชาทั้งสาขาที่ทุ่มเทให้กับการสำรวจระบบเช่นนี้
ภาพใหญ่
กระดาษปี 1960 ที่ชื่อว่า "ระบบเทคนิคทางสังคม" สำรวจปฏิสัมพันธ์ระหว่างเทคโนโลยี มนุษย์ และสภาพแวดล้อมที่ใหญ่กว่าที่พวกมันมีอยู่ Enid Mumford อธิบายว่านักวิจัยเริ่มต้นด้วยการศึกษาวิธีสร้างความสัมพันธ์ที่ดีขึ้นระหว่างผู้จัดการและพนักงาน แต่ในช่วงทศวรรษ 1980 พวกเขามุ่งเน้นที่การทำให้งานมีประสิทธิภาพและคุ้มทุนมากขึ้น ในปี 2011 Gordon Baxter และ Ian Sommerville เขียนว่างานวิจัยนี้ช่วยจุดประกายการออกแบบที่เน้นผู้ใช้เป็นศูนย์กลาง และยังมีงานอีกมากที่ต้องทำ
Baxter และ Sommerville แย้งว่าทุกวันนี้ ยังมีความตึงเครียดระหว่างการวิจัยแบบ "มนุษยนิยม" ซึ่งเน้นที่คุณภาพชีวิตของพนักงาน และการวิจัย "การจัดการ" ซึ่งเน้นที่ประสิทธิภาพการทำงาน พวกเขายังอธิบายด้วยว่าการพิจารณาทั้งเทคโนโลยีและการโต้ตอบของมนุษย์เป็นสิ่งสำคัญ: "ประสิทธิภาพของระบบขึ้นอยู่กับการเพิ่มประสิทธิภาพร่วมกันของระบบย่อยด้านเทคนิคและสังคม"
ฉันขอยืนยันว่าระบบการออกแบบเป็นระบบทางสังคมและเทคนิค พวกเขาเกี่ยวข้องกับการโต้ตอบระหว่างผู้ที่สร้างระบบ คนที่สร้างผลิตภัณฑ์โดยใช้ระบบ และผู้ใช้ปลายทางที่โต้ตอบกับผลิตภัณฑ์เหล่านี้ พวกเขายังทำให้เกิดความตึงเครียดแบบเดียวกันระหว่างประสิทธิภาพและมนุษยนิยมที่ Baxter และ Sommerville เห็น
ระบบการออกแบบไม่ได้ประกอบด้วยแค่รูปภาพและโค้ดเท่านั้น พวกเขาเกี่ยวข้องกับการสนทนาระหว่างนักออกแบบ นักพัฒนา ผู้จัดการผลิตภัณฑ์ ซีอีโอ และผู้คนแบบสุ่มบน GitHub การโต้ตอบเหล่านี้เกิดขึ้นในบริบทต่างๆ เช่น บริษัท ชุมชนโอเพนซอร์ส บ้าน และเกิดขึ้นข้ามวัฒนธรรมและขอบเขตขององค์กร การสร้างทีมอาจหมายถึงการรวมผู้คนจากสาขาวิชาต่างๆ เช่น แอนิเมชั่น การออกแบบเสียง การสร้างภาพข้อมูล การสัมผัส และการเขียนคำโฆษณา การสร้างระบบการออกแบบที่ประสบความสำเร็จนั้นต้องใช้ความเชี่ยวชาญด้านเทคนิคและทักษะทางอารมณ์ที่เท่าเทียมกัน
อย่างไรก็ตาม อ่านผู้รวบรวมข่าวด้านการออกแบบหรือวิศวกรรม และคุณมักจะเห็นจุดเน้นที่ชัดเจนใน “ระบบย่อยทางเทคนิค” — รหัสและเครื่องมือ มากกว่าผู้คนและการสนทนา เครื่องมือสร้างสรรค์ใดที่ดีที่สุดในการติดตามโทเค็นการออกแบบ ควรใช้เทคโนโลยี JavaScript ใดในการสร้างส่วนประกอบที่นำกลับมาใช้ใหม่ได้ เช่น React ส่วนประกอบเว็บ หรืออย่างอื่น เครื่องมือสร้างใดดีที่สุด
คำตอบสำหรับคำถามเหล่านี้คือ "มันขึ้นอยู่กับ!" ใครจะเป็นผู้ออกแบบ สร้าง และใช้ระบบ? ความต้องการของพวกเขาคืออะไร? พวกเขากำลังดำเนินการภายใต้ข้อ จำกัด อะไรบ้าง? พวกเขาพอใจกับเครื่องมือและเทคโนโลยีอะไรบ้าง? พวกเขาต้องการเรียนรู้อะไร
เพื่อตอบคำถามเหล่านี้ Baxter และ Sommerville ขอแนะนำกิจกรรมสองประเภท:
- กิจกรรมกระตุ้นความรู้สึกและการรับรู้
เรียนรู้เกี่ยวกับผู้คนที่หลากหลายที่จะสร้างและมีส่วนร่วมในระบบ และแบ่งปันข้อมูลนั้นในวงกว้าง - การมีส่วนร่วมที่สร้างสรรค์
การสื่อสารข้ามบทบาท การสร้างต้นแบบ และการพิจารณาทั้งด้านเทคนิคและส่วนทางสังคมของระบบ
ขุดใน
ในช่วงต้นปี 2019 ฉันเป็นส่วนหนึ่งของทีม — เรียกพวกเขาว่า “team blue” — นั่นคือการสร้างระบบการออกแบบสำหรับองค์กรขนาดใหญ่ ฉันอำนวยความสะดวกในการสนทนาอย่างไม่เป็นทางการกับทีมนี้และ "ทีมสีเขียว" ซึ่งใช้ระบบการออกแบบเพื่อสร้างเว็บแอปพลิเคชัน ทุก ๆ สองสามสัปดาห์ เรามีนักพัฒนาและนักออกแบบทั้งหมดมารวมกันที่โต๊ะและพูดคุยเกี่ยวกับสิ่งที่เรากำลังสร้างและปัญหาที่เราพยายามแก้ไข การสนทนาเหล่านี้เป็น "กิจกรรมการทำให้ไวต่อความรู้สึกและการรับรู้" ของเรา
เราไม่ได้รับอนุญาตให้เผยแพร่ระบบการออกแบบของเราสู่สาธารณะ ดังนั้นเราจึงทำสิ่งที่ดีที่สุดต่อไป: เราปฏิบัติต่อมันเหมือนเป็นโครงการโอเพนซอร์ซขนาดเล็กภายในองค์กร เราใส่รหัสในที่เก็บที่ทั้งสองทีมสามารถเข้าถึงได้และขอความร่วมมือ ทีมสีน้ำเงินมีหน้าที่ตรวจสอบและอนุมัติผลงานเหล่านี้ แต่ทุกคนในทีมใดทีมหนึ่งสามารถมีส่วนร่วมได้ Team blue กำลังสร้างแอปพลิเคชันของตนเอง ดังนั้นในแง่หนึ่งแล้ว พวกเขาเป็นทั้งผู้ใช้และผู้ดูแลระบบการออกแบบ
การโต้ตอบเหล่านี้ช่วยให้ทีมสร้างผลิตภัณฑ์ที่ดีขึ้น แต่ที่สำคัญคือ พวกเขาสร้าง ความไว้วางใจ ระหว่างทีม Team blue ได้เรียนรู้ว่าผู้คนใช้ระบบอย่างรอบคอบและสร้างสรรค์แนวคิดใหม่ๆ ที่ชาญฉลาด ทีมกรีนได้เรียนรู้ว่าระบบได้รับการปรับแต่งให้เข้ากับความต้องการของพวกเขาจริงๆ ดังนั้นพวกเขาจึงสามารถทำงานกับมันได้แทนที่จะต่อต้านมัน Baxter และ Sommerville อาจเรียกงานนี้ว่า "การมีส่วนร่วมที่สร้างสรรค์"
เราพบว่าทั้งสองทีมอยู่ภายใต้แรงกดดันในการเรียนรู้เทคโนโลยีใหม่และส่งมอบผลิตภัณฑ์ที่สมบูรณ์อย่างรวดเร็ว กล่าวอีกนัยหนึ่งพวกเขากำลังดำเนินการภายใต้ภาระทางปัญญาที่ค่อนข้างมาก ส่งผลให้ทั้งสองทีมตกลงที่จะให้ความสำคัญกับการทำให้ระบบใช้งานง่ายขึ้น นั่นหมายถึงการหลีกเลี่ยงการอภิปรายเกี่ยวกับองค์ประกอบของเว็บทั้งหมด โดยเน้นที่ CSS เป็นส่วนใหญ่ และทำให้แน่ใจว่าเอกสารของเรามีความชัดเจนและเป็นมิตร
วางมันทั้งหมดเข้าด้วยกัน
องค์กรทุกขนาดสร้างองค์ประกอบการออกแบบที่นำกลับมาใช้ใหม่ได้เพื่อช่วยให้ทีมสร้างแอปพลิเคชันที่สม่ำเสมอและสวยงามยิ่งขึ้น ความต้องการและพลวัตขององค์กรต่างๆ จะแสดงออกมาในระบบการออกแบบ นี่เป็นเพียงตัวอย่างบางส่วน:
- การออกแบบวัสดุของ Google มีการใช้งานหลายอย่างในเฟรมเวิร์กและภาษาต่างๆ มีผู้ใช้หลายคนทั้งในและนอก Google ดังนั้นจึงมีเอกสารประกอบที่ครอบคลุมและชุดเครื่องมือที่หลากหลายสำหรับแอปออกแบบ
- Fluent Design System ของ Microsoft กำหนดเป้าหมายสี่แพลตฟอร์มที่แตกต่างกันมาก เช่นเดียวกับ Material มันมีชุดเครื่องมือสำหรับนักออกแบบ UX และเอกสารประกอบที่ครอบคลุม
- โปรโตคอลของ Mozilla ใช้ใน Sass และ vanilla JavaScript มีการมุ่งเน้นอย่างมากในการเป็นสากล Alex Gibson กล่าวว่าระบบนี้ช่วยให้ Mozilla "สร้างหน้าเว็บในแบรนด์ได้เร็วขึ้นด้วยการทำงานด้วยตนเองที่ซ้ำซากน้อยลง"
- Cedar ของ REI สร้างขึ้นด้วยส่วนประกอบ Vue.js และไม่สามารถใช้กับเฟรมเวิร์ก JavaScript อื่นๆ ได้ Cedar ถูกใช้โดยนักพัฒนาภายในของ REI เป็นหลัก และมีความเกี่ยวข้องอย่างใกล้ชิดกับแบรนด์ของบริษัท โค้ดของระบบการออกแบบเป็นโอเพ่นซอร์ส แต่ฟอนต์ไม่ใช่
- Lightning Design System ของ Salesforce เป็นเฟรมเวิร์ก CSS ที่ไม่เชื่อเรื่องพระเจ้า สามารถเลือกใช้ร่วมกับ Lightning Component Framework ซึ่งรวมถึงการใช้งาน JavaScript สองแบบ: แบบหนึ่งใช้คอมโพเนนต์ของเว็บ และอีกแบบหนึ่งใช้เฟรมเวิร์ก Aura ที่เป็นกรรมสิทธิ์ของ Salesforce
- PatternFly ของ Red Hat สร้างขึ้นเพื่อมอบประสบการณ์ผู้ใช้ที่สอดคล้องกันในผลิตภัณฑ์แพลตฟอร์มคลาวด์ของบริษัท จึงมีความหนาแน่นของข้อมูลค่อนข้างสูงและรวมองค์ประกอบการแสดงข้อมูลที่หลากหลาย ทีมงาน PatternFly เพิ่งเปลี่ยนจาก Angular เป็น React หลังจากทดลองกับส่วนประกอบเว็บ PatternFly ยังรวมการใช้งาน JavaScript ที่ไม่เชื่อเรื่องพระเจ้าโดยใช้ HTML และ CSS (การเปิดเผยแบบเต็ม: ฉันเป็นอดีต Red Hatter)
- Carbon Design System ของ IBM มีการใช้งานใน JavaScript React, Vue, Angular และ vanilla รวมถึงชุดเครื่องมือการออกแบบสำหรับ Sketch ทีม Carbon กำลังทดลองกับส่วนประกอบเว็บ (เคล็ดลับสำหรับ Jonathan Speek เพื่อติดตามที่เก็บนั้น)
ระบบเช่นนี้มีความสม่ำเสมอและเชื่อถือได้ เนื่องจากผู้คนจากทีมและบทบาทต่างๆ ทำงานร่วมกันเพื่อสร้างระบบดังกล่าว ระบบเหล่านี้แก้ปัญหาได้จริง สิ่งเหล่านี้ไม่ใช่ผลลัพธ์ของนักพัฒนาที่พยายามกำหนดเจตจำนงของตนกับนักออกแบบหรือในทางกลับกัน
Josh Mateo และ Brendon Manwaring อธิบายว่านักออกแบบของ Spotify “เห็นบทบาทของพวกเขาในฐานะผู้สนับสนุนหลักและผู้เขียน ร่วม ของระบบที่ใช้ร่วมกัน ซึ่งพวกเขามีความเป็นเจ้าของ” Mina Markham อธิบายตัวเองว่าเป็น "ผู้แปลระหว่างวิศวกรรมและการออกแบบ" ในระบบการออกแบบกางเกง Jina Anne เจาะลึกถึงพลวัตของทีมและการวิจัยผู้ใช้ที่อยู่เบื้องหลังระบบการออกแบบ: “สปอยเลอร์แจ้งเตือน! คุณจะต้องการมากกว่านักออกแบบ”
มาสร้างบางสิ่งกันเถอะ!
เมื่อเราผ่านการวิจัยและตัวอย่างแล้ว เรามาพูดถึงวิธีสร้างระบบการออกแบบใหม่กัน เริ่มต้นด้วยการพูดคุยกับผู้คน พิจารณาว่าใครจะใช้และมีส่วนร่วมในระบบการออกแบบของคุณ คนเหล่านี้อาจจะครอบคลุมหลากหลายสาขาวิชา — การออกแบบ, การพัฒนา, การจัดการผลิตภัณฑ์, ธุรกิจ และอื่นๆ เรียนรู้เกี่ยวกับความต้องการและเป้าหมายของผู้คน และขอให้พวกเขาแบ่งปันสิ่งที่พวกเขากำลังทำอยู่ พิจารณาวางแผนการประชุมอย่างไม่เป็นทางการด้วยของว่าง กาแฟ หรือชาเพื่อสร้างบรรยากาศที่เป็นกันเอง สร้างการสื่อสารเป็นประจำกับคนเหล่านี้ นั่นอาจหมายถึงการเข้าร่วมห้องสนทนาที่ใช้ร่วมกันหรือกำหนดการประชุมปกติ รักษาน้ำเสียงที่เป็นกันเองและเป็นกันเอง และเน้นที่การฟัง
ขณะที่คุณพูดถึงสิ่งที่คุณกำลังทำอยู่ ให้มองหาปัญหาและเป้าหมายทั่วไป คุณอาจพบว่าทีมจำเป็นต้องแสดงข้อมูลจำนวนมาก ดังนั้นพวกเขากำลังตรวจสอบเครื่องมือสำหรับการแสดงตารางและสร้างรายงาน จัดลำดับความสำคัญในการแก้ปัญหาเหล่านี้
มองหารูปแบบซ้ำและรูปแบบต่างๆ ในธีมที่คล้ายคลึงกัน คุณอาจพบว่าปุ่มและแบบฟอร์มการเข้าสู่ระบบจะแตกต่างกันเล็กน้อยในแต่ละทีม รูปแบบเหล่านี้มีความสำคัญอย่างไร รูปแบบใดที่ตั้งใจไว้ ตัวอย่างเช่น ปุ่มหลักกับปุ่มรอง และรูปแบบใดที่เกิดขึ้นโดยไม่ได้ตั้งใจ ระบบการออกแบบของคุณสามารถตั้งชื่อและจัดรายการรูปแบบและรูปแบบที่ตั้งใจไว้ได้ และสามารถขจัดรูปแบบ "โดยบังเอิญ" ได้
เป้าหมายที่นี่คือการสร้างลูปการตอบกลับอย่างรวดเร็วกับผู้ที่ใช้ระบบการออกแบบ ข้อเสนอแนะที่เร็วขึ้นและการทำซ้ำที่น้อยลงสามารถช่วยหลีกเลี่ยงการไปในทิศทางที่ผิดมากเกินไปและต้องเปลี่ยนเส้นทางอย่างมาก PJ Onori เรียกการเปลี่ยนแปลงครั้งใหญ่อย่างกะทันหันเหล่านี้ว่า “thrash” เขาบอกว่าการฟาดฟันเป็นสิ่งที่ดี ซึ่งเป็นสัญญาณว่าคุณกำลังเรียนรู้และตอบสนองต่อการเปลี่ยนแปลง แต่นั่นก็อาจเป็นอุปสรรค์ได้ “คุณไม่ควรกลัวการฟาดฟัน” เขากล่าว “แต่คุณจำเป็นต้องรู้ว่าเมื่อใดที่มีประโยชน์และวิธีช่วยลดข้อเสียของมัน [วิธี] ที่ดีที่สุดวิธีหนึ่งในการบรรเทาข้อเสียของการฟาดฟันคือการเริ่มต้นจากสิ่งเล็กๆ — กับ ทุกสิ่ง ”
ลองเริ่มต้นเล็ก ๆ ด้วยการตั้งค่าองค์ประกอบพื้นฐานสองสามอย่าง:
- ระบบควบคุมเวอร์ชันสำหรับจัดเก็บรหัสของคุณ GitHub, GitLab และ Bitbucket เป็นตัวเลือกที่ยอดเยี่ยมทั้งหมดที่นี่ ตรวจสอบให้แน่ใจว่าทุกคนที่ใช้ระบบสามารถเข้าถึงรหัสและเสนอการเปลี่ยนแปลงได้ หากเป็นไปได้ ให้ลองสร้างโค้ดแบบโอเพนซอร์สเพื่อเข้าถึงผู้ชมในวงกว้างที่สุด
- รหัส CSS เพื่อใช้งานระบบ ใช้ตัวแปร Sass หรือคุณสมบัติที่กำหนดเองของ CSS เพื่อจัดเก็บ “โทเค็นการออกแบบ” — ค่าทั่วไป เช่น ความกว้างและสี
- ไฟล์ package.json ที่กำหนดวิธีที่แอปพลิเคชันสามารถสร้างและติดตั้งระบบการออกแบบ
- เอกสาร HTML ที่สาธิตวิธีใช้ระบบการออกแบบ โดยควรใช้ CSS ของระบบเอง
เอกสารประกอบ node-sass สำหรับเฟรมเวิร์ก CSS Bulma อธิบายขั้นตอนเหล่านี้โดยละเอียดอีกเล็กน้อย คุณสามารถข้ามการติดตั้งและนำเข้า Bulma ได้หากต้องการเริ่มต้นจากศูนย์ หรือจะรวมไว้ก็ได้หากต้องการเริ่มต้นด้วยข้อมูลพื้นฐานบางส่วน
คุณอาจสังเกตเห็นว่าฉันไม่ได้พูดถึงอะไรเกี่ยวกับ JavaScript ที่นี่ คุณอาจต้องการเพิ่มองค์ประกอบนี้ในที่สุด แต่คุณไม่จำเป็นต้องใช้เพื่อเริ่มต้น การค้นคว้าเกี่ยวกับเครื่องมือ JavaScript ที่ดีที่สุดและใหม่ล่าสุดเป็นเรื่องง่าย การหลงทางในงานวิจัยนี้อาจทำให้การเริ่มต้นใช้งานยากขึ้น ตัวอย่างเช่น “5 เหตุผลที่ Web Components เหมาะสมสำหรับระบบการออกแบบ” และ “ทำไมฉันไม่ใช้ Web Components” ต่างก็ชี้ให้เห็นถึงความถูกต้อง แต่มีเพียงคุณเท่านั้นที่ตัดสินใจได้ว่าเครื่องมือใดเหมาะกับระบบของคุณ เริ่มต้นด้วย CSS และ HTML เพียงอย่างเดียวทำให้คุณสามารถรวบรวมคำติชมในโลกแห่งความเป็นจริง ซึ่งจะช่วยให้คุณตัดสินใจได้เมื่อถึงเวลา
เมื่อคุณเปิดตัวเวอร์ชันใหม่ของระบบ ให้อัปเดตหมายเลขเวอร์ชันของระบบเพื่อระบุว่ามีอะไรเปลี่ยนแปลงบ้าง ใช้การกำหนดเวอร์ชันเชิงความหมายเพื่อระบุสิ่งที่เปลี่ยนแปลงด้วยตัวเลข เช่น “1.4.0” เพิ่มจำนวนสุดท้ายสำหรับการแก้ไขจุดบกพร่อง ตัวเลขตรงกลางสำหรับคุณสมบัติใหม่ และหมายเลขแรกสำหรับการเปลี่ยนแปลงครั้งใหญ่ที่ก่อกวน สื่อสารกับผู้ที่ใช้ระบบการออกแบบ เชิญข้อเสนอแนะและการสนับสนุน และทำการปรับปรุงเล็กน้อยในขณะที่คุณทำ วิธีการทำงานร่วมกันแบบวนซ้ำนี้สามารถช่วยลด "การรบกวน" และสร้างความรู้สึกเป็นเจ้าของร่วมกันได้
สุดท้าย ให้พิจารณาเผยแพร่ระบบการออกแบบของคุณเป็นแพ็คเกจบน npm เพื่อให้นักพัฒนาสามารถใช้งานได้โดยการรันคำสั่ง npm install your-design-system
ตามค่าเริ่มต้น แพ็คเกจ npm จะเป็นแบบสาธารณะ แต่คุณยังสามารถเผยแพร่แพ็คเกจส่วนตัว เผยแพร่แพ็คเกจไปยังรีจิสตรีส่วนตัว หรือขอให้นักพัฒนาติดตั้งแพ็คเกจโดยตรงจากระบบควบคุมเวอร์ชัน การใช้ที่เก็บแพ็กเกจจะทำให้ค้นหาและติดตั้งการอัปเดตได้ง่ายขึ้น แต่การติดตั้งโดยตรงจากการควบคุมเวอร์ชันอาจเป็นวิธีแก้ปัญหาระยะสั้นที่ง่ายดายเพื่อช่วยให้ทีมเริ่มต้นได้
หากคุณสนใจที่จะเรียนรู้เพิ่มเติมเกี่ยวกับด้านวิศวกรรมของสิ่งต่างๆ Katie Sylor-Miller's Building Your Design System ให้การดำน้ำลึกที่ยอดเยี่ยม (การเปิดเผยแบบเต็ม: ฉันเคยร่วมงานกับเคธี่)
ห่อ
ระบบการออกแบบประกอบด้วยรหัส การออกแบบ และเอกสารประกอบ ตลอดจนความสัมพันธ์ การสื่อสาร และความไว้วางใจซึ่งกันและกัน กล่าวอีกนัยหนึ่งก็คือ ระบบทางสังคมและเทคนิค ในการสร้างระบบการออกแบบ อย่าเริ่มต้นด้วยการเขียนโค้ดและเลือกเครื่องมือ เริ่มต้นด้วยการพูดคุยกับคนที่จะใช้ระบบ เรียนรู้เกี่ยวกับความต้องการและข้อจำกัดของพวกเขา และช่วยพวกเขาแก้ปัญหา เมื่อทำการตัดสินใจด้านเทคนิค การออกแบบ หรือกลยุทธ์ ให้พิจารณาความต้องการของคนเหล่านี้ด้วยวิธีที่ "ดีที่สุด" ในทางทฤษฎี เริ่มต้นจากสิ่งเล็กๆ ทำซ้ำ และสื่อสารตามที่คุณไป รักษาระบบของคุณให้เรียบง่ายที่สุดเพื่อลดการรบกวน และเชิญข้อเสนอแนะและการสนับสนุนเพื่อสร้างความรู้สึกเป็นเจ้าของร่วมกัน
ด้วยการให้น้ำหนักที่เท่ากันกับการพิจารณาด้านวิศวกรรมและความสัมพันธ์ระหว่างบุคคล เราจะได้รับประโยชน์จากระบบการออกแบบในขณะที่หลีกเลี่ยงหลุมพราง เราสามารถทำงานได้อย่างมีประสิทธิภาพ และ มีมนุษยธรรม เราไม่ต้องเลือกอันใดอันหนึ่ง เราสามารถส่งเสริมทีมมากกว่าที่จะจำกัดพวกเขา ในที่สุดทีมที่มีอำนาจก็ช่วยให้เราให้บริการผู้ใช้ได้ดียิ่งขึ้น ซึ่งท้ายที่สุดแล้วคือเหตุผลที่เรามาที่นี่ตั้งแต่แรก
อ่านเพิ่มเติม เกี่ยวกับ SmashingMag:
- เคล็ดลับในการจัดการระบบการออกแบบ
- รวมแอนิเมชั่นในระบบการออกแบบของคุณ
- Beyond Tools: การสร้างระบบการออกแบบสามารถปรับปรุงวิธีการทำงานของคุณได้อย่างไร
- การสร้างระบบการออกแบบขนาดใหญ่สำหรับรัฐบาลสหรัฐฯ (กรณีศึกษา)