GRPSARAWUT · NUI

Product UX · Frontend design · Functional web prototype

GRP Restaurant POS

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

หน้าผังโต๊ะของ GRP POS แสดงโต๊ะว่าง มีลูกค้า จองแล้ว และขอบิล
Floor plan · 4 operational statesDemo data · 2880 × 1800

Project overview

One Service.
Many Pressure Points.

POS ร้านอาหารไม่ใช่แค่หน้ารับเงิน แต่เป็นระบบส่งต่องานระหว่างคนหลายบทบาท การออกแบบจึงต้องรักษาทั้งความเร็ว ความถูกต้อง และหลักฐานย้อนหลัง โดยไม่ทำให้หน้าจอหนาแน่นเกินไป

จากสถานะโต๊ะ
สู่ความชัดเจนทั้งร้าน

ผมวาง GRP เป็น local-first operational product ที่ยังขายได้เมื่ออินเทอร์เน็ตล่ม ข้อมูลอยู่ในร้าน และไม่มี dependency กับ cloud สำหรับ flow หลัก

Problem
ข้อมูลโต๊ะ ออเดอร์ ครัว การชำระ และรายงานมักแยกกัน ทำให้ทีมต้องถามซ้ำและหาต้นเหตุเมื่อบริการช้าได้ยาก
Design goal
ทำให้แต่ละบทบาทเห็น “สิ่งที่ต้องทำต่อ” และส่งสถานะต่อกันโดยมีเวลา ยอดเงิน และหลักฐานที่ตรวจสอบได้
Constraints
ภาษาไทยเป็นหลัก · เครื่องเก่าในร้าน · ใช้ได้หลายขนาดจอ · ทำงานในเครือข่ายร้าน · กฎราคาไทย
Deliverables
Service flow · IA · design tokens · PHP/Vanilla JS functional prototype · interaction/state handling · responsive CSS · accessibility baseline · 17 QA screenshots
11

โมดูลหลัก ครอบคลุมหน้าร้าน ครัว และ back office

4

สถานะโต๊ะที่สื่อความหมายด้วยสีและข้อความ

17

ภาพหลักฐาน desktop, mobile และ dark mode

6

accent themes บนระบบ token เดียวกัน

Role & delivery evidence

Three Dimensions.
One Working Product.

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

01 · Web buildWeb Development

วางโครง web app และ data flow

สร้าง app shell สำหรับระบบ local-first และทำให้หน้าจอฝั่ง client ติดต่อข้อมูลชุดเดียวกันผ่าน JSON API โดยมี error path ที่สื่อสารกลับผู้ใช้

  • Application shellSession, CSRF token, asset cache-busting และ theme ก่อน first paint อยู่ใน PHP entry point
  • Data integrationFetch wrapper รองรับ GET/POST, same-origin credentials, JSON errors และ CSRF header
  • Module coverageเชื่อม auth, tables, orders, kitchen, payment, members, stock และ reports เข้ากับ flow เดียว
