Client ไม่ยอมทำ User Research ต้องทำยังไง?

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

“ไม่มีเวลาทำ research แล้ว”
“ลูกค้าเรารู้จัก user ดีอยู่แล้ว”
“ทำไปก่อน เดี๋ยว feedback ทีหลัง”
“งบไม่พอ”
“ถาม user ไปก็ไม่ได้คำตอบหรอก”

ในฐานะ UX/UI Designer คำถามสำคัญจึงไม่ใช่แค่ “ทำไม client ไม่ยอมทำ research?” แต่คือ “ถ้าเขายังไม่เห็นคุณค่าของ research เราจะพาเขาเข้าใกล้ผู้ใช้ให้ได้มากขึ้นยังไง ภายใต้ข้อจำกัดที่มี?”

User research ไม่ควรถูกขายในฐานะ “ขั้นตอนเพิ่ม” แต่ควรถูกอธิบายว่าเป็นวิธีลดความเสี่ยงในการตัดสินใจ เพราะการเข้าใจผู้ใช้ ความต้องการของเขา และรู้ว่าเรากำลังแก้ปัญหาอะไรอยู่ คือฐานของงานออกแบบทั้งหมด (GOV.UK Service Manual) ถ้าเราไม่รู้ว่าผู้ใช้จริงต้องการอะไร ใช้งานยังไง ติดตรงไหน หรือคิดต่างจากทีมตรงไหน เราก็อาจกำลังออกแบบจากสมมติฐานของคนในห้องประชุม มากกว่าความจริงของคนที่ใช้งานจริง

01อย่าเริ่มด้วยคำว่า “ต้องทำ Research” ให้เริ่มจาก “เรากำลังเสี่ยงเรื่องอะไร”

หลายครั้ง client ไม่ได้เกลียด user research แต่เขามองว่ามันคือของแพง ช้า หรือทำให้โปรเจกต์ซับซ้อนขึ้น

ถ้าเราเปิดด้วยประโยคว่า “โปรเจกต์นี้ต้องทำ user research ก่อนค่ะ” บางคนจะได้ยินเป็น “ต้องเพิ่มเวลา เพิ่มงบ และเลื่อนงานออกไป”

วิธีที่ดีกว่าคือเปลี่ยนจากการขาย research มาเป็นการคุยเรื่อง risk หรือความเสี่ยงของการตัดสินใจ เช่น

ประโยคแบบนี้ทำให้ research ไม่ใช่งานแยกที่ขอเวลาเพิ่ม แต่เป็นเครื่องมือช่วยตัดสินใจ และเป็นการ “ลดโอกาสแก้งานผิดทาง” มากกว่า การมองแบบนี้ก็ตรงกับหลัก human-centred design ที่บอกว่า ระบบจะ usable และ useful ได้ ต้องเริ่มจากเข้าใจผู้ใช้ ความต้องการ และบริบทการใช้งานจริงก่อน (ISO 9241-210)

02เข้าใจก่อนว่า ทำไม client ถึงไม่อยากทำ User Research

ก่อนจะ convince client เราต้องเข้าใจแรงต้านของเขาก่อน เพราะแต่ละเหตุผลใช้วิธีตอบไม่เหมือนกัน

• บางคนไม่อยากทำเพราะ งบจำกัด
• บางคนไม่อยากทำเพราะ timeline แน่น
• บางคน หาผู้ใช้ยาก ไม่รู้จะไปเอา user ที่ไหนมาทดสอบ
• บางคน กลัว scope บาน เพราะ research อาจเปิดปัญหาใหม่
• บางคน เชื่อว่าตัวเองรู้จักลูกค้าดีแล้ว
• บางคนเคยเจอ research report หนา ๆ ที่อ่านแล้วเอาไปทำอะไรต่อไม่ได้

ดังนั้นแทนที่จะบอกว่า “ไม่ทำไม่ได้” เราควรถามกลับแบบนุ่ม ๆ ให้ชัดว่าเขากังวลเรื่องอะไร

