13 เรื่องเก็บตกที่ได้จากการทำงานเป็น UX/UI Designer ในปีแรกของการทำงาน

หลังจากที่เราเคยมาบอกเล่าประสบการณ์การย้ายสายงานจาก “Graphic Designer” มาเป็น “UX/UI Designer” แล้ว ในวันที่เราเขียน Blog นี้ มันเป็นช่วงเวลาครบ 1 ปีพอดีที่เราได้ย้ายสายมา เราเลยอยากจะมาแชร์ว่าใน 1 ปีที่ผ่านมาเราตกผลึกอะไรบ้างเกี่ยวกับการเป็น UX/UI Designer มือใหม่ ในบ.ที่เราทำอยู่เราเป็นทั้ง UX Designer, UI Designer และ UX Writer เลยอาจจะมีทั้ง 3 เรื่องปน ๆ กันไป

1. Persona มีประโยชน์ไม่ใช่แค่แง่ของ Design อย่างเดียว ในแง่ของ Writing ก็ช่วย

ตอนเราเรียนเกี่ยวกับ UX Bootcamp เค้าจะมีสอนเรื่อง Persona ซึ่งจะเป็น User คนที่เราจะแก้ปัญหาให้เค้า ในตอนนั้นเราพยายามทำความเข้าใจอย่างหนักว่าทำไปทำไมนะ ไม่เห็นเข้าใจเลยว่ามันจะมีประโยชน์ยังไง ตอนทำดีไซน์เราก็ยังเห็นไม่ชัด จนวันที่เราต้องมาทำ UX Writing ให้กับ Product ที่เราถืออยู่ ด้วยความที่เราทำ Product เกี่ยวกับกฎหมาย (Tech+Data+Law) ทำให้เวลาที่เราจะเลือกใช้คำอธิบายในหน้า UI มันยากขึ้นไปอีกเลเวลนึง ยิ่งพอเป็นภาษาไทยยิ่งยาก เราคิดหลายตลบมากว่าจะใช้คำว่าอะไรดี จนเรานึกถึง Persona เราเลยย้อนกลับไปถาม PO (Product Owner)และ UX Designer ของเราว่าเรากำลังทำ Platform นี้ให้ใคร เขาเป็นคนทั่วไปที่รู้ภาษากฎหมายมั้ย หรือเค้าเป็น Tech Savvy ที่รู้ภาษากฎหมายด้วย หรือเค้าไม่รู้อะไรเลย อย่างเช่นตอนนี้มี PDPA มีการจัดการ Consent หรือความยินยอม เราก็ต้องทำ UX Writing ให้ Persona ของเราเข้าใจในสิ่งที่เราออกแบบไปซึ่ง Persona จะช่วยให้เราเลือกคำที่ต้องใช้ได้ดียิ่งขึ้น ตอนเรียนก็ไม่เข้าใจหรอกนะ จนมาลงมือทำเองถึงจะเข้าใจ

2. เขียน Writing ภาษาไทย ยากกว่าภาษาอังกฤษแบบตะโกน

เราว่าภาษาที่เราใช้ทุกวันนี้เราซึมซับคำต่างประเทศมาใช้กันเยอะเช่นคำว่า Download, Import, Export และอื่นๆ บางประโยคเราอ่านภาษาอังกฤษเราก็เข้าใจในทันที แต่พอเราต้องมาทำ Platform ภาษาไทยเพื่อคนไทย โอ้โห ยากอะ เพราะภาษาไทยมันมีเอกลักษณ์บางอย่าง บางครั้งการแปลแบบตรงตัวเลยก็ค่อนข้างเยิ่นเย้อและเข้าใจลำบาก เช่น อย่าง Error Message อย่าง Session Expire เราก็เข้าใจเลยว่าอ่อ เว็บหรือแพลตฟอร์มเราใช้อยู่ เราอาจจะ Log in มานานเกินไปแล้ว ระบบเลยแจ้งเราว่าหมดอายุนะ เราต้อง Login ใหม่ แต่พอจะต้องเขียนเป็นภาษาไทย เราจะทำยังไงให้ Error Message ของเราไม่ยืดยาวจนอ่านแล้วไม่เข้าใจ

