การเจรจาด้านการออกแบบ: การทำงานร่วมกันระหว่างนักออกแบบและนักพัฒนาที่ดีขึ้นกับ Aarron Walter แห่ง InVision

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

นักออกแบบมักมีปัญหาในการทำงานกับนักพัฒนา และในทางกลับกัน ทีมของทั้งสองฝ่ายสามารถเรียนรู้มากมายจากกันและกัน แต่การต่อต้านยังคงมีอยู่ แขกรับเชิญในสัปดาห์นี้คือ Aarron Walter รองประธานฝ่าย Design Education ของ InVision และเราจะพูดถึงการทำงานร่วมกันระหว่างนักออกแบบและนักพัฒนา

Aarron ใช้ประสบการณ์ 15 ปีในการบริหารทีมผลิตภัณฑ์และการสอนการออกแบบเพื่อช่วยให้บริษัทต่างๆ ใช้แนวทางปฏิบัติที่ดีที่สุดด้านการออกแบบ เขาก่อตั้งแนวทางปฏิบัติ UX ที่ MailChimp และช่วยขยายผลิตภัณฑ์จากผู้ใช้ไม่กี่พันคนเป็นมากกว่า 10 ล้านคน

คำแนะนำด้านการออกแบบของเขาได้ช่วยทำเนียบขาว กระทรวงการต่างประเทศสหรัฐฯ และบริษัทยักษ์ใหญ่ สตาร์ทอัพ และบริษัทร่วมทุนหลายสิบแห่ง เขาเป็นผู้เขียนหนังสือขายดีอันดับหนึ่งเรื่อง Designing for Emotion from A Book Apart คุณจะพบ @aarron บน Twitter ที่แบ่งปันความคิดเกี่ยวกับการออกแบบ และคุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ Aarron ได้ที่ aarronwalter.com

เกี่ยวกับ Design Better Podcast โฮสต์ Aarron Walter และ Eli Woolery สัมภาษณ์ผู้นำด้านการออกแบบและผู้มีอิทธิพลที่แบ่งปันเรื่องราวเกี่ยวกับวิธีการแก้ปัญหาและเส้นทางอาชีพของพวกเขา แขกรับเชิญ ได้แก่ David Kelley (ผู้ร่วมก่อตั้ง IDEO และผู้ก่อตั้ง Stanford d.school), Julie Zhuo (รองประธานฝ่ายผลิตภัณฑ์และการออกแบบที่ Facebook) และ Jake Knapp (ผู้เขียนหนังสือขายดีของ Sprint) เป็นต้น

สวัสดี Aarron ยินดีที่ได้รู้จักคุณในบล็อก Toptal Design นักพัฒนาจาก Mars และนักออกแบบจาก Venus หรือไม่?

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

นักพัฒนาได้ค้นพบวิธีที่จะแบ่งงานออกเป็นชิ้นเล็กชิ้นน้อย และนักออกแบบมักจะคิดว่าทั้งหมดนี้เป็น "เค้กทั้งชิ้น" และเราจะกินเค้กทั้งหมดได้อย่างไร

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

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

มีโอกาสที่ทั้งสองฝ่ายจะงอที่นี่ บางครั้งนักออกแบบพยายามโน้มน้าวนักพัฒนาว่าเราต้องรอและสร้างสิ่งทั้งหมด จากนั้นนำมันออกมาเป็นประสบการณ์ที่สวยงามและสมบูรณ์

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

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

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

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

ในการทำความเข้าใจพื้นที่ของกันและกันดีขึ้น...

ทีมจะทำอะไรได้บ้างเพื่อให้เข้าใจพื้นที่ของกันและกันดีขึ้น นักออกแบบควรทำความคุ้นเคยกับการพัฒนาและในทางกลับกันหรือไม่?

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

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

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

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

มันสามารถวัดได้แม้ว่าองค์ประกอบคุณภาพจะนำมาซึ่ง ROI ที่สามารถวัดได้

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

