ทำไมถึงใช้คำนี้? ก่อนหน้านี้เราใช้คำว่าอะไรนะ แล้วเราเปลี่ยนไปใช้คำนี้เมื่อไหร่? มันคงจะดีถ้ามีที่ที่หนึ่งที่รวบรวมที่มาที่ไปของ microcopy ที่เราเขียน หรือเวลาที่เราไปรับงานต่อจากคนอื่น เราจะได้เขียนต่อได้อย่างถูกต้อง
ในการทำงานของ UX Writer หลังจากที่เราคิดและเขียนคำลงในหน้าจอเสร็จเรียบร้อยแล้ว เราก็จะส่งงานของเราไปให้ stakeholders ที่เกี่ยวข้องรีวิวดูว่าเขาเห็นด้วยและพอใจกับคำที่เราเขียนไปหรือไม่ ซึ่ง stakeholders หลักๆ ก็จะมาจากหลากหลายฝ่าย ไม่ว่าจะเป็น PO, BA, BU, CX, Compliance และ Legal
และด้วยความที่ปัจจุบันเราทำงานโดยใช้ Figma เป็นหลัก การ feedback ก็จะมีทั้งการปัก comment ใน Figma การส่ง feedback กลับมาทางอีเมล การบอกปากเปล่าระหว่างการประชุม หรืออาจจะผ่านการ chat ทาง MSTeam ซึ่งจะเห็นได้ว่า feedback นั้นจะมาจากหลายฝ่ายและมาจากหลายช่องทาง คำ 1 คำ ปุ่ม 1 ปุ่ม อาจจะมี feedback มากถึง 5 คน 4 รูปแบบเลยก็เป็นได้
แล้วเราจะทำอย่างไรให้เราสามารถเอา feedback เหล่านั้นมาดูได้ง่ายๆ ว่าควรจะปรับแก้ตามใคร ปรับแก้ออกมาเป็นอย่างไรถึงจะออกมาเป็นที่พอใจของทุกฝ่าย แล้วถ้าเรามี UX Writer หลายคนที่ทำงานอยู่ใน project เดียวกันล่ะ ทำอย่างไรเราถึงจะสื่อสารให้ทุกคนเข้าใจได้ตรงกัน และสามารถทำงานต่อในโฟลวอื่นๆ ได้อย่างราบรื่น โดยที่คำที่ใช้ยังคงยึด voice & tone เดิมและยังคงรักษาความ consistency ไว้ได้ต่อไป รวมไปถึงในอนาคต ถ้ามี UX Writer คนอื่นมารับงานต่อจากเรา เขาก็ควรจะเข้าใจเหตุผลและที่มาที่ไปของการแก้ไข ถ้าหากจู่ๆ มีคนถามขึ้นมาว่า ทำไมถึงใช้คำนี้ล่ะ? เขาก็ควรจะมีที่สักที่หนึ่งที่สามารถเข้ามา track ดูประวัติได้ว่า การแก้ไขคำ หรือข้อความในแต่ละจุดนั้น มันมีที่มาที่ไปอย่างไร
ซึ่งในการทำงานใน project ที่เรารับผิดชอบอยู่นั้น จะมี UX Writer สองคนทำงานร่วมกัน ซึ่งเราทั้งคู่ได้สร้างไฟล์ไว้ไฟล์นึงที่ชื่อว่า “Microcopy review backup” ซึ่งจะเป็นพื้นที่ทำงานของ UX Writer ทุกคนใน project และเป็นเหมือน Single source of truth ที่เราจะเอา feedback ทั้งหมดมาเก็บรวบรวมไว้ในนี้ และใช้เป็นที่พูดคุยและปรึกษากันว่าจะปรับแก้ข้อความไปในรูปแบบไหน
วิธีรวบรวม feedback ต่างๆ มาไว้ในไฟล์นี้
ในวิธีการทำงานของ UX Writer จังหวะที่เราส่งงานให้กับ stakeholders โดยปกติเราจะไม่ได้ส่งทั้งโฟลวไปให้รีวิวคำ แต่จะคัดเฉพาะหน้าจอที่มีคำที่เราต้องการให้รีวิวออกมา แล้วทำกรอบวงไว้ให้รู้ว่าคำนี้เป็นคำใหม่ที่เราอยากให้เขาช่วยรีวิวนะ
หลังจากที่เราส่งหน้าจอไปให้รีวิวแล้ว เราก็จะเอาหน้าจอนั้นมาแปะไว้ในไฟล์ Microcopy review backup นี้ และเมื่อที่ได้รับ feedback แล้ว เราจะ capture feedback ต่างๆ ที่ส่งมา ไม่ว่าจะเป็นทางอีเมล ทางคอมเมนต์ Figma ทาง chat หรือถ้าเป็นการบอกปากเปล่า เราก็จะจดโน๊ตมาแปะไว้ เสร็จแล้วทำกรอบของแต่ละ feedback ใส่สีตามที่เรากำหนดไว้ว่าแต่ละฝ่ายเป็นสีอะไรบ้าง เพื่อที่เวลาเราเอาคอมเมนต์มาลง เราจะได้ไม่งงว่าคอมเมนต์นี้มาจากฝ่ายไหน โดยที่ไม่ต้องมาคอยเสียเวลาพิมพ์ว่ามาจาก Legal นะ หรือมาจาก CX คือมันจะช่วยให้ refer ได้ง่ายๆ และไม่รกด้วย
เวลาที่เราจะแก้คำ ก็ให้สร้าง section ขึ้นมาใหม่ อาจจะตั้งชื่อว่า Revise แล้ว copy หน้าจอนั้นๆ มาไว้ใน section แล้วก็มาแก้ไขคำในหน้าจอใหม่ที่เราเอามาวาง
ทีนี้เราก็จะมีหน้าจอที่มีคำเดิมที่เราส่งไป มี feedback ทั้งหมดที่ได้รับมา และมีหน้าจอที่มีคำที่เราจะแก้ไข ซึ่งพอเรากางคอมเมนต์ออกมาทั้งหมด เราก็จะเห็นภาพรวมแล้วว่า feedback ที่ส่งมาเป็นไปในทิศทางเดียวกันไหม และเราก็สามารถเช็คได้ว่าคอมเมนต์นี้แก้ไปรึยัง เราแก้ครบทุกจุดไหม และสามารถดู consistency ได้ว่าจากจุดนี้ที่เราแก้ไปมันมีจุดไหนที่มันไม่ consistent กันรึเปล่า
และถ้าเราส่ง revise รอบแรกไปแล้วและได้กลับมาแก้อีกรอบนึง เราก็ทำซ้ำแบบเดิม คือสร้าง section ใหม่แล้วตรงชื่อ section เราก็ตั้งชื่อเป็น Update และใส่วันที่กำกับไว้ว่าเราอัปเดตใหม่ล่าสุดวันที่เท่าไหร่
หากมีการทำหลายโฟลว แล้วเราแบ่งส่งตรวจเป็นรอบๆไป เราก็ควรแยก page ออกมาเฉพาะแต่ละรอบ ใส่ชื่อโฟลวและเขียนวันที่ส่งตรวจกำกับไว้ให้ชัดเจน และแปะ link ไฟล์หลักที่ใช้ทำงานร่วมกับ UX Designer เอาไว้ก็จะช่วยให้ทำงานข้ามไฟล์ไปมาได้สะดวก
ประโยชน์ของการมี Microcopy review backup file
- เป็นที่รวบรวม feedback จากทุกๆฝ่าย ไม่ว่าจะเป็นจาก PO BA 4P BU CX ซึ่งมักจะมาไม่พร้อมกัน ทีนี้หากเขาส่งมาแล้ว UX Writer คนใดคนหนึ่งว่างก็สามารถเอา feedback นั้นๆ มารวมไว้ในไฟล์นี้ก่อนได้เลยโดยไม่ต้องรอว่าเป็นหน้าที่ใคร เมื่อคนอื่นๆ เข้ามาดูก็จะเห็นว่า อ้อมีคนรวมแล้ว ก็จะได้ไม่ต้องทำงานซ้ำซ้อน หรืออาจช่วยรีเช็คอีกทีก็ได้ว่าครบไหม
- พอได้ feedback มาครบ UX Writer ทุกคนในโปรเจคก็สามารถเปิดไฟล์ Figma นี้คุยไปพร้อมๆ กันได้เลยว่าใครคอมเมนต์อะไรมาบ้างและจะแก้ไขไปในแนวทางไหน จะแก้ตาม legal ไหม หรือแก้ตาม CX หรือต้องจับเอามาผสมผสานกัน ซึ่ง UX Writer แต่ละคนก็สามารถใช้พื้นที่ในไฟล์นี้ลองคิด พิมพ์ และนำเสนอ microcopy ของตัวเองได้เลย
- หลังจากที่เราตกลงกันได้แล้วว่าจะแก้ไข microcopy เป็นแบบไหน การที่เราแยกจอไว้ให้มาอยู่ใน section Revise ทุกคนก็จะรู้แล้วว่าอันนี้นะคือ final ที่เราจะเอาไปลงในโฟลจริง UX Writer แต่ละคนก็จะสามารถกระจายตัว แยกย้ายกันหยิบคำนั้นๆ ไปแก้ในหน้าจอจริงได้เลยโดยไม่ต้องรอกันให้เสียเวลา และไม่สับสน การทำงานก็จะรวดเร็วและถูกต้องแม่นยำ
- เวลาที่เราได้รับ feedback มาจาก stakeholders เราก็สามารถเอามาแปะไว้ แล้วรีเช็คกับหน้าจออื่นๆ ได้ง่ายขึ้น ว่ามันขัดกับคำที่เราเคยเขียนไหมนะ สมมติว่ามีคำแบบนี้แต่อยู่โฟลวอื่น ก็สามารถ copy หน้าจอนั้นๆ มาเทียบกันได้เลยว่าตรงกันรึเปล่า หรือบางทีมันอาจจะไม่อยู่ในหน้าจอนี้ แต่อยู่ในหมายเหตุของอีกหน้าจอนึง เราก็เอาข้อความในหมายเหตุมาแปะเทียบดูได้เลยว่าควรจะเขียนเป็นยังไง คือมันจะช่วยให้เรามองเห็นภาพรวมได้ง่ายกว่า
- เราสามารถกลับมา track คำเดิมที่เราเคยใช้ และดูประวัติการแก้ไขได้ง่ายขึ้น เพราะเรามีการเก็บคำเดิมที่เคยร่างไว้ มี feedback ทั้งหมดที่ได้รับมา และคำใหม่ที่แก้ไป รวมถึงถ้ามี UX Writer คนใหม่เข้ามาก็จะรู้ที่มาที่ไปว่า เอ๊ะ ทำไมถึงใช้คำนี้นะ พอเข้ามาดูก็อาจจะเห็นว่า “อ๋อ เราใช้คำนี้เพราะเป็นคำที่ทางลูกค้าให้ใช้” หรือ “อ๋อ ที่ไม่ใช้คำนี้ เพราะทาง Legal เห็นว่าอีกคำเหมาะสมกว่า” เป็นต้น ซึ่งพอรู้ที่มาที่ไปแล้วก็จะทำให้ UX Writer ที่มารับช่วงต่อ สามารถทำงานได้ง่ายขึ้น รู้ว่าควรจะเลือกใช้คำไหน และจะได้เลี่ยงคำเดิมที่เคยส่งไปแล้วไม่ผ่านได้อีกด้วย
ในกรณีที่ microcopy ในโฟลวหลักถูกแก้ไขโดยไม่ได้ตั้งใจ หรือระบบเกิดปัญหา เราก็สามารถเข้ามาดูคำที่ได้รับการ approved แล้วในไฟล์ Microcopy review backup นี้ได้
ข้อดีของการจัดเก็บ Microcopy review backup ใน Figma file
- เนื่องจากปกติเราทำงานใน Figma อยู่แล้ว ดังนั้น เราจึงสามารถ copy หน้าจอและคำจากในโฟลวหลักมาแปะไว้ได้เลย และเมื่อได้คำที่ final แล้ว เราก็สามารถ copy คำนั้นๆ จากในไฟล์นี้ กลับไปใส่ในโฟลวหลักได้เลย โดยไม่ต้องพิมพ์ซ้ำให้เสียเวลาและหลีกเลี่ยงปัญหาการพิมพ์ผิดได้อีกด้วย
- สามารถค้นหาคำที่ต้องการได้ง่ายและรวดเร็ว รวมถึงสามารถหาข้าม flow ได้ด้วย บางทีเราอาจคุ้นๆ ว่าเราเคยเขียนคำๆ นี้ไว้แล้ว แต่จำโฟลวไม่ได้ว่าเคยเขียนในโฟลวไหน หาก search หาใน Figma เราจะเห็นได้เลยว่าคำๆ นั้นอยู่ในโฟลวไหนบ้าง ซึ่งบางทีเราอาจจะนึกไม่ถึงว่ามีคำๆ นี้อยู่ในโฟลวนั้นด้วย ก็จะช่วยลดความผิดพลาดที่เราอาจจะแก้คำๆ นั้นไม่ครบในทุกๆ จุดได้
- สามารถ capture หลักฐานการ chat มาเก็บไว้เพิ่มเติมและเขียน note เก็บไว้ได้ง่ายๆ นอกจากนี้ Figma ยังมีส่วนเสริมที่เป็น checklist ซึ่งถ้าเรามีคำที่ต้องแก้หลายจุด เราก็สามารถดูจาก checklist นี้ได้เลย
- การใส่วันที่กำกับไว้ ทำให้เราสามารถย้อนกลับไป track หาในอีเมลได้ง่ายขึ้นด้วย เพราะในแต่ละวัน เราได้อีเมลเยอะมาก การ search หาใน MS Outlook ก็อาจจะดึงอีเมลที่ไม่เกี่ยวข้องมาด้วย แต่ถ้าเรารู้ขอบเขตของช่วงเวลาก็จะช่วยให้เราลดเวลาในการค้นหาและเสียเวลากับการที่ต้องคลิกเข้าไปดูอีเมลละฉบับน้อยลงด้วย
ทั้งนี้ อาจจะมีข้อสงสัยว่า แล้วถ้าเรารับ feedback เฉพาะการ comment ใน Figma เท่านั้นล่ะ เรายังต้องมี Microcopy review backup file นี้ไหม เพราะอย่างไรเราก็น่าจะกลับมาดู comment ใน Figma ก็ได้รึเปล่า แต่จากการที่เราได้ทำงานมาหลายโปรเจคที่ใช้วิธีแก้ไขตามคอมเมนต์ใน Figma ก็พบว่ามันก็มีข้อเสียอยู่บ้าง เพราะสุดท้ายแล้วถ้าเวลาผ่านไปนานๆ หรือไฟล์งานมันมีการอัปเดตบ่อยๆ รวมถึงมีการคอมเมนต์ระหว่างทางเยอะๆ การกลับมาไล่หาคอมเมนต์เพื่อดูว่าที่มาที่ไปของคำๆ นั้นมันคืออะไร มันก็ใช้เวลาค่อนข้างเยอะ หรือบางทีพอเราแก้ตามที่เขา comment เสร็จแล้ว เขาก็จะลบคอมเมนต์ออก หรือมันอาจจะถูกสั่งแก้โดยไม่ได้มีการคอมเมนต์ในไฟล์ แต่เป็นการบอกปากเปล่า หรือเป็นการคุยผ่าน chat ทำให้มันไม่ได้ถูก log ไว้ว่าตอนนั้นเกิดอะไรขึ้น อีกทั้งยังมีกรณีที่ทำๆไปไฟล์ใหญ่เกินจนต้องย้ายบางโฟลวออกไปทำให้คอมเมนต์ไม่ได้ตามไปด้วย
จึงคิดว่าการที่เรามีที่เก็บคอมเมนต์หรือมีที่เก็บประวัติการแก้ไขที่ดูง่ายๆ ชัดๆ ไว้แบบนี้ก็จะมีประโยชน์ไม่มากก็น้อยค่ะ
แต่อย่างไรก็ตาม การที่ไฟล์ Microcopy review backup นี้จะมีประโยชน์สูงสุดได้ สิ่งสำคัญที่สุดคือ UX Writer ทุกคนจะต้องมองเห็นความสำคัญของมันให้เท่ากันก่อน ถ้าทุกคนเห็นพ้องต้องกันแล้วว่ามันมีประโยชน์จริงๆ ทุกคนก็จะมีแรงช่วยกันเก็บรวบรวมทั้ง feedback ต่างๆ หลักฐานการ chat รวมถึงขยันจดโน๊ตสำคัญทิ้งไว้ว่าเกิดอะไรขึ้นถึงใช้คำนี้ แล้วสุดท้ายพอมีเหตุที่ต้องกลับเข้าไปดูที่มาที่ไป มันก็จะช่วยเราได้อย่างมีประสิทธิภาพจริงๆค่ะ
