Smashing Podcast ตอนที่ 9 กับ Stephanie Walter: ฉันจะทำงานกับ UI Frameworks ได้อย่างไร

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

แสดงหมายเหตุ

• เว็บไซต์ของสเตฟานี
• สเตฟานีบน Twitter

อัพเดทประจำสัปดาห์

• “วิธีสร้างเกมจับคู่การ์ดโดยใช้ Angular และ RxJS” โดย Anna Prenzel
• “วิธีสร้างเว็บไซต์ WordPress ที่ไม่มีหัวบน JAMstack” โดย Sarah Drasner
• “Magic Flip Cards: การแก้ปัญหาการปรับขนาดทั่วไป” โดย Dan Halliday
• “จุดเด่นของ Django: โมเดลผู้ใช้และการตรวจสอบสิทธิ์ (ตอนที่ 1)” โดย Philip Kiely
• “วิธีสร้างแผนที่ด้วย React และ Leaflet” โดย Shajia Abidi

การถอดเสียง

Drew McLellan: เธอเป็นนักออกแบบที่เน้นผู้ใช้เป็นศูนย์กลางและเชี่ยวชาญด้านประสบการณ์การใช้งานอุปกรณ์พกพา ผู้ซึ่งข้ามผลิตภัณฑ์และอินเทอร์เฟซที่น่าพึงพอใจโดยมุ่งเน้นที่ประสิทธิภาพเป็นพิเศษ เธอทำงานในโครงการต่างๆ สำหรับลูกค้า เช่น มหาวิทยาลัยลักเซมเบิร์ก ธนาคารเพื่อการลงทุนแห่งยุโรป BMW และ Microsoft และเธอช่วยลูกค้าเหล่านั้นนำเสนอโครงการที่ประสบความสำเร็จไปยังผู้ชมตลอดทางตั้งแต่กลยุทธ์ไปจนถึงผลิตภัณฑ์ขั้นสุดท้าย เธอเป็นผู้เชี่ยวชาญด้าน Google Developer ในการออกแบบผลิตภัณฑ์และเป็นครูที่กระตือรือร้นที่จะแบ่งปันความรู้ของเธอในบล็อกโพสต์ บทความ เวิร์กชอป และการนำเสนอในการประชุมมากมาย เราจึงรู้ว่าเธอเป็นผู้เชี่ยวชาญด้านการออกแบบประสบการณ์ผู้ใช้ แต่คุณรู้หรือไม่ว่าครั้งหนึ่งเธอเคยร่วมงานกับเซอร์ เอลตัน จอห์น เพื่อนยอดเยี่ยมของฉัน ยินดีต้อนรับ สเตฟานี วอลเตอร์ สวัสดีสเตฟานี สบายดีไหม

สเตฟานี วอลเตอร์: สวัสดี ฉันรู้สึกยอดเยี่ยมและชอบการแนะนำนี้มาก

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

Stephanie: ใช่ เป็นสิ่งที่ฉันเห็นบ่อยมาก โดยเฉพาะอย่างยิ่งในช่วงไม่กี่ปีที่ผ่านมา เพราะฉันเริ่มทำงานกับเอเจนซี่ และตอนนี้ฉันทำงานภายในบริษัท ดังนั้นในทีมเทคโนโลยีไอทีรายใหญ่ๆ เหล่านั้น และใช่ ตอนนี้มีเฟรมเวิร์ก UI มากมาย เช่นเดียวกับที่ผมเห็นมากที่สุดคือ Material-UI โดยพื้นฐานแล้ว การออกแบบ Material คือแนวทางการออกแบบของ Google และวัสดุ -UI คือทีมจาก Angular แต่ยังมาจาก React ด้วย พวกเขาสร้างเฟรมเวิร์กของตนเองโดยใช้รูปลักษณ์ของดีไซน์ Material จาก Google แต่ก็ไม่มีส่วนเกี่ยวข้องกับ Google อีกต่อไป มันเหมือนกับพวกเขา ฉันไม่รู้ ฉันคิดว่าพวกเขาชอบรูปลักษณ์ ดังนั้นในตอนนี้ สิ่งเหล่านี้คือเฟรมเวิร์ก UI หลักสองอันที่ฉันทำงานด้วย และยังมีบางอย่างที่เรียกว่า Ant Design ซึ่งได้รับความนิยมอย่างมาก

