6 คำถามว่าด้วยความสำเร็จและความล้มเหลวของ Design System

ช่วงนี้ฉันมีเรื่องให้คิดเยอะมาก เพราะกำลังมีส่วนร่วมกับการออกแบบช่วงเริ่มต้นของ design system

เกี่ยวกับเรื่องนี้ นี่คือสิ่งที่อ่านใน UX Collective เมื่อสัปดาห์ก่อน ฉันแปลไว้ให้สมาชิก design system ในบริษัทอ่าน แล้วเสียดายเลยเอามาแชร์ที่นี่ด้วย

เขาบอกว่าเป็นเนื้อหาที่สรุปจากการสัมภาษณ์ดีไซเนอร์ 10 คนที่ทำงานกับ design system

คำถาม 1. ถ้าอยากล้มเหลวในบทบาท DS ต้องทำอย่างไร?:

• ทำตัวเป็นตำรวจ

• ใช้อำนาจของดีไซเนอร์ (พูดเรื่องการเมืองในองค์กร)

• รวมองค์ประกอบต่าง ๆ ไว้แล้วแต่ไม่ใช้จริง

• ทำงานแบบคอยแก้ทีหลัง แทนที่จะคาดการณ์ความต้องการของทีมล่วงหน้า

• ไม่ฟังหรือไม่ศึกษาความเห็นของผู้ใช้ (ดีไซเนอร์หรือดีเวลอปเปอร์คนอื่น ๆ)

• DS ที่สร้างมาเพื่อ DS เอง

• ไม่มีโรดแมปและกระบวนการทำงานที่ชัดเจน

• สร้างประสบการณ์ในอุดมคติที่ทำให้เกิดขึ้นจริงไม่ได้

• ไม่ทดสอบร่วมกับทีม

• ไม่เข้าใจ DS ว่าเป็นผลิตภัณฑ์หนึ่งชิ้น

• สร้างเครื่องมือแล้วไม่สอนคนอื่นให้ใช้

• เอาทฤษฎีที่ห่างไกลจากวิธีทำงานจริงมาใช้มากเกินไป

• คิดว่าทำคนเดียวได้

• ไม่โฟกัส 100% กับการแลกเปลี่ยนความรู้กับใครสักคนในทีมเทคนิค

• สร้างคอมโพเนนต์ที่ไม่ยืดหยุ่นเกินไปและไม่อนุญาตให้ detaching

• ไม่ขอความช่วยเหลือและไม่เชื่อมต่อกับผู้คน (ไม่ว่าจะภายในหรือภายนอก)

• สั่งกฎจากที่ไกล ๆ ไม่ใช่จากการทำงานเคียงข้างกัน

คำถาม 2. ถ้า DS จะประสบความสำเร็จ ต้องมี soft skills อะไรบ้าง?

• การสื่อสาร การสื่อสาร และการสื่อสาร!!!

• การทำงานร่วมกับผู้ใช้ การฟัง การถาม และการค้นคว้า สำคัญมากจริง ๆ

• ยอมรับความล้มเหลวอย่างถ่อมตัว

• จงอดทน

• ความสามารถในการสร้างพื้นที่ที่ปลอดภัย

• การสอน

• นำเสนอวิสัยทัศน์เชิงระบบเกี่ยวกับวิธีนำกลับมาใช้ซ้ำ

• แม้ขยายระบบก็ยังต้องรักษาความสม่ำเสมออย่างหนักแน่น

• เวลาทำความเข้าใจอีกฝ่าย ไม่จำเป็นต้องอินมากขนาดนั้น จงยอมรับกฎตามที่มันเป็น

• 95% คือ hard skills และอีก 5% คือ soft skills สำหรับเวลาที่มีคนออกนอกกฎ

• ส่งเสริมการเติบโตของผู้คนและแบ่งปันมัน

• ความเป็นอิสระในการทำงาน

• ขายผลิตภัณฑ์ (DS) ต่อไปเรื่อย ๆ

• คิดเชิงกลยุทธ์

• ทำให้ทุกคนมีส่วนร่วม

• สร้างกระแสเกี่ยวกับ DS

• ทุ่มเวลาให้มากที่สุดเพื่อค้นหาสถานการณ์การใช้งานให้ได้มากที่สุดเท่าที่จะทำได้

• ใช้ภาษาเดียวกัน

คำถาม 3. วิธีดำเนินการของ DS ควรเป็นแบบรวมศูนย์มากกว่า หรือแบบกระจายมากกว่า?

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

• ทีมของเรารวมศูนย์มากเกินไปจนเกิดคอขวด แต่โมเดลแบบกระจายก็อาจมีปัญหาเรื่อง ownership ที่อ่อนลง

• เรามีทีมดีไซเนอร์มากกว่า 100 คนที่รวมตัวกันเพื่อรวมศูนย์ DS

• เราร่วมมือกับ alpha libraries ที่ผู้คนสร้างขึ้น และใช้ตรงนั้นมาสร้าง backlog ของทีม DS

• เราสอนให้ผู้คนสร้างคอมโพเนนต์ด้วยความสมัครใจ

• จะรวมศูนย์หรือไม่เป็นเรื่องการเมืองในองค์กรอย่างมาก ก่อนจะตัดสินใจต้องรู้ให้ชัดก่อนว่าต้องการ scalability มากแค่ไหน

• ต้องปรับความคาดหวังและทำให้ผู้คนมีส่วนร่วมในการสร้าง DS

• เราอยากร่วมมือกัน แต่ไม่รู้วิธีที่ดีพอ เลยสร้าง process ขึ้นมา (Culture vs Process)

• ในช่วงแรกอาจร่วมมือน้อยหน่อยเพื่อให้ส่งมอบงานได้ พอระบบโตขึ้นก็ค่อยทำให้ร่วมมือกันมากขึ้นได้