หรืออย่างคำว่า Export ซึ่งมันแปลว่าส่งออก เราก็ต้องคิดว่าถ้าเราจะให้เค้า Export ไฟล์งานออกมา เราใช้คำว่าส่งออกได้มั้ยหรือเขียนตรงตัวไปเลยว่า เอ็กซ์ปอร์ต หรือจะใช้เป็น Download ที่เป็นปลายทางของการ Export อยู่ดี สุดท้ายเราก็เลือกที่จะใช้คำว่า Download แทน นี่ก็เป็นสิ่งที่เราจะต้องคิด ต้องชั่งน้ำหนัก ต้องดู Mood and Tone ของ Product ด้วย This is so challenging! แต่ทั้งหมดทั้งมวลแล้วเราก็ต้องไปทำ Usability Test อยู่ดีว่าที่เราทำไปมันใช้ได้จริงหรือเปล่า

ยังไม่รวมว่าต้องเขียนให้ถูกต้องตามราชบัณฑิตยสภาอีกนะ ปวดหัวจริง

3. ควรทำ Sheet ของคำที่เราใช้ เพื่อจะได้กลับมาดูว่าทุกอย่างยังมี Consistency อยู่มั้ย

เรามีโอกาสได้จับ Project นึงโดยที่เราทำหลัก ๆ จะเป็น UI กับ UX Writing (มี Senior ทำพาร์ทของ UX Design) ทำให้เราต้องคิดคำทั้ง Platform ซึ่งพอ Design ไปหลาย ๆ หน้า คำที่เราใช้จะเริ่มหลุด Theme หรือ Mood and Tone พอมารู้ตัวอีกทีมันก็ไม่ Consistent กันแล้ว Senior Designer ของเราก็แนะนำเราให้ทำ Sheet ขึ้นมาอันนึงเผื่อใส่คำหลัก ๆ ที่เราเช่น เช่น

“เราจะเรียกตัวเราในฐานะ Product ตัวนี้ว่าอะไร ใช้คำว่า “ระบบ” หรือ “เรา””

หรือ

“เราจะใช้คำว่าถึงโควต้าหรือถึงขีดจำกัด”

หรือ

“คำว่า ID เราจะใช้ว่า ID หรือทับศัพท์ว่า ไอดี หรือ เลขไอดี หรือเลขประจำตัว”

ซึ่งพอมันมี Google Sheet ที่เป็น Source of Truth ของ Product มันจะทำให้คนในพาร์ทอื่นเช่น Dev, QA หรือ Designer คนอื่นทำงานได้ง่ายขึ้น เกิดเค้าเอ๊ะกับคำที่เราใช้ก็สามารถมาดูใน Sheet นี้ได้ ทำให้ทีมลดแรงการทำงานไปได้ประมาณนึงเลย

4. นอกจาก Sheet ของ Microcopy แล้วก็ควรทำของส่วนอื่นเช่น Error Toast

สิ่งที่เราเจอตอนเรา Design คือบางครั้งเราจำไม่ได้ว่าถ้าเกิด Scenario นี้ด้วยเงื่อนไขนี้ เราจะขึ้น Toast ว่ายังไงเช่นเราจะเอาไฟล์เข้ามาในระบบแต่ไม่สามารถเอาเข้ามาได้เพราะไม่ได้ใช้นามสกุลที่กำหนดเช่น

Toast issue: ไม่สามารถนำเข้าข้อมูลได้
Toast Detail: นามสกุลของไฟล์ไม่ถูกต้อง กรุณาลองใหม่