สเตฟานี: มันเป็นเฟรมเวิร์กของ React ฉันไม่รู้ว่าพวกเขามี Angular ด้วยหรือเปล่า ฉันคิดว่ามันถูกสร้างขึ้นโดยทีมในประเทศจีน และมันก็น่าสนใจเพราะว่ามันไม่เพียงแค่ให้ส่วนประกอบทุกอย่างใน React เท่านั้น แต่ถ้าคุณไปที่เว็บไซต์ของพวกเขา คุณก็จะได้ไฟล์สแครชด้วย ซึ่งจริงๆ แล้วค่อนข้างน่าสนใจเพราะมันเป็นแรงจูงใจหรือช่วยให้นักออกแบบสร้างหรือปรับแต่ง อินเทอร์เฟซไปยังส่วนประกอบ UI ที่ใช้โดยกรอบงานนั้น ใช่แล้ว เป็นสิ่งที่ฉันเห็นบ่อยมาก โดยเฉพาะอย่างยิ่งในทีมไอทีขนาดใหญ่ เพราะส่วนใหญ่แล้วพวกเขาจะไม่มีนักออกแบบ ในตอนนี้โดยพื้นฐานแล้ว ฉันคือทีม UX ของหนึ่งในทีมเล็กๆ ที่ธนาคารเพื่อการลงทุนในยุโรป ดังนั้นฉันจึงเป็นนักออกแบบ UX ฉันทำงานร่วมกับทีมนักพัฒนา นักวิเคราะห์ธุรกิจ คนดีทุกคน แต่ก็ยังเป็นนักออกแบบคนเดียวสำหรับโครงการทั้งหมด

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

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

Drew: เป็นไปได้ไหมที่คุณคิดว่าสามารถสร้างอินเทอร์เฟซผู้ใช้ที่ใช้งานได้โดยใช้เฟรมเวิร์ก UI นอกชั้นวาง หรือมันจะเป็นการประนีประนอมอยู่เสมอ?

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

สเตฟานี: นี่คือการประนีประนอมที่คุณทำ แต่ในระหว่างนี้ ฉันไม่ประนีประนอมกับบางสิ่งที่เป็นส่วนประกอบที่กำหนดเอง ที่ที่ฉันทำงานมาก่อน เป็นลูกค้าปัจจุบันของบริษัทท่องเที่ยวและสายการบิน และสายการบินก็มีความต้องการที่เฉพาะเจาะจงมากจริงๆ ปฏิทินของสายการบิน เช่น อยากใส่ราคา อยากใส่... ถ้าไม่เดินทางไปจุดหมายนี้ตามวันที่กำหนด ไม่รู้จะใส่วันไหน มีทั้งขาออกและขาเข้า และ ปฏิทินพื้นฐานของเฟรมเวิร์ก UI ส่วนใหญ่ไม่มีสิ่งเหล่านี้ เมื่อถึงจุดหนึ่ง คุณสามารถพูดได้ว่า ตกลง เราจะใช้ปฏิทินที่พวกเขามี และนั่นแหล่ะ คุณต้องไปไกลกว่านั้น ดังนั้นการประนีประนอมส่วนใหญ่จึงถูกสร้างขึ้นโดยพื้นฐานแล้ว เราใช้องค์ประกอบพื้นฐานหรือไม่? เราสร้างแบบกำหนดเองที่เหมาะกับความต้องการของผู้ใช้หรือไม่? หรือเราจะผสมทั้งสองอย่างเข้าด้วยกัน? ในกรณีของปฏิทิน เราใช้ตารางปฏิทิน ดังนั้นเราจึงใช้องค์ประกอบพื้นฐาน จากนั้นเราปรับปรุงด้วยการปรับแต่งเอง ดังนั้นจึงเป็นการพัฒนา React จำนวนมากสำหรับตัวนั้น

