นักพัฒนาควรทำเลียนแบบ UI หากไม่มีผู้ออกแบบในโครงการหรือไม่

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

ในฐานะนักพัฒนาฉันควรสร้างการจำลองแบบ UI ก่อนที่ฉันจะเริ่มสร้างหน้าจอใหม่หรือไม่ ไม่มีอะไรแฟนซีเกินไปส่วนใหญ่เป็นเค้าโครงทั่วไปเพื่อพูดคุยกับเพื่อนร่วมงานและมีแบบจำลองอ้างอิง ฉันเปรียบเทียบกับการสร้างไดอะแกรม UML ก่อนที่จะทำการเขียนโค้ดแบบสุ่มสี่สุ่มห้า

เพื่อนร่วมงานคนหนึ่งของฉันบอกว่าสิ่งนี้น่ารังเกียจและไม่ใช่หน้าที่ของฉันที่จะทำเช่นนั้น

ฉันมักจะทำงานในโครงการดังกล่าวและคำตอบคือใช่ดังก้องและเร็วที่สุด

ผู้คนพบว่าการวิพากษ์วิจารณ์ปรับปรุงร่างจดหมายง่ายกว่าการหาคำตอบตั้งแต่ต้น ดังนั้นฉันเริ่มร่างเร็วด้วยเหตุผลสองประการ:

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

ในบางกรณีมันก็ดีที่มีหลักฐานว่าฉันได้ส่งสิ่งที่เราเห็นด้วย ...

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

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

ใช่แล้ว

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

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

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

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

ไม่จำเป็น. มีเหตุผลอย่างน้อยสองประการที่ทำไมการเยาะเย้ยถากถางอาจใช้เพียงเล็กน้อย

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

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

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

เสมอ!

ฉันทำงานกับ บริษัท เล็ก ๆ และฉันเป็นคนเดียวที่ "เบา" ฉันทำทุกความต้องการการออกแบบการเข้ารหัสการทดสอบ (แม้ว่าบางคนจะตรวจสอบการทดสอบของฉันเสมอ) การออกแบบฐานข้อมูลเป็นต้น

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

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

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

ลองดูสิ่งนี้ด้วยวิธีทั่วไปมากขึ้น:

• การสร้างร่างเป็นความคิดที่ดีหรือไม่?
• ใครควรสร้างร่างจดหมาย

การสร้างร่างเป็นความคิดที่ดีหรือไม่?

การสร้างแบบร่างส่วนใหญ่มี 2 ประโยชน์ ขั้นแรกให้โฟกัสซึ่งนำไปสู่การเพิ่มความเร็วในการทำงานจริงที่กำลังทำอยู่ ประการที่สองมันทำให้การอภิปรายทิศทางของงานก่อนที่งานจะเสร็จสมบูรณ์ง่ายขึ้นมาก

ข้อเสียของการสร้างร่างคือมันใช้เวลา การใช้เวลา 2 ชั่วโมงในการสร้างแบบร่างที่ซับซ้อนนั้นเป็นสิ่งที่ใช้เวลา 4 ชั่วโมงในการสร้าง

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

ใครควรสร้างร่างจดหมาย

ไม่จำเป็นต้องมีคำตอบที่ซับซ้อนที่นี่: หากคุณได้รับประโยชน์จากการสร้างแบบร่างคุณจะต้องสร้างแบบร่าง หากคุณได้รับประโยชน์จากการที่คนอื่นทำแบบร่างให้คุณขอให้คนอื่นทำแบบร่างให้คุณ

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