ซึ่งตอนแรกเราไม่ได้จดไว้ พอเจอเคสอื่นที่เป็นเคสลักษณะคล้ายกัน เราดันใช้ประโยคอื่นเช่น

Toast issue: ไม่สามารถอิมพอร์ตข้อมูลได้
Toast Detail: นามสกุลของไฟล์ต้องเป็น .CSV เท่านั้น

พอตอนมาตรวจงานอีกรอบก็เจอว่ามันไม่ Consistent กันซึ่งมันมีผลกับงานของเรา อาจจะดูเป็นสิ่งเล็ก ๆ น้อย ๆ แต่เพื่อความ Consistency เราก็ควรคำนึงถึงด้วย รวมถึงอย่าง Error Toast ทั่วไปเช่น “เกิดข้อผิดพลาด” มันก็ไม่ได้บอกว่านะว่าเกิดอะไรผิดพลาด ซึ่งถ้าเราสามารถระบุได้ว่าเกิดอะไรขึ้นจริง ๆ และสามารถแก้ไขมันได้ยังไง มันจะเป็น UX Writing ที่ดีกว่าและดีต่อประสบการณ์ผู้ใช้ด้วย

5. Auto Layout saves my time

เราเคยใช้ Auto Layout ใน Figmaตอนที่เรียน Bootcamp แต่ยังไม่ค่อยชินนัก (ในช่วงเดือนแรก ๆ ที่มาทำงาน) ตอนนั้นใช้วิธีกรุ๊ปทุกอย่าง เอาจริงแม้แต่ทำปุ่มเราก็สร้างพื้นมาอันนึงกรุ๊ปรวมกับ Text แล้วก็เป็น Senior Designer นี่แหละที่แนะนำเราว่า “เอาทุกอย่างเข้า Auto Layout ไปเลยสิพี่” หลังจากนั้นเราเลยหัดใช้และใส่ทุกอย่างเข้า Auto Layout แทบจะทุกอย่างเลยที่สามารถรวมเป็นกลุ่มก้อนได้ และเราพบว่า เราประหยัดเวลาไปประมาณ 70% ในการแก้ไขหรือถ้าจะ Move ของ ก็ง่ายมาก ๆ เราอยากจะบอกทุกคนว่า ทำ Auto Layout เถอะ ชีวิตจะดีมาก ๆ เพราะทุกอย่างถูกล็อกตำแหน่งและระยะขอบ (Padding) ไปแล้ว อาจจะมีหลาย ๆ คนที่ยังไม่เคยใช้หรือไม่ถนัด แต่เชื่อเรา ใช้ Auto Layout ใน Figmaให้เป็นแล้วชีวิตคุณจะดีขึ้นมาทันที

6. อะไรที่ใช้ Plugin ได้ก็ใช้เถอะ

เราว่าเราเองเป็นคนที่ Old School ประมาณนึง คือเรามีคติว่า เราควรจะทำทุกอย่างทุกขั้นตอนด้วยมือตัวเอง หรือทำแบบ Manual ซึ่งเราว่ามันดีต้องที่พอเราทำมือเองทั้งหมดเราจะรู้ Concept รู้ที่มาที่ไป สามารถกลับไป Recap หรือ Recheck ได้ แต่มันแลกมาด้วยเวลามหาศาลในการทำมือ และด้วยความที่เราเคยใช้ Photoshop มาก่อน มันจะมี Plugin บางตัวที่เวลาเราใช้กับอะไรที่จำนวนมาก ๆ มันจะทำงานได้ไม่ 100% (แต่อันนึงเคยใช้เมื่อ 10 ปีที่แล้วนะ ตอนนี้อาจจะพัฒนาแล้ว) เราเลยแอบไม่ค่อยเชื่อ Plugin เท่าไหร่ กลัวมีหลุด