การถามแบบนี้ทำให้ client รู้สึกว่าเราไม่ได้ยัดขั้นตอนใส่โปรเจกต์ แต่กำลังช่วยหาวิธีที่เหมาะกับข้อจำกัดจริงของเขา

03เปลี่ยน Research จาก “งานใหญ่” เป็น “การเช็กความเสี่ยงเล็ก ๆ”

ปัญหาหนึ่งคือพอได้ยินคำว่า research หลายคนจะนึกถึงงานใหญ่ เช่น recruit user จำนวนมาก สัมภาษณ์ยาว ทำ report หนา ใช้เวลาหลายสัปดาห์

แต่ในงาน UX/UI ก่อนขึ้น development จริง เราไม่จำเป็นต้องเริ่มจาก research หนักเสมอไป เราเริ่มจาก research แบบเล็ก เร็ว และตอบคำถามเฉพาะจุดได้ เช่น

• ทดสอบ prototype กับผู้ใช้ 3–5 คน
• สัมภาษณ์ลูกค้าเดิม 3 คน
• ไล่ดู support ticket หรือ complaint เดิมที่มีอยู่แล้ว
• คุยกับทีมขายหรือทีมซัพพอร์ตที่เจอผู้ใช้ทุกวัน
• ทำ usability test แบบ remote สั้น ๆ 30 นาที

หัวใจคือไม่ต้องพยายาม “พิสูจน์ทุกอย่าง” ในครั้งเดียว แต่เลือกเช็ก assumption ที่เสี่ยงที่สุดก่อน วิธีคิดแบบนี้คือหัวใจของ usability testing — เราทดสอบเพื่อหาปัญหาใน design เห็นโอกาสปรับปรุง และเรียนรู้ว่าผู้ใช้จริงทำพฤติกรรมยังไง (Nielsen Norman Group)

และข่าวดีคือ research แบบเล็กก็ช่วยได้จริง งานวิจัยด้าน usability ชี้ว่าการทดสอบเชิงคุณภาพกับผู้ใช้ราว 5 คนต่อรอบ มักเจอ usability problem ส่วนใหญ่ได้แล้ว แต่ต้องเข้าใจให้ตรงว่า ตัวเลขนี้เหมาะกับ qualitative usability testing ที่เน้น “หาปัญหาเพื่อไปแก้” ไม่ใช่การพิสูจน์เชิงสถิติหรือวัดตัวเลขให้แม่นยำ (Nielsen Norman Group)

04เสนอเป็นตัวเลือก ไม่ใช่บังคับ

ถ้า client ยังลังเล วิธีที่ช่วยได้คือเสนอ research เป็นหลายระดับ เพื่อให้เขารู้สึกว่ามีทางเลือก ไม่ใช่มีแค่ “ทำเต็ม” กับ “ไม่ทำเลย”

พอ research กลายเป็น option ที่เลือกได้ client จะเริ่มเห็น trade-off ชัดขึ้นว่า ถ้าเลือกไม่ทำ เราประหยัดเวลา แต่รับความเสี่ยงมากขึ้น ถ้าเลือกทำแบบเบา เราใช้เวลานิดหน่อยเพื่อกันความผิดพลาดที่อาจแพงกว่าในอนาคต ที่สำคัญคือ research method ที่เลือกควรล้อตามคำถามที่อยากตอบ ช่วงของโปรเจกต์ และชนิดของ insight ที่ต้องการ ไม่ใช่ทำตามสูตรเดียวกันหมดทุกงาน (Nielsen Norman Group)

05ทำให้ client ได้ “เห็น” ผู้ใช้ ไม่ใช่แค่อ่านรายงาน

บางครั้ง report ดีแค่ไหนก็ไม่แรงเท่าการได้เห็น user จริง ๆ ใช้งานแล้วติด

ถ้าอยากให้ client buy-in มากขึ้น ลองชวนเขามานั่ง observe research session ด้วย ไม่ต้องเข้าทุกรอบ แค่ดู 1–2 session ก็พอ หรือถ้าเขาไม่มีเวลา ให้ตัด highlight สั้น ๆ เป็นคลิป quote หรือ observation ที่เชื่อมกับ decision โดยตรง เช่น

