DESIGN.md คืออะไร

DESIGN.md ไม่ใช่มาตรฐานบังคับของ Web Development แต่เป็นรูปแบบเอกสารที่เราสามารถสร้างขึ้นเพื่อเก็บ Design Context ที่ควรใช้ร่วมกันทั้งโปรเจกต์ ในไฟล์ข้อความที่คนและ AI Agent อ่านได้ง่าย

มันเหมาะกับ Workflow ที่มี AI ช่วยทั้ง Design และ Code เพราะแทนที่จะอธิบาย Typography, Color หรือ Spacing ใหม่ทุก Prompt เรามีจุดอ้างอิงกลางหนึ่งจุด

ควรสร้าง DESIGN.md ตอนไหน

ไม่จำเป็นต้องเขียนไฟล์ละเอียดตั้งแต่ยังไม่เห็น UI เลย เพราะตอนนั้นเรายังไม่รู้ว่าระบบต้องใช้ Component อะไรจริงบ้าง

ผมชอบสร้าง Design Foundation ขั้นต้นก่อน แล้วหลังได้ Anchor Screen จาก Vibe Design ค่อยเติมกฎที่ “เกิดขึ้นจริง” จากงาน เช่น Sidebar width, Content max width, Card radius หรือ Button hierarchy

วิธีนี้ทำให้ไฟล์สะท้อน Design ไม่ใช่บังคับ Design จากสมมติฐานก่อนเห็นหน้าจอ

DESIGN.md ควรมีอะไร

โครงสร้างพื้นฐานอาจมี

# Design Principles
# Typography
# Colors
# Spacing
# Radius and Borders
# Layout
# Shared Components
# Tables and Forms
# Responsive Notes
# Do / Don't

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

ตัวอย่างกฎที่มีประโยชน์

## Application Shell
- ใช้ Left Sidebar และ Top Header ตาม Anchor Screen
- ห้าม redesign Shell ในหน้ารอง

## Buttons
- Primary ใช้สำหรับ Action หลักของหน้าเท่านั้น
- Secondary ใช้ Border style เดิม
- ห้ามสร้าง Radius ใหม่ถ้ามี Token เดิมอยู่แล้ว

## Tables
- ใช้ Header, Row height และ Status badge ชุดเดียวกันทุกหน้า

สังเกตว่ากฎเหล่านี้บอกพฤติกรรมและความสม่ำเสมอ ไม่ได้พยายามอธิบายพิกัดทุก Pixel

DESIGN.md ไม่ได้แทน Design จริง

นี่เป็นจุดที่สำคัญมาก ถ้าเราเขียนว่า “ใช้ Sidebar 240px, สี Blue, Card radius 12px” Agent ก็ยังไม่รู้ว่า Dashboard จัด Card อย่างไร Table อยู่ส่วนไหน หรือแต่ละ Section มีลำดับอย่างไร

ดังนั้นถ้าต้องการให้ Code ตรง Google Stitch ให้ Agent อ่าน Design Reference จริงด้วย โดยเฉพาะ Layout ที่ซับซ้อน อ่านต่อได้ที่ Stitch MCP คืออะไร

แล้วไฟล์นี้ช่วยอะไรจริง

DESIGN.md มีประโยชน์มากใน 4 เรื่อง

  • ทำให้ศัพท์ Design ในทีมตรงกัน
  • ลดการสร้าง Style ใหม่โดยไม่จำเป็น
  • ใช้เป็น Checklist ตอน Review หน้าใหม่
  • ช่วย Agent รู้กฎที่ต้องรักษาแม้ Design Reference ไม่ได้แสดงทุก State

ตัวอย่างเช่น Stitch อาจแสดง Primary button หนึ่งจุด แต่ DESIGN.md บอกได้ว่า Primary button ใช้ได้หนึ่ง Action หลักต่อ Section หรือบอกว่า Status badge ต้องใช้คำและสีจากชุดเดิม

Component Rule ควรเขียนเมื่อไร

มือใหม่มักสงสัยว่า “ยังไม่รู้ว่ามี Component อะไร จะเขียนกฎยังไง” คำตอบคือ ไม่ต้องรีบเดา

เริ่มจากกฎระดับ Foundation และ Application shell ก่อน เมื่อออกแบบจริงแล้วเจอ Pattern ที่ซ้ำ เช่น Button, Input, Card, Table, Badge จึงบันทึกกฎของ Component นั้นเพิ่ม

DESIGN.md ควรโตไปพร้อม Product ไม่ใช่เอกสารยาวมากตั้งแต่วันแรก

DESIGN.md กับ AGENTS.md ต่างกันอย่างไร

DESIGN.md บอกว่า UI ควรเป็นอย่างไร ส่วน AGENTS.md บอกว่า Coding Agent ควรทำงานใน Repository นี้อย่างไร เช่นใช้คำสั่งไหน ห้ามติดตั้ง Library โดยไม่จำเป็น และก่อนจบ Task ต้องตรวจอะไร

สองไฟล์นี้เสริมกัน แต่ไม่ควรรวมจนกลายเป็นกฎยาวมากที่ Agentจับประเด็นสำคัญไม่ได้ อ่านต่อได้ใน AGENTS.md คืออะไร

สิ่งที่ไม่ควรใส่

  • รายละเอียด Feature ที่ควรอยู่ใน Product/Project Context
  • กฎซ้ำกันหลายรอบ
  • Component ที่ยังไม่มีและอาจไม่ใช้จริง
  • คำสั่ง Coding ที่ไม่เกี่ยวกับ Design
  • ข้อมูลที่ขัดกับ Design ล่าสุด

ถ้ากฎเปลี่ยนแล้วต้องแก้ไฟล์ให้ทัน เพราะ Context ที่เก่าก็ทำให้ Agent ทำงานผิดได้เหมือนกัน

สรุป

DESIGN.md มีหน้าที่ทำให้ Design “อธิบายได้และอ้างอิงซ้ำได้” แต่ความแม่นของ UI ยังต้องอาศัย Design Reference, Prompt และการ Review ร่วมกัน

ให้มองไฟล์นี้เป็นสะพานระหว่างความตั้งใจของ Designer กับสิ่งที่ Coding Agent ต้องรักษา แล้วมันจะมีประโยชน์มากกว่าการมองว่าเป็นไฟล์ที่แก้ปัญหา Design หลุดได้ทุกอย่างครับ

FROM DESIGN TO REAL APP

อยากลองทำตั้งแต่ Vibe Design ไปจนเป็น Web App ที่ใช้งานได้จริง?

ดูรายละเอียดคอร์ส Design to Web App with AI และ Workflow ที่ใช้ Google Stitch, MCP และ AI Coding Agent ทำโปรเจกต์จริงแบบเป็นขั้นตอน

ดูรายละเอียดคอร์ส ↗