เราเคยที่จะต้องแก้ Font Size ใน Design System จุดที่เราจะแก้มีประมาณ 20+ จุด เราก็คลิกไปทีละอัน ๆ ค่อย ๆ แก้ไปเรื่อย ๆ แล้วก็เริ่มเหนื่อย เริ่มท้อ เพราะมันใช้เวลามากในการรื้องานเก่า จนตอนนั้นเราคิดถึงขั้นว่าจะทำขึ้นใหม่เลยทั้งหมด เราเลยไปปรึกษา Senior Designer เราว่าทำท่าไหนดี แล้ว Senior ของเราก็ถามเราว่า “ทำไมพี่ไม่ใช้ Similayer (Plugin) ไปเลยละ เปลี่ยนทีเดียวได้หมดเลย” Senior ของเรา Demo ให้ดูว่ามันทำงานยังไง แล้วเราก็พบว่าเรามัวแต่นั่งทำมือทั้งหมดเพื่ออะไร ในเมื่อสามารถใช้ Plugin แก้มันได้ใน 4–5 คลิกและไม่ถึง 1 นาที ถามว่ามันจะมีจุดที่หลุดมั้ย เราว่าอาจจะมีก็ได้แต่เก็บไว้เป็นเรื่องของอนาคตเถอะ เพราะข้อผิดพลาดมันน่าจะน้อยมาก อาจจะแค่ 1% เท่านั้น แล้วเราจะเสียเวลาหลาย ๆ ชั่วโมงเพื่อสิ่งนี้ทำไม

ใช้ Plugin เถอะ แล้วเอาเวลาไปทำงานใน Sprint ดีกว่า!

7. Design System เหมือนง่าย แต่ไม่ง่าย

ส่วนตัวเราเป็นคนที่ชอบเรื่อง Design System มาก ๆ ไม่รู้ว่าทำไม เรารู้สึกว่าเราตื่นเต้นกับมันมาก เราไปดูของหลายที่มากแล้วก็อยากมีโอกาสลองทำ เคยคิดว่ามันไม่ยากมาก อาจจะคล้าย ๆ CI (Coperate Identity) ซึ่งจริง ๆแล้วมันไม่ใช่ และพอได้มาจับ Product แล้วต้องมาทำจริง ๆ ก็พบว่ามันไม่ง่ายเลย ในเวลานานพอสมควร มันต้องคิดเยอะ เป็นการคิด Logic อย่างหนึ่งเช่นการทำปุ่มก็ต้องคิดถึง State ต่างๆ หรือปุ่มแบบที่มี Icon ต้องทำ Variant อีก มี Form, Input, Menu และอื่น ๆ อีกมากมาย มันต้องคิดว่าจะทำยังไงให้เวลาเราเอาไปใช้มัน Effective ที่สุดแล้วมีระบบที่สุด ง่ายต่อการแก้ไขที่สุด เราเคยคิดว่าจะใช้เวลา 2 อาทิตย์เพื่อที่จะทำ Design System อย่างเดียว แต่สุดท้ายแล้วเราก็ไม่มีเวลาขนาดนั้น และมันมีส่วนประกอบหลายอันที่ทำไปก็ไม่ได้ใช้ แต่เสียเวลาทำไปแล้ว เราเลยลองไปอ่าน ๆ ศึกษามาจนเจอหลาย ๆ ที่จนพบว่าเค้าบอกให้เราทำเท่าที่ใช้ หลัง ๆ เราเลยไปซื้อ Design System (UI) ของเจ้านึงมาคือ Untitled UI เราซื้อเพื่อเอามาแกะ Design System ของเค้า เอามาดู Logic ว่าเค้าทำยังไง แล้วก็พบว่ามันมีประโยชน์มากๆ ของ Untitled UI ก็มีให้ครบ จริง ๆ สามารถนำไปใช้ขึ้นโปรเจกต์ใหม่ได้เลย แนะนำมาก ๆ ค่ะ