• ตอนนี้เราเข้าสู่ช่วงที่ต้อง decentralize แล้ว; ต้องสอนผู้คนถึงวิธีการ contribute

• ถ้าคุณไม่สอนผู้คน คนก็จะไม่เข้ามามีส่วนร่วม

• เมื่อนักออกแบบอยากทำผลงานให้ดีกว่ามาตรฐานที่มีอยู่ ก็ควรคิดไปพร้อมกันด้วยว่าจะทำให้สิ่งนั้นกลายเป็นมาตรฐานได้อย่างไร

• DS ไม่ใช่งานที่คน 1~2 คนทำได้ เพราะมันคือการสร้างระบบ ดังนั้น DS ควรเริ่มต้นในระดับสควอด

• เรื่องนี้ต่างกันมากตามขนาดทีม และบางครั้งทีม DS อาจโฟกัสที่การพัฒนาคอมโพเนนต์แกนหลัก แล้วให้ ambassador คนอื่นช่วยกระจายต่อ

-ท้ายที่สุดเราเป็นทีมแบบรวมศูนย์ แต่ทำงานร่วมกับบรรดา ambassador อย่างร่วมมือกัน การตัดสินใจขั้นสุดท้ายอยู่ที่ทีม DS

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

ปิดหรือเปิด? ถ้าคุณทำงานด้าน design system คุณคงสนใจคำถามนี้ ฉันเองก็สนใจเหมือนกัน เลยลองถามคนอื่นดู

• เรื่อง "accessibility" ควรใช้แนวทางที่เข้มงวดกว่า

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

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

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

• DS คือธุรกิจ ยิ่งมีคอมโพเนนต์น้อยยิ่งดี

• ผู้คนควรรู้สึกสนุกกับการใช้ DS ภายนอกอาจดูเหมือนเครื่องแบบจนทำให้คิดว่าไม่จำเป็นต้องยืดหยุ่น (ซึ่งไม่จริง)

• เราไม่สามารถเริ่มต้นด้วยข้อจำกัดที่เข้มงวดมากได้ตั้งแต่แรก เมื่อเวลาผ่านไปมากพอ มันค่อยเริ่มพัฒนาไปเป็นแพตเทิร์นบางอย่างได้

• สำหรับดีไซเนอร์ที่เพิ่งเข้าบริษัทใหม่ ข้อจำกัดที่มากขึ้นอาจช่วยได้ ถ้าอยากแหกกฎ ก็ต้องเริ่มจากการรู้กฎก่อน

• เราเตรียมวัตถุดิบไว้มากพอให้ผู้คนสร้างสูตรของตัวเองได้

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

• ถ้าเป็นเรื่อง accessibility และสุนทรียภาพ ก็ควรมีข้อจำกัดมากกว่า

• token มีความสำคัญต่อการรักษาความสม่ำเสมอ

• เอกสารที่ดีต้องบาลานซ์ระหว่างการทำให้ผู้คนทำงานสอดคล้องกัน กับการเปิดอิสระให้พวกเขา

คำถาม 5. คุณคิดอย่างไรกับ DS ที่เชื่อมโยงกับ branding และ marketing?

(เป็นหัวข้อที่ฉันไม่ค่อยรู้ เลยแปลยากนิดหน่อย)

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

• วิธีคิดเรื่อง branding ที่เชื่อมกับ DS คือคิดกลับกันว่ามันส่งผลต่อ DS อย่างไร

• เราเริ่มปรับ design system ให้เข้ากับแบรนด์ เพื่อจัดแนวรูปลักษณ์และความรู้สึกของแบรนด์

• DS มีไว้เพื่อ scalability และ brand ID แต่การเชื่อมสองสิ่งนี้เข้าด้วยกันจะต่างกันไปตามทีม branding

• Since DS is a language, MKT could support with assets for it;

• ทีม branding ควรเข้ามาร่วมกับ DS ตั้งแต่ต้นเพื่อวางกฎพื้นฐาน

• มันขึ้นอยู่กับแต่ละบริษัท DS เป็นเครื่องมือในการเสริมความแข็งแรงให้แบรนด์ ดังนั้นการจัดแนวให้ตรงกันจึงสำคัญ ความเชื่อมโยงระหว่างสองด้านนี้ยังส่งผลต่อ accessibility ของ DS ด้วย

• การหาวิธีซิงก์กับทีม branding เพื่อปรับกลยุทธ์ให้สอดคล้องกันเป็นเรื่องสำคัญ

• They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;

• บางครั้งสามารถใช้เอกสารและระบบร่วมกันได้ แต่ส่วนใหญ่ไม่ใช่แบบนั้น DS คืออินเทอร์เฟซ ส่วนทีมแบรนด์ก็มักมี "branding system" แยกต่างหาก และโดยทั่วไปจะเป็นการให้แต่ละไลบรารีทำงานเชื่อมถึงกันมากกว่า ทั้งสองอย่างนี้ไม่เหมือนกันทั้งหมด

คำถาม 6. เราจะวัดความสำเร็จของ DS ได้อย่างไร?

• การรับรู้เพื่อทำความเข้าใจเรื่องการมีส่วนร่วม การนำไปใช้ และสถานะของทีม

• ความครอบคลุมของคอมโพเนนต์ (DS ถูกใช้งานมากแค่ไหน เทียบกับส่วนที่ยัง hardcode อยู่)

• Adoption

• Time to market

• ROI

• Figma Analytics

• ปฏิกิริยาจากทีมพัฒนา

• accessibility

• จำนวนครั้งที่องค์ประกอบถูกใช้งาน

[xguru]

ว้าว ดีมากเลยครับ ขอบคุณที่สรุปให้!