• “ผู้ใช้ 4 จาก 5 คน ไม่เข้าใจคำว่า ‘Submit Request’ และคิดว่าเป็นการส่งเรื่องร้องเรียน”
• “ผู้ใช้ 3 คนมองไม่เห็นปุ่ม Next เพราะมันอยู่ต่ำกว่าพื้นที่ที่เขากำลังสนใจ”
• “ทุกคนเข้าใจ feature นี้ต่างจากที่ทีมตั้งใจไว้”

จากนั้นอย่าส่งแค่ finding แต่แปลงให้เป็น design decision ไปเลย เพราะ research จะมีประโยชน์จริงก็ต่อเมื่อทีมเอาสิ่งที่เรียนรู้ไปปรับปรุงงานต่อได้ และการแชร์ finding ให้ทุกคนเห็นตรงกัน ช่วยให้ทีมเห็น gap และตั้งคำถามร่วมกันได้ (GOV.UK Service Manual)

วิธีนี้ทำให้ research ไม่ใช่ “เอกสาร” แต่กลายเป็นหลักฐานที่ช่วยให้ทีมตัดสินใจง่ายขึ้น

06ผูก Research กับ Business Metric ที่ client สนใจ

ถ้า client เป็นฝั่งธุรกิจ เขาอาจไม่ได้ซื้อคำว่า user empathy เท่า conversion, cost, adoption หรือ support workload เพราะสุดท้าย design ที่ดีควรผูกกับ business outcome และวัดผลได้ ไม่ใช่เป็นแค่งานหน้าตา (McKinsey)

ดังนั้นควรแปล research ให้เชื่อมกับ metric ที่เขาแคร์ตามประเภทงาน

• E-commerce: research ช่วยดูว่าจุดไหนทำให้คนไม่กดซื้อ ไม่จ่ายเงิน หรือไม่กลับมาซ้ำ — ลด drop-off ก่อน checkout
• ระบบภายในองค์กร: ช่วยดูว่าพนักงานทำงานช้าตรงไหน กรอกผิดตรงไหน หรือต้องถามซัพพอร์ตเรื่องอะไรซ้ำ ๆ
• SaaS: ช่วยดู onboarding, activation, retention และ feature adoption
• เว็บไซต์บริษัท: ช่วยดูว่าคนเข้าใจ value proposition ไหม หาข้อมูลเจอไหม และติดต่อได้ง่ายไหม

พูดง่าย ๆ คืออย่าพูดแค่ “เราควรเข้าใจ user” แต่พูดว่า “ถ้าเราเข้าใจ user เราจะลดความเสี่ยงเรื่อง conversion, adoption หรือ rework ได้ยังไง” มุมนี้เชื่อมกับ HEART framework ได้ตรง ๆ เพราะ UX ผูกกับ goals, signals และ metrics อย่าง task success, adoption และ retention ได้จริง (Google Research, HEART Framework)

07ถ้า client ยังไม่ยอมจริง ๆ ให้ทำ Assumption-based Design แบบโปร่งใส

มีบางเคสที่ต่อให้เราพยายามแค่ไหน client ก็ยังไม่ทำ research อยู่ดี

ในสถานการณ์นี้ สิ่งที่ควรทำไม่ใช่การยอมเงียบ ๆ แล้วออกแบบเหมือนเรามั่นใจ 100% แต่ควรทำให้ assumption ชัดเจน แยกให้เห็นว่าอะไรคือสิ่งที่รู้จาก brief, อะไรที่ยังไม่รู้, อะไรที่กำลัง assume, ความเสี่ยงถ้า assumption ผิด และจุดที่ควร validate ภายหลัง

วิธีนี้ช่วยปกป้องทั้งทีมออกแบบและ client เพราะทุกคนเห็นตรงกันว่า design นี้เกิดจากข้อมูลระดับไหน และยังมีจุดไหนที่ควรเช็กต่อ ซึ่งก็คือการพยายามรักษาหลัก human-centred design ไว้ให้ได้มากที่สุดเท่าที่เงื่อนไขจะอำนวย คือยังพยายามเข้าใจผู้ใช้ requirement และ context of use แม้จะยังทำ research เต็มไม่ได้ (ISO 9241-210)

