บางครั้งคุณต้องพูดอย่างสุภาพว่า “ไม่”

Nov 26 2022
การปฏิเสธเชิงโต้แย้งเป็นส่วนหนึ่งของงานในการสร้างและบำรุงรักษาระบบการออกแบบ
มีบทความจำนวนมากที่สอนว่านักออกแบบปฏิเสธได้อย่างไร ส่วนใหญ่เกี่ยวกับฟรีแลนซ์และวิธีโต้ตอบกับลูกค้าที่เข้าใจยาก
เครดิต — เอฟเฟกต์แสงนีออนโดย Valery Zanimanski

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

ฉันไม่รู้ว่าฉันกำลังทำอะไรอยู่…

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

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

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

ที่มา Giphy

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

ฉันเคยเห็นสิ่งนี้ที่ไหนมาก่อน…

คุณสามารถขอตัวอย่างจากชุมชนได้เสมอเมื่อต้องตัดสินใจผิดพลาด นักออกแบบ (และอาชีพอื่นๆ อีกมากมาย) ชอบทำรายการสิ่งที่ไม่ควรทำ

มีบทความจำนวนมากในหมวดหมู่ " 10 การตัดสินใจออกแบบที่แย่ที่สุด " และอื่นๆ ในทำนองเดียวกัน อย่างไรก็ตาม เกี่ยวกับระบบการออกแบบ สิ่งที่สำคัญที่สุดคือคำอธิบายของแนวปฏิบัติ "ดี/ไม่ดี" "รูปแบบ" "สิ่งที่ควรทำและไม่ควรทำ" เป็นต้น และเป็นการดีที่สุดที่จะค้นหาสิ่งเหล่านี้ในเอกสารประกอบของระบบการออกแบบแบบเปิด

ที่มา Material.io

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

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

“ ถ้าไม่บันทึกไว้ก็ไม่มีอยู่จริง ”

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

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

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

ไลบรารีการออกแบบ ≠ ระบบการออกแบบ

บ่อยครั้งที่ปัญหาเกิดขึ้นเมื่อผู้ใช้ (หรือผู้ร่วมให้ข้อมูล) ไม่เข้าใจว่าระบบการออกแบบคืออะไร และคิดว่ามันเป็นไลบรารีการออกแบบ นักออกแบบหลายคนเคยชินกับการจัดการกับไลบรารีการออกแบบที่มีอยู่ทั่วไปและต้องแก้ไขให้เหมาะกับความต้องการของพวกเขา

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

สิ่งที่คล้ายกันนี้ แต่แตกต่างกันเล็กน้อย….

ในความคิดของฉัน สิ่งที่ยากที่สุดคือเมื่อผู้ใช้ร้องขอการเปลี่ยนแปลงเล็กน้อย การเปลี่ยนแปลงเล็กน้อย:

  • เพิ่มความสามารถในการใช้ไอคอนในส่วนหัว
  • เปลี่ยนลำดับของบล็อกในรายการ
  • แสดง 3 ปุ่มแทน 2 (กำหนดโดยส่วนประกอบ)
  • ความสอดคล้องของแนวทางกับองค์ประกอบอื่นๆ
  • ความซับซ้อนของการใช้งานโค้ดและองค์ประกอบการออกแบบ (Figma, Sketch เป็นต้น)

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

ความซับซ้อนของการใช้งาน

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

เราเป็นคนรับใช้ไม่ใช่เผด็จการ

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

  • การขาดความยืดหยุ่นในอนาคต
  • ความล่าช้าในการพัฒนาโซลูชัน (เนื่องจากความซับซ้อนของโซลูชันและการบำรุงรักษา)
  • ความจำเป็นในการเปลี่ยนแปลงองค์ประกอบหรือข้อตกลงอื่นๆ
  • การสนับสนุนระบบการออกแบบ Stewarding

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

เหตุผลทั้งหมดที่พูดว่า "ไม่" เป็นเพียงการสร้างความมั่นใจว่าเราสร้างผลิตภัณฑ์ที่ผู้ใช้ต้องการ ไม่ใช่ผลิตภัณฑ์ที่พวกเขาต้องการ

เมื่อถามถึงความคิดเห็นของลูกค้าในการพัฒนา Ford Model T เฮนรี ฟอร์ดกล่าวอย่างมีชื่อเสียงว่า “ถ้าผมถามผู้คนว่าพวกเขาต้องการอะไร พวกเขาคงตอบว่าม้าที่เร็วกว่า”

ขอบคุณที่อ่าน! มาติดต่อกัน! เชื่อมต่อกับฉันบนLinkedInและติดตามฉันบนDribbbleและที่นี่บนสื่อสำหรับเนื้อหาเกี่ยวกับการออกแบบเพิ่มเติม