Repository evidenceapp/index.phpapp/assets/app.jsapp/api/*.php
02 · Interface systemFrontend Design

แปลงงานร้านเป็น UI ที่สแกนเร็ว

ออกแบบลำดับข้อมูลและ component language สำหรับสภาพแวดล้อมที่มีเวลาเป็นข้อจำกัด โดยให้สถานะอ่านได้จากข้อความ รูปแบบ และสีร่วมกัน

  • Design tokensแยก brand, semantic status และ surface tokens เพื่อเปลี่ยน accent/dark mode โดยไม่เปลี่ยนความหมาย
  • Operational hierarchyออกแบบ table card, kitchen ticket, payment summary และ KPI card รอบ next action
  • Thai-first responsive UIรองรับข้อความไทย เนื้อหาหนาแน่น และหลักฐาน desktop/mobile/light/dark จำนวน 17 ภาพ
Repository evidenceapp/assets/donezo.cssapp/screenshots/*.pngapp/design_source/
03 · Browser behaviorFrontend Development

ทำ interaction และ states ให้ใช้งานได้จริง

พัฒนา SPA views และ event handling สำหรับ flow ต่อเนื่อง ตั้งแต่เปิดโต๊ะถึงปิดบิล พร้อม timer, notification, modal, disabled และ error feedback

  • InteractionEvent delegation สำหรับ click/change/input, keyboard search shortcut, toast feedback และ modal state
  • Live stateKitchen timer อัปเดตทุกวินาที และ refresh สถานะเป็นช่วงโดยไม่ reload ทั้งหน้า
  • Responsive & a11y baseline3 layout tiers, mobile drawer, 44px coarse-pointer target, focus-visible, aria-modal และ aria-live
Repository evidenceapp/assets/app.js · view*() / render()app/assets/donezo.css · @media / :focus-visibleapp/index.php · lang="th" / viewport
Scope boundary

หลักฐานนี้ยืนยัน functional prototype และการเชื่อม frontend กับ PHP/MySQL application stack ในเครื่องทดสอบเท่านั้น ยังไม่อ้าง production deployment, ผลจากร้านจริง, assistive-technology testing หรือความพร้อมด้าน security/operations สำหรับใช้งานเชิงพาณิชย์

Design challenge

ทำอย่างไรให้ทีมทั้งร้านเห็น สถานะเดียวกัน โดยไม่ต้องตะโกนถามกัน?

ผมแบ่งปัญหาออกเป็นจุดส่งต่องานที่มีความเสี่ยงสูง แทนการเริ่มจากรายการหน้าจอ

01

Front of house needs a shared truth

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

02

Kitchen work is time-sensitive

ตั๋วอาหารต้องเดินทางทางเดียวจาก ใหม่ → กำลังทำ → พร้อมเสิร์ฟ → เสิร์ฟแล้ว และเวลาต้องช่วยชี้ว่าคอขวดอยู่ช่วงไหน

03

Money must stay explainable

คูปอง แต้ม ค่าบริการ VAT และการแบ่งบิลเพิ่มโอกาสผิด ผมจึงแสดงลำดับการคำนวณและคำนวณส่วนลดใหม่ทุกครั้งที่บิลเปลี่ยน

04

Operational data must lead to action

รายงานต้องแยก gross, discount, net sales และ collected เพื่อให้เจ้าของร้านรู้ว่าเงินเปลี่ยนตรงไหน ไม่ใช่เห็นเพียงกราฟสวย ๆ

Users & jobs to be done

Four Roles.
One Continuous Service.

กลุ่มผู้ใช้เหล่านี้เป็น role hypotheses ที่สกัดจาก workflow ของระบบ ใช้กำหนดลำดับข้อมูลและสิทธิ์ที่ควรมีใน pilot ถัดไป

FOH

พนักงานหน้าร้าน

ต้องเปิดโต๊ะ รับจอง สั่งอาหาร และรู้ว่าอาหารพร้อมเสิร์ฟโดยไม่เดินไปถามครัว

  • เห็นสถานะทุกโต๊ะในจอเดียว
  • ส่งรายการไปครัว/บาร์
  • รับ ready-to-serve alert
KDS

ครัวและบาร์

ต้องเห็นคิวที่เกี่ยวกับสถานีของตน เรียงลำดับงาน และส่งสัญญาณเมื่อพร้อม

  • แยก route อาหาร/เครื่องดื่ม
  • เห็นอายุ ticket
  • เปลี่ยนสถานะทางเดียว
PAY

แคชเชียร์

ต้องปิดบิลถูกยอด รองรับสมาชิก คูปอง แต้ม และหลายวิธีจ่ายโดยไม่คำนวณเอง

  • ตรวจ order summary
  • อธิบายส่วนลดได้
  • พิมพ์ใบเสร็จซ้ำได้
BO

เจ้าของและผู้จัดการ

ต้องรู้ว่ายอดเปลี่ยนเพราะอะไร เมนูใกล้หมดตรงไหน และช่วงใดบริการช้า

  • เทียบ KPI ตามช่วงเวลา
  • ดู discount breakdown
  • ติดตาม stock movement

Journey map

From Arrival
to Reconciliation

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

Phase
① รับลูกค้า
② เปิดออเดอร์
③ ผลิตและเสิร์ฟ
④ ชำระเงิน
⑤ ปิดรอบ
User Action
เลือกโต๊ะว่าง หรือรับลูกค้าที่จองไว้เข้าโต๊ะ
เพิ่มเมนู ปรับจำนวนแขก และส่งรายการ
ติดตามสถานะครัวและนำอาหารไปเสิร์ฟ
เลือกสมาชิก ใช้คูปอง/แต้ม และวิธีจ่าย
พิมพ์ใบเสร็จ ตรวจรายงาน และปรับสต๊อก
Touchpoint
Floor plan · Reservation modal
Order · Menu availability
KDS · Ready notification
Payment · Receipt
Reports · Stock · Ledger
User Thought
“โต๊ะไหนพร้อมรับลูกค้า?”
“ส่งรายการครบหรือยัง?”
“บิลนี้ช้าตรงไหน?”
“ยอดนี้คิดอย่างไร?”
“วันนี้เกิดอะไรขึ้นกับยอด?”
Pain / Emotion
กลัวเปิดโต๊ะซ้ำ หรือพลาดการจอง
ของหมดแต่หน้าร้านยังรับออเดอร์
เร่งรีบ คิวซ้อน ไม่รู้ว่าใครรับช่วง
กดผิด อธิบายส่วนลดไม่ได้
ตัวเลขหลายชุดไม่ตรงกัน
App Opportunity
สถานะ + ชื่อผู้จองบนการ์ดเดียว
stock state และ server-side validation
timer + directional state + alert
calculation hierarchy + receipt payload เดียว
metric definitions + source-linked breakdown

Service flow

Every Handoff
Has a State.

ผมออกแบบให้ flow หลักเดินหน้าเป็นลำดับชัด และเก็บหลักฐานไว้หลังการส่งต่อ โดยเฉพาะตั๋วครัวและ payload ใบเสร็จ

Core dine-in flowReservation → Revenue
STEP 01

จอง / เลือกโต๊ะ

บันทึกชื่อ เบอร์ และหมายเหตุ หรือเลือกโต๊ะว่าง

Floor plan
STEP 02

เปิดโต๊ะ

เปลี่ยนบริบทเป็น occupied และสร้างออเดอร์เปิดหนึ่งใบ

Table context
STEP 03

สั่งอาหาร

ตรวจ availability เพิ่มรายการ และ route ตามสถานี

Order
STEP 04

ครัวผลิต

New → Preparing → Ready พร้อมนาฬิกาอายุ ticket

Kitchen / Bar
STEP 05

พร้อมเสิร์ฟ

พนักงานเห็น alert และปิดสถานะ Served โดยไม่ลบ ticket

Notification
STEP 06

ชำระเงิน

คำนวณส่วนลด service VAT วิธีจ่าย และแต้มในลำดับเดียว

Payment
STEP 07

ปิดบิล

สร้าง receipt โต๊ะกลับเป็นว่าง และข้อมูลไหลสู่รายงาน

Receipt / Report

Information architecture

Organized by Work,
Not by Database.

เมนูหลักแยกตามงานที่ผู้ใช้ต้องทำ ส่วน object หลักยังเชื่อมกันผ่าน branch, context, order, ticket, member และ receipt

Role-based sitemap

เข้าสู่ระบบเลือกสาขา · PIN
หน้าร้านผังโต๊ะ · ออเดอร์ · ชำระเงิน
สถานีผลิตครัว · บาร์น้ำ · พร้อมเสิร์ฟ
จัดการร้านเมนู · สมาชิก · โปรโมชั่น · สต๊อก
บริหารรายงาน · ตั้งค่า

Known gap: เวอร์ชันปัจจุบันยังไม่บังคับ RBAC จริง จึงกำหนดสิทธิ์ตามบทบาทเป็น requirement อันดับแรกของ v2

Screen inventory

Floor planzones · table states · reservations
Ordercategories · menu stock · live totals
Paymentmember · coupon · points · split bill
Kitchen / Barticket queue · timer · production state
Menuavailability · quantity · price
MembersOTP · tier · points ledger
Promotions7 validation rules · usage status
ReportsKPI · breakdown · timing · stock alerts
Stockreceive · issue · count · history
Settingstheme · accent · live preview

Product decisions

Clarity Before
Decoration.

การตัดสินใจหลักผูกกับความเสี่ยงของงานจริง: พลาดโต๊ะ พลาดคิว พลาดยอด หรือเห็นข้อมูลแล้วตีความผิด

01

Status is text + color

ทุกสถานะสำคัญมี label สองภาษาและรูปแบบการ์ดต่างกัน สีจึงไม่ใช่สัญญาณเพียงอย่างเดียว

02

Ready-to-serve closes the gap

ครัวส่งสัญญาณกลับหน้าร้านทันที ทำให้ handoff เป็นส่วนหนึ่งของ product ไม่ใช่ภาระของคน

03

Discounts come before tax

ลำดับ subtotal − discount = net ก่อน service 10% และ VAT 7% ถูกแสดงบนจอและใช้สูตรเดียวกันทุกจุด

04

Time reveals the bottleneck

อายุ ticket แบ่งช่วงปกติ เหลือง และแดง พร้อม breakdown เวลารอ ทำ และรอรับไปเสิร์ฟ

05

Comparison uses equal windows

ยอดวันนี้เทียบกับเมื่อวานถึงเวลาเดียวกัน ส่วน discount ที่เพิ่มใช้สีแดง เพราะเป็นต้นทุน ไม่ใช่ growth

06

Local-first is a service choice

flow ขายหลักไม่พึ่งอินเทอร์เน็ต ช่วยลดความเสี่ยงที่ร้านหยุดขายเมื่อ WAN มีปัญหา

Selected UI work

Designed Around
the Next Action.

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

SCREEN 01 · FLOOR

A floor plan that reads like a live board

การ์ดโต๊ะรวมหมายเลข ที่นั่ง จำนวนแขก ชื่อผู้จอง และสถานะไว้ในก้อนเดียว พร้อมตัวกรองโซนและบริบท dine-in / takeaway / delivery

  • Decision: ขอบเส้นประใช้กับการจองเพื่อแยกจากโต๊ะ active
  • Handoff: รับลูกค้าที่จองไว้แล้วชื่อและเบอร์ไหลเข้าบิล
หน้าผังโต๊ะ GRP POSDEMO DATA
หน้าสั่งอาหาร GRP POS แสดงหมวด เมนู สถานะคงเหลือ และตะกร้าDEMO DATA
SCREEN 02 · ORDER

Availability at the moment of choice

สถานะ “เหลือ N” และ “หมด” อยู่บนการ์ดเมนู ปุ่มสั่งถูกปิดเมื่อขายไม่ได้ และจำนวนคืนกลับเมื่อผู้ใช้ลดหรือลบรายการ

  • Decision: แยก category navigation จาก product grid
  • Safety: ตรวจของหมดซ้ำทั้ง UI และ server
SCREEN 03 · KITCHEN

A queue that exposes time

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

  • Timing: เกิน 10 นาทีเป็นเหลือง เกิน 15 นาทีเป็นแดง
  • Traceability: Served ticket ไม่ถูกลบ แต่ถูกกรองออกจาก board
จอครัว GRP POS แสดงตั๋ว New Preparing Ready พร้อมนาฬิกาDEMO DATA
หน้าชำระเงิน GRP POS แสดงสมาชิก คูปอง แต้ม และยอดชำระDEMO DATA
SCREEN 04 · PAYMENT

Explainable pricing before confirmation

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

  • Guardrail: แต้มถูก clamp ไม่ให้เกินยอดหรือแต้มที่มี
  • Recovery: ส่วนลดคำนวณใหม่เมื่อบิลเปลี่ยน
SCREEN 05 · REPORTS

Numbers with an audit trail

KPI แยกยอดเก็บจริง ยอดขายสุทธิ ส่วนลด และจำนวนออเดอร์ พร้อม breakdown ที่ทำให้ยอดบวกกลับลงตัว

  • Decision: discount growth ใช้สีแดงโดยตั้งใจ
  • Honesty: ตัวเลขภาพนี้เป็น demo data ไม่ใช่ผลประกอบการจริง
หน้ารายงาน GRP POS แสดง KPI และสรุปยอดขายDEMO DATA

Design system

One Token System.
Multiple Conditions.

Donezo system แยก brand colors ออกจาก semantic status colors ทำให้เปลี่ยน accent หรือ dark mode ได้โดยไม่เปลี่ยนความหมายของ success, warning และ danger

Core visual tokens

Forest
Mint
Warning
Danger
Canvas
Ink
สถานะที่อ่านออก

Prompt / system sans · Thai-first · rounded geometry · 4px spacing scale

01Table cardAvailable · Reserved · Occupied · Bill requested
02Kitchen ticketNew · Preparing · Ready · Served · timer severity
03Status pillText + semantic color · bilingual label
04Metric cardValue · delta · comparison window · drill-down
05Payment summarySubtotal · discount · service · VAT · total
06Action controls44px+ target · primary/secondary hierarchy · focus-visible

State design

The Product Lives
Between Screens.

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

ว่าง · Available

Table availability

เปิดโต๊ะได้และมี action จองแยกจาก action หลัก

มีลูกค้า · Occupied

Active service

แสดงจำนวนแขกและเชื่อมกับออเดอร์เปิดปัจจุบัน

จองแล้ว · Reserved

Reservation

เก็บชื่อ เบอร์ เวลา และเปลี่ยนเป็น occupied เมื่อรับลูกค้า

ขอบิล · Requested

Payment handoff

ทำให้โต๊ะที่ต้องการแคชเชียร์โดดเด่นจากโต๊ะ active ทั่วไป

ใหม่ · New

Kitchen queue

งานใหม่รอเริ่มและมีอายุ ticket เป็นบริบท

กำลังทำ · Preparing

Production active

action ถัดไปชัดเจนและสถานะย้อนกลับไม่ได้โดยไม่ตั้งใจ

พร้อมเสิร์ฟ · Ready

Ready notification

ส่งสัญญาณกลับ front of house และนับรายการพร้อมเสิร์ฟ

หมด · Sold out

Menu disabled

การ์ดจาง ปุ่มปิด และ API ปฏิเสธเพื่อป้องกันออเดอร์เกิน

Responsive behavior

Same Meaning.
Different Density.

บนเดสก์ท็อป ระบบใช้พื้นที่เพื่อกวาดดูหลายโต๊ะ ส่วนมือถือเปลี่ยน sidebar เป็นเมนูและวาง notification ไว้ก่อนตัวกรอง โดยยังคงข้อมูลสถานะบนการ์ดครบ

ผังโต๊ะ GRP POS บนเดสก์ท็อปในโหมดมืด
ผังโต๊ะ GRP POS บนมือถือ
Desktopsidebar คงที่ · grid หลายคอลัมน์ · เห็น operational overview ใน viewport เดียว
Mobile2-column table grid · horizontal filters · navigation แบบ drawer · alert อยู่ด้านบน
Dark modesemantic status ยังคงความหมายเดิม ขณะที่ brand ramp และ surfaces ปรับ contrast ตามพื้นหลัง

Evidence & validation

Built to Be
Checked.

หลักฐานปัจจุบันยืนยันความครบของ prototype และกฎระบบ ยังไม่ใช่ usability outcome หรือ business impact จากร้านจริง

UI evidence17

ภาพ desktop, mobile, light และ dark สำหรับตรวจ layout และ state meaning

Demo depth90d

ข้อมูลจำลองประมาณ 90 วันสำหรับดูรูปทรงรายงานและเทียบตัวเลข

Money rules1

ลำดับราคาเดียวสำหรับหน้าจอ ใบเสร็จ และรายงาน ลดการคำนวณซ้ำ

Field outcome—

ยังไม่มี baseline จากร้านจริง จึงไม่อ้าง conversion, speed หรือ revenue uplift

Reflection & next phase

From Functional
to Field-Ready.

งานนี้แสดงความสามารถในการคิดระบบตั้งแต่ service flow ไปจนถึง UI และกฎธุรกิจ ขั้นถัดไปคือพิสูจน์กับบริบทจริงและปิดความเสี่ยงด้านสิทธิ์ อุปกรณ์ และความต่อเนื่องของข้อมูล

What I delivered

Design + working web prototype

  • ผังโต๊ะ ออเดอร์ ครัว ชำระเงิน ใบเสร็จ และรายงานที่เชื่อมสถานะกัน
  • PHP app shell, Vanilla JS views, JSON API integration และ centralized interaction handling
  • responsive UI, dark mode, 6 accents และ reusable CSS design tokens
  • disabled/error/loading feedback, keyboard shortcut, focus state และ live-region baseline
  • เอกสาร domain rules, data model และ roadmap สำหรับ v2
Recommended next

Pilot before claiming impact

  • ทดสอบ contextual inquiry และ usability กับร้านนำร่อง 3–5 ร้าน
  • ทำ keyboard + screen-reader audit และเพิ่ม focus management ใน dialog ให้ครบ
  • เพิ่ม RBAC ตามบทบาทและ audit log ที่แก้ย้อนหลังไม่ได้
  • ต่อ ESC/POS, SMS gateway, PromptPay และ queue ตอน Wi‑Fi หลุด
  • ทำ automated end-to-end test, backup และ restore drill
  • วัด order-entry time, kitchen handoff time, payment error และ report reconciliation