สเตฟานี: และใช่ ปกติแล้วคุณจะประนีประนอมกันมาก

Drew: ดูเหมือนว่าการใช้เฟรมเวิร์กส่วนต่อประสานกับผู้ใช้จะช่วยให้คุณได้รับวิธีการบางอย่าง แต่เพื่อให้มีส่วนต่อประสานผู้ใช้ที่ดีจริง ๆ คุณต้องปรับแต่งอีกเล็กน้อยหรือไม่?

สเตฟานี: โดยปกติ ใช่.

Drew: การปรับแต่งนั้นเหนือกว่าธีมหรือไม่?

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

สเตฟานี: คุณไปได้ไกลกว่านั้นนิดหน่อย คุณต้องมีพื้นหลังที่มีการบดบัง คุณต้องเปิดใช้งานเมื่อมีการคลิก โดยปกติการ์ดของคุณจะมีอยู่ในอินเทอร์เฟซอยู่แล้ว ดังนั้นเราจึงใช้องค์ประกอบการ์ดนี้ เพราะมันมีหลายสิ่งที่เราต้องการ เช่น พื้นหลัง ส่วนหัว และชื่อที่ด้านบน และปุ่มบางปุ่มที่ด้านล่าง ดังนั้นเราจึงมีโครงสร้างแล้วจึงปรับแต่งเล็กน้อย แต่เราก็จบลงด้วยความขัดแย้งในบางครั้งเกี่ยวกับความหมาย HTML เช่นกัน ตัวอย่างเช่น ฉันต้องการปุ่มที่ไม่มีรูปร่างของปุ่ม เช่นเดียวกับปุ่มลิงก์และนักพัฒนากล่าวว่า "เอาล่ะ เราใช้ลิงก์เช่นลิงก์ href ของคุณ" ฉันพูดว่า “ไม่ นี่ไม่ใช่ลิงค์ มันเป็นปุ่ม เมื่อพวกเขาคลิก จะไม่เปิดหน้าใหม่ มันล้างทุกอย่างที่อยู่ในแบบฟอร์ม”

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

Drew: ฉันเดาว่าการเริ่มต้นโครงการใหม่ที่จะใช้เฟรมเวิร์ก UI คุณอาจต้องเริ่มต้นด้วยการวิจัยผู้ใช้บางประเภท

สเตฟานี่: ค่ะ

ดรูว์: มันยุติธรรมไหม?

สเตฟานี: คุณควร คุณต้อง ใช่ โดยปกติคุณสามารถมีส่วนประกอบทั้งหมดที่คุณต้องการได้ คุณยังต้องรู้ว่าผู้ใช้ของคุณต้องการอะไรในหน้าเว็บ พวกเขาจะนำทางอย่างไร? คุณต้องสร้างกระแส ดังนั้น แม้กระทั่งก่อนตัดสินใจเกี่ยวกับเฟรมเวิร์ก สิ่งที่เราทำคือไปหาผู้ใช้ พูดคุยกับพวกเขา เราพยายามทำความเข้าใจความต้องการของพวกเขา ตอนนี้ฉันค่อนข้างโชคดีเพราะผู้ใช้อยู่ในธนาคาร ดังนั้นเราจึงทำเวิร์กช็อปกับพวกเขามากมาย และคุณต้องจินตนาการว่ามันเป็นอินเทอร์เฟซที่ซับซ้อนมาก เรากำลังโยกย้ายจากสิ่งที่สร้างขึ้นมา ฉันไม่รู้ ฉันคิดว่าเมื่อ 10 หรือ 15 ปีที่แล้ว เป็นสิ่งที่ใหม่หมดจดโดยใช้ Material-UI React ดังนั้นจึงเป็นการเปลี่ยนแปลงครั้งใหญ่ และคุณต้องเข้าใจว่าในช่วง 15 ปีที่ผ่านมานี้ ทุกคนที่ต้องการบางสิ่งบางอย่างสามารถไปที่ฝ่ายสนับสนุนและขอให้ทีมไอทีดำเนินการ ดังนั้นในขณะนี้อินเทอร์เฟซของฉันก็เหมือน 400 หน้าที่มีตาราง ภายในตาราง ภายในตาราง กับตารางอื่นๆ และสิ่งต่างๆ ที่ไม่ควรอยู่ในตารางด้วยซ้ำ

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

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

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

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

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

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

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

