“ออกแบบ UX/UI หน้านี้ราคาเท่าไรครับ?”
เป็นคำถามที่ผมเจออยู่เรื่อยๆ และจริงๆ แล้วก็เป็นคำถามที่สมเหตุสมผลครับ เพราะเวลาจะจ้างงาน เราก็อยากรู้ก่อนว่าต้องเตรียม Budget ประมาณไหน
แต่สิ่งที่ตอบยากคือ งาน UX/UI ไม่ได้มีหน่วยวัดที่ตรงไปตรงมาเหมือนซื้อสินค้า
บางโปรเจกต์ผมสามารถดู Requirement แล้วบอกได้เลยว่า คิดเป็นจำนวนหน้าได้
แต่บางโปรเจกต์ ถ้าพยายามนับทุกอย่างเป็นหน้าอย่างเดียว กลับทำให้ประเมินงานผิดไปจากความเป็นจริงมาก
เพราะหน้าจอหนึ่งหน้า อาจใช้เวลาออกแบบไม่ถึงชั่วโมง
ขณะที่อีกหนึ่งหน้าอาจต้องคิด Flow, State, Permission, Validation และเงื่อนไขอีกสิบอย่างก่อนจะออกแบบได้
ดังนั้นก่อนถามว่า ราคา UX UI เท่าไร ผมอยากชวนมาดูกันก่อนว่า Designer กำลังประเมินอะไรอยู่บ้าง และทำไมบางครั้งผมเองก็คิดราคาเป็นหน้า แต่บางครั้งเลือกเหมาทั้ง Project
ก่อนอื่น “1 หน้า” ของ ราคา UX/UI คือเท่าไรกันแน่?
สมมุติว่าลูกค้าบอกว่า
“มีประมาณ 10 หน้าครับ”
ฟังครั้งแรกเหมือน Scope ค่อนข้างชัดแล้ว
แต่พอเปิด Requirement จริง 10 หน้าของแต่ละ Project อาจไม่เหมือนกันเลย
เว็บไซต์บริษัท 10 หน้า อาจประกอบด้วย Home, About, Services, Portfolio, Blog และ Contact ซึ่งหลายหน้ามีโครงสร้างค่อนข้างตรงไปตรงมา
แต่ Web Application 10 หน้า อาจมี Dashboard, User Management, Report, Permission, Search, Filter, Table และ Form ที่มีเงื่อนไขหลายแบบ
จำนวนเท่ากันคือ 10 หน้า
แต่เวลาที่ใช้คิดและออกแบบอาจต่างกันมาก
นี่เป็นเหตุผลแรกที่ผมไม่ค่อยอยากใช้ จำนวนหน้าจอเป็นตัวบอกขนาดของ Project เพียงอย่างเดียว
แล้วเมื่อไรผมคิดราคาเป็นหน้า?
สำหรับงานที่ Scope ค่อนข้างชัด และแต่ละหน้าสามารถแยกออกจากกันได้พอสมควร การคิดเป็นหน้ากลับเป็นวิธีที่ง่ายและตรงไปตรงมามากครับ
ตัวอย่างเช่น Corporate Website หรือ Marketing Website ที่มี Sitemap ชัดเจน
Home
About Us
Service
Portfolio
Contact
เราพอมองออกว่าแต่ละหน้ามี Content อะไร Complexity ระดับไหน และต้องออกแบบอะไรบ้าง
ในกรณีแบบนี้ การคิดเป็นหน้ามีข้อดีตรงที่ทั้ง Designer และลูกค้าเข้าใจ Scope ได้ง่าย
ถ้าวันหนึ่งลูกค้าบอกว่า
“ขอเพิ่มอีก 2 หน้านะครับ”
เราก็สามารถคุยเรื่อง Scope ที่เพิ่มขึ้นได้ตรงไปตรงมา
และลูกค้าเองก็สามารถควบคุม Budget ได้ง่ายเช่นกัน
ดังนั้น คิดเป็นหน้าไม่ได้หมายความว่าเป็นวิธีที่ไม่ Professional ถ้าธรรมชาติของงานเหมาะกับการประเมินแบบนั้น
แต่คำว่า “หนึ่งหน้า” ต้องตกลงกันให้ชัด
ปัญหาเริ่มเกิดตรงนี้ครับ
สมมุติเราตกลงกันว่าออกแบบหน้า Dashboard 1 หน้า
Designer ออกแบบ Default State ให้เสร็จ
จากนั้นเริ่มมีคำถามตามมา
ถ้าไม่มีข้อมูลล่ะ?
ถ้า Loading อยู่ล่ะ?
ถ้าเกิด Error ล่ะ?
ถ้า User คนนี้ไม่มี Permission ล่ะ?
กด Filter แล้วเป็นอย่างไร?
เปิด Modal นับเป็นอีกหน้าหรือเปล่า?
แล้ว Mobile ของหน้าเดียวกันนับอีกหน้าหรือไม่?
ทันใดนั้นคำว่า “1 หน้า” เริ่มไม่ใช่หนึ่งหน้าแล้ว
ในงาน UX/UI โดยเฉพาะ Application ผมจึงมองว่า Screen กับ State เป็นคนละเรื่องที่ควรคุยกันตั้งแต่ต้น
เพราะถ้าตกลงกันไม่ชัด ลูกค้าอาจคิดว่าทุกอย่างอยู่ในราคาหน้าเดียว ขณะที่ Designer มองว่ากำลังมีงานเพิ่มขึ้นเรื่อยๆ
สุดท้ายไม่ได้มีใครตั้งใจเอาเปรียบใครครับ
แค่เรานิยามคำว่า “หน้า” ไม่เหมือนกันตั้งแต่แรก
ทำไม Web Application บางงานผมจึงเลือกประเมินเป็น Project
ลองนึกถึงระบบจองบริการครับ
ตอนแรกเราอาจเขียน Screen List ได้ไม่เยอะ
เลือกบริการ
เลือกวันและเวลา
กรอกข้อมูล
ชำระเงิน
สำเร็จ
ดูเหมือน 5 หน้าจอ
แต่พอเริ่มทำ User Flow จริง จะพบคำถามเพิ่มขึ้นทันที
ถ้าวันนั้นเต็มล่ะ?
ผู้ใช้ย้อนกลับไปเปลี่ยนบริการได้ไหม?
เวลาที่เลือกไว้ถูกคนอื่นจองระหว่างชำระเงินจะเกิดอะไรขึ้น?
Payment Failed ไปหน้าไหน?
ถ้า User Login อยู่แล้ว ต้องกรอกข้อมูลใหม่หรือไม่?
ตรงนี้งานของ UX/UI Designer ไม่ได้เกิดขึ้นเฉพาะตอนวาง Rectangle ลงใน Figma แล้วครับ
เวลาส่วนหนึ่งถูกใช้ไปกับการ ทำความเข้าใจระบบและตัดสินใจว่าแต่ละสถานการณ์ควรทำงานอย่างไร
ถ้า Project มี Workflow ลักษณะนี้เยอะ การนั่งนับว่ามีกี่หน้าจออาจไม่ใช่วิธีประเมินที่เหมาะที่สุด
ผมจึงมักมองภาพรวมของ Project มากกว่า
ราคา UX UI จึงไม่ได้เกิดจากเวลาที่ใช้วาดหน้าจออย่างเดียว
บางครั้งลูกค้าเห็นหน้าจอหนึ่งแล้วอาจคิดว่า
“หน้านี้ดูเรียบๆ ไม่น่าทำนาน”
ซึ่งก็อาจจริงครับในขั้นตอน UI
แต่สิ่งที่มองไม่เห็นคือ ก่อนจะได้หน้าจอนั้น Designer อาจผ่านการคิดมาแล้วว่า
ข้อมูลอะไรสำคัญที่สุด
User ต้องทำอะไรเป็นอันดับแรก
อะไรควรซ่อน
อะไรควรแสดง
CTA ควรอยู่ตรงไหน
Flow ก่อนหน้าและหลังจากนี้คืออะไร
งาน UX ที่ดีบางครั้งจึงมีความย้อนแย้งอยู่เล็กน้อย
ยิ่งคิดมาเยอะ หน้าจอสุดท้ายอาจยิ่งดูง่าย
ถ้าเราวัดราคาจากจำนวน Element ที่เห็นบนหน้าจอเพียงอย่างเดียว เราอาจกำลังวัด Output แต่ไม่ได้วัดกระบวนการที่ทำให้ Output นั้นเกิดขึ้น
แล้ว Responsive คิดเป็นอีกหน้าหรือเปล่า?
นี่ก็เป็นอีกคำถามที่เจอบ่อยครับ
คำตอบคือ ขึ้นอยู่กับขอบเขตที่ตกลงกัน
ถ้า Desktop Design ถูกนำมาย่อขนาดอย่างตรงไปตรงมา งานอาจไม่ได้เพิ่มเป็นสองเท่า
แต่ Responsive Design ที่ดีไม่ได้หมายถึงแค่เอาของจาก Desktop มาเรียงลง Mobile
Navigation อาจเปลี่ยน
Table อาจต้องเปลี่ยนรูปแบบ
บาง Content ต้องจัด Priority ใหม่
Interaction ที่ใช้ Hover บน Desktop อาจใช้ไม่ได้บน Touch Screen
บาง Feature อาจต้องออกแบบใหม่เพื่อให้ใช้งานด้วยนิ้วโป้งได้สะดวก
ดังนั้นเวลาขอใบเสนอราคา ผมแนะนำให้ระบุให้ชัดเลยว่า Project ต้องการ
Desktop อย่างเดียว
Desktop + Mobile
หรือมี Tablet รวมอยู่ด้วย
จะช่วยลดคำว่า “ผมนึกว่ารวมแล้ว” ได้เยอะมากครับ
งานเล็กแต่ Complexity สูง อาจแพงกว่างานหลายหน้า
สมมุติมีสอง Project
Project A: เว็บไซต์บริษัท 12 หน้า
Project B: Dashboard ระบบจัดการ 5 หน้าจอ
ถ้ามองเฉพาะจำนวนหน้า Project A ดูเหมือนงานใหญ่กว่า
แต่ Dashboard 5 หน้าอาจมี Data Table, Filter, Chart, Permission, Bulk Action, Empty State, Error State และ Responsive Behavior จำนวนมาก
สุดท้าย Project B อาจใช้เวลาคิดมากกว่าเว็บไซต์ 12 หน้าก็ได้
นี่เป็นเหตุผลว่าทำไมการถาม ราคา UX UI ต่อหน้า อย่างเดียว บางครั้งยังไม่เพียงพอที่จะเปรียบเทียบใบเสนอราคาจาก Designer หลายคน
สิ่งที่ควรดูควบคู่กันคือ Complexity ของแต่ละหน้า
แล้วทำไมไม่คิดเป็นชั่วโมงไปเลย?
จริงๆ ก็ทำได้ครับ และบาง Project เหมาะมากด้วย
เช่น งาน Consulting งานปรับปรุง Design เดิม งานที่ Requirement ยังเปลี่ยนบ่อย หรือ Project ที่ทำงานร่วมกับ Product Team แบบต่อเนื่อง
แต่สำหรับลูกค้าหลายคน การซื้อ “40 ชั่วโมงของ Designer” ไม่ได้ช่วยให้รู้ว่า Project จะจบที่ตรงไหน
ลูกค้าอยากรู้มากกว่าว่า
Budget เท่านี้ เราจะได้อะไรกลับมา?
ผมจึงมองว่าการคิดเป็นชั่วโมงเหมาะกับงานบางประเภท แต่ไม่จำเป็นต้องเป็นคำตอบของทุก Project เช่นเดียวกับการคิดเป็นหน้าครับ
ก่อนประเมินราคา ผมอยากเห็นอะไรมากกว่าจำนวนหน้า
ถ้าลูกค้าส่งมาว่า
“มีประมาณ 20 หน้า ขอราคาหน่อยครับ”
ผมพอให้ช่วงราคาเบื้องต้นได้ แต่ถ้าจะประเมินให้ใกล้เคียงงานจริง ผมอยากรู้เพิ่มเติมอีกเล็กน้อย
Project นี้คืออะไร?
ใครเป็นคนใช้?
มี User กี่ประเภท?
มี Sitemap หรือ Screen List หรือยัง?
มีระบบเดิมให้ดูไหม?
ต้องออกแบบ Desktop / Mobile หรือทั้งคู่?
มี Design System อยู่แล้วหรือเริ่มใหม่?
ต้องการ Prototype ระดับไหน?
Requirement ชัดแค่ไหน?
คำถามเหล่านี้ไม่ได้มีไว้ทำให้ขั้นตอนขอราคายุ่งยากขึ้น แต่ช่วยลดโอกาสที่ ราคาเริ่มต้นดูถูกมาก แล้วค่อยๆ บานขึ้นระหว่างทำงาน
ผมชอบให้ Scope ชัดก่อนเริ่มมากกว่ามานั่งถกกันทีหลังว่าอะไรอยู่หรือไม่อยู่ในใบเสนอราคาครับ
ถ้าเป็นเจ้าของธุรกิจ ควรเปรียบเทียบใบเสนอราคา UX/UI อย่างไร?
สมมุติได้รับใบเสนอราคามา 3 เจ้า
20,000 บาท
40,000 บาท
70,000 บาท
อย่าเพิ่งสรุปว่าเจ้าแรกถูก และเจ้าสุดท้ายแพงครับ
ลองดูต่อว่าแต่ละเจ้ารวมอะไรไว้บ้าง
มี UX Research หรือไม่?
ทำ User Flow หรือเปล่า?
Wireframe รวมไหม?
UI Design กี่ Device?
มี Prototype หรือไม่?
มี Design System / Component หรือไม่?
Revision กี่รอบ?
ส่ง Source File อะไรบ้าง?
มี Developer Handoff หรือ Support หลังส่งงานหรือไม่?
บางครั้งตัวเลขต่างกันเพราะ Scope ต่างกันตั้งแต่แรก
การเปรียบเทียบราคาจึงควรพยายามทำให้สิ่งที่ได้รับใกล้เคียงกันก่อน แล้วค่อยดูว่าข้อเสนอไหนเหมาะกับ Project มากที่สุด
ราคาถูกหรือแพง ไม่ได้บอกคุณภาพทั้งหมด
ผมคิดเหมือนตอนพูดเรื่องราคาออกแบบ Logo ครับ
แพงกว่าไม่ได้หมายความว่าดีกว่าเสมอ
ถูกกว่าก็ไม่ได้หมายความว่างานไม่ดี
Freelance Designer ที่ทำงานคนเดียวอาจมี Cost Structure ต่างจาก Agency ที่มี UX Researcher, UI Designer, Project Manager และ Developer หลายคน
ในทางกลับกัน Project บางประเภทก็ไม่ได้ต้องการทีมขนาดนั้นเลย
Landing Page สำหรับทดลองตลาดอาจต้องการเพียง Designer ที่ทำงานเร็ว เข้าใจโจทย์ และจบงานได้ตรง Scope
แต่ระบบ Enterprise ที่มีหลาย Role และ Workflow ซับซ้อน การเลือกจากราคาต่ำที่สุดเพียงอย่างเดียวอาจสร้าง Cost ที่ใหญ่กว่าตอนต้องกลับมาแก้ระบบภายหลัง
คำถามจึงไม่ควรมีแค่
“ใครถูกที่สุด?”
แต่ควรมีอีกคำถามว่า
“ใครเหมาะกับ Project นี้ที่สุด?”
สรุปแล้วควรคิด UX/UI เป็นหน้า หรือเหมา Project?
สำหรับผม ใช้ได้ทั้งสองแบบครับ
ถ้างานเป็น Website ที่ Scope ชัด แต่ละหน้าแยกกันได้ และ Complexity ไม่ต่างกันมาก การคิดเป็นหน้าช่วยให้เข้าใจง่ายและยืดหยุ่นเวลามีหน้าเพิ่ม
แต่ถ้าเป็น Web Application, Mobile Application หรือระบบที่มี Workflow, State และ Business Logic จำนวนมาก การประเมินเป็น Project มักสะท้อนงานจริงได้ดีกว่า
และยังมีงานอีกประเภทที่เหมาะกับ Hourly / Daily Rate หรือ Retainer มากกว่าอีกด้วย
ดังนั้นไม่มีสูตรว่า
UX/UI ต้องคิดราคาวิธีนี้เท่านั้นถึงจะ Professional
วิธีที่ดีที่สุดคือวิธีที่ทำให้ทั้ง Designer และลูกค้า เข้าใจ Scope เดียวกันก่อนเริ่มงาน
เพราะสุดท้ายแล้ว ปัญหาที่น่ากลัวกว่าราคาแพงหรือราคาถูก คือ
คนจ้างคิดว่าซื้ออย่างหนึ่ง แต่คนออกแบบคิดว่ากำลังขายอีกอย่างหนึ่ง
กำลังประเมินงบสำหรับงาน UX/UI อยู่หรือเปล่า?
หากกำลังวางแผนทำ Website, Web Application หรือ Mobile Application แต่ยังไม่แน่ใจว่าจะประเมิน Scope อย่างไร สามารถเริ่มจาก Requirement ที่มีอยู่ก่อนได้ครับ
ไม่จำเป็นต้องเตรียม Wireframe หรือ Screen List สมบูรณ์ตั้งแต่แรก
Dot Design สามารถช่วยดู Requirement, User Flow และขอบเขตของงานก่อนประเมินแนวทางการออกแบบที่เหมาะสมกับ Project ได้
บางงานเหมาะกับการคิดเป็นหน้า
บางงานเหมาะกับการประเมินเป็น Project
สิ่งสำคัญกว่าคือ ก่อนเริ่มงาน เราควรรู้ตรงกันว่าอะไรคือสิ่งที่จะถูกออกแบบ และอะไรคือผลลัพธ์ที่ Project ต้องการ