Người không code vẫn review được UI rất tốt nếu review như người dùng thật. Bạn không cần đọc React component để phát hiện form thiếu field. Không cần hiểu API để thấy button báo thành công quá sớm. Không cần biết CSS để thấy mobile layout vỡ. Vấn đề là nhiều người review vibe-coded app như đang xem screenshot, không phải đang dùng sản phẩm.

Mở app lên, nhìn đẹp, nói “ổn”, rồi prompt tiếp feature mới. Đó là cách bug tích tụ. Review UI đúng phải chậm hơn một chút: đi qua flow chính, thử mobile, thử empty state, thử loading/error, so lại yêu cầu ban đầu, và kiểm tra AI có sửa ngoài scope không.

Đừng review homepage trước

Nếu app là tool vận hành, homepage không phải nơi quan trọng nhất. Main flow mới là nơi app sống hoặc chết.

Với booking app, main flow có thể là:

  1. Tạo booking.
  2. Xem booking trong danh sách.
  3. Đổi deposit status.
  4. Filter theo ngày/status.

Với lead tracker:

  1. Tạo lead.
  2. Chuyển status từ new sang contacted.
  3. Ghi note cuộc gọi.
  4. Lọc lead cần follow-up.

Hãy review đúng flow này trước khi khen dashboard. Nếu form tạo record sai, chart đẹp không cứu được app. Nếu status update không lưu, màu badge đẹp không quan trọng.

Một cách làm đơn giản: viết ra một kịch bản 5 phút.

Scenario:
I am the studio owner.
A customer calls and wants to book a family shoot next Friday.
I need to create the booking, mark deposit as unpaid, add a note, then find it again from the list.

Sau đó dùng app đúng kịch bản. Không click lung tung trước. Nếu kịch bản chính fail, dừng và sửa. Đừng thêm feature mới.

Kiểm tra requested vs actual

AI có thể làm đúng phần bạn nhìn thấy nhưng sai phần bạn yêu cầu. Sau mỗi vòng, mở prompt cũ và check từng acceptance item.

Ví dụ bạn yêu cầu:

  • Add filter by status.
  • Keep existing table columns.
  • Do not change create form.

Review:

  • Filter có hoạt động không?
  • Status options có đúng không?
  • Table column có bị đổi không?
  • Create form có bị thêm/bớt field không?

Điểm thứ tư rất quan trọng. Agent đôi khi sửa ngoài scope vì nghĩ “improve”. Nếu bạn chỉ test filter, bạn bỏ qua việc form đã bị đổi. Với vibe coding, unrelated changes là nguồn bug lớn.

Bạn có thể dùng checklist ngắn:

Requested:
- [ ] Feature A works.
- [ ] Feature B works.

Should stay unchanged:
- [ ] Existing create flow still works.
- [ ] Existing table layout still works.
- [ ] Existing mobile behavior still works.

Review không chỉ là “cái mới có chạy không”. Review là “cái cũ có bị phá không”.

Mobile không phải việc sau

Rất nhiều vibe-coded app nhìn ổn ở desktop preview nhưng vỡ trên điện thoại. Non-tech lại thường demo trên laptop nên không thấy. Nếu app có người dùng mobile, test mobile từ sớm.

Bạn không cần thiết bị phức tạp. Dùng browser responsive mode hoặc kéo cửa sổ hẹp. Test ít nhất 390px width vì nhiều điện thoại phổ biến quanh mức đó.

Checklist mobile:

  • Header có chiếm quá nhiều chiều cao không?
  • Button chính có nằm dưới fold không?
  • Table có biến thành list/card dễ đọc không?
  • Filter có wrap kỳ cục không?
  • Text có bị cắt không?
  • Modal có vừa màn hình không?
  • Form field có đủ khoảng cách để bấm không?
  • Bottom action có bị keyboard che không?

Nếu app dùng table nhiều cột, đừng ép table desktop xuống mobile. Với mobile, list card hoặc detail-first flow thường tốt hơn. Prompt feedback:

At 390px width, the booking table is too wide and requires horizontal scrolling.
For mobile only, convert each row into a compact booking card.
Keep the desktop table unchanged.

Câu “for mobile only” và “keep desktop unchanged” giúp tránh AI rewrite toàn bộ layout.

Keyboard và form interaction

Form là nơi UI đẹp thường lộ lỗi. Test bằng cách nhập data thật hơn lorem ipsum.

Checklist form:

  • Required fields có rõ không?
  • Submit khi thiếu field báo lỗi đúng chỗ không?
  • Phone/email/date field có keyboard phù hợp trên mobile không?
  • Date picker có dùng được không?
  • Long note có làm vỡ layout không?
  • Bấm Cancel có mất data ngoài ý muốn không?
  • Bấm Submit hai lần có tạo duplicate không?
  • Sau khi submit thành công, app đưa user tới đâu?

Một bug hay gặp: form báo success nhưng list không update. Hoặc list update nhưng refresh mất data. Với prototype local state, refresh mất data có thể chấp nhận nếu đã label rõ. Với real API thì không.

Prompt sửa:

The create form shows success, but the new booking does not appear in the list until refresh.
Fix the post-submit behavior so the user can immediately see the created booking.
Do not change the form fields or table columns.

Feedback cụ thể tốt hơn “form bị lỗi”.

Empty state

Empty state không phải trang trắng. Nếu user mới vào app chưa có data, họ cần biết chuyện gì đang xảy ra và bấm gì tiếp.

Test bằng cách xóa sample data hoặc dùng account mới. Nếu app hiện table trống không lời giải thích, đó là lỗi UX. Nếu app crash vì array rỗng, đó là lỗi kỹ thuật.

Empty state tốt nên trả lời:

  • Chưa có gì?
  • Vì sao chưa có?
  • User nên làm gì tiếp?

Ví dụ:

Chưa có booking nào trong khoảng ngày này.
Thử đổi bộ lọc hoặc tạo booking đầu tiên.

Đừng để AI viết empty state quá marketing. Với app vận hành, text ngắn và hữu dụng là đủ.

Loading và error state

Loading state trả lời: app đang làm gì. Error state trả lời: chuyện gì hỏng và user có thể làm gì.

Test loading bằng mạng chậm nếu có thể. Nếu không, yêu cầu agent mô phỏng hoặc thêm delay tạm trong môi trường dev, rồi gỡ trước khi xong. Test error bằng cách dùng endpoint sai trong dev hoặc ngắt mạng. Với non-tech, ít nhất hãy hỏi agent: “Show me how this UI behaves when API loading fails.”

Checklist:

  • Loading có hiện ở đúng vùng không?
  • User có thể bấm submit nhiều lần khi loading không?
  • Error có rõ ràng không?
  • Error có giữ input đã nhập không?
  • Có retry không nếu phù hợp?
  • App có báo success khi API fail không?

Prompt:

Add a clear API error state for the booking list.
If loading fails, show an inline error with a retry action.
Do not replace the whole page with a generic error screen.

Error state tốt không cần dài. Nhưng phải thật. “Something went wrong” có thể đủ cho demo, không đủ cho operator cần biết nên làm gì.

Broken flow: đi ngược lại

Người dùng không chỉ đi thẳng. Họ quay lại, sửa, hủy, refresh, mở tab mới, bấm back. Review UI phải thử các đường này.

Checklist broken flow:

  • Bấm Back sau khi tạo record có làm mất context không?
  • Mở detail rồi đóng lại có giữ filter không?
  • Refresh trang detail có load đúng record không?
  • Hủy form có hỏi confirm nếu đã nhập nhiều không?
  • Link trực tiếp tới record không tồn tại hiển thị gì?
  • User không có quyền vào URL admin thấy gì?

Không cần test mọi thứ trong bài đầu. Nhưng khi app có data thật hoặc user thật, những đường ngược này quan trọng.

Feedback bằng screenshot

Screenshot feedback hiệu quả hơn câu chung chung. Nhưng screenshot cần đi kèm mô tả.

Kém:

Fix this.

Tốt:

In this screenshot, the Save button is below the mobile keyboard after editing the note.
Move the primary action above the keyboard or keep it sticky at the bottom of the visible panel.
Do not change the desktop layout.

Nếu có nhiều lỗi, đánh số:

Fix only these three UI issues:
1. Mobile filter wraps into three lines at 390px.
2. Empty state text says "No data" instead of Vietnamese.
3. Error message disappears after two seconds before user can read it.

Do not redesign the page.

“Fix only” giúp giữ scope. “Do not redesign” chống AI làm quá.

Non-dev review checklist

Bạn có thể copy checklist này cho mỗi vòng:

Main flow:
- [ ] I can complete the primary user scenario.
- [ ] The result appears where I expect.
- [ ] Refresh behavior is understood.

Mobile:
- [ ] 390px width is usable.
- [ ] Buttons are reachable.
- [ ] Text does not overlap or get cut.
- [ ] Keyboard does not block critical actions.

States:
- [ ] Empty state is useful.
- [ ] Loading state is clear.
- [ ] Error state is clear.
- [ ] Validation errors appear near fields.

Scope:
- [ ] Requested change works.
- [ ] Existing flow still works.
- [ ] No unrelated redesign happened.
- [ ] Mock vs real data is clear.

Checklist này không thay thế developer review. Nó giúp bạn không bị screenshot đẹp đánh lừa.

Khi nào cần dev review

Gọi developer hoặc reviewer kỹ thuật khi:

  • App bắt đầu dùng real user data.
  • Có auth, role, permission.
  • Có payment.
  • Có file upload.
  • Có external API key.
  • Có database migration.
  • Có dependency mới.
  • Bạn không hiểu app lưu data ở đâu.
  • Agent sửa nhiều file ngoài scope.

Non-tech review bắt bug sản phẩm rất tốt. Nhưng security, data ownership, database, deploy, dependency vẫn cần người đọc code.

Chốt lại

Review UI vibe-coded app không phải ngồi ngắm màn hình đẹp. Hãy dùng app như người dùng thật: đi qua main flow, thử mobile, nhập data xấu, xem empty/loading/error, so requested vs actual, và bắt unrelated changes. Nếu feedback, dùng screenshot kèm mô tả cụ thể. Bạn không cần biết code để phát hiện nhiều lỗi quan trọng. Bạn chỉ cần đừng để app đẹp làm mình ngừng test.