User · ผู้ใช้
"What will the user actually do with this dashboard?" "ผู้ใช้จะเอา Dashboard ไปใช้ทำอะไร?"
Always begin by understanding the user. The core design question is not "what data do we have?" but "what will they do with this dashboard?"
Common purposes: support a decision, monitor performance, alert on anomalies. The purpose drives every later choice — measures, charts, layout.
Old-school requirements gathering asks users "what data do you want to see?" and "which chart do you want?" — and then the finished dashboard delivers exactly that, only for the user to say "this isn't what I wanted!" Why? Because the team built to the feature list, not to the underlying job. Once you understand how they'll use it, you design something they recognize as theirs.
ต้องเข้าใจผู้ใช้ก่อนเป็นอันดับแรก การเข้าใจผู้ใช้นั้น ให้ยึดตามหลักการของ Design Thinking เลยครับ ว่า จงหา Insight ของผู้ใช้ หรือ ตอบให้ได้ว่า ทำไมเขาถึงใช้
คำถามหลักของการออกแบบ Dashboard ก็คือ ผู้ใช้จะเอา Dashboard ไปใช้ทำอะไร เช่น ช่วยตัดสินใจ ติดตามผลการดำเนินงาน ใช้เตือนเมื่อมีสิ่งผิดปกติ
ในอดีต เวลาส่งคนไปเก็บ Requirement กับผู้ใช้ ก็จะชอบไปถามว่า อยากดูข้อมูลอะไรบ้าง อยากดูเป็นกราฟไหน ซึ่งพอไปทำกราฟมาเสร็จเรียบร้อย ผู้ใช้มักจะบอกว่า ไม่เห็นตรงกับที่อยากได้เลย! (แม้ว่าจะทำมาตรงกับที่เค้าบอกเป๊ะๆ) อันนี้เกิดจากการที่เราไม่ได้เข้าใจจริงๆ ว่าเค้าอยากจะเอาไปใช้ทำอะไร ถ้าเราเข้าใจถึงรูปแบบว่าเค้าจะเอา Dashboard ไปใช้อย่างไร เราก็จะออกแบบได้ตรงใจมากขึ้นครับ
Content · เนื้อหา
"What measures and dimensions does the decision need?" "ต้องใช้ตัวเลขอะไร มองมุมไหน?"
Once you know how they'll use it, decide what content matters. Two parts:
Measures — the numbers we care about (revenue, customer count, churn rate). Dimensions — the angles we slice by (time, product, region, segment).
Choosing the right measure is leverage. A poorly-chosen measure sends the whole dashboard the wrong direction. Example: "how do you measure customer satisfaction?" Most students answer "Customer Satisfaction Score" or "repeat purchase rate." But repeat purchase for the BTS Skytrain doesn't measure satisfaction — it measures lack of alternatives. Measure first, then design.
เมื่อเข้าใจแล้วว่า ผู้ใช้อยากเอา Dashboard ไปใช้อย่างไร ก็ต้องมาคิดต่อว่า เนื้อหา หรือ สิ่งที่เค้าจะต้องเอาไปใช้นั้น มีอะไรบ้าง ซึ่งก็ขอแบ่งเป็น
Measures หรือ ตัวเลขที่เราสนใจ เช่น ยอดขาย จำนวนลูกค้า · Dimensions หรือ มุมมองที่เราอยากวิเคราะห์ข้อมูล เช่น ตามช่วงเวลา ตามกลุ่มสินค้า ตามพื้นที่
การเลือก measures นั้น ถ้าเราสามารถช่วยคิด ช่วยออกแบบให้การวัดผลนั้น มีความน่าสนใจ หรือ ตรงประเด็นมากขึ้น ก็จะทำให้ Dashboard นั้น มีความน่าสนใจมากขึ้นไปอีก คือ ถ้าวัดผลผิด นี่ก็ไปผิดทิศทางได้ไกลเหมือนกัน
เวลาผมถามนักศึกษาว่า จะรู้ได้อย่างไรว่า ลูกค้าพึงพอใจเรา ชอบเรา ส่วนมากก็จะตอบว่า ถ้าไม่วัดจาก Customer Satisfaction (ซึ่งต้องทำ Survey) ก็ไปวัดจากอัตราการซื้อซ้ำ เลยยกตัวอย่างว่า อัตราการซื้อซ้ำของรถไฟฟ้า BTS บ่งบอกถึงความพึงพอใจไหม… เด็กๆ ก็ฮาครืนนน
Presentation · การนำเสนอ
"Which chart fits this question?" "จะใช้กราฟแบบไหน?"
Once you've settled on measures and dimensions, pick the right chart. Most people don't pick well.
The most-voted "worst chart" is the pie chart — beloved because line and bar charts feel boring. Pies aren't terrible, but with too many slices they become unreadable, and with few slices they waste enormous space showing little information.
Encoding-accuracy hierarchy (most to least accurate for comparison): position / length > angle > area > color intensity > volume (3D). That's why a sorted horizontal bar chart almost always beats a pie.
หลังจากที่รู้แล้วว่า จะใช้ measures และ dimensions แบบไหน ก็ถึงเวลาที่มาเลือกกราฟให้ถูกต้องครับ พบว่า คนส่วนมากก็ยังเลือกกราฟกันได้ไม่ดีนัก
กราฟที่ถูกโหวตให้เป็นกราฟยอดแย่ ก็คือ Pie Graph ซึ่งเป็นกราฟที่หลายคนชื่นชอบ อารมณ์ว่า ใช้กราฟเส้น กราฟแท่งเบื่อแล้ว ขอใช้ Pie Graph ซักหน่อย
Pie Graph นี้ ก็ไม่ได้แย่อะไรมากมายนะครับ เพียงแต่ว่า พอ Slice มันเยอะ ก็จะดูไม่รู้เรื่อง แถมพอ Slice น้อยๆ ก็เป็นกราฟที่ใช้พื้นที่เยอะ แต่แสดงข้อมูลได้น้อยอีก
Navigation · การจัดวาง
"How do the charts come together as one screen?" "จัดวางกราฟอย่างไรให้ไหลลื่น?"
Finally, when you have multiple charts, layout matters. The simple rule: charts about the same topic belong next to each other.
Don't make the reader jump from one chart, across the page to another, then back. Eye-jumping wastes time and breaks the connection between data points. The eye should flow naturally — top-left first, then right, then down.
Place the most important data top-left. Group related metrics. Put the action queue or summary table at the bottom — recommendations make sense only after the diagnosis above them.
สุดท้าย เมื่อมีหลายกราฟแล้ว จะเอามาประกอบกันเป็น Dashboard การจัดวางกราฟก็เป็นส่วนสำคัญ หลักง่ายๆ คือ กราฟที่เป็นเรื่องเดียวกัน ก็ควรวางไว้ใกล้ๆ กัน อย่าให้คนต้องอ่านกราฟนึงแล้วกระโดดข้ามไปอีกกราฟ แบบกระโดดไปมา
มันจะทำให้เสียเวลาในการไล่อ่าน ไม่เจอความเชื่อมโยง
Ready to see UCPN in action? พร้อมดู UCPN ในการใช้งานจริงหรือยัง?
Browse the gallery to see real dashboard mockups built with this framework. ลองดู Dashboard ตัวอย่างในแกลเลอรี ที่ออกแบบด้วยกรอบคิดนี้
Browse the gallery →ดูแกลเลอรี →