8. ควรทำ Wireflow และ Information Architecture ก่อนลงมือดีไซน์ จะได้ไม่ต้องแก้งานไป ๆ มา ๆ

เรามีโอกาสได้ทำ Product นึง เป็น Product ใหม่ ด้วยความที่เป็น Product ใหม่ และทุกอย่างก็ดูรีบเร่งไปหมด หลังจาก Senior UX ไปทำ Research ผ่าน Product Owner เรียบร้อยก็ทำ Wireframe ต่าง ๆ แล้วเราก็ Design ตาม พอ Design ทั้งหมดเสร็จเราพบว่าเราเจอช่องโหว่เยอะมากระหว่าง Design ทั้งเงื่อนไขต่างๆระหว่าง Process ต่างๆ เราพบว่าเราทำ Flow ไม่ครบ แล้วมันทำให้เราต้องเสียเวลาแก้และต้องไปรบกวน Dev ให้แก้งานบ่อยๆ ซึ่งถ้าเราคิดให้ครอบคลุมมากที่สุดแต่แรก มันจะช่วยลดเวลาในการทำงานได้มากกว่า

9. เรียนใน Bootcamp ไม่เท่ากับทำงานจริง

เราเรียน Bootcamp ประมาณ 6 สัปดาห์ สิ่งที่เราได้เรียนมาบางอย่างเราก็นึกภาพไม่ออกว่ามันจะเป็นปัญหายังไง หรือบางทีก็คิดว่าที่เรียนมามันก็ไม่ยากเลยนิ แต่พอได้มาทำงานจริง เราก็ค้นพบว่า สิ่งที่เราได้เรียนใน Bootcamp นั้น มันน่าจะเป็นแค่ 10-20% ของจักรวาล UX ด้วยซ้ำ เวลามาทำงานจริงเราจะเจอหลาย ๆ อย่างเช่น ตอนเรียนเราจะถูกสอนให้เราต้องทำเพื่อ User แต่พอมาทำงานจริงบางครั้งเราอาจจะไม่มีเวลามา Empathy user ด้วยซ้ำ หรือบางทีเราก็ต้องทำตามสิ่งที่ลูกค้า (Client) หรือ PO (Product Owner) อยากให้ทำ หรือบางทีเราอาจจะไม่มีเวลามาทำอะไรให้สวยงามเพราะต้องรีบออกของ หลาย ๆ ครั้งที่เราต้องกัดฟันยอมปล่อยให้มีความไม่ Smooth หรือเกิดประสบการณ์ที่ไม่ดีไปก่อน เพราะเวลามีจำกัด ในช่วงแรก ๆ เรารับไม่ได้ เราไม่ยอมเลย แต่สุดท้ายก็ไม่สามารถทำอะไรได้เพราะเวลาไม่มี ตอนนี้ก็เริ่มปล่อยวางได้บ้างแล้ว และที่สำคัญเลยคือเราต้องคอยเติมความรู้เรื่อย ๆ เพราะมันมีอะไรที่อัปเดตตลอดเวลา ถ้าเราทำตัวเป็นน้ำเต็มแก้ว เราจะไม่มีวันทันโลก

10. เป็นกราฟิกมาก่อนมันดีอย่างนี้นี่เอง

