6 principles ของการทำ Wireframe ของพรักซุส

จากบทความที่แล้วที่เราพูดว่าทำไมเราถึงเน้นการทำ Wireframe และไม่ทำ UI บทความนี้เลยอยากจะมาเล่าถึง 6 Principles ในการทำ Wireframe ของเราครับ

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

-----------------------------

1. Wireframe ที่ทำ จะต้องผ่านสายตาคนในทีมอย่างน้อย 2 รอบ ก่อนนำส่ง

เวลาที่ทำ เรามักจะมีดีไซเนอร์ 1-2 คนที่เป็นตัวหลักในการขึ้น Wireframe แต่เวลาดีไซน์ flows ของ Wireframe จบ มันยังไม่ได้จบแค่นั้น มันจำเป็นต้องมีคนระดับ Senior (หรือแม้แต่ คุณพิจ Founder เอง ก็ยังมานั่งรีวิว wireframe กับทีมดีไซน์ประจำครับ ) ก็จะมาคอยรีวิวงานว่ามีจุดที่แปลก ขาดตกบกพร่องตรงไหนยังไงบ้าง เพราะยิ่งดีไซเนอร์คิดในหัวมากเท่าไหร่ มันก็มีโอกาสสูงที่จะลืมมองในจุดง่าย ๆ หรือใช้คำที่เข้าใจยากเกินไป เราจึงต้องการ fresh eyes ในการช่วยมองและรีวิว ซึ่งมันเหมือนเป็นการทำ Usability Test แบบกลาย ๆ ในทีมเราเองกันก่อนครับ ซึ่งเราก็สามารถปรับแก้เป็น Iterations ใหม่ได้ทันที

ยิ่งระบบใหญ่ ๆ บางที Iterate กันหลายสิบรอบก็มี โดยเฉพาะพวก flows ระบบใหม่ ๆ ที่ไม่เคยมีตัวอย่างในตลาดมาก่อน เช่น ระบบ startup ซื้อขายเหล็กเส้น, ระบบเลือกซื้อแหวนเพชร ที่ users มีพฤติกรรมที่แตกต่างจากการช้อปปิ้งในแอปช้อปปิ้งทั่วไปครับ

-----------------------------

2. ไม่สนแค่ “Happy” แต่ให้น้ำหนักกับ “Unhappy” ยิ่งกว่า

หลายครั้งทีม Business ที่คิด requirement มักจะมองแค่ “Happy case” หรือ เวลาที่ users ใช้งานได้ถูกต้องไม่เจอปัญหาอะไร

แต่ในความเป็นจริงสิ่งที่คนสาย UX ต้องโฟกัสยิ่งกว่า ก็คือ “Unhappy cases” หรือกรณีที่ users เจอปัญหาแปลก ๆ ตอนใช้งานต่าง ๆ ซึ่งจะกลายเป็นประสบการณ์ใช้งานที่เลวร้ายมาก ๆ ได้ ถ้าเราไม่ได้คิดถึงและออกแบบเผื่อไว้ครับ

ตัวอย่างเช่น Flow การเข้าสู่ระบบ (Log in) - users บางคนอาจจะจำ password ไม่ได้, users บางคนอาจจะเปลี่ยนเบอร์มือถือไปแล้ว ไม่สามารถรับ OTP ได้, users บางคนสมัครสมาชิกไปแล้วแต่ลืม เลยสมัครซ้ำ เราต้องแสดงข้อมูลบอกยังไงให้ users เข้าใจ โดยไม่ทำให้ security ลดลง เป็นต้นครับ

ซึ่ง flow ที่ง่าย ๆ flow เดียว อาจจะมี Unhappy cases งอกออกมาอีกนับ 10 flows ก็เป็นไปได้ ทำให้ดีไซเนอร์เลยต้องคิดเผื่อให้ครอบคลุมที่สุดเสมอ ซึ่งก็อาจจะส่งผลให้ขั้นตอนการทำ Wireframe ออกแบบ flow ที่ดูง่าย ๆ อาจต้องใช้เวลาทำเป็นสัปดาห์หรือเป็นเดือนได้ครับ

-----------------------------

3. หน้าซับซ้อน ต้องแสดง States ต่าง ๆ ออกมาให้ชัด

การออกแบบ UX มันไม่ใช่แค่คิดว่าแต่ละหน้าจอจะมีหน้าตาเป็นยังไงก็พอ แต่เรายังต้องมีการคิดถึง “Interactions” หรือการปฏิสัมพันธ์ของ users กับหน้าจอด้วยครับ ยิ่งถ้าหน้าที่มีจุดที่ users interacts ได้เยอะ ยิ่งต้องมีการคิดถึง states ที่มันเป็นไปได้ให้มาก เพราะมันมีโอกาสที่เราจะลืมคิดถึงบางขั้นที่ users ใช้งาน แล้วทำให้เกิดปัญหาบนหน้า UI ได้ เช่น ลืมคิดว่าถ้า users กดเลือกค่า Filters ไปหลายตัว แล้ว จะกลับไปตอนแรกเริ่มได้ยังไง พอกดปุ่ม Reset แล้วแต่ละจุดต้องเกิดอะไรขึ้นบ้าง ต้องมีอะไรเกิดขึ้นบนหน้าจอบ้าง เป็นต้นครับ

-----------------------------

4. จัด Information ยังไงให้ชัด ต้องมาใน wireframe

