# Lab — ให้ AI ช่วย research ข้อมูล สร้าง website brief และ brand kit

ต่อยอดโจทย์รายวิชาได้ใน [สร้างเว็บไซต์หลักสูตรด้วย Codex แบบทีละขั้น](build-course-website-step-by-step.md) พร้อม prompt ที่รันจริงและภาพผลลัพธ์แต่ละช่วง

**AI Web Studio — ออกแบบและพัฒนาเว็บไซต์ด้วย AI** · ส่วนหนึ่งของ **977-121 Module: Website Design and Development**, มหาวิทยาลัยสงขลานครินทร์ วิทยาเขตภูเก็ต (Prince of Songkla University, Phuket Campus)

Lab เต็มประมาณ **150 นาทีสำหรับ prework / เรียนต่อด้วยตัวเอง** ผู้สอนเลือกสาธิต inventory → research → brief 20 นาทีในช่วง design 30 นาทีที่มีอยู่ได้ ตาราง workshop ยังคง **2 วัน วันละ 4 ชั่วโมง รวม 8 ชั่วโมง** รวมพักวันละ 10 นาที ไม่ต้องทำทุกขั้นให้จบในห้อง

เป้าหมายคือใช้ข้อมูลที่มีทำ brief ซึ่งย้อนตรวจแหล่งที่มาได้ แล้วพัฒนาต่อเป็น mini brandbook, UI icons, key visual และชุดส่งต่อสำหรับสร้างเว็บไซต์ ผู้เรียนต้องอธิบายได้ว่าอะไรมีหลักฐาน อะไร AI เสนอ และอะไรยังต้องถามเจ้าของ

## เปิดตัวอย่างก่อนเริ่ม

- [HUSH brand kit — เปิด style board และไฟล์ตัวอย่าง](/labs/hush-brand-kit/) ต่อยอดจาก [เว็บสินค้า HUSH](/examples/store/)
- [Prompt ฉบับเต็ม P0–P8](../prompts/research-to-brand-prompts.md) สำหรับคัดลอกทำซ้ำทุกขั้น
- [ผล research และแหล่งทางการ](../research/research-to-brand-website.md) ตรวจเมื่อ 11 กันยายน 2026
- [บทเรียน 04: Design และ assets](../lessons/04-design-and-assets.md) และ [บทเรียน 07: เว็บสินค้า GSAP](../lessons/07-gsap-storefront.md)

![ข้อมูลตั้งต้นผ่านการ research และตรวจหลักฐานก่อนสร้าง brief brandbook icons key visual และส่งต่อเว็บไซต์ ถ้าหลักฐานยังไม่พอให้ย้อนกลับไปวิจัยเพิ่ม](/diagrams/research-to-brand.svg)

[เปิดแผนภาพพร้อม prompt และที่มา](/diagrams/research-to-brand.html) จุดตัดสินใจในภาพหมายถึงมีหลักฐานพอสำหรับข้อความที่จะใช้ใน brief หรือยัง ช่องที่ไม่ทราบยังเก็บเป็น GAP ได้ โดยไม่ต้องเติมคำตอบสมมติให้ครบทุกช่อง

## ผลงานที่ต้องส่ง