ข้อผิดพลาดของการทำงานร่วมกันระหว่างนักออกแบบและนักพัฒนา...

อะไรคือข้อผิดพลาดที่ใหญ่ที่สุดที่นักออกแบบและนักพัฒนาทำงานร่วมกัน

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

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

ในสภาพแวดล้อมนั้น การสร้างเคสสำหรับฟีเจอร์ UX เป็นสิ่งที่ท้าทายอย่างยิ่งสำหรับนักออกแบบ: “เราควรมีแอนิเมชั่นนี้ในผลิตภัณฑ์เพราะมันจะสร้างประสบการณ์ที่น่าดึงดูดยิ่งขึ้น…” เมื่อวิศวกร 75 คนพูดว่า: “นั่นคืออีก 250 คน บรรทัดของรหัสและการทำงานพิเศษสองวัน คุ้มจริงหรือ?” และคงไม่ใช่ สำหรับพวกเขา ดูเหมือนว่า "เปลือกน้ำrostาล" แต่การโต้ตอบขนาดเล็กที่เคลื่อนไหวได้เหล่านั้นกับนักออกแบบ UX จะสร้างประสบการณ์ของลูกค้าได้อย่างแท้จริง พวกเขาไม่ใช่สิ่งเดียว แต่มีความสำคัญ

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

เกี่ยวกับนักออกแบบที่ถ่ายทอดความสำคัญของ UX...

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

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

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

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

คุณคงเคยได้ยินคำเทศนาของเจฟฟ์ โกเธลฟ์ว่าเราควรเน้นที่ “ผลลัพธ์ ไม่ใช่ผลลัพธ์” นั่นเป็นอีกวิธีหนึ่งที่เราสามารถปรับความคิดของเราใหม่ ว่า ผลลัพธ์ คือ: "เราจัดส่งคุณลักษณะเพิ่มเติมอีก 5 รายการ" เทียบกับ ผลลัพธ์: "เราลดการหยุดทำงาน 10%"

เกี่ยวกับอนาคตของการทำงานร่วมกันระหว่างนักออกแบบและนักพัฒนา...

คุณพูดคุยกับบริษัทจำนวนมากและเห็นทีมออกแบบและนักพัฒนาหลายคนทำงานร่วมกัน เครื่องมือ สภาพแวดล้อม และวิธีการกำลังเปลี่ยนแปลง อนาคตจะเป็นอย่างไรสำหรับความสัมพันธ์ระหว่างนักออกแบบ/นักพัฒนา?

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

ในแง่นั้น เราเห็นนักออกแบบใช้เวลามากมายในจิรา คิดในเรื่องราวของผู้ใช้ และเริ่มคิดด้วยกรอบความคิดทางวิศวกรรมเช่นกัน และในทางกลับกัน เราเห็นวิศวกรใช้เครื่องมืออย่าง InVision Inspect ที่พวกเขาเห็นสเปกและรายละเอียดของระบบการออกแบบ และเข้าใจองค์ประกอบของความเข้ากันทั้งหมด เนื่องจากเครื่องมือเหล่านี้และการผสมผสานของระเบียบวินัย ความเข้าใจร่วมกันจึงกำลังพัฒนา

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

อ่านเพิ่มเติมเกี่ยวกับบล็อก Toptal Design:

• วิธีเข้าถึงการออกแบบสำหรับนักพัฒนา
• Design Talks: การวิจัยเชิงปฏิบัติกับนักวิจัย UX Caitria O'Neill
• การเจรจาด้านการออกแบบ: การออกแบบที่ชาญฉลาดทางอารมณ์กับ Pamela Pavliscak
• Design Talks: การแสวงหาการออกแบบตามมูลค่ากับ Nick Disabato
• วิธีการเปลี่ยนจาก UX Designer เป็น UX Consultant