Charmiss · AI-assisted design and build

Charmiss E-commerce

How I designed, built and tested a full e-commerce site with AI

In seven weeks I turned Charmiss's Figma design into a clickable storefront and admin that the whole team could use from one link. I did it by directing AI the way I'd brief a developer, then used the same AI to check the real dev build against it.

Timeline
Sep - Oct 2026
Duration
7 weeks, 15 sessions
Role
UX/UI Designer, AI-directed build and QA
Platform
Web storefront and admin
Open the prototype Skip to how my work changed
Charmiss prototype on four phones: home, product page, checkout and member popup

The Problem

A Figma file can't show how a store really behaves. The team needed to click through every flow, and the developers needed a living reference, long before the real system was ready.

The Solution

I used AI as my builder, auditor and QA engineer. I wrote the briefs and made the decisions; AI wrote the code, checked its own work, and later checked the dev team's build.

Background

A prototype that behaves like the real store

Usually I'd hand over a Figma file, developers would build for weeks, and only then would we find out that something like the coupon flow didn't work well on a phone. Questions about behavior had to wait for code.

Charmiss needed a storefront and a back office for its own brand. The real backend, database and APIs were planned for the developer team in a later phase. My brief to the AI on day one set the goal:

"A front for the system that works and shows every flow as close to the real thing as possible."My project brief to the AI, September 2026

The rules were clear from the start: frontend only, mock data, mobile first, the Charmiss design system, and always deployable to Vercel so anyone on the team could open a link and try it.

How I used AI

Four jobs I gave the AI

I went back through all 573 prompts I wrote across 15 working sessions. The AI did four distinct jobs, and the way I prompted changed with each one.

The four roles

Builder

Turned Figma nodes into SolidJS pages and components: home, categories, product pages, cart, a one-page checkout with Thai addresses, tax invoices and member accounts, then a full admin.

Auditor

Before touching code, it inspected the running site and the codebase and reported what it found. "Audit only, change nothing" was one of my most used instructions.

Design system keeper

Every time I corrected something, I asked it to make the fix a site-wide rule and remember it, so the same mistake never came back in a later session.

QA engineer

In the last phase it compared the dev team's build against my prototype, page by page, and wrote a bug report with screenshots into a shared Google Sheet.

What my 573 prompts were about

I tagged every prompt by topic. Checking and refining took far more of my time than asking for new features.

Checking and QA

124 prompts asked the AI to check, compare or test something, more than any other topic.

Words on screen

120 prompts were about copy: button labels, Thai wording, and removing text that sounded machine-written.

Reference and truth

105 prompts pointed the AI at a source of truth: a Figma node, the production prototype, or the storefront as the master for the admin.

Design system rules

81 prompts asked for one standard across the whole site, from button weight to badge color to the gap above the footer.

My toolkit

The tools behind the project

No single tool did everything. Each one had a clear job, and the numbers come from my own session history.

Claude Code

Builder and auditor

Wrote and refactored the SolidJS code, checked the running site in its built-in browser at every screen size, and kept the 12 design rules in its memory.

573 prompts in 15 sessions

ChatGPT

Thinking partner

Used alongside Claude to think through ideas and shape long briefs before handing them to Claude to build.

Planning and briefs

Claude in Chrome

QA in my real browser

Tested the dev build in my own signed-in Chrome, measured both sites side by side, and placed evidence images straight into the report.

1,159 browser actions

Figma

Source of truth

Build prompts pointed at an exact Figma node, and Claude read the design before writing any code.

69 prompts referenced Figma

Vercel

One shareable link

Every "commit and deploy" published a new version the whole team could open on any phone.

61 commit and deploy prompts

GitHub

Handover to developers

A public repo with the pages, components, tokens and mock data. GitHub Desktop let me push without the command line.

39 commits

Google Sheets

Living QA report

One sheet with a tab per page, priority, Dev and reference pictures, and the exact fix for each issue.

100+ issues in 7 tabs

iOS Simulator and iPhone

Testing on real phones

Checked layouts in the iOS Simulator and on my own iPhone, where most of my detail feedback came from.

92 simulator checks

Built with

SolidJS and SolidStart Tailwind CSS daisyUI

My method

Writing prompts like design briefs

My early prompts were short. They quickly grew into structured briefs, the same kind of spec I'd write for a developer, because vague prompts produced work I had to undo.

Anatomy of one of my prompts

This is my fifth prompt on the first day of the project, word for word. I wrote it after the AI rebuilt more than I asked for, so it spells out the scope, the source of truth and how to test.

prompt.mdSession 1 · 9 Sep 2026 · 4,155 characters
Fix Hero Banner Carouselแก้ไข Hero Banner / Main Banner ของหน้า Home เดิม เท่านั้น ห้าม rebuild หน้าใหม่ และห้ามกระทบส่วนอื่นที่ทำงานอยู่แล้ว1. ต้องทำให้ Banner เลื่อนซ้าย–ขวาได้จริงHero Banner ต้องทำงานเป็น Carousel / Slider ที่สามารถเปลี่ยน Artwork ได้หลายรูปรองรับการเปลี่ยน Slide ด้วย:* ปุ่ม Previous / Next* Pagination Dots* Swipe ซ้าย / ขวาบน Mobile และ Touch Device* Drag ซ้าย / ขวาบน Desktop ถ้าเหมาะสม* Keyboard Arrow Left / Right เมื่อ Banner อยู่ใน focusการเปลี่ยน Slide ต้องเปลี่ยน Artwork จริง ไม่ใช่แค่เปลี่ยน active dot2. ใช้ Artwork จริงจาก Figmaใช้ image assets จริงที่มีอยู่ในโปรเจกต์/Figmaห้ามใช้ placeholder หรือสร้าง artwork ขึ้นมาใหม่Banner ให้ถือเป็น Artwork / Media Asset เดียวเพราะ artwork อาจมีทั้งรูปภาพและข้อความอยู่ใน asset เดียวกันห้ามแยก text ออกจาก artwork แล้วสร้าง HTML text ทับเอง เว้นแต่มี mobile-specific artwork ใน Figma อยู่แล้ว3. Responsive BehaviorDesktop* แสดง Banner ตามสัดส่วนและ layout ของ Figma* มี Previous / Next เมื่อเหมาะสม* Pagination dots อยู่ตำแหน่งตาม design* รองรับ mouse interactionTablet* ปรับขนาด Banner ตามพื้นที่* ยังคงสามารถเลื่อนซ้าย / ขวาได้* ปุ่มควบคุมต้องกดง่ายMobile* ต้องรองรับ Swipe ซ้าย / ขวาเป็นหลัก* Touch interaction ต้องลื่น* ไม่บังคับให้ user ต้องกดลูกศรเล็ก ๆ* Pagination dots ต้องยังมองเห็นและกดได้* ห้าม crop artwork จนข้อความหรือเนื้อหาสำคัญถูกตัด4. Slide Transitionใช้ transition ที่เรียบและ premium เช่น:* 200–400ms* ease-out / ease-in-out* ไม่ต้องใส่ animation เยอะเกินไปถ้ามีการ swipe ให้รู้สึกต่อเนื่องกับ gesture ของ userรองรับ:prefers-reduced-motionถ้า user เปิด Reduced Motion ให้ลด/ปิด transition ที่ไม่จำเป็น5. Auto Playถ้า Banner ใน Figma/UX เหมาะสม ให้รองรับ Auto Play* เปลี่ยน Slide อัตโนมัติทุกประมาณ 4–5 วินาที* เมื่อ user interaction กับ Banner ให้ reset timer* เมื่อ hover บน Desktop ให้ pause* เมื่อ user swipe/click ให้ pause ชั่วคราวแล้วเริ่มใหม่* ห้าม autoplay ถ้า prefers-reduced-motion: reduceถ้า Banner มีเพียง 1 Artwork ให้ไม่ต้องทำ autoplay หรือ navigation6. Navigation Stateต้องมี state ที่ชัดเจน:* Active Slide* Previous Slide* Next Slide* First Slide → Previous ไป Last Slide ได้* Last Slide → Next ไป First Slide ได้Pagination:● ○ ○ ○ต้องเปลี่ยนตาม Slide จริง7. AccessibilityCarousel ต้องสามารถใช้งานด้วย Keyboard ได้เพิ่ม:* aria-label ให้ Previous / Next* aria-current ให้ active pagination* accessible label สำหรับแต่ละ slide* keyboard navigation* visible focus state* touch target อย่างน้อย 44×44pxถ้า autoplay ทำงาน ต้องไม่ทำให้ accessibility แย่ลง8. Prevent Interaction Bugsตรวจสอบเป็นพิเศษ:* Swipe แล้วหน้าเว็บต้องไม่เลื่อนผิดทิศทาง* Swipe แนวนอนต้องไม่ทำให้เกิด horizontal overflow ของทั้งหน้า* กด Next/Previous รัว ๆ แล้ว state ต้องไม่พัง* Dot กดแล้วต้องไป Slide ที่ถูกต้อง* Auto Play ต้องไม่ชนกับ manual navigation* Resize browser แล้ว Carousel ต้องยังทำงาน* Mobile Safari / Chrome Mobile ต้องใช้งานได้* รูปต้องไม่กระพริบระหว่างเปลี่ยน Slide9. ห้ามกระทบ Header และส่วนอื่นก่อนแก้ ตรวจสอบว่า Home ตอนนี้มี:Promo Strip→ Utility Bar→ Main Header→ Category Navigation→ Hero Bannerห้ามลบ Promo Strip ที่เพิ่ง restore กลับมาห้ามทำให้ Sticky Header / Dynamic Header behavior เสียห้ามแก้ Product Card, Product Grid หรือ section อื่นโดยไม่จำเป็น10. Code Structureถ้ามี Carousel component อยู่แล้ว ให้แก้ component เดิมและ reuseถ้ายังไม่มี ให้สร้าง reusable component เช่น:ArtworkCarouselโดยรองรับ:* images* optional video* autoplay* navigation* pagination* swipe* responsive behaviorอย่า hardcode logic เฉพาะกับ Banner จน reuse ไม่ได้11. Final QAหลังแก้เสร็จ ให้ทดสอบจริงที่:* 375px* 390px* 430px* 768px* 834px* 1024px* 1280px* 1440px* 1920pxตรวจสอบ:1. Banner เลื่อนซ้ายได้2. Banner เลื่อนขวาได้3. Next / Previous ทำงาน4. Pagination ทำงาน5. Swipe Mobile ทำงาน6. Artwork เปลี่ยนจริง7. Auto Play ทำงานถ้าเปิดใช้8. ไม่มี horizontal overflow9. ไม่มี layout jump10. Header / Promo Strip ยังอยู่ครบ11. ไม่มี console errorสุดท้ายสรุปให้ผมสั้น ๆ ว่า:* แก้อะไร* Carousel ใช้ interaction อะไรบ้าง* ใช้ Artwork asset ตัวไหน* รองรับ Responsive ถึงระดับไหน* มี issue ที่ยังเหลือหรือไม่

Scope

Lines 1-2 and section 9

Edit only the existing banner. Don't rebuild the page, and don't touch the header, promo strip or product cards that already work.

Source of truth

Section 2

Use the real artwork from Figma as one asset. No placeholders, and no HTML text laid on top of the artwork.

Acceptance

Sections 8 and 11

Nine screen widths from 375 to 1920px, an 11-point checklist, and a short report of what changed and what's left.

Rules I gave the AI again and again

  • Audit first and report back. Don't change anything until I say go.
  • Keep the existing architecture, tokens and components. Don't rebuild.
  • One rule for the whole site, not a fix for one screen.
  • The storefront is the source of truth. The admin only keeps what the storefront uses.

Turning feedback into rules

Every correction became a rule the AI remembers

AI forgets between sessions unless you write things down for it. So whenever I fixed something twice, I asked the AI to save it as a design system rule in its memory. By the end there were 12 rules that every new screen had to follow, each one traceable to the prompt that created it.

The 12 rules, and the prompts that started them

Each rule began as one sentence I typed while reviewing, usually ending with "save it as DSL". The AI stored it in its memory and applied it to every screen after that. Listed in the order they were created.

  1. 012 Oct 2026

    Button text is Medium

    All button text uses font weight 500, on the storefront and in the admin.

    ตัวอักษรที่อยู่ในปุ่ม ให้ใช้น้ำหนักฟอนต์เป็น mediem ให้หมด เช็คทั้ง site และปรับเลย และยึดเป็น DSL
  2. 023 Oct 2026

    One arrow everywhere

    Every left and right arrow is the FAQ chevron at 24px, and slider arrow buttons get a half-white background.

    ปรับไอคอนลูกศร < > ทั้งเว็บไซต์ ให้ใช้แบบเดียวกับลูกศรที่ section คำถามที่พบบ่อย (24px) และยึดลูกศรนี้เป็น DSL
  3. 034 Oct 2026

    The current design is the baseline

    Fonts, modals and layout are approved. New screens reuse the shared components instead of inventing new styles.

    ตอนนี้ภาพรวมเรื่องฟอนต์, modal และการจัดวาง layout ลงตัวแล้ว ขอให้ใช้ดีไซน์นี้ยึดเป็น DSL ในทุกจุดที่จะเกิดขึ้นหลังจากนี้
  4. 044 Oct 2026

    One Add to Cart button

    Every "เพิ่มลงตะกร้า" button is the same component, with its icon, at every screen size.

    ยังต้องการให้ทุกปุ่มที่มีคำว่า เพิ่มลงตะกร้าใช้เหมือนกันทุกที่ ทุกหน้าจอ พร้อมไอคอน
  5. 054 Oct 2026

    Check on a phone before saying done

    Before reporting a change as done, inspect zoomed phone-width screenshots for clipped shadows, cramped spacing and stray Thai marks.

    ระยะห่างระหว่างการ์ดสินค้า กับ ปุ่ม โดยตัดไป เช็คทุกครั้งหากทำเสร็จ ต้องเก็บรายละเอียดพวกนี้ดีๆ
  6. 065 Oct 2026

    24px above the footer

    The gap between the last content and the footer is 24px on every page and every screen size.

    จำระยะห่างระหว่าง content สุดท้ายขอจอกับ footer ที่หน้านี้ไว้ และปรับทุกหน้าในเว็บไซต์ให้เท่ากับหน้านี้ และบันทึกเป็น DSL
  7. 075 Oct 2026

    One check mark

    Every check mark uses the shared check icon, never a typed character.

    เครื่องหมาย Check ถูกใช้แบบเดียวกับใน DSL
  8. 087 Oct 2026

    One close mark, a bag for the cart

    Every close mark is the one from the home popup, and the cart icon is a shopping bag, never a trolley.

    เครื่องหมาย x ต้องใช้ให้เหมือนกันทั้งเว็บไซต์ ยึด x ที่ modal popup หน้าแรกคือ ไฟล์ที่ถูกต้อง
เปลี่ยนไอคอนรถเข็น เป็นถุงช้อปปิ้ง ทุกจุด
  9. 098 Oct 2026

    No AI-looking copy

    No long dashes, arrows or emoji in any text on screen, on the storefront or in the admin.

    ใน admin ผมยังพบเครื่องหมาย — เอาออกให้หมด และยึดนี้เป็นกฎ ห้ามใส่ข้อความที่ดูเหมือน AI สร้าง
  10. 108 Oct 2026

    The storefront is the source of truth

    The admin keeps only what the storefront uses, and anything edited in the admin shows live on the storefront.

    อะไรที่คิดว่าหน้าบ้านไม่มี ไม่จำเป็นต้องแสดง หรือไม่เกี่ยวข้องกัน ให้ตัดข้อมูลจากหลังบ้านออกได้เลย
  11. 1111 Oct 2026

    Draft first

    Every new admin item starts as a draft: save draft, or save and publish. The on/off switch appears only after the first publish.

    การบันทึกร่างหรือปิดเปิดสวิตซ์ อยากให้ใช้กฎเดียวทั้งเว็บ ว่าจะใช้แบบปิดเปิดสวิตตอนเพิ่ม หรือแบบร่างก่อน ผมมองว่าควรใช้แบบร่างครับ
  12. 1228 Oct 2026

    One living QA report

    Dev QA goes into one Google Sheet: the problem in plain words, then the fix with the exact size, weight and hex code.

    บอกปัญหาทีเจอสั้นๆ แต่ได้ใจความ แล้วบอกสิ่งที่ต้องแก้ เช่น "ตัวอักษรชื่อสินค้าเล็กกว่าต้นฉบับ แก้เป็น 18px" หรือ "สีไม่เหมือนต้นฉบับ แก้เป็น #ffffff"

Architecture before features

Halfway through, the admin had menus that overlapped: promotions, campaigns, collections and banners all did similar things. I stopped all building and asked the AI for an architecture audit only: which entity is the source of truth, which is classification, which is curation, and which pages duplicate each other. I made the decisions, then we rebuilt the admin around them.

Home product cards and flash sale, built on the shared product card rules

The loop

A typical day of work

Most days followed the same loop. A change that would normally go through a ticket and a sprint happened in one conversation.

How a change moved from idea to a shared link

  • Brief: I wrote what to change, the source of truth, and what not to touch.
  • Audit: the AI inspected the running site and code, then asked questions or proposed options.
  • Decide: I answered, often as a numbered list, and only then said "go".
  • Build and check: the AI made the change and checked it in a real browser at each screen size.
  • Review on my phone: I tested on a real iPhone and sent back what I saw.
  • Commit and deploy: 61 of my prompts were simply "commit and deploy", so the team always had the latest version.
  • Hand over: the same commits were pushed to GitHub, so developers could pull the latest code instead of waiting for a handoff file.
Member popup that appears once a day, with a do-not-show-again option Cookie consent bar added for PDPA, shown before the popup
Home with product cards and flash sale Product detail page with gallery and sticky buy row One-page checkout with delivery and payment choices Member sign-up popup Cookie consent bar

How my work changed

Five things that changed in how I work

Speed was the obvious change. These five were more interesting to me.

From static handoff to a clickable link

Before, I handed over frames and waited for developers to build them. Now I hand over two things: a deployed prototype the team can click on any phone, and a GitHub repository with the code behind it. Questions about behavior get answered in the review, and developers start from working code, not a picture.

Static Figma frame
Before
Working checkout anyone on the team can try
After

Results

A prototype that became the team's reference

The prototype grew into a full storefront and admin: product pages with TikTok clips, flash sales, coupons, free gifts with options, a one-page checkout with Thai addresses and tax invoices, a cookie bar for PDPA, a promotions hub and a page builder. When the developer team built the real system, my prototype was the reference they were checked against.

Handover through GitHub

Halfway through the project I asked the AI a simple question: could the code go to GitHub so I can send developers one link? I had never used Git. The AI set up the repository, walked me through signing in and installing GitHub Desktop, and from then on every "commit and deploy" also updated the repo the developers worked from.

  • One link to try: the Vercel prototype showed every flow and every state, on any device.
  • One repo to build from: the GitHub repository held the real pages, components, design tokens and mock data, so developers could read how each screen worked.
  • One reference to check against: during QA the AI read the same repo to find the exact component behind each issue, instead of guessing file names.
573Prompts across 15 working sessions in 7 weeks
12Design system rules saved in the AI's memory
100+Dev issues logged across 7 pages for the developers
"Check every time you finish. Get these details right."My feedback to the AI after testing on my iPhone
Checkout with DHL, Flash Express, Kerry Express and EMS options Product detail page with sticky add to cart

Final Thoughts

Most of my time went into briefs, decisions and checking quality, and less into drawing screens.

What I learned: AI is fast, but speed without direction creates rework. The prompts that worked best named a source of truth, limited the scope, listed what not to touch, and asked for an audit before any change. I also learned to keep a git baseline: one day the local build drifted from production, and the fix started with "stop all code changes first". And I learned that a designer can hand over code: GitHub turned my prototype from a demo into a starting point for the dev team.

Next steps: Turn the 12 memory rules into a shared design system the developers can read, keep a library of prompt templates for audits, builds and QA, and run the AI QA pass on every dev release instead of once at the end.

What I'm most proud of: Getting a working store and admin in front of the whole team, then using the same setup to check the real build against it.

Charmiss · ใช้ AI ช่วยออกแบบและสร้างเว็บ

Charmiss E-commerce

ถ้ามี Figma อยู่แล้ว เราจะทำเว็บไซต์ให้กดใช้งานได้เองแค่ไหน?

เวลาออกแบบเว็บไซต์เสร็จ เรามักจะส่ง Figma ให้ Developer เอาไปพัฒนาต่อใช่ไหมครับ แล้วก็รอจนกว่าเว็บไซต์จะเสร็จ ถึงจะได้ลองกดดูว่าทุกอย่างทำงานเป็นอย่างไร

ช่วงเวลา
ก.ย. - ต.ค. 2026
ระยะเวลา
7 สัปดาห์ 15 เซสชัน
บทบาท
UX/UI Designer คุมงาน AI ทั้งตอนสร้างและตอน QA
แพลตฟอร์ม
เว็บหน้าร้านและระบบหลังบ้าน
เปิดดูต้นแบบ
ต้นแบบ Charmiss บนมือถือสี่เครื่อง: หน้าแรก หน้าสินค้า checkout และ popup สมาชิก

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

โปรเจกต์ Charmiss E-commerce เลยกลายเป็นโอกาสที่ผมได้ลองทำสิ่งนี้ดูครับ ผมใช้ AI เข้ามาช่วยพัฒนาเว็บไซต์จาก Figma ตั้งแต่หน้าร้านไปจนถึงหน้าตาของระบบหลังบ้าน โดยใช้ Claude Code เป็นเครื่องมือหลักในการเขียนและแก้ไข Code

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

บางปุ่มกดแล้วไม่มีอะไรเกิดขึ้น บาง Flow ยังต่อกันไม่ครบ หรือบางครั้งแก้ Component หนึ่งแล้วกลับไปกระทบอีกหน้าที่ทำเสร็จไปแล้ว

ผมเลยต้องเปลี่ยนจากการสั่งให้ AI ทำตาม Design อย่างเดียว มาเป็นการคอยกำหนดขอบเขต ตรวจสอบ และตัดสินใจในรายละเอียดต่าง ๆ ด้วย

สุดท้ายสิ่งที่ได้ไม่ใช่แค่เว็บไซต์ต้นแบบ แต่ยังมี Source Code และข้อมูลที่ทีม Developer สามารถเปิดดูและนำไปทำต่อได้ด้วย

เริ่มจากสิ่งที่มีอยู่แล้ว

โจทย์ไม่ได้เริ่มจากศูนย์ เพราะเรามี Design อยู่แล้ว

ก่อนเริ่มทำ ผมมี Design ใน Figma อยู่แล้ว ทั้งหน้า Home, Product Detail, Cart, Checkout และหน้าอื่น ๆ ของเว็บไซต์

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

ผมเริ่มจากกำหนดให้ AI ดู Figma เป็น Reference หลัก แล้วค่อย ๆ ทำเว็บไซต์ตามหน้าที่ออกแบบไว้

ช่วงแรกผมเน้นทำหน้าร้านก่อน เพราะเป็นส่วนที่ User ต้องใช้งานโดยตรง และมีหลาย Flow ที่ต้องเชื่อมต่อกัน ตั้งแต่เลือกสินค้าไปจนถึงสั่งซื้อ

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

มีเรื่องหนึ่งที่ผมกำหนดไว้ตั้งแต่แรกคือ รอบนี้จะทำเป็น Frontend Prototype ก่อน ใช้ Mock Data แทนข้อมูลจริง ยังไม่เชื่อมต่อ Backend, Database หรือ API จริง เพราะส่วนนี้จะเป็นงานที่ Developer นำไปพัฒนาต่อ

แล้วเว็บไซต์ต้องมีอะไรบ้าง?

ผมเริ่มจาก Flow หลักที่ User ต้องใช้งานก่อน

  • Home และ Product Discovery
  • Product Categories และ Product Listing
  • Product Detail พร้อม Product Gallery
  • Cart และการจัดการสินค้าในตะกร้า
  • Checkout แบบหน้าเดียว
  • Coupon และ Promotion
  • Flash Sale
  • Bundle และ Set Promotion
  • Product Review และ Rating
  • Wishlist และ Membership
  • Shipping Options และ Payment Methods
  • Cookie Consent สำหรับ PDPA

ส่วน Checkout ผมให้ความสำคัญกับรายละเอียดที่เกี่ยวข้องกับผู้ใช้ในไทยด้วย เช่น การกรอกที่อยู่ การเลือกวิธีจัดส่ง และการขอใบกำกับภาษี

ผมไม่อยากให้เว็บไซต์มีแค่หน้าจอให้ดู แต่ต้องมี Flow ให้ลองกดไปจนถึงขั้นตอนต่าง ๆ ได้ด้วย

จาก Figma ไปเป็นเว็บไซต์ ต้องเริ่มอย่างไร?

ผมไม่ได้เริ่มด้วยการสั่งให้ AI สร้างเว็บไซต์ทั้งหมดในครั้งเดียว

ตอนแรกผมใช้วิธีค่อย ๆ ทำทีละหน้า โดยเริ่มจากหน้า Home ก่อน แล้วค่อยไปยังหน้า Product Detail, Cart และ Checkout

สิ่งที่ผมต้องทำคือเตรียม Reference ให้ AI ดูว่าแต่ละหน้าควรหน้าตาอย่างไร และบอกว่าต้องการให้ส่วนต่าง ๆ ทำงานแบบไหน

ตัวอย่างเช่น ถ้าผมอยากให้ Product Card กดเข้า Product Detail ได้ ผมไม่ได้ต้องการแค่ให้ AI ทำหน้าตาของ Card ให้เหมือน Figma แต่ต้องให้มันเชื่อมข้อมูลสินค้าไปยังหน้ารายละเอียดสินค้าด้วย

หรือถ้าเป็น Banner ผมไม่ได้ต้องการแค่รูปภาพนิ่ง แต่ต้องรองรับหลาย Artwork และเลื่อนเปลี่ยนภาพได้จริง

พอทำไปหลายหน้า ผมเริ่มเห็นว่าการเขียน Prompt สั้น ๆ บางครั้งไม่พอ เพราะ AI อาจเข้าใจสิ่งที่เราต้องการไม่ครบ

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

ตัวอย่าง: จาก Banner รูปนิ่ง ให้กลายเป็น Carousel ที่ใช้งานได้จริง

หน้า Home ของต้นแบบ ต่อจาก Hero Banner มีการ์ดสินค้าและ Flash Sale

ตอนทำ Hero Banner ผมพบว่าการบอกให้ AI ทำ Banner ให้เลื่อนได้อย่างเดียวไม่พอ เพราะยังมีรายละเอียดอื่นที่ต้องคิดต่อ

  • ต้องใช้ Artwork จาก Figma จริง ไม่ใช่รูปที่ AI สร้างขึ้นเอง
  • ต้องรองรับหลายภาพ
  • Desktop, Tablet และ Mobile ต้องแสดงผลเหมาะกับแต่ละขนาด
  • Mobile ต้อง Swipe ได้
  • ปุ่ม Previous / Next และ Pagination ต้องทำงานจริง
  • การเลื่อนภาพต้องไม่กระทบ Header หรือส่วนอื่นของหน้า Home

ผมเลยเขียน Prompt ให้ครอบคลุมทั้งการทำงานของ Carousel, Responsive Behavior, Transition, Accessibility และ Final QA

prompt.mdตัวอย่าง Prompt ที่ใช้กับ Hero Banner
แก้ไข Hero Banner / Main Banner ของหน้า Home เดิมเท่านั้น ห้าม rebuild หน้าใหม่ และห้ามกระทบส่วนอื่นที่ทำงานอยู่แล้ว1. การทำงานของ Bannerต้องทำให้ Banner เลื่อนซ้าย–ขวาได้จริงHero Banner ต้องทำงานเป็น Carousel / Slider ที่สามารถเปลี่ยน Artwork ได้หลายรูปรองรับการเปลี่ยน Slide ด้วย:* ปุ่ม Previous / Next* Pagination Dots* Swipe ซ้าย / ขวาบน Mobile และ Touch Device* Drag ซ้าย / ขวาบน Desktop ถ้าเหมาะสม* Keyboard Arrow Left / Right เมื่อ Banner อยู่ใน focusการเปลี่ยน Slide ต้องเปลี่ยน Artwork จริง ไม่ใช่แค่เปลี่ยน active dot2. ใช้ Artwork จริงจาก Figmaใช้ image assets จริงที่มีอยู่ในโปรเจกต์/Figmaห้ามใช้ placeholder หรือสร้าง artwork ขึ้นมาใหม่Banner ให้ถือเป็น Artwork / Media Asset เดียว เพราะ artwork อาจมีทั้งรูปภาพและข้อความอยู่ใน asset เดียวกันห้ามแยก text ออกจาก artwork แล้วสร้าง HTML text ทับเอง เว้นแต่มี mobile-specific artwork ใน Figma อยู่แล้ว3. Responsive BehaviorDesktop* แสดง Banner ตามสัดส่วนและ layout ของ Figma* มี Previous / Next เมื่อเหมาะสม* Pagination dots อยู่ตำแหน่งตาม design* รองรับ mouse interactionTablet* ปรับขนาด Banner ตามพื้นที่* ยังคงสามารถเลื่อนซ้าย / ขวาได้* ปุ่มควบคุมต้องกดง่ายMobile* ต้องรองรับ Swipe ซ้าย / ขวาเป็นหลัก* Touch interaction ต้องลื่น* ไม่บังคับให้ user ต้องกดลูกศรเล็ก ๆ* Pagination dots ต้องยังมองเห็นและกดได้* ห้าม crop artwork จนข้อความหรือเนื้อหาสำคัญถูกตัด4. Slide Transitionใช้ transition ที่เรียบและ premium เช่น:* 200–400ms* ease-out / ease-in-out* ไม่ต้องใส่ animation เยอะเกินไปถ้ามีการ swipe ให้รู้สึกต่อเนื่องกับ gesture ของ userรองรับ prefers-reduced-motionถ้า user เปิด Reduced Motion ให้ลด/ปิด transition ที่ไม่จำเป็น5. Auto Playถ้า Banner ใน Figma/UX เหมาะสม ให้รองรับ Auto Play* เปลี่ยน Slide อัตโนมัติทุกประมาณ 4–5 วินาที* เมื่อ user interaction กับ Banner ให้ reset timer* เมื่อ hover บน Desktop ให้ pause* เมื่อ user swipe/click ให้ pause ชั่วคราวแล้วเริ่มใหม่* ห้าม autoplay ถ้า prefers-reduced-motion: reduceถ้า Banner มีเพียง 1 Artwork ให้ไม่ต้องทำ autoplay หรือ navigation6. Navigation Stateต้องมี state ที่ชัดเจน:* Active Slide* Previous Slide* Next Slide* First Slide → Previous ไป Last Slide ได้* Last Slide → Next ไป First Slide ได้Pagination:● ○ ○ ○ต้องเปลี่ยนตาม Slide จริง7. AccessibilityCarousel ต้องสามารถใช้งานด้วย Keyboard ได้เพิ่ม:* aria-label ให้ Previous / Next* aria-current ให้ active pagination* accessible label สำหรับแต่ละ slide* keyboard navigation* visible focus state* touch target อย่างน้อย 44×44pxถ้า autoplay ทำงาน ต้องไม่ทำให้ accessibility แย่ลง8. Prevent Interaction Bugsตรวจสอบเป็นพิเศษ:* Swipe แล้วหน้าเว็บต้องไม่เลื่อนผิดทิศทาง* Swipe แนวนอนต้องไม่ทำให้เกิด horizontal overflow ของทั้งหน้า* กด Next/Previous รัว ๆ แล้ว state ต้องไม่พัง* Dot กดแล้วต้องไป Slide ที่ถูกต้อง* Auto Play ต้องไม่ชนกับ manual navigation* Resize browser แล้ว Carousel ต้องยังทำงาน* Mobile Safari / Chrome Mobile ต้องใช้งานได้* รูปต้องไม่กระพริบระหว่างเปลี่ยน Slide9. ห้ามกระทบ Header และส่วนอื่นก่อนแก้ ตรวจสอบว่า Home ตอนนี้มี:Promo Strip→ Utility Bar→ Main Header→ Category Navigation→ Hero Bannerห้ามลบ Promo Strip ที่เพิ่ง restore กลับมาห้ามทำให้ Sticky Header / Dynamic Header behavior เสียหายห้ามแก้ Product Card, Product Grid หรือ section อื่นโดยไม่จำเป็น10. Code Structureถ้ามี Carousel component อยู่แล้ว ให้แก้ component เดิมและ reuseถ้ายังไม่มี ให้สร้าง reusable component เช่น:ArtworkCarouselโดยรองรับ:* images* optional video* autoplay* navigation* pagination* swipe* responsive behaviorอย่า hardcode logic เฉพาะกับ Banner จน reuse ไม่ได้11. Final QAหลังแก้เสร็จ ให้ทดสอบจริงที่:* 375px* 390px* 430px* 768px* 834px* 1024px* 1280px* 1440px* 1920pxตรวจสอบ:1. Banner เลื่อนซ้ายได้2. Banner เลื่อนขวาได้3. Next / Previous ทำงาน4. Pagination ทำงาน5. Swipe Mobile ทำงาน6. Artwork เปลี่ยนจริง7. Auto Play ทำงานถ้าเปิดใช้8. ไม่มี horizontal overflow9. ไม่มี layout jump10. Header / Promo Strip ยังอยู่ครบ11. ไม่มี console errorสุดท้ายสรุปให้ผมสั้น ๆ ว่า:* แก้อะไร* Carousel ใช้ interaction อะไรบ้าง* ใช้ Artwork asset ตัวไหน* รองรับ Responsive ถึงระดับไหน* มี issue ที่ยังเหลือหรือไม่

พอเขียน Prompt แบบนี้ ผมเริ่มเห็นว่าการสั่ง AI ทำงานก็คล้ายกับการส่งงานให้ Developer มากขึ้น เราต้องบอกให้ชัดว่าต้องการอะไร และต้องเช็กอะไรบ้าง ไม่อย่างนั้น AI อาจทำแค่ส่วนที่เราบอก แต่ไม่ได้คิดถึงสิ่งที่เกี่ยวข้องกับมัน

ปัญหาที่เจอ ไม่ได้มีแค่เรื่องหน้าตา

บางครั้งแก้จุดหนึ่ง แต่ส่วนอื่นกลับเปลี่ยนตามไปด้วย

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

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

ผมเลยเปลี่ยนวิธีจากการสั่งแก้ทันที มาเป็นให้ AI ตรวจสอบก่อน

คำสั่งที่ใช้บ่อยคือ

Audit only, change nothing

ผมให้ AI ตรวจสอบ Code และรายงานกลับมาก่อน โดยยังไม่ต้องแก้อะไร จากนั้นผมจะอ่านผลที่ได้ แล้วค่อยตัดสินใจว่าจะให้แก้ตรงไหน

วิธีนี้ทำให้ผมเห็นภาพก่อนว่าปัญหาเกิดจากอะไร และส่วนไหนอาจได้รับผลกระทบ

อีกเรื่องที่ต้องคิดคือ ทำอย่างไรไม่ให้ AI ทำงานเกินขอบเขต

ผมเริ่มเขียน Prompt ให้ระบุชัดขึ้นว่า

  • Scope: ให้แก้เฉพาะส่วนที่ต้องการ
  • Reference: ต้องอ้างอิง Design หรือข้อมูลจากที่ไหน
  • Constraints: ส่วนไหนห้ามแก้หรือห้ามเปลี่ยน
  • Acceptance Criteria: ทำเสร็จแล้วต้องทดสอบอะไรบ้าง

พอทำแบบนี้ไปเรื่อย ๆ ผมก็เริ่มมี Prompt ที่ใช้เป็นแนวทางสำหรับงานแต่ละประเภท ไม่ต้องเริ่มคิดใหม่ทุกครั้ง

จากการแก้ซ้ำ ๆ กลายเป็นกฎของทั้งเว็บไซต์

ผมเริ่มให้ AI จำสิ่งที่เคยแก้ไว้

พอเว็บไซต์มีหลายหน้า รายละเอียดเล็ก ๆ ที่ต้องคอยบอกซ้ำก็เริ่มเยอะขึ้น

อย่าง Font Weight ของปุ่ม บางหน้าก็ใช้ไม่เหมือนกัน ไอคอนลูกศรก็มีหลายแบบ หรือระยะห่างก่อนถึง Footer ก็ไม่เท่ากัน

ผมเลยเริ่มให้ AI เก็บสิ่งที่แก้ไว้เป็นกฎกลาง หรือ DSL เพื่อให้เวลาทำหน้าใหม่หรือแก้ Component อื่น ยังใช้รูปแบบเดียวกัน

สุดท้ายผมมีกฎทั้งหมด 12 ข้อที่ใช้เป็น Reference ระหว่างทำงาน

12 กฎที่ผมให้ AI ใช้กับเว็บไซต์

  1. 012 Oct 2026

    Button Font Weight

    ผมเห็นว่าปุ่มในแต่ละหน้ามีน้ำหนักตัวอักษรไม่เท่ากัน เลยกำหนดให้ใช้ Medium เหมือนกันทั้งหมด

    ตัวอักษรที่อยู่ในปุ่ม ให้ใช้น้ำหนักฟอนต์เป็น mediem ให้หมด เช็คทั้ง site และปรับเลย และยึดเป็น DSL
  2. 023 Oct 2026

    Arrow Icon

    ผมอยากให้ลูกศรซ้ายและขวาใช้รูปแบบเดียวกันทั้งเว็บ โดยอ้างอิงจาก Chevron ในส่วน FAQ ขนาด 24px

    ปรับไอคอนลูกศร < > ทั้งเว็บไซต์ ให้ใช้แบบเดียวกับลูกศรที่ section คำถามที่พบบ่อย (24px) และยึดลูกศรนี้เป็น DSL
  3. 034 Oct 2026

    ใช้ Design ปัจจุบันเป็นมาตรฐาน

    หลังจากปรับ Font, Modal และ Layout จนลงตัว ผมให้ AI ใช้ Design ที่ทำไว้เป็น Reference สำหรับงานต่อจากนี้

    ตอนนี้ภาพรวมเรื่องฟอนต์, modal และการจัดวาง layout ลงตัวแล้ว ขอให้ใช้ดีไซน์นี้ยึดเป็น DSL ในทุกจุดที่จะเกิดขึ้นหลังจากนี้
  4. 044 Oct 2026

    Add to Cart Button

    ปุ่มเพิ่มลงตะกร้ามีอยู่หลายหน้า ผมเลยกำหนดให้ทุกหน้าต้องใช้รูปแบบเดียวกัน รวมถึง Icon ด้วย

    ยังต้องการให้ทุกปุ่มที่มีคำว่า เพิ่มลงตะกร้าใช้เหมือนกันทุกที่ ทุกหน้าจอ พร้อมไอคอน
  5. 054 Oct 2026

    Mobile Spacing

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

    ระยะห่างระหว่างการ์ดสินค้า กับ ปุ่ม โดยตัดไป เช็คทุกครั้งหากทำเสร็จ ต้องเก็บรายละเอียดพวกนี้ดีๆ
  6. 065 Oct 2026

    Footer Spacing

    ผมเลือกหน้าที่จัดวางลงตัวแล้วมาเป็นมาตรฐาน โดยให้ Content สุดท้ายของทุกหน้าห่างจาก Footer 24px

    จำระยะห่างระหว่าง content สุดท้ายขอจอกับ footer ที่หน้านี้ไว้ และปรับทุกหน้าในเว็บไซต์ให้เท่ากับหน้านี้ และบันทึกเป็น DSL
  7. 075 Oct 2026

    Check Icon

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

    เครื่องหมาย Check ถูกใช้แบบเดียวกับใน DSL
  8. 087 Oct 2026

    Close Icon และ Shopping Bag

    ผมกำหนดให้เครื่องหมาย X ใช้แบบเดียวกับ Modal Popup หน้าแรก และเปลี่ยนไอคอนรถเข็นทั้งหมดให้เป็นถุงช้อปปิ้ง

    เครื่องหมาย x ต้องใช้ให้เหมือนกันทั้งเว็บไซต์ ยึด x ที่ modal popup หน้าแรกคือ ไฟล์ที่ถูกต้อง
เปลี่ยนไอคอนรถเข็น เป็นถุงช้อปปิ้ง ทุกจุด
  9. 098 Oct 2026

    ข้อความที่ไม่ดูเหมือน AI

    ผมยังเจอเครื่องหมายขีดยาว (—) อยู่ในระบบหลังบ้าน ทั้งที่ไม่ต้องการให้มี เลยกำหนดให้เอาออก รวมถึงไม่ใช้ลูกศรและ Emoji ในข้อความด้วย

    ใน admin ผมยังพบเครื่องหมาย — เอาออกให้หมด และยึดนี้เป็นกฎ ห้ามใส่ข้อความที่ดูเหมือน AI สร้าง
  10. 108 Oct 2026

    Backend ต้องสอดคล้องกับ Frontend

    ผมอยากให้ระบบหลังบ้านมีเฉพาะข้อมูลที่หน้าร้านนำไปใช้จริง ไม่ต้องมีเมนูหรือข้อมูลที่ไม่เกี่ยวข้องเพิ่มขึ้นมา

    อะไรที่คิดว่าหน้าบ้านไม่มี ไม่จำเป็นต้องแสดง หรือไม่เกี่ยวข้องกัน ให้ตัดข้อมูลจากหลังบ้านออกได้เลย
  11. 1111 Oct 2026

    Draft ก่อน Publish

    ผมไม่อยากให้ข้อมูลใหม่ถูก Publish ทันทีที่เพิ่ม เลยกำหนดให้เริ่มจาก Draft ก่อน แล้วค่อยเลือก Save Draft หรือ Save and Publish ส่วน Switch สำหรับเปิดและปิดจะแสดงหลังจาก Publish ครั้งแรกแล้วเท่านั้น

    การบันทึกร่างหรือปิดเปิดสวิตซ์ อยากให้ใช้กฎเดียวทั้งเว็บ ว่าจะใช้แบบปิดเปิดสวิตตอนเพิ่ม หรือแบบร่างก่อน ผมมองว่าควรใช้แบบร่างครับ
  12. 1228 Oct 2026

    QA Report

    เวลาส่งปัญหาให้ Developer ผมอยากให้เขาอ่านแล้วเข้าใจเลย ไม่ต้องเดาเอง เลยกำหนดให้เขียนสั้น ๆ พร้อมบอกวิธีแก้ที่ชัดเจน เช่น ขนาด Font หรือ Hex Code ของสี

    บอกปัญหาทีเจอสั้นๆ แต่ได้ใจความ แล้วบอกสิ่งที่ต้องแก้ เช่น "ตัวอักษรชื่อสินค้าเล็กกว่าต้นฉบับ แก้เป็น 18px" หรือ "สีไม่เหมือนต้นฉบับ แก้เป็น #ffffff"

แล้วระบบหลังบ้านล่ะ?

ยิ่งทำหน้าร้านมากขึ้น ผมยิ่งเห็นว่าต้องคิดเรื่องหลังบ้านตามไปด้วย

ตอนที่เริ่มทำ Backend UI Prototype ผมพบว่ามีหลายอย่างที่ต้องกลับมาคิดใหม่ เพราะหน้าร้านกับหลังบ้านไม่สามารถแยกกันคิดได้ทั้งหมด

ตัวอย่างเช่น ถ้าหน้าร้านมี Promotion เราก็ต้องคิดต่อว่าทีมจะสร้างและจัดการ Promotion จากตรงไหน ถ้ามี Banner หลายชุด ระบบหลังบ้านก็ควรจัดการ Artwork เหล่านั้นได้ด้วย

ผมเริ่มเห็นเมนูบางส่วนที่ทำหน้าที่ใกล้เคียงกัน เช่น Promotions, Campaigns, Collections และ Banners เลยไม่อยากรีบเพิ่ม Feature ต่อโดยยังไม่เข้าใจโครงสร้างทั้งหมด

ผมให้ AI ช่วยตรวจสอบระบบหลังบ้านก่อนว่าแต่ละเมนูทำหน้าที่อะไร ใช้ข้อมูลจากไหน และมีข้อมูลซ้ำกันหรือเปล่า

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

ตัวอย่างการตัดสินใจ: Draft ก่อน Publish

ผมไม่อยากให้ข้อมูลที่เพิ่มเข้ามาใหม่ถูกแสดงบนหน้าร้านทันที เพราะบางครั้งทีมอาจยังต้องกลับมาแก้ไขก่อน

ผมเลยกำหนดให้ข้อมูลเริ่มจาก Draft ก่อน แล้วค่อยเลือกว่าจะ Save Draft หรือ Save and Publish

ส่วน Switch สำหรับเปิดและปิดสถานะ จะปรากฏหลังจาก Publish ครั้งแรกแล้ว

รายละเอียดแบบนี้อาจดูเป็นเรื่องเล็ก แต่มีผลกับวิธีทำงานของทีมที่ต้องเข้ามาจัดการข้อมูลในระบบจริง

พอเว็บไซต์เริ่มครบ ผมก็ต้องกลับมาเป็น QA ด้วย

หน้าตาเหมือนแล้ว แต่ต้องลองกดด้วยถึงจะรู้ว่าผ่านหรือยัง

เมื่อ Prototype เริ่มมี Flow หลักครบ ผมก็เริ่มใช้มันเป็น Reference สำหรับตรวจสอบเว็บไซต์ที่ Developer พัฒนาขึ้น

ผมไม่ได้ดูแค่ภาพรวมว่าหน้าเว็บสวยหรือไม่ แต่ลองกดใช้งานทีละขั้นตอนด้วย

เช่น หน้า Cart เพิ่มและลบสินค้าได้ถูกต้องไหม Product Detail แสดงข้อมูลและตัวเลือกครบหรือเปล่า หรือ Checkout มีจุดไหนที่ User กรอกข้อมูลแล้วไปต่อไม่ได้

ช่วงนี้ผมใช้ Claude in Chrome ช่วยเปิดเว็บไซต์และลองทำงานผ่าน Browser รวมถึงช่วยเก็บภาพหน้าจอของจุดที่พบปัญหา

ผมรวบรวมปัญหาทั้งหมดไว้ใน Google Sheets

หน้า Cart ของทีม Developer ที่เก็บไว้ในรายงาน QA
งานของทีม Developer
หน้า Cart ของต้นแบบที่ใช้เป็น Reference
Reference จากต้นแบบ

ผมแยกปัญหาตามแต่ละส่วนของเว็บไซต์ รวมแล้วมีมากกว่า 100 Issues ใน 7 Tabs

แต่ละรายการจะมีรายละเอียดว่าพบปัญหาตรงไหน ควรแก้อะไร และมีภาพ Reference ให้ดูประกอบ

ผมพยายามเขียนให้สั้นและชัดที่สุด เพราะไม่อยากให้ Developer ต้องมานั่งเดาว่าผมต้องการให้แก้แบบไหน

ตัวอย่างเช่น

  • ตัวอักษรชื่อสินค้าเล็กกว่าต้นฉบับ แก้เป็น 18px
  • สีไม่เหมือนต้นฉบับ แก้เป็น #ffffff

ถ้าเป็นเรื่อง Layout หรือ Component ผมก็จะใส่ภาพเปรียบเทียบให้เห็นว่าจุดที่ทำอยู่ต่างจาก Reference อย่างไร

สิ่งที่ต้องเช็กบน Mobile ก็มีรายละเอียดของมันเอง

บางครั้งเปิดบน Desktop แล้วดูไม่มีปัญหา แต่พอเปิดบน iPhone กลับพบว่าปุ่มอยู่ชิดกันเกินไป ข้อความแสดงผลไม่เหมือนเดิม หรือบาง Component ใช้งานยากกว่าที่คิด

ผมเลยกลับมาเช็กบน iPhone และ iOS Simulator อยู่เรื่อย ๆ โดยมีการทดสอบทั้งหมด 92 Simulator Checks

ตรงนี้เป็นเหตุผลที่ผมไม่อยากให้การ QA จบแค่การดู Screenshot เพราะบางอย่างต้องลองกดจริงถึงจะเห็นปัญหา

หน้า Home พร้อมการ์ดสินค้าและ Flash Sale หน้า Product Detail พร้อม Gallery Checkout แบบหน้าเดียว พร้อมวิธีจัดส่งและชำระเงิน Popup สมัครสมาชิก แถบ Cookie Consent สำหรับ PDPA

เครื่องมือที่ใช้ในโปรเจกต์นี้

แต่ละเครื่องมือมีหน้าที่ต่างกัน

ระหว่างทำงาน ผมใช้เครื่องมือหลายตัว แต่ไม่ได้ใช้ทุกตัวทำงานเหมือนกันทั้งหมด

Claude Code

เป็นเครื่องมือหลักที่ใช้ทำเว็บไซต์ ตั้งแต่สร้างหน้าและ Component ไปจนถึงแก้ไข Code และตรวจสอบโครงสร้างของโปรเจกต์

573 Prompts · 15 Working Sessions

ChatGPT

ใช้ช่วยคิดและเตรียมรายละเอียดก่อนเริ่มงาน เช่น จัด Requirement และเขียน Brief ให้ชัดขึ้น ก่อนนำไปใช้กับ Claude Code

Claude in Chrome

ใช้เปิดเว็บไซต์ผ่าน Browser และลองกดใช้งานเหมือน User จริง รวมถึงช่วยตรวจสอบและเก็บภาพหน้าจอ

1,159 Browser Actions

Figma

เป็น Reference หลักของ Design ใช้ระบุหน้าจอและรายละเอียดที่ต้องการให้ AI นำไปพัฒนา

69 Prompts

Vercel

ใช้ Deploy เว็บไซต์ขึ้นออนไลน์ เพื่อให้ทีมเปิด Prototype เวอร์ชันล่าสุดได้จากลิงก์เดิม

61 Prompts สำหรับ Commit และ Deploy

GitHub

ใช้เก็บ Source Code ของเว็บไซต์ รวมถึง Component, Design Tokens และ Mock Data เพื่อให้ Developer เปิดดูและนำไปทำต่อได้

39 Commits

Google Sheets

ใช้รวบรวมปัญหาที่เจอระหว่าง QA พร้อมรายละเอียดและภาพ Reference

100+ Issues · 7 Tabs

iOS Simulator และ iPhone

ใช้ทดสอบการแสดงผลและการใช้งานบน Mobile

92 Simulator Checks

Tech Stack

SolidJS · SolidStart Tailwind CSS daisyUI

จาก Designer ที่ส่งงานให้ Developer สู่ Designer ที่ลองทำ Prototype เอง

สิ่งที่เปลี่ยนไป ไม่ได้มีแค่เครื่องมือที่ใช้

หลังจากทำโปรเจกต์นี้ ผมเริ่มเห็นว่างานของตัวเองเปลี่ยนไปหลายอย่าง

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

ผมได้เห็นว่า Design ที่ทำไว้จะถูกนำไปใช้จริงอย่างไร และมีรายละเอียดอะไรที่อาจมองไม่เห็นจาก Figma

เมื่อก่อนผมต้องทำหน้าจอหลาย State แต่ครั้งนี้ผมเริ่มเขียน Spec ให้ AI ทำตาม

อย่าง State ของสินค้า การแสดง Popup หรือเงื่อนไขการทำงานของปุ่มต่าง ๆ ผมสามารถอธิบายเป็น Requirement แล้วให้ AI ช่วยพัฒนาต่อได้

เมื่อก่อนเจอปัญหาก็แก้ทีละหน้า แต่ครั้งนี้ผมเริ่มคิดถึงกฎของทั้งเว็บไซต์

พอพบว่า Component หรือ Design บางอย่างไม่เหมือนกัน ผมไม่ได้มองแค่หน้าที่กำลังทำ แต่กลับมาดูว่ามีส่วนอื่นที่ใช้ Component เดียวกันอยู่หรือไม่

จากที่เคยดูแค่หน้าตา ผมต้องคิดเรื่อง Product และ Backend มากขึ้น

อย่างการจัดเมนูหลังบ้าน การกำหนดแหล่งข้อมูลหลัก หรือการเลือกว่าจะให้ข้อมูลเริ่มจาก Draft ก่อน Publish หรือไม่ เรื่องเหล่านี้เป็นการตัดสินใจที่เกี่ยวข้องกับการทำงานของระบบด้วย

และจากการจับภาพส่ง Comment ผมได้ลองใช้ AI ช่วยทำ QA

ผมสามารถให้ AI ช่วยเปรียบเทียบหน้าจอและรวบรวมปัญหาได้ แต่ยังต้องกลับมาตรวจสอบเองว่าปัญหาที่เจอถูกต้องหรือไม่ และควรแก้แบบไหน

ผลลัพธ์ที่ได้จากการลองทำครั้งนี้

จาก Figma ที่ออกแบบไว้ กลายเป็น Prototype ที่ทีมเปิดเข้ามาลองได้

หลังจากทำงานต่อเนื่อง เว็บไซต์ต้นแบบก็มีทั้งหน้าร้านและหน้าตาของระบบหลังบ้าน โดยมีรายละเอียดหลัก ๆ ดังนี้

  • Customer-facing Website สำหรับทดลอง Flow การเลือกสินค้าและสั่งซื้อ
  • Product Detail ที่มี Gallery และเนื้อหาประกอบสินค้า
  • Cart และ Checkout
  • Promotion, Coupon และ Flash Sale
  • Membership และ Customer Experience Features
  • Backend UI Prototype
  • Responsive Layout สำหรับ Desktop, Tablet และ Mobile
  • Mock Data สำหรับแสดงข้อมูลใน Prototype
  • Source Code ที่เก็บไว้ใน GitHub
  • QA Report สำหรับส่งต่อให้ Developer

เว็บไซต์ถูก Deploy ผ่าน Vercel ทำให้ทีมเปิดดู Prototype ได้จากลิงก์เดิม ส่วน Code ก็อยู่ใน GitHub เพื่อให้ Developer สามารถเปิดดูและนำไปศึกษาต่อได้

Checkout พร้อมตัวเลือก DHL, Flash Express, Kerry Express และ EMS หน้า Product Detail พร้อมปุ่มเพิ่มลงตะกร้า

ตัวเลขจากการทำงาน

รายการจำนวน
Prompts573
Working Sessions15
Browser Actions1,159
Figma Prompts69
Vercel Prompts61
GitHub Commits39
Design System Rules12
QA Issues100+
Google Sheets Tabs7
Simulator Checks92

ตัวเลขเหล่านี้ช่วยให้เห็นภาพว่าระหว่างทำ Prototype มีงานที่ต้องตรวจสอบและปรับแก้มากกว่าการสร้างหน้าเว็บเพียงอย่างเดียว

สิ่งที่ผมได้จากโปรเจกต์นี้

AI ช่วยให้ผมลงมือทำได้มากขึ้น แต่ไม่ได้ตัดสินใจแทนผม

ก่อนหน้านี้ผมคุ้นเคยกับการออกแบบใน Figma แล้วส่งต่อให้ Developer เป็นหลัก แต่ครั้งนี้ผมได้ลองทำต่อไปจนถึงขั้นพัฒนาเว็บไซต์และทดสอบการใช้งานด้วยตัวเอง

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

แต่ก็ไม่ได้หมายความว่าใช้ AI แล้วทุกอย่างจะถูกต้องไปหมดครับ

บางครั้งมันทำออกมาไม่ตรงกับที่คิด แก้จุดหนึ่งแล้วไปกระทบอีกจุดหนึ่ง หรือบางอย่างดูเหมือนเสร็จแล้วแต่พอลองกดจริงกลับมีปัญหา

ผมยังต้องคอยดู คอยเช็ก และตัดสินใจอยู่ตลอด

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

ถ้ามีโอกาสทำต่อ ผมอยากเอากฎทั้ง 12 ข้อที่เก็บไว้ มาจัดเป็น Design System ที่ Developer เปิดอ่านและนำไปใช้ได้ด้วย รวมถึงทำ Prompt Template สำหรับ Audit, Build และ QA เพื่อให้การทำงานครั้งต่อไปไม่ต้องเริ่มเขียนคำสั่งใหม่ทั้งหมด

อีกอย่างที่อยากลองคือการใช้ AI ช่วยตรวจ QA ทุกครั้งที่มี Release ใหม่ จะได้เจอปัญหาเร็วขึ้น ไม่ต้องรอจนจบโปรเจกต์แล้วค่อยกลับมาตรวจทีเดียว

สำหรับผม โปรเจกต์นี้ไม่ได้ทำให้รู้สึกว่า AI จะเข้ามาแทน Designer ได้ แต่ทำให้เห็นว่า Designer สามารถลงมือทำอะไรได้มากกว่าเดิม

จากที่เคยออกแบบแล้วส่งต่อ ผมได้ลองทำ Prototype เอง ลองตรวจสอบระบบ และเข้าไปดูรายละเอียดที่เมื่อก่อนอาจไม่ได้มีโอกาสลงไปทำมากขนาดนี้

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

และนั่นเป็นสิ่งที่ผมได้จากการลองทำ Charmiss E-commerce ในครั้งนี้ครับ

Next case study

KEX Mobile App Revamp

Revamped Kerry Express app screens

Get in touch

Let's talk

Resume LinkedIn
thanakrit_soou_@hotmail.com