สเตฟานี: ดังนั้นจึงเป็นเรื่องที่น่าสนใจเช่นกันที่มีคนสองสามคนอยู่ในห้องและฟังบทสนทนา จดบันทึกและพูดว่า “โอ้ บางทีเราอาจทำอย่างนั้นได้” และ “องค์ประกอบนี้น่าจะดีกว่าโดยอิงจากสิ่งที่ฉันเพิ่งทำไป ได้ยิน." และสิ่งต่างๆ เช่นนั้น

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

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

สเตฟานี: ฉันจะแนะนำคุณเพียงข้อเดียวคือทดสอบเครื่องมือนี้ก่อน เพราะฉันกำลังใช้อยู่ จึงเรียกว่าปรากฎ.in แต่ฉันคิดว่าพวกเขาเปลี่ยนชื่อเป็น Whereby หรือบางสิ่งบางอย่าง แต่ในเบราว์เซอร์ที่ฉันพูดว่า โอเค มันดีเพราะจากนั้นผู้ใช้ไม่จำเป็นต้องติดตั้งอะไรเลย แต่ผู้ใช้ไม่ได้ใช้คอมพิวเตอร์จริง พวกเขาใช้ VM, ใน Citrix และพวกเขาไม่มีไมโครโฟน ดังนั้นสิ่งที่เราทำจึงเหมือนกับว่าพวกเขาใช้เครื่องมือของฉันเพื่อแชร์หน้าจอ พวกเขากำลังคลิกที่ต้นแบบ และในขณะเดียวกันฉันก็ให้โทรศัพท์ เหมือนโทรศัพท์บ้าน เพื่อพูดคุยกับพวกเขาโดยตรง ดังนั้นจึงมีอยู่เสมอ นี่เป็นราคาที่ค่อนข้างถูกเพราะเป็นวันที่ยอดเยี่ยมในการสรรหา ฉันคิดว่าเรามีผู้ใช้ 10 คนหรืออะไรทำนองนั้น ใช่ คุณสามารถทำสิ่งต่างๆ ได้มากมาย แม้ว่าคุณจะเผชิญหน้ากันไม่ได้ก็ตาม ฉันได้ทำการทดสอบความสามารถในการใช้งานบน Skype โดยตรงหรืออะไรทำนองนั้นมาหลายครั้งแล้ว ดังนั้นจึงมีวิธีราคาถูกอยู่เสมอ

Drew: เมื่อพูดถึงการเลือกเฟรมเวิร์ก UI ที่จะใช้งาน ถ้านั่นคือเส้นทางที่คุณจะไป นั่นคือสิ่งที่คุณจะปล่อยให้นักพัฒนาหรือเป็นสิ่งที่นักออกแบบควรมีส่วนร่วมด้วยหรือไม่

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