08ประโยคคุยกับ client แบบไม่กดดัน

แทนที่จะพูดว่า “ถ้าไม่ทำ user research งานจะไม่ดีนะคะ” ลองเปลี่ยนเป็นประโยคที่เปิดทางเลือกและลดความกดดัน กดปุ่มคัดลอกที่มุมการ์ดเพื่อเอาไปใช้ได้เลย

ประโยคเหล่านี้ไม่ได้ทำให้ client รู้สึกผิด แต่ช่วยให้เขาเห็นว่า research คือเครื่องมือประกอบการตัดสินใจ ไม่ใช่ขั้นตอนที่ designer เรียกร้องเพิ่มเอง

สรุป: พาโปรเจกต์เข้าใกล้ผู้ใช้ทีละนิด

เวลา client ไม่ยอมทำ user research เราไม่จำเป็นต้องเถียงให้ชนะว่า research สำคัญแค่ไหน สิ่งที่ทำได้คือ

• เปลี่ยน research ให้เป็นภาษาความเสี่ยง — เริ่มจากคำถามที่เล็กแต่สำคัญที่สุดของ flow ก่อน
• เสนอ research เป็นหลายระดับ — ให้ client เลือกระดับความมั่นใจและความเสี่ยงเองตามเวลาและงบ
• ชวน client เห็นผู้ใช้จริง — แปลง finding เป็น decision ไม่ใช่ทิ้งไว้เป็น insight ลอย ๆ
• ผูก finding กับ business metric — conversion, adoption, retention หรือ support cost ที่ client แคร์
• ถ้ายังทำไม่ได้จริง ๆ — บันทึก assumption และ risk อย่างโปร่งใส ระบุจุดที่ควรกลับมา validate

เพราะสุดท้าย UX ไม่ใช่การทำ research ให้ครบพิธี แต่คือการทำให้ทีมตัดสินใจบนความจริงของผู้ใช้มากขึ้นทีละนิด

บางโปรเจกต์อาจไม่ได้เริ่มจาก research ที่สมบูรณ์แบบ แต่ควรจบด้วยทีมที่เข้าใจมากขึ้นว่า สิ่งที่เรากำลังออกแบบนั้นสร้างให้ใคร และเรายังไม่รู้อะไรเกี่ยวกับเขาอีกบ้าง

ปิดท้ายจากต้าน

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

บางโปรเจกต์อาจมีพื้นที่ให้ทำ research เต็มรูปแบบ บางโปรเจกต์อาจทำได้แค่ light validation สั้น ๆ หรือบางครั้งอาจเริ่มจากการคุยกับทีมที่อยู่ใกล้ผู้ใช้มากที่สุดก่อน แต่ไม่ว่าจะเริ่มจากตรงไหน สิ่งที่ไม่อยากให้ลืมคือการถามตัวเองว่า “ตอนนี้เรารู้เรื่องผู้ใช้พอสำหรับการตัดสินใจนี้แล้วหรือยัง”

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

บทความนี้เลยไม่ได้อยากบอกว่า client ที่ยังไม่ทำ user research คือผิด แต่อยากชวนมองว่า ในฐานะคนทำงานออกแบบ เราจะช่วยค่อย ๆ พาโปรเจกต์เข้าใกล้ผู้ใช้จริงมากขึ้นได้ยังไง โดยไม่ลืมความจริงของงาน ความสัมพันธ์กับทีม และบริบทของลูกค้าที่เรากำลังทำงานด้วย

แหล่งอ้างอิง

• GOV.UK Service Manual — User research for government services: an introduction
• GOV.UK Service Manual — Sharing user research findings
• ISO 9241-210 — Human-centred design for interactive systems
• Nielsen Norman Group — Usability Testing 101
• Nielsen Norman Group — Why You Only Need to Test with 5 Users
• Nielsen Norman Group — When to Use Which User-Experience Research Methods
• Google Research — Measuring the User Experience on a Large Scale / HEART Framework
• McKinsey — The Business Value of Design