| ไฟล์/งาน | ใช้ตัดสินใจเรื่องใด |
| --- | --- |
| inputs.md, research.md, evidence.csv | ข้อมูลมาจากไหน เชื่อได้ในขอบเขตใด และยังขาดอะไร |
| brief.md | เว็บไซต์ทำเพื่อใคร ให้ทำอะไร และต้องมีเนื้อหา/สถานะใด |
| brandbook.md, tokens.css | กฎภาพ ภาษา และค่าที่ component จะใช้ร่วมกัน |
| icons/*.svg | ความหมายของ UI icon และรูปแบบเส้นที่สม่ำเสมอ |
| keyvisual-prompt.md, ไฟล์ภาพ, assets.csv | ทิศทางภาพ prompt ที่ใช้จริง และที่มาของ asset |
| index.html / style board, handoff.md | แสดงการใช้กฎบนหน้าเว็บและสิ่งที่ผู้พัฒนาต้องตรวจ |

**Logo** คืออัตลักษณ์องค์กร, **UI icon** สื่อความหมายหรือการกระทำ, **key visual** เป็นภาพหลักของหน้า/แคมเปญ และ **favicon/OG image** เป็น asset ตามช่องทาง อย่าใช้คำเหล่านี้แทนกัน หากงานต้องมีโลโก้ใหม่ให้แยกเป็นข้อเสนอที่เจ้าของต้องพิจารณา Lab นี้ฝึก UI icons และ key visual โดยใช้ชื่อแบรนด์เดิม

## 1. รวบรวมข้อมูลที่มี — 10 นาที

เลือกเว็บไซต์ของตน หรือใช้ HUSH ตั้งโฟลเดอร์ `brand-lab/` แล้วรวบรวม brief เก่า, notes จากเจ้าของ, หน้าเว็บปัจจุบัน, catalog/ราคา, screenshots, brandbook, logo, ภาพ และข้อจำกัดของระบบ ระบุไฟล์ที่ AI อ่านได้จริงและไฟล์ที่ยังไม่ได้รับ ใช้ **P0** สร้าง source inventory ก่อนค้นเว็บ

สำหรับบริษัท Rawinnipa ให้ยึด brandbook ที่ `/home/dev/projects/rawinnipa-brandbook` ในเครื่องผู้สอน โดยใช้ฉบับที่เจ้าของอนุมัติ ผู้เรียนใช้ไฟล์หรือ excerpt ที่ได้รับอนุญาต ไม่คาดว่า cloud chat จะอ่าน local path นี้ได้เอง ส่วน HUSH เป็นแบรนด์สมมติของตัวอย่างสินค้า ใช้ชุดสี/รูปแบบ HUSH จาก source เดิม แยกจากอัตลักษณ์ Rawinnipa ของเว็บไซต์หลักสูตร

| ป้าย | ความหมายและตัวอย่าง |
| --- | --- |
| FACT | มีแหล่งรองรับในขอบเขตที่ระบุ เช่น seed catalog มีสินค้า ID headphones ไม่ได้แปลว่ามีสินค้าจริงจำหน่าย |
| INFERENCE | อนุมานจากหลักฐาน เช่น ผู้ใช้คงต้องเปรียบเทียบสินค้า ต้องทดสอบต่อ |
| PROPOSAL | ทางเลือกที่เสนอ เช่น ใช้ headline สั้นและเว้นที่ว่างข้างภาพ |
| GAP | ยังไม่มีข้อมูล เช่น warranty, งานวิจัยผู้ใช้ หรือราคาจริงวันเปิดขาย |

FACT ใน Lab นี้เป็นข้อสังเกตที่มีแหล่งอ้าง ไม่ใช่การรับรองความจริงทั้งหมดของแหล่งนั้น ใส่วันที่และขอบเขตด้วย ข้อความโฆษณาของผู้ขายจึงไม่เท่ากับผลทดสอบอิสระ

## 2. ใช้ research prompt สร้าง evidence — 25 นาที

เริ่มจากคำถามที่จะเปลี่ยนแบบเว็บได้จริง เช่น “ผู้ใช้ต้องเห็นข้อมูลอะไรจึงเลือกสินค้าได้” หรือ “เรายืนยันคำกล่าวใดบน hero ได้แล้ว” แยกแหล่งข้อมูลสามกลุ่ม: เจ้าของ/ระบบของเรา, เอกสารทางการสำหรับมาตรฐานและเครื่องมือ, และเว็บคู่แข่งสำหรับสังเกตรูปแบบที่เผยแพร่สาธารณะ ข้อมูลคู่แข่งไม่ยืนยันกลุ่มลูกค้าหรือยอดขายของเรา

**ใน ChatGPT:** หากบัญชีมี Deep Research ให้เลือกเครื่องมือ แนบข้อมูลที่อนุญาต ระบุเว็บไซต์ที่ใช้ได้ ตรวจ research plan แล้วจึงรัน เปิด citations ของข้อค้นพบสำคัญและเก็บรายงานพร้อมแหล่งที่มา ตัวเลือกเว็บไซต์/แอปและโควตาขึ้นกับบัญชี [OpenAI Academy: Deep Research](https://academy.openai.com/public/clubs/work-users-ynjqu/resources/deep-research)

**ใน Claude:** ใช้ Research พร้อม web search เมื่อบัญชีมีให้ใช้ แนบข้อมูลและกำหนดขอบเขตเดียวกัน integrations ต้องมีสิทธิ์พร้อมก่อนจึงจะใช้ข้อมูลได้ เมื่อรายงานเสร็จให้เปิด source links ตรวจทีละ claim [Claude Research](https://support.anthropic.com/en/articles/11088861-using-research-on-claude-ai), [Claude web search](https://support.claude.com/en/articles/10684626-enable-and-use-web-search)

**หากไม่มี Research:** ค้นและเปิดเอกสารเอง เก็บข้อความ/URL/วันที่ แล้วส่งให้ AI สังเคราะห์ด้วย prompt เดิม ระบุว่าใช้เฉพาะข้อมูลที่แนบ ห้ามเขียนว่าได้ค้นเว็บหากเครื่องมือไม่มี web access การแนบไฟล์ไม่ได้แปลว่าเชื่อม MCP แล้ว

คัดลอก **P1** นี้และแทนช่อง `<...>` ก่อนใช้:

```text
ช่วย research เพื่อเตรียม website brief สำหรับ <ชื่อโครงการ>
เป้าหมายการตัดสินใจ: <ผู้ใช้ควรเข้าใจอะไรและทำอะไรบนเว็บไซต์>
ข้อมูลตั้งต้น: <แนบ inputs.md พร้อมไฟล์/ข้อความที่อนุญาต>
ขอบเขตเว็บที่อนุญาต: <official URLs/domains หรือแหล่งที่เจ้าของกำหนด>
ช่วงเวลาข้อมูลที่ต้องการ: <วันที่หรือช่วงเวลา>
สิ่งที่ยังไม่รู้: <รายการ GAP จาก P0>

ก่อนค้น สรุปคำถามวิจัย 3–5 ข้อ และแผนค้นที่ผูกกับการตัดสินใจของเว็บไซต์
ใช้ข้อมูลของเจ้าของเพื่อยืนยันข้อเท็จจริงของธุรกิจ
ใช้แหล่งทางการภายนอกเพื่อศึกษาบริบท รูปแบบเว็บไซต์ มาตรฐาน และข้อจำกัดเครื่องมือ
ถ้าดูเว็บคู่แข่ง ให้บอกว่าเป็นสิ่งที่สังเกตบนเว็บ ไม่ใช่หลักฐานว่ายอดขายหรือ UX ดีกว่า
ห้ามนำคำอ้างของคู่แข่งมาเป็นข้อเท็จจริงของธุรกิจเรา

ส่ง research.md และ evidence.csv โดยแต่ละข้อมี:
ID | ข้อค้นพบ | FACT/INFERENCE/PROPOSAL/GAP | source ID + URL/ไฟล์และตำแหน่ง
วันที่เผยแพร่ถ้าทราบ + วันที่เข้าถึง | ข้อจำกัด | ผลต่อ brief
เปิดอ่านแหล่งที่อ้างจริง ตรวจว่าแหล่งสนับสนุนข้อค้นพบโดยตรง
แยกข้อมูลที่เจ้าของให้จากข้อมูลภายนอก และชี้เมื่อสองแหล่งขัดกัน
อย่าให้จำนวน citation ทดแทนคุณภาพของหลักฐาน

ท้ายรายงานสรุป: กลุ่มผู้ใช้ที่มีหลักฐานหรือเป็นสมมติฐาน,
งานสำคัญของหน้า, เนื้อหาที่พร้อมใช้, เนื้อหาที่ต้องขอเพิ่ม,
ข้อจำกัด brand/accessibility/assets และ 2–3 ทางเลือกที่มีเหตุผลจากหลักฐาน
อย่าสร้าง brandbook หรือเลือกทิศทางแทนเจ้าของในขั้นนี้
หากไม่มี web access ให้ทำรายงานจากไฟล์ที่มี พร้อมเขียนว่าไม่ได้ทำ web research
และระบุ URL/คำค้นที่ควรตรวจต่อ ห้ามสร้าง citation หรือผลสัมภาษณ์ขึ้นเอง
```

หลังได้รายงาน ใช้ **P2** ตรวจข้อค้นพบที่กระทบ audience, ราคา, positioning และ product claims ก่อน เปิดแหล่งจริงและแก้ evidence.csv ด้วย ID เดิม เก็บข้อขัดแย้งไว้ หากแหล่งรองรับแค่บางส่วนให้ลดระดับหรือเขียน GAP การให้ AI อีกตัวเห็นด้วยไม่ใช่หลักฐานใหม่

## 3. สรุป website brief — 15 นาที

ส่ง inputs.md + research.md + evidence.csv ที่ตรวจแล้วเข้า **P3** ให้สร้าง brief 1–2 หน้า: เป้าหมาย, audience/งานของผู้ใช้, value proposition, CTA หลักและผลหลังคลิก, sitemap/sections, เนื้อหาที่พร้อม, brand constraints, form/error/empty states, เกณฑ์ตรวจรับ และคำถามเจ้าของ

ใช้แนว Discover → Define ก่อนพัฒนา visual direction เพื่อให้ brief เกิดจากข้อมูลและการสังเคราะห์ ไม่ใช่เดาสิ่งที่ลูกค้าต้องการ [Design Council: Double Diamond](https://www.designcouncil.org.uk/resources/the-double-diamond/)

**ตัวอย่าง HUSH:** ชื่อ HUSH ONE เป็นชื่อเล่าเรื่องบนหน้า ส่วน catalog/API ใช้ ID `headphones` และชื่อ “หูฟัง Studio One” ให้ทำ mapping ไว้ ไม่สร้างสินค้าใหม่เพื่อให้ชื่อตรงกัน ราคาใน seed เป็นข้อมูลตัวอย่าง; เมื่อทำร้านจริงให้แสดงราคาจาก API ส่วนข้อความ 40 mm / 30 ชั่วโมงเป็น concept copy สมมติ ไม่ใช่ผลทดสอบสินค้า การเลือก audience และน้ำเสียงใหม่ยังเป็นข้อเสนอ หากไม่มีข้อมูล warranty ให้แสดง GAP แทนคำว่า “รับประกัน 2 ปี”

ในชุดตัวอย่างใช้ **S1** สำหรับ HTML/CSS ของเว็บ, **S2** สำหรับ seed catalog, **S3** สำหรับข้อกำหนด HUSH ใน DESIGN.md และ **S4** สำหรับที่มาภาพ เช่น E01 ผูกชื่อ HUSH ONE กับ product ID ผ่าน S1/S2, E09 เป็น audience proposal และ E14 เป็นช่องว่างหลักฐาน performance เปิด [inputs.md](/labs/hush-brand-kit/inputs.md) และ [research.md](/labs/hush-brand-kit/research.md) เพื่อดู source locator และขอบเขตของแต่ละแหล่ง

เปิด [brief ตัวอย่าง](/labs/hush-brand-kit/brief.md) เทียบกับ [evidence ledger](/labs/hush-brand-kit/evidence.csv) แล้วเลือกหนึ่งประโยคใน brief ไล่กลับถึง source ที่ระบุ หากทำไม่ได้ให้แก้ก่อนสร้างภาพ

## 4. จาก brief สู่ mini brandbook — 20 นาที

ใช้ **P4** โดยแนบ brandbook เดิมถ้ามี ให้ AI เสนอทิศทาง 2–3 แบบพร้อมเหตุผลและเลือกหนึ่งแบบสำหรับทดลอง บันทึกผู้เลือกและสถานะ **draft/proposed** ให้ตรงจริง งานนักเรียนไม่เท่ากับการอนุมัติจากเจ้าของบริษัท

ฉบับที่เลือกต้องมี positioning/หลักฐาน, voice พร้อม do/don’t, logo/wordmark ที่อนุญาต, palette, typography ไทย/ละติน, spacing/radius, UI icons, imagery และ component ตัวอย่าง ให้แยกกฎเดิมออกจากค่าที่เสนอเพิ่ม ใช้ semantic tokens เช่น surface, text, action พร้อมค่าตาม mode เพื่อส่งต่อได้ [Figma: Variables](https://help.figma.com/hc/en-us/articles/15339657135383-Guide-to-variables-in-Figma)

ดู [HUSH mini brandbook](/labs/hush-brand-kit/brandbook.md) และ [tokens.css](/labs/hush-brand-kit/tokens.css) สำหรับเว็บไซต์หลักสูตรให้คง Light default และ Dark ตามข้อกำหนด ส่วน style board HUSH ใช้ทิศทางของตัวอย่างสินค้า ตรวจคู่สีข้อความ/พื้นจริง และอย่าอ้างว่าผ่าน WCAG ทั้งเว็บไซต์จากการตรวจสีเพียงคู่เดียว

## 5. ให้ AI ช่วยสร้าง UI icon system — 20 นาที

ใช้ **P5** ให้ coding agent เขียน SVG ต้นฉบับ 4 ชิ้น: headphones, speaker, battery และ bag กำหนด `viewBox="0 0 24 24"`, stroke 2, rounded caps/joins และ `currentColor` ให้สม่ำเสมอ ตรวจภาพที่ 24 และ 48 px รวมถึงรูปร่างที่คนอาจตีความผิด หลักการ grid และ alignment ช่วยให้ชุด icon มีน้ำหนักใกล้กัน [Carbon: Icon contribution](https://v10.carbondesignsystem.com/contributing/contribute-icons/)

ใช้ข้อความกำกับ icon เมื่อทำได้ ปุ่มที่มีแต่ icon ต้องมีชื่อที่สื่อการกระทำ เช่น “เปิดกระเป๋า” และ focus ที่เห็นได้ ส่วน icon ตกแต่งข้าง label ให้ซ่อนจาก screen reader เพื่อลดการอ่านซ้ำ อย่าเรียกปุ่มปิดว่า “X” [W3C: SVG icons](https://design-system.w3.org/styles/svg-icons.html), [W3C: Accessible names](https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/)

ไฟล์ SVG ที่ใช้ผ่าน `<img>` ต้องใส่ alt ที่ element นั้น; `currentColor` ภายในไฟล์ภายนอกไม่ได้รับสีจาก CSS ของหน้าหลักโดยอัตโนมัติ หากต้องเปลี่ยนสีตามโหมดใช้ inline SVG ที่ตรวจแล้ว ดูรูปแบบจริงใน [style board](/labs/hush-brand-kit/) การสร้างภาพ icon ด้วยโมเดลภาพให้ผลเป็น raster จึงยังต้องมีงานออกแบบ vector ก่อนอ้างว่าส่ง SVG system แล้ว

## 6. สร้าง key visual สำหรับ website และ mobile — 20 นาที

ใช้ **P6** พร้อม reference ที่มีสิทธิ์ใช้ ระบุสินค้า/สิ่งที่ห้ามเปลี่ยน, mood, palette, แสง, composition, ขนาด และพื้นที่สำหรับข้อความ สร้าง desktop 3:2 และ mobile 4:5 โดยจัดองค์ประกอบให้เหมาะแต่ละจอ ไม่พึ่ง crop กลางภาพอย่างเดียว ให้หัวเรื่อง/ราคา/CTA เป็น HTML เพื่อแก้ข้อความและรองรับการอ่านได้

ใช้เครื่องมือสร้างภาพใน Codex ตาม workflow `gpt-image-2` เมื่อมีให้ใช้ตามการตั้งค่าของเครื่องมือ หาก UI ไม่เปิดเผยชื่อ model ให้บันทึกชื่อเครื่องมือที่ใช้จริง ไม่เดาว่าได้รัน model ใด [OpenAI: GPT Image 2](https://developers.openai.com/api/docs/models/gpt-image-2)

ตัวอย่าง prompt พร้อมข้อกำหนด HUSH อยู่ใน [keyvisual-prompt.md](/labs/hush-brand-kit/keyvisual-prompt.md) และ [P6 ฉบับแก้ใช้กับเว็บไซต์อื่น](../prompts/research-to-brand-prompts.md) บันทึก prompt และไฟล์ผลลัพธ์ลง assets.csv ตรวจรูปทรงสินค้า การตัดขอบ และความหมายของภาพก่อนใช้ หากภาพเป็นเพียงฉากตกแต่งใช้ alt ว่าง แต่ภาพที่สื่อสินค้า/สาระต้องมีข้อความทดแทนตามหน้าที่ [W3C: Images Tutorial](https://www.w3.org/WAI/tutorials/images/)

**สถานะตัวอย่างที่ให้:** HUSH kit ใช้ภาพ `headphones.webp` ที่มีอยู่ในหลักสูตรแล้วจัด composition ด้วย HTML/CSS ไม่ได้สร้างภาพ raster ใหม่ใน Lab ฉบับนี้ `keyvisual-prompt.md` เป็น prompt สำหรับฝึกทำซ้ำ ชุด icon เป็น SVG ที่สร้างจากโค้ด อย่ารายงานว่ามี output จาก image model หากยังไม่ได้รันจริง

## 7. ทำ style board และส่งต่อเว็บไซต์ — 20 นาที

ใช้ **P7** ให้สร้างหน้าเดียวที่เห็นสี typography, icon, hero, card, CTA, form/error/empty states และ asset usage จัด handoff เป็นตาราง section → evidence ID → copy → token → asset → interaction → acceptance check ให้ผู้พัฒนาอ่านแล้วรู้ว่าต้องทำอะไร ไม่ได้มีเพียงภาพตัวอย่าง

ดู [handoff ของ HUSH](/labs/hush-brand-kit/handoff.md) แล้วส่ง brief/brandbook/tokens/assets ไปใช้กับ [Claude Design, Stitch หรือ Figma MCP](design-tools-and-mcp.md) โดยใช้ prompt ของเครื่องมือนั้นเพิ่มเติม หากเครื่องมือเข้าถึงไฟล์ไม่ได้ให้แนบไฟล์ที่อนุญาตจริงและบอกว่าเป็น file handoff

กลับไปที่ [เว็บสินค้า GSAP](../lessons/07-gsap-storefront.md) โดยรักษา product ID, API pricing และ checkout behavior เดิม สำหรับผู้ที่ต้องการออกแบบ mobile app ให้ทำต่อจาก [Website → Mobile App](website-to-mobile-app.md) และปรับ navigation/interaction ให้เหมาะกับงานของผู้ใช้ ไม่ใช่ย่อ screenshot ของ desktop

## 8. ตรวจรับและอธิบายเหตุผล — 20 นาที

ใช้ **P8** รีวิวงาน แล้วผู้เรียนเปิดแหล่งจริงและทดสอบเอง ตรวจทุก claim สำคัญถึง evidence, draft/owner decisions, สี/ตัวอักษร/เส้น icon, key visual desktop/mobile, alt, keyboard, form states และราคาจากระบบ บันทึกสิ่งที่ทดสอบจริงแยกจากสิ่งที่ยังไม่ได้ทดสอบ

| เกณฑ์ให้คะแนน | คะแนน |
| --- | --- |
| หลักฐานย้อนตรวจได้ แยกข้ออนุมาน/ข้อเสนอ/ข้อมูลขาดถูกต้อง | 5 |
| Brief มีเป้าหมาย CTA และเกณฑ์ตรวจรับที่สอดคล้องกับข้อมูล | 5 |
| Brandbook, icons และ key visual ใช้กฎเดียวกัน มี prompt/ที่มา | 5 |
| Handoff นำไปใช้ได้ มี responsive/accessibility checks และคำถามค้าง | 5 |

ส่งโฟลเดอร์งานพร้อมสรุปหนึ่งหน้า: “ข้อมูลใดเปลี่ยนแบบเว็บของเรา”, “ข้อเสนอใดเลือกเพราะอะไร” และ “เจ้าของต้องตอบอะไรต่อ” ตัวอย่าง HUSH เป็นคำตอบประกอบการเรียนจาก source ที่มี ไม่ใช่หลักฐานว่าได้สัมภาษณ์ผู้ใช้หรือทำ market research ของแบรนด์จริง ดาวน์โหลด source ของหลักสูตรได้จาก [เอกสารและไฟล์ประกอบ](/resources/)

## ฝึกต่อด้วย brandkit

เมื่อมี brief และทิศทางแบรนด์แล้ว ใช้ [Lab brandkit สร้าง overview board 3 × 3](brandkit-skill.md) เพื่อฝึกส่ง prompt พร้อม reference, ตรวจผลราย panel และทำ website handoff มี [ภาพ HUSH ที่สร้างจริงพร้อมไฟล์ต้นทาง](/labs/brandkit-hush/) สำหรับเปิดเทียบ เป็น Lab เสริม 60–90 นาที ไม่เพิ่มชั่วโมง workshop