สเตฟานี: แต่มันยากมากที่จะพูดว่า “ใช่ ไปที่เฟรมเวิร์กนี้ เรามีส่วนประกอบทั้งหมดที่เราต้องการ” หรือเช่น “อย่าไปหากคุณไม่มีความคิดคร่าวๆ ว่าเนื้อหาของคุณจะเป็นอย่างไร การนำทางคืออะไร” ดังนั้น ฉันคิดว่าคุณควรมีภาพรวมทั่วโลกก่อนที่จะเลือกเฟรมเวิร์กของคุณ เว้นแต่คุณจะแน่ใจ 100% ว่าคุณมีส่วนประกอบทั้งหมด แต่ฉันมีความรู้สึกว่าโดยส่วนใหญ่การเลือกเฟรมเวิร์กนั้นขึ้นอยู่กับเทคโนโลยีที่นักพัฒนาชอบในขณะนี้ พวกเขามีประสบการณ์กับเฟรมเวิร์กมาก่อนหรือไม่ เราใช้ Ant ในบางโปรเจ็กต์เพียงเพราะว่านักพัฒนาบางคนมีประสบการณ์กับสิ่งนั้น และพวกเขาชอบมันมาก และพวกเขาก็ใช้ Ant ได้อย่างมีประสิทธิภาพ และสำหรับ Material React UI ก็เหมือนกัน มันเหมือนกับว่าผู้พัฒนาได้ใช้มันไปแล้วในโครงการก่อนหน้านี้ ดังนั้นพวกเขาจึงมีประสิทธิภาพด้วย

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

สเตฟานี่: ค่ะ ฉันมีข้อกำหนดเฉพาะสำหรับบางโครงการ ซึ่งก็คือ… ฉันอยู่ในลักเซมเบิร์ก เรามีสถาบันในยุโรปมากมายและอะไรทำนองนั้น ดังนั้นเราจึงมีข้อกำหนดการเข้าถึงเพิ่มเติมสำหรับบางสถาบัน และโดยปกติเมื่อกำหนดกรอบงานแล้ว พวกเขาไม่ได้ตรวจสอบความสามารถในการเข้าถึงของกรอบงานจริง ๆ แล้วพวกเขาก็กลับมาอีกสองสามเดือนหลังจากเริ่มโครงการโดยกล่าวว่า "โอ้ เพิ่งบอกเราว่ามีกฎหมายใหม่นี้ และเราควร สามารถเข้าถึงได้ แต่เราไม่รู้ว่าต้องทำอย่างไร” เช่น ใช่ มันสายไปหน่อย ดังนั้น สำหรับฉัน ในการเลือกกรอบงาน คุณต้องรู้ข้อจำกัดทั้งหมดตั้งแต่เริ่มต้นโครงการ และหากการช่วยสำหรับการเข้าถึงเป็นหนึ่งในนั้น คุณต้องทดสอบส่วนประกอบของคุณ และทำให้แน่ใจว่าจะสามารถเข้าถึงได้ แต่ฉันไม่ใช่นักพัฒนา React หรือ Angular แต่ฉันค่อนข้างแน่ใจว่ามันซับซ้อนมากในการเปลี่ยนเฟรมเวิร์ก UI ที่ไม่สามารถเข้าถึงได้เป็นสิ่งที่สามารถเข้าถึงได้ ฉันเดาว่ามันอาจซับซ้อนเล็กน้อยในการสร้างส่วนประกอบทั้งหมดขึ้นมาใหม่ ดังนั้นสิ่งต่างๆ เช่นนั้น

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

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

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

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

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

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

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

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

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

Drew: ถ้าในฐานะนักออกแบบ คุณถูกขอให้เปลี่ยนสไตล์ของส่วนประกอบบางอย่าง คุณจะลองเปลี่ยนสไตล์ทั้งหมดไหม คุณจะปรับแต่งทั้งหมดหรือมีบางพื้นที่ที่คุณจะเน้นหรือไม่

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

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

Drew: I guess things like that, that might seem obvious might seem just like a surface level effect, Do you think that would be easy to change and in this case it turns out it wasn't easy to change? Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. คุณรู้หรือไม่?

Drew: Yup.

Stephanie: It does. ตกลง. So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.