ข้อดีของการที่เป็นกราฟิกมาก่อนคือบางทีเราอาจจะนึกภาพในหัวออกได้เร็ว บางครั้งเราสามารถทำ Wireframe แบบเร็ว ๆ วาดออกมาให้ Dev เห็นภาพจากที่ในหัวเราคิดได้ เรื่องความสวยงามก็มีผลมาก ๆ การจับคู่สี บางครั้งเรานึกภาพออกเลยว่าสีคู่ไหนวางด้วยกันได้หรือไม่ได้ หรือไอคอนอันนี้มันยังไม่กลางนะต้องขยับอีก จนบางทีเราอาจจะเกือบ ๆ เป็น Pixel-perfect เลยด้วยซ้ำ (แต่ยังไม่ถึงขั้นนั้นนะ)ในฐานะที่เราทำ UI มากกว่า UX บางครั้งเราก็อาศัยสกิลการเป็นกราฟิกเพื่อมาทำให้ UI ของเรามันชัดเจน อ่านง่ายและสวยงาม แล้วอย่างการเลือกใช้ Icon หรือทำกราฟิกประกอบเว็บไซต์ เราก็สามารถลงมือทำได้เลย บางครั้งคนอื่นดูไม่ออกว่าสีที่ใช้อยู่มันไม่ใช่สีที่มันเคยเป็น แต่ก็จะเป็นดีไซน์เนอร์เองที่ดูออกว่ามันไม่เหมือนเดิมนะ ซึ่งทำให้งานมันมีความแม่นขึ้น

11. อ่าน Blog บ่อยๆ จะได้มีเทคนิคเอามาช่วยเวลาทำงาน

สำหรับเราแล้วในโลก UX/UI มันมีอะไรอีกหลายอย่างที่เรายังไม่รู้ เราอาจจะไม่มีเวลามาอ่านหนังสือหลาย ๆ เล่ม แต่สิ่งที่เราทำบ่อย ๆ คือการอ่าน Blog ใน Medium หรือการดู IG Post เพื่อเอาเทคนิคเล็ก ๆ น้อย ๆ เช่นเรื่องของปุ่ม, การทำ variant หรือเทคนิคด้าน UX Writing ที่เราสามารถเก็บเล็กผสมน้อยมาเป็นความรู้ของเรา สำหรับเราการเรียน Bootcamp แค่ครั้งเดียวมันไม่มีทางเพียงพอสำหรับการทำงาน แต่การสะสมข้อมูลทีละเล็กละน้อยนั่นแหละที่จะทำให้เราสามารถพัฒนาตัวเองให้ทันกับการทำงานได้ จริงๆเราตั้งกฎให้ตัวเองว่าจะต้องอ่าน Blog วันละ 1–2 เรื่องและดู IG Post ทุกวัน (นอกจากส่องรูปเพื่อนแล้วมันยังมีความรู้ด้าน UX/UI ในนั้นอีกด้วย)

12. การมี Senior เก่งๆ ใจดีๆ ถือว่าเป็นบุญ

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

13. คุยกับ Dev เยอะ ๆ Empathy เค้าหน่อย

เราเคยเป็นคนใจแคบมาก่อน เราถูกสอนมาเสมอว่าต้องเอาใจ Dev นะ ต้องพยายามช่วยทำงานให้ Dev ใช้แรงน้อยที่สุด หรืออย่าทำให้ Dev โกรธ เราก็มาคิดนะว่าอะไรกัน ทำไมเราต้องเอาใจทีม Dev ขนาดนั้นนะ ไม่เห็นมีใครมาเห็นใจทีม Designer บ้างเลย จนเรามีโอกาสได้ไปทำ Workshop กับพี่แบงค์ อภิรักษ์ เลยได้รู้เหตุผลว่าทำไมเราต้องช่วย Dev เพราะในขณะที่เราแก้ดีไซน์นี้ 20 นาที Dev อาจจะต้องไปขุด Code ปั้นงานขึ้นมา 2 อาทิตย์ งานของเค้ายากกว่าฝั่งเรามาก ถ้าเราสามารถช่วยงานเค้าก็เท่ากับช่วยงานตัวเราเองด้วย หลัง ๆ เราเลยจะเอา Design คร่าวๆไปคุยกับ Dev บ่อย ๆ ว่าทำแบบนี้ได้มั้ย แบบไหนดีกว่า แล้วเราก็พบว่า เออ งานมัน Flow ดีนะ จนเป้าหมายต่อไปของเราคือจะไปเรียน Frontend แบบเบสิคเพื่อเอามาคุยกับ Dev แล้ว

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