ถึง Wireframe จะไม่มีสีสัน แต่สิ่งหนึ่งที่เวลาทำ Wireframe เราต้องมีเสมอ คือการแสดงให้ชัดถึงโครงสร้างของข้อมูลที่แสดงบนหน้าจอ หรือ “Information hierarchy” และ Grouping ของข้อมูล หรือข้อมูลอะไรที่เกี่ยวข้องกันที่ควรต้องเห็นชัดว่าอยู่ในกลุ่มเดียวกัน ข้อมูลอะไรควรอยู่คนละกลุ่ม ข้อมูลอะไรที่ควรเด่นมาก-น้อย ตามลำดับความสำคัญของมัน

ซึ่งปกติเวลาเราทำ Wireframe เราจะใช้แค่สีดำ และสีเทาหลากเฉด ซึ่งมันก็เพียงพอในการแสดงโครงสร้างของข้อมูลบนหน้าจอได้แล้ว รวมไปถึงการใช้ White space ที่ว่างระหว่าง element ก็จะช่วยให้สามารถแสดงถึง Grouping ของ elements ต่าง ๆ ได้แล้ว

พอ Wireframe ทำเรื่อง Information hierarchy ได้ชัดเจนแล้ว ทีมที่จะทำ UI ให้สวยงามต่อก็จะทำงานได้ง่ายขึ้นเยอะด้วยครับ

-----------------------------

5. ไม่ “Lorem Ipsum” แต่เน้นคำจริง ๆ

ข้อผิดพลาดอย่างนึงที่มักจะเห็นบ่อย ๆ เวลาที่น้อง ๆ ชาว UX ทำ Wireframe คือ การใช้ “Lorem Ipsum” ใส่แทนข้อมูลบนหน้าจอเต็มไปหมดครับ Lorem Ipsum นั้นเป็น placeholder text ชั่วคราวที่ใช้เวลาที่เรายังไม่มีดาต้าจริง แต่ปัญหาคือ การที่มีคำว่า Lorem ipsum เต็มหน้าจอไปหมด เวลาที่มีคนในทีมมารีวิวตัวดีไซน์ คนรีวิวก็จะไม่สามารถทดลองอ่านข้อมูลได้ เนื่องจากมันไม่ใช่ข้อมูลจริง ๆ และไม่สามารถบอกได้ว่า จัดวางข้อมูลแบบนี้ดีจริง ๆ แล้วรึเปล่า หรือ ชื่่อของปุ่มนี้ในเวอร์ชันจริงมันจะเป็นคำว่าอะไร เข้าใจได้ง่ายจริงหรือเปล่า (หรือการทำ UX Writing นั่นเองครับ)

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

-----------------------------

6. Wireframe ไม่ใช่เพื่อแค่มีหน้าตาให้ดู แต่เพื่อเอาไป User Test ต่อได้ด้วย

จาก 5 ข้อที่กล่าวมา จะเห็นได้ว่า Wireframe ที่ทางเราทำ เราพยายามทำให้หน้าจอแต่ละหน้าที่ออกแบบ มันแสดงถึง “การทำงานจริงและข้อมูลจริง” ของ UI ที่ครบถ้วน ประมาณว่าไม่ต้องทำ UI ให้สวยงามต่อ แต่ใช้ Wireframe ไป Dev เลย ก็สามารถให้ users ใช้งานจริงได้เลยครับ ซึ่งปกติแล้วเราจะเอา Wireframe ที่ทำนี้ไปทำ User Test รอบนึงก่อน เพื่อดูว่า flow และข้อมูลที่เราออกแบบมานั้น มันใช้ได้ง่ายจริง ๆ รึเปล่า (เวลา Test users ต้องลองทำโจทย์ตั้งแต่ต้นจนจบ ด้วยหน้าตาขาวดำแบบนี้เลย ดังนั้นข้อมูลมันต้องใช้คำจริง ๆ ให้มากที่สุด เป็นแค่ Lorem ipsum ไม่ได้ครับ)

ซึ่งผลของการ User Test เราก็จะนำมาปรับแก้ใน Wireframe ก่อน แล้วค่อยส่ง Wireframe ไปให้ทางทีม UI กับ Devs ต่อไป ซึ่งแปลว่าอย่างน้อยเรามั่นใจใน Flows และ Information ว่าใช้งานได้ง่ายแน่นอนในระดับนึงแล้วครับ ซึ่งก็จะลดการ rework ในอนาคตได้มาก และลด cost ในภาพรวมของโปรเจ็คได้มากด้วย

===========

สรุป

===========

เราให้น้ำหนักกับการทำ Wireframe เยอะ และใช้เวลาพอสมควรในขั้นตอนการทำ Wireframe เพราะขั้นตอนนี้ มันไม่ใช่แค่การทำหน้าจอสำหรับ Happy cases อย่างเดียว แต่มันรวมถึงการเก็บ Unhappy cases ทั้งหลาย และการคิดคำและจัดวาง Information ให้ดูง่ายเข้าใจง่ายอีกด้วยครับ และจะมีการรีวิวด้วยสายตาหลายคู่ให้เกิดหลาย Iterations กันภายในก่อนด้วย เพื่อลดปัญหาของดีไซน์ลงให้น้อยที่สุดในเวลาที่จำกัดครับ

และ Wireframe ที่ทำเสร็จก็จะต้องถูกนำไปทำ User Test รอบนึงก่อน เพื่อที่จะได้รีบแก้ไขแต่เนิ่น ๆ และลด Cost ของการต้องมา Rework ทีหลัง ซึ่งจะกลายเป็น cost ที่สูงกว่า และกระทบต่อ Business มาก ยิ่งกว่าครับ

และนอกจาก 6 ข้อนี้แล้ว เราก็ยังใช้ Heuristic Evaluation เพื่อเป็นไกด์ไลน์ในการออกแบบแต่ละขั้นของ Flow อยู่เรื่อย ๆ ด้วยครับ

แล้วทุกวันนี้ทีมคุณมีการทำ Wireframe ยังไงกันบ้างครับ