อนาคตของการออกแบบส่วนต่อประสานผู้ใช้: เครื่องมือ UI ยุคหน้า

เครื่องมือออกแบบ UI มาไกลตั้งแต่ Adobe Photoshop รุ่นแรก ซึ่งเป็นโปรแกรมสำหรับแก้ไขรูปภาพ ไม่ใช่สร้างอินเทอร์เฟซผู้ใช้แบบไดนามิก เครื่องมือรุ่นปัจจุบัน เช่น Adobe XD, Figma และ Sketch ทำให้งานของเราง่ายขึ้นและเร็วขึ้น

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

ถึงเวลาสำหรับเครื่องมือ UI รุ่นใหม่

การบูรณาการการออกแบบและโค้ด

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

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

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

นี่คือสิ่งที่อนาคตถือ

การสร้างแบบขนานจะเข้ามาแทนที่ Handoffs ของนักออกแบบ/นักพัฒนา

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

นักออกแบบจะวางรากฐานของ UI ด้วยโค้ดที่ฝังไว้ และนักพัฒนาจะสร้างโค้ดนี้เพื่อสร้างชีวิตชีวาให้กับผลิตภัณฑ์ นักออกแบบไม่จำเป็นต้องจู้จี้นักพัฒนาด้วยคำขอเช่น "โปรดเพิ่มช่องว่างภายใน 16 px แทน 8 px ตามที่แสดงในแบบจำลอง" และนักพัฒนาจะไม่ต้องหยุดชั่วคราวเพื่อถามคำถามเกี่ยวกับการออกแบบ เช่น "คอมโพเนนต์นี้ควรปรับขนาดระหว่างเบรกพอยต์ของแท็บเล็ตและเดสก์ท็อปอย่างไร"

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

การออกแบบเครื่องมือ UI และซอฟต์แวร์สำหรับนักพัฒนาจะสอดคล้อง

เครื่องมือปัจจุบันอาศัยโมเดลการเขียนโปรแกรมที่ออกแบบมาโดยเฉพาะเพื่อสร้างส่วนประกอบการออกแบบ โดยทั่วไป โมเดลเหล่านี้ไม่แข็งแกร่งเท่ากับ CSS และไม่อนุญาตให้นักออกแบบเห็นโค้ดที่สร้างโดยอัตโนมัติซึ่งอยู่ภายใต้ไฟล์การออกแบบของพวกเขา—โค้ดที่ต้องส่งออกไปยัง HTML, CSS หรือ JavaScript ในท้ายที่สุด มันจะง่ายกว่ามากถ้าเครื่องมือของเราใช้ HTML และ CSS โดยกำเนิด

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

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

เราต้องการเครื่องมือของเราในการแสดงผลการดูเว็บ ไม่ใช่สแตติกอาร์ตบอร์ดหรือม็อคอัพ เราไม่ต้องการโปรแกรมจำลอง HTML และ CSS เราต้องการ HTML และ CSS

ภาพจำลองจะล้าสมัย

แทนที่จะทิ้งหุ่นจำลองทิ้ง ให้โยนหุ่นจำลองออกไปนอกประตู

ภาพจำลองปล่อยให้คำถามที่ยังไม่ได้ตอบมากเกินไป เป็นไปไม่ได้ที่จะออกแบบให้เหมาะกับทุกสภาพแวดล้อมดิจิทัล วันนี้ นักออกแบบสร้างเลย์เอาต์สำหรับความกว้างของหน้าจอ 320 px, 834 px และ 1440 px; แต่จะเกิดอะไรขึ้นหากส่วนหนึ่งของเลย์เอาต์แตกบนวิวพอร์ต 1220 px และทำไมไม่ปรับให้เหมาะสมสำหรับ 375 px ซึ่งเป็นขนาดทั่วไปสำหรับโทรศัพท์ขนาดใหญ่ในปัจจุบัน

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

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

สถานะของระบบทั้งหมดจะถูกนำมาพิจารณา

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

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

ข้อมูลจริงจะแทนที่เนื้อหาตัวยึดตำแหน่ง

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

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

การทดสอบกรณีขอบจะง่ายขึ้น

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

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

เมื่องานของเราใช้งานได้ใน HTML และ CSS ระบบนิเวศของส่วนขยายทั้งหมดจะพร้อมใช้งานในระหว่างขั้นตอนการออกแบบ เช่น Lighthouse ที่ขาดไม่ได้สำหรับประสิทธิภาพ SEO และการตรวจสอบการช่วยสำหรับการเข้าถึง หรือเครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ต่างๆ ที่จำลองจุดพักของอุปกรณ์และความเร็วเครือข่ายต่ำ ชุดเครื่องมือเบราว์เซอร์มีค่ามากสำหรับการสร้างและทดสอบ UI ที่พร้อมใช้งานจริงมากกว่าปลั๊กอินใดๆ ใน Figma, Sketch หรือ Adobe XD

นักออกแบบและนักพัฒนาจะทำงานแบบคู่ขนาน

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

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