iUXUI Journey VIII— Wireframe
ต่อจากบทความที่แล้ว ติดใจคำนี้ wireframe เลยขอแวะที่ป้ายนี้หน่อย 😆
อยากรู้ว่า wireframe คืออะไรก็ส่องวิดีโอนี้ซะ youtube: what wireframe ? จากเว็ปไซต์ของ balsamiq เครื่องมือที่ใช้ในการทำ wireframe ที่บทความของ designil กล่าวถึง รายละเอียดด้านล่างก็เรียบเรียงมาจากเว็ปของ balsamiq เหมือนกัน
Ideation & Validation
มาเริ่มที่หัวข้อแรกกันก่อน การทำ wireframe จะแบ่งออกเป็น 2 เฟสด้วยกันคือ การแปลงความคิด (ideation) และการตรวจสอบความคิดดังกล่าว (validation)
การจะสร้าง wireframe ขึ้นมาต้องแน่ใจว่ามันได้ตอบคำถาม 2 ข้อ คือ
- มันจะแก้ปัญหาของลูกค้าของเราได้อย่างไร และ
- จะรู้ได้อย่างไรว่าวิธีนี้ แก้ปัญหาดังกล่าวได้จริง
ซึ่งจากคำถามนี้ก็จะนำไปสู่ 2 เฟสหลักข้างต้น
Ideation
ในเฟสแรกของการหาไอเดียว่าจะแก้ปัญหาได้อย่างไร ให้เริ่มต้นด้วยการเน้นปริมาณเข้าว่า ไอเดียอะไรที่คิดได้ในหัวเขียนมาออกมาให้หมด จะดีจะแย่ อย่าไปสน อย่าคิดลึก เน้นว่าจะทำอะไรเพื่ออะไร โฟกัสเฉพาะตรงส่วนนั้นก่อน ยังไม่ต้องลงรายละเอียด รีบๆ เขียนเป็นร่างคร่าวๆ ออกมาให้เยอะสุดไว้ก่อน
The root of “creative,” after all, is “create”.
จากนั้นค่อยมาไล่ดู อันไหนแย่ อันไหนดี ให้เหตุผลกับแต่ละไอเดีย ตัวเองต้องตอบตัวเองให้ได้ก่อนว่า ทำไมแบบนี้ดี ทำไมแบบนี้ใช้ไม่ได้ ทำให้ดีขึ้นได้ไหม จะทำเป็น version ไว้ก็ได้ ค่อยๆ คิดให้ลึกขึ้น
Many bad ideas, make a good one.
เมื่อได้ไอเดียที่ใช่ ก็ค่อยมาลงรายละเอียดส่วนที่เหลือ ในการออกแบบหน้าจอ เราก็ต้องเพิ่มส่วนที่ยังขาดอยู่ เพื่อให้ผู้ใช้เห็นองค์ประกอบทั้งหมด ก่อนไปสู่เฟสถัดไป
Validation
เฟสต่อมาคือ เฟสของการเปิดตัว นำเสนอไอเดียของเรากับเพื่อนร่วมทีม หรือไม่ก็ลูกค้า เพื่อแลกเปลี่ยนให้เกิดการพัฒนาให้ดีขึ้น โดยเราใช้ wireframe เป็นสื่อกลาง ในการสื่อสารในสิ่งที่เราคิด เพราะมนุษย์ทำความเข้าใจภาษาภาพได้ดีกว่าภาษาพูด
A picture is worth 1000 words.
เราต้องเป็นคนอธิบาย ไม่ใช่ให้ wireframe พูดแทนเรา ดึงให้เขาเข้าร่วมการสนทนาเพื่อหารือ ซึ่งถ้าไอเดียที่เราเสนอไปมันไม่เวริ์ค เราก็ต้องมีทางเลือกสำรองไว้บ้างเหมือนกัน สุดท้ายตัวที่ใช้วัดว่าไอเดียของเรามันดีหรือไม่ดี ก็คือ usability (usability คืออะไร อ่านแบบเต็มๆ ที่นี่)
tips
- นำเสนอไอเดียที่หลากหลาย และให้เขาเห็นว่า เราคิดมาลึกพอควรกับไอเดียดังกล่าว
- แต่ง wireframe ให้มันดูง่ายๆ อย่ารก และลาก flow ให้ชัดเจน กรณีใช้พวกโปรแกรมสร้าง ให้แสดงด้วย presentaion mode อย่าเอาเครื่องมือสร้าง wireframe มาแสดงให้รกหน้าจอ
- จดโน็ต comment ในแต่ละจุดไว้ เพื่อจะได้ไม่ลืมว่าต้องปรับอะไรบ้าง
Four techniques for starting a wireframe
พอจะรู้จักหน้าค่าตาของ wireframe บ้างละ แต่การจะสร้างมันขึ้นมาจากความว่างเปล่า ต้องทำไง มาลองดูวิธีเสกของจากความไม่มีกัน
I. Start with words instead of pictures
หากนึกหน้าตา UI ไม่ออก ให้เริ่มจากการถามตัวเอง 3 คำถามก่อน ว่า
- ใคร คือคนที่จะมาใช้
- จุดมุ่งหมายคืออะไร ผลิตภัณต์หรือฟีเจอร์ที่เราสร้างจะช่วยแก้ปัญหาอะไรให้เขา
- เขาต้องทำอะไรบ้าง
หากยังตอบสามข้อนี้ไม่ได้ กรุณา กลับไปดม requirement ใหม่ซะ และกรุณา note ไว้ใน wireframe ด้วย เพื่อที่คนมาอ่านเขาจะได้เข้าใจจุดประสงค์ที่เราออกแบบ หรือกันตัวเราเองนั่นแหละที่ลืมเป้าหมายหลักไป
II. Create a site map
site map (ศัพท์ใหม่ 😆 อีกแว้วว) มันคือการลองวางหน้าจอที่จะต้องมีในระบบ เพื่อให้เห็นภาพคร่าวๆ ว่า ต้องมีอะไรบ้าง ผู้ใช้มี flow การใช้งานแบบไหน แต่ละหน้าสัมพันธ์กันอย่างไร
เป็นการตีฟีเจอร์หลักๆ ก่อน ที่จะไล่ลงรายละเอียดในแต่ละฟีเจอร์
III. Use the existing design
ใช้การออกแบบเก่า กรณีนี้จะใช้ได้ก็ต่อเมื่อเรามีระบบเก่าอยู่แล้ว แล้วต้องการเพิ่มหรือปรับฟีเจอร์บางอย่าง (เคสทำระบบใหม่นี่ วาง flow ใหม่เลยดีกว่าหรือเปล่า อันนี้พิจารณากันเองแล้วกัน เพราะที่เคยเจอนี่ ทำใหม่ดีกว่านะ 😝) เราก็นำ wireframe เก่ามาปรับ หรือถ้าไม่มี wireframe อยู่ สร้างขึ้นมาเลยก็ได้ แล้วค่อยนำมาปรับต่อ
IV. Find inspiration elsewhere
ตามหาแรงบันดาลใจจากที่อื่น แล้วจะหาได้ที่ไหนละจ๊ะ 😆
ก็ลอก(เรียน)คนอื่นๆ ไง แอพหรือระบบดีๆ ที่เราใช้กันอยู่มีเยอะแยะ ตัวไหนดัง ตัวไหนที่เราใช้แล้วรู้สึกว่า เฮ้ย!!! ทำแบบนี้ดีหวะ ก็จุดธูปอัญเชิญเขามาตั้งไว้บนโต๊ะหมู่บูชา อ้างอิงซะ ศึกษาซะ ทำไมวางปุ่มตรงนี้ ทำไมให้ flow เป็นแบบนี้ สีล่ะ font ล่ะ layout ล่ะ เลือกปรับให้เหมาะกับระบบของเรา
สุดท้ายอย่าลืม ว่ามันตอบโจทย์สามข้อนั้นไหม
Five Steps to Creating Great Wireframes
การสร้างขึ้นมาก็ว่ายากแล้ว แต่การสร้างของที่ดีด้วยนั้นยากกว่า มาลองดูเคล็ดวิชาต่อมาซิ ว่าเราจะสร้างของดีขึ้นมาได้เยี่ยงไร
1. Articulate: เริ่มต้นด้วยคำถาม
กลับไปที่คำถามสามข้อ ในหมวดก่อนหน้านี้ ผู้ใช้ ต้องทำอะไร เพื่อจะแก้ปัญหาที่เขากำลังเผชิญอยู่ได้ ถ้าเรา ซึ่งเป็นคนที่จะช่วยหาคำตอบให้เขายังไม่รู้เลย แล้วสิ่งที่เราตอบ มันจะช่วยเขาได้จริงไหม หาาาา 😤
2. Generate: เปลี่ยนนามธรรมเป็นรูปธรรม
วาด วาด วาด
จำเฟสแรกได้ไหม วาดให้มันเยอะที่สุด ถ้าวาดๆ ไป แล้วตัน มอง flow ถัดไปไม่ออก ก็ขึ้น flow ใหม่ซะ โดยกลับไปถามคำถามชุดเดิมใหม่ ยังไม่ต้องคิดให้มาก (เดี๋ยวได้คิดแน่ 😝)
3. Iterate: ยำผสมและปรุงเพิ่ม
หลังจากได้กองขยะไอเดียในขั้นตอนที่สองพอสมควรละ เราก็มาไล่ดูทีละอัน ตรงไหนดี ตรงไหนแย่ เอามายำรวมกัน จะให้คนอื่นมาช่วยแนะก็ได้ แต่ยังไม่ต้องลงรายละเอียดกันมากนะ เอามาเรียงให้ได้ flow หลักซักสองสามแบบ แต่ละหน้าจอก็ออกแบบเผื่อให้มีตัวเลือกไว้ด้วย
4. Communicate: เติมความสมบูรณ์ด้วยความเห็น
เรามาคุยกันเต๊อะ และแล้วก็ถึงเวลาเชือด 5555
อย่ากลัวการที่ต้องนำเสนอสิ่งที่เราคิด สื่อสารเรื่องราวที่เราต้องการแก้ปัญหา และ wireframe ที่นำเสนอวิธีแก้ปัญหาของเรา ให้กับคนในทีม ให้กับลูกค้า ได้เข้าใจและร่วมกันซักถาม
อีกหนึ่งคนที่ต้องคุยในขั้นตอนนี้คือ developer (โอ้ว นึกว่าผมจะไม่มีบทซะแล้ว 😝) เพราะไอที่คิดไปนะ พวกพี่เขียนได้ไหม ฉะนั้น สิ่งที่ note ไว้ใน wireframe นอกจาก comment ต่างๆ ที่ต้องปรับแล้ว ยังจะมีพวกข้อคำถามทางเทคนิค เช่น ช่องนี้ถ้าไม่มีค่าส่งมาจะเป็นแบบไหน, กดตรงนี้แล้ว หน้าจอต้องปรับเป็นแบบไหน จะมี animation อะไรบ้าง, หรือถ้าขนาดหน้าจอเล็กมากๆ จะเป็นแบบไหน, ประสิทธิภาพของระบบละ จะใช้ paging หรือ scroll down ต้องทำ lazy load ไหม
กรุณาคุยกับพวกผมซักนิด เพื่อบรรยากาศในออฟฟิศที่ดีขึ้น 555 (ส่วนตัวยังไม่เคยเจออารมณ์นี้ เพราะคนออกแบบ มันก็คนเขียนโค้ดนี่แหละ อีตอนออกแบบนะ มันลงโค้ดไปในหัวแล้ว 😆)
5. Validate: และถามย้ำว่า มันเป็นไปได้ไหม
หลังจากไปปรับแบบแล้ว เราก็ยังต้องมาตรวจสอบต่อ
หนึ่ง ถามคนที่เข้าใจปัญหาของผู้ใช้จริงๆ ว่า ที่เราออกแบบนั้น สามารถแก้ปัญหาได้จริงไหม
สอง ถามคนทำ ว่าที่ออกแบบไปนั้น ด้วยระยะเวลาที่มี ด้วยในโลกแห่งความเป็นจริงนี้ มันสามารถสร้างขึ้นมาได้จริงๆ ไหม (หากงาน scale ใหญ่ ให้แบ่งเฟสทำ แต่ถ้าเป็นงานยาก ให้ต่อรองฟีเจอร์กันดู เน้น main flow ก่อน)
สุดท้าย ใช้ usability test ซะ (ลิงค์ด้านบนอธิบายได้พอควร)
จบละ ขอให้สนุกกับการออกแบบนะฮัฟฟฟ
หากถูกตาต้องใจ ขอเสียงปรบมือเป็นกำลังใจนิสสสนุงนะ 👏👏👏
ขอบคุณหลาย 😘😘😘
Ref: