---
title: "Vibe แอปเสร็จแล้ว ผู้ใช้จะติดตรงไหน? ลอง Persona Review ด้วย Claude Code"
description: "ให้ AI subagent สวมบทผู้ใช้ เปิดแอปจริงผ่าน Playwright MCP แล้วรายงานจุดที่ติดขัดพร้อม screenshot มีตัวอย่างจากการทดสอบบทความนี้เอง brief ที่ copy ไปใช้ได้ ค่าใช้จ่ายต่อรอบ และควรรันบน Dev, UAT หรือ Prod"
canonical_url: "https://iamthana.com/blogs/2026-11-11-persona-review-subagents"
---

> Index of every page on this site: [llms.txt](https://iamthana.com/llms.txt)

ทำแอปเสร็จ vibe มาหมาด ๆ คำถามต่อมาคือ ถ้ามีคนเอาไปใช้จริง เขาจะมี feedback อะไรบ้าง?

ตอนเรียนวิชา UX/UI อาจารย์ให้ทำ **Persona Review** เป็นขั้นตอนหนึ่งสำหรับเก็บ feedback ผมเลยเอาวิธีนี้มาปรับใช้กับ AI ครับ ให้ subagent สวมบทเป็นผู้ใช้ แล้วเปิด browser เข้าไปทำงานในแอป โดยบอกแค่ว่าอยากทำอะไรให้สำเร็จ จากนั้นดูว่ามันไปต่อได้ไหม ติดตรงไหน และมีอะไรที่เราควรกลับมาตรวจสอบ

ถ้าเป็นงานจริง ควรเก็บ feedback จากผู้ใช้ตั้งแต่ตอนวาง UX/UI เลยนะครับ แต่รอบนี้ทำแบบรีบ ๆ เลยขอ shortcut หน่อย ทำแอปออกมาก่อน แล้วค่อยทำ persona review ทีหลัง ฮ่า ๆ

## Persona Review ทำอย่างไร

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

จากนั้นให้ agent เปิดแอปผ่าน browser แล้วลองทำงานตามโจทย์ พร้อมบันทึกสิ่งที่เห็นและจุดที่ติดขัด

ภาพรวมของทั้งรอบเป็นแบบนี้ครับ เราเขียน brief ให้ persona ทีละคน แต่ละคนคุม browser ผ่าน Playwright MCP เข้าไปใช้แอปที่รันอยู่ แล้วส่งรายงานพร้อม screenshot กับคลิปกลับมาให้เราลองทำซ้ำ

![Flow ของ Persona Review: เรากับ Claude Code ส่ง brief ให้ persona แต่ละคน persona ใช้ Playwright MCP คุม browser เข้าไปใช้แอป แล้วส่งรายงานกลับมา](https://iamthana.com/images/2026-11-11-persona-review-subagents/persona-review-flow.png)

ตัวอย่างโจทย์ง่าย ๆ คือ

> คุณต้องการสร้างกิจกรรมสำหรับสัปดาห์หน้า ตรวจสอบว่าวันเวลาถูกต้อง แล้วเปลี่ยนสถานที่จัดงาน

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

<note>

ต้องเตรียม 3 อย่าง: **Claude Code** (ใช้ผ่าน terminal), **Playwright MCP** สำหรับให้ agent คุม browser และแอปที่เปิดรันไว้ให้ทดสอบ ติดตั้ง Playwright MCP ด้วยคำสั่ง `claude mcp add playwright npx @playwright/mcp@latest` ถ้าอยากให้อัดคลิประหว่างทดสอบด้วย ใช้ `claude mcp add playwright -- npx @playwright/mcp@latest --caps=devtools` แทน

</note>

Playwright MCP อ่านข้อมูลหน้าเว็บผ่าน accessibility snapshot (โครงสร้างหน้าเว็บที่เป็นข้อความ ไม่ใช่ภาพ) ได้ด้วย จึงควรให้ agent เปิดดู screenshot ประกอบ โดยเฉพาะเวลารายงานเรื่องตำแหน่งปุ่ม ข้อความถูกตัด หรือสิ่งที่มองไม่เห็นในหน้าจอ [ดูรายละเอียด Playwright MCP](https://github.com/microsoft/playwright-mcp)

ตัวอย่างจากรอบที่ให้ persona อ่านบทความนี้ ฝั่งซ้ายคือ snapshot ที่ agent อ่านได้ ข้อความในกล่อง prompt ครบทุกตัวอักษร ฝั่งขวาคือสิ่งที่คนเห็นบนจอมือถือ บรรทัดยาวล้นขอบขวาจนต้องเลื่อนซ้ายขวา ถ้า agent อ่านแค่ snapshot จะไม่เห็นปัญหานี้เลย

![เทียบ accessibility snapshot ที่อ่านข้อความในกล่อง prompt ได้ครบ กับ screenshot มือถือที่บรรทัดล้นขอบขวา](https://iamthana.com/images/2026-11-11-persona-review-subagents/snapshot-vs-screenshot.png)

ภาพด้านล่างตัดมาจากคลิปตอนผมให้ persona นักศึกษาที่อ่านบนมือถือลองอ่านบทความนี้เอง agent ขึ้นป้ายงานข้อ 6 กางสารบัญ "ในหน้านี้" แล้วกดข้ามไปหัวข้ออื่น Playwright MCP อัดคลิปแบบนี้ได้ ถ้าเปิด capability `devtools` ไว้

![Persona บนมือถือ 400x850 กางสารบัญแล้วกดข้ามไปหัวข้อ "ให้เป้าหมาย พร้อมขอบเขตที่ชัดเจน"](https://iamthana.com/images/2026-11-11-persona-review-subagents/persona-mobile-toc.gif)

## เลือก persona จากลักษณะการใช้งาน

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

<table>
<thead>
  <tr>
    <th>
      Persona
    </th>
    
    <th>
      บริบท
    </th>
    
    <th>
      สิ่งที่อยากสังเกต
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ผู้ใช้ใหม่บน desktop
    </td>
    
    <td>
      ยังไม่รู้ว่าแต่ละเมนูทำอะไร อยากตรวจสอบก่อนบันทึก
    </td>
    
    <td>
      หาเมนูเจอไหม เข้าใจข้อความไหม รู้หรือยังว่าทำสำเร็จแล้ว
    </td>
  </tr>
  
  <tr>
    <td>
      ผู้ใช้ประจำบนมือถือ
    </td>
    
    <td>
      ทำงานเดิมบ่อย ๆ และอยากทำให้เสร็จเร็ว
    </td>
    
    <td>
      ต้องเลื่อนหรือแตะมากแค่ไหน เห็นผลหลังทำรายการหรือไม่
    </td>
  </tr>
</tbody>
</table>

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

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

## ให้เป้าหมาย พร้อมขอบเขตที่ชัดเจน

ก่อนเริ่ม ควรเตรียม URL บัญชีทดสอบ และข้อมูลตัวอย่างให้พร้อม แล้วกำหนดงานที่ครอบคลุมตั้งแต่เริ่มจนจบ เช่น

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

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

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

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

## ควรทดสอบบน Dev, UAT หรือ Prod?

เลือกจากสองเรื่องครับ ตอนนี้อยากรู้อะไร และ persona ต้องสร้างหรือแก้ข้อมูลในระบบหรือเปล่า

<table>
<thead>
  <tr>
    <th>
      Environment
    </th>
    
    <th>
      ใช้ตอนไหน
    </th>
    
    <th>
      ข้อดี
    </th>
    
    <th>
      ต้องระวัง
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Dev (local)
    </td>
    
    <td>
      หลังแก้หน้าจอเสร็จ ก่อนเปิด PR
    </td>
    
    <td>
      รอบสั้น เจอแล้วแก้ได้ทันที
    </td>
    
    <td>
      ข้อมูล seed ไม่เหมือนของจริง dev toolbar หรือ error overlay อาจบังหน้าจอ และบาง service ไม่ได้รัน
    </td>
  </tr>
  
  <tr>
    <td>
      UAT / Staging
    </td>
    
    <td>
      ก่อน release หรือก่อนส่งให้ลูกค้าดู
    </td>
    
    <td>
      build เดียวกับที่จะขึ้นจริง ข้อมูลและ config ใกล้ของจริง
    </td>
    
    <td>
      ต้องใช้บัญชีทดสอบ และต่อบริการภายนอกแบบ sandbox
    </td>
  </tr>
  
  <tr>
    <td>
      Prod
    </td>
    
    <td>
      หลัง deploy เพื่อเช็กว่างานหลักยังใช้ได้
    </td>
    
    <td>
      เห็นแบบเดียวกับที่ผู้ใช้เห็น
    </td>
    
    <td>
      ให้ดูกับอ่านได้อย่างเดียว ห้ามสร้างหรือแก้ข้อมูล และยอดเข้าชมของ persona จะไปปนกับตัวเลข analytics
    </td>
  </tr>
</tbody>
</table>

Dev เหมาะกับรอบเร็ว ๆ ระหว่างพัฒนา ส่วน UAT ให้ผลใกล้ผู้ใช้จริงที่สุดโดยไม่เสี่ยงกับข้อมูลจริง

รอบที่ให้ persona อ่านบทความนี้รันบน dev server ของบล็อก persona รายงานว่ามี error ใน console ด้วย แต่พอไล่ดู error พวกนั้นมาจาก view counter กับสคริปต์โฆษณาที่ไม่ได้รันบนเครื่อง dev ผู้อ่านจริงไม่เจอ ถ้ารายงานมีปัญหาที่น่าจะเกิดจาก dev ให้เช็กซ้ำบน build จริงก่อนลงมือแก้

## ตัวอย่าง Prompt สำหรับเริ่มลอง

ด้านล่างเป็น brief สำหรับส่งให้ subagent ส่วนที่อยู่ใน `<...>` ให้เปลี่ยนเป็นค่าของระบบเราก่อนใช้ครับ

```text [persona-brief.txt]
ให้คุณทดลองใช้แอปผ่าน Playwright MCP โดยสวมบทเป็นผู้ใช้ตามข้อมูลนี้

บทบาท
- เป็นผู้ใช้ใหม่ที่ยังไม่เคยเห็นแอปนี้
- ใช้งานเว็บทั่วไปได้ แต่ไม่รู้ศัพท์เทคนิคหรือโครงสร้างภายในระบบ
- ใช้ <desktop ขนาด 1440x900>
- ต้องการตรวจสอบข้อมูลให้แน่ใจก่อนบันทึก

สภาพแวดล้อม
- URL: <URL ของระบบทดสอบ>
- ใช้บัญชีทดสอบที่ login ไว้แล้ว ถ้าเจอหน้า login ให้หยุดและรายงาน
- ใช้เฉพาะข้อมูลสมมติ

งานที่ต้องทำ
1. หาว่าจะสร้างกิจกรรมใหม่ได้จากตรงไหน
2. สร้างกิจกรรมชื่อ “<ประชุมทีมตัวอย่าง>” สำหรับสัปดาห์หน้า
3. ตรวจสอบว่าชื่อและวันเวลาที่บันทึกตรงกับที่กรอก
4. เปลี่ยนสถานที่ แล้วตรวจสอบว่าข้อมูลใหม่ถูกบันทึกแล้ว
5. ลบกิจกรรมที่ตัวเองสร้างเมื่อทดสอบเสร็จ

กติกา
- ห้ามอ่าน source code หรือแก้ไฟล์ในโปรเจกต์
- ห้ามแก้ไขหรือลบข้อมูลที่มีอยู่ก่อนเริ่ม
- ห้ามส่งคำเชิญ ส่งข้อความ หรือเผยแพร่ข้อมูลออกไปภายนอก
- เปิดดู screenshot ประกอบการประเมินหน้าจอ
- อธิบายจุดที่ลังเลหรือไม่เข้าใจ โดยอ้างอิงสิ่งที่เห็น
- ถ้าทำต่อไม่ได้ ให้รายงานตรง ๆ ไม่ต้องฝืนทำให้สำเร็จ

รายงานกลับ
- แต่ละงานทำได้ ทำได้แต่ติดขัด หรือทำไม่ได้
- จุดที่ติดขัด: เห็นอะไร คาดว่าจะเกิดอะไร และอยู่ตรงไหน
- ถ้าพบ bug ให้ระบุขั้นตอน ข้อมูลที่กรอก และผลลัพธ์ที่เกิดขึ้น
- แนบชื่อ screenshot ที่เกี่ยวข้อง
- แยกสิ่งที่สังเกตได้ออกจากข้อสันนิษฐานเกี่ยวกับผู้ใช้
- ยืนยันว่าลบข้อมูลทดสอบของตัวเองแล้ว และไม่ได้เปลี่ยนข้อมูลเดิม
```

จากนั้นอาจลองอีก persona ที่ใช้มือถือและคุ้นเคยกับระบบมากกว่า โดยใช้เป้าหมายคล้ายกันเพื่อดูว่าขนาดหน้าจอและวิธีทำงานทำให้เจอปัญหาต่างกันหรือเปล่า

ถ้าใช้บ่อย ค่อยเก็บขั้นตอนเตรียมงานและ brief นี้ไว้เรียกซ้ำเป็น `/persona-review` ก็ได้ สำหรับ Claude Code เอกสารปัจจุบันแนะนำให้สร้างงานใหม่เป็น skill ส่วนไฟล์ใน `~/.claude/commands/` ยังใช้งานได้ [ดูเอกสาร Skills](https://code.claude.com/docs/en/skills)

## อ่านรายงานแล้วต้องลองทำซ้ำ

รายงานจาก persona เป็นจุดเริ่มต้นให้เราไปตรวจต่อครับ โดยเฉพาะข้อที่ระบุว่าเป็น bug ควรทำซ้ำด้วยขั้นตอนและค่าที่รายงานมาก่อนแก้โค้ด

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

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

รายงานที่ดูขัดกันก็มีประโยชน์เหมือนกัน เช่น persona หนึ่งบอกว่าหาปุ่ม Undo ไม่เจอ แต่อีกตัวเห็นและกดได้ อาจเป็นเพราะตำแหน่งปุ่มกับขนาดหน้าจอ ทำให้ตัวหนึ่งเห็นทันที ส่วนอีกตัวต้องเลื่อนลงไปก่อน ข้อนี้ต้องกลับไปดู screenshot และลองตามเส้นทางที่แต่ละตัวใช้

ตอนรวมผล ผมจะแยกเป็นสามกลุ่มเพื่อให้อ่านง่าย

<table>
<thead>
  <tr>
    <th>
      กลุ่ม
    </th>
    
    <th>
      ตัวอย่าง
    </th>
    
    <th>
      ขั้นตอนถัดไป
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      ผลลัพธ์ผิด
    </td>
    
    <td>
      บันทึกแล้วค่าเปลี่ยน หรือข้อมูลไม่ถูกเก็บ
    </td>
    
    <td>
      ทำซ้ำเพื่อยืนยัน แล้วเพิ่ม test ครอบคลุมเคสนั้น
    </td>
  </tr>
  
  <tr>
    <td>
      ใช้งานติดขัด
    </td>
    
    <td>
      ต้องเลื่อนกลับไปกลับมา หรือกดแล้วมองไม่เห็นผล
    </td>
    
    <td>
      ตรวจหน้าจอและเส้นทางการใช้งาน
    </td>
  </tr>
  
  <tr>
    <td>
      ข้อความไม่ชัด
    </td>
    
    <td>
      อ่านชื่อปุ่มแล้วไม่รู้ว่าจะเกิดอะไร
    </td>
    
    <td>
      ทบทวนถ้อยคำและตรวจความเข้าใจกับผู้ใช้
    </td>
  </tr>
</tbody>
</table>

## ข้อจำกัด

วิธีนี้เหมาะกับการหาประเด็นเบื้องต้น โดยเฉพาะหลังเพิ่มฟีเจอร์หรือเปลี่ยนหน้าจอ ก่อนจะส่งให้คนอื่นลองใช้ แต่มีข้อจำกัดอยู่หลายอย่างครับ

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

อีกอย่างคือ accessibility snapshot ช่วยให้ agent เข้าถึงข้อมูลที่คนทั่วไปต้องกวาดตาหาเอง การบังคับให้ดู screenshot ช่วยเพิ่มหลักฐานด้านภาพได้ แต่ไม่ได้ทำให้การทดสอบเหมือนคนใช้ browser ทุกอย่าง และการย่อ viewport เป็นมือถือก็ยังไม่ใช่การทดสอบบนโทรศัพท์จริง

เรื่องเวลากับค่าใช้จ่าย ตอนผมให้ persona สองคนลองอ่านบทความนี้ คนละ 7–8 งาน ใช้ Sonnet ไปคนละ 75k–88k tokens และประมาณ 2 นาที ถ้าเป็นแอปที่ต้องกรอกฟอร์มหรือหน้าจอซับซ้อนกว่านี้ ตัวเลขจะสูงขึ้นตามจำนวน persona และจำนวนงาน เริ่มจากงานเล็ก ๆ แล้วดู usage จริงของเราเองก่อนขยาย

## สรุป

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

เริ่มจากหน้าจอเดียว งานหลักไม่กี่ข้อ และ persona สองแบบก็พอครับ แล้วเลือกสิ่งที่รายงานกลับมาลองทำซ้ำเอง จะได้รู้ว่าวิธีนี้ช่วยงานของเราได้แค่ไหน

## References

- [Claude Code: Subagents](https://code.claude.com/docs/en/sub-agents)
- [Claude Code: Skills](https://code.claude.com/docs/en/skills)
- [Microsoft Playwright MCP](https://github.com/microsoft/playwright-mcp)

## Sitemap

See the full [sitemap](https://iamthana.com/sitemap.md) for all pages.