先统一业务事实
围绕租户、商品、订单、客户、支付、资源和员工梳理对象关系与状态，避免每个终端维护一套不同逻辑。
角色UX/UI Lead
全程参与并主导核心体验设计
设计资料6 份产品源文件
本案例精选 19 个核心流程节点
产品覆盖8 类终端
Admin / Mobile / POS / Kiosk / KDS / ITS / CDS / Web
系统基础200+ 设计与代码组件
主题、配置、状态与多端适配共用
Product × UX/UI leadership
从业务目标和角色边界，推到跨端任务与验收。
我的职责不止是多端 UI：会参与需求和范围梳理、业务对象与状态定义、交互规则、组件契约、研发走查和上线检查。
- 01 / Define商家目标、角色与场景
- 02 / Model商品、客户、订单与支付
- 03 / Orchestrate后台、门店与消费者触点
- 04 / Recover支付、库存、权限与离线
- 05 / Ship组件规则、走查与验收
规则复用，任务布局适配
Admin 强调密集编辑，POS 强调速度，Kiosk 强调引导，消费者端强调理解与反馈；语义和状态保持一致。
异常进入主路径
支付中断、库存变化、设备离线、权限不足、订单修改和退款都必须给出当前状态与下一步。
用系统资产对齐完成标准
通过功能图谱、流程、状态矩阵、组件文档、主题规则和设计走查，连接产品、设计与研发。
01 / CONTEXT
同一套业务，需要适应不同角色和使用环境。
Pisell 面向零售、餐饮、服务与预约类商家。业务一旦从线上商店扩展到门店、终端、Kiosk 与 App，设计问题就从“画一个页面”变成“维护同一套业务事实”。
例如，一个商品可能同时拥有规格、组合、预约资源、库存、配送方式、折扣和会员权益；一张订单又会经历创建、挂起、支付、拆分、履约、退款和异常恢复。界面如果只按模块分别设计，用户会在每个终端重新学习。
统一业务对象，适配不同操作环境
后台适合密集编辑，门店终端强调速度，消费者端需要更清楚的引导和反馈。
给商家配置空间，也提供清楚的默认值
应用、渠道和低代码能力保持开放，同时通过默认值、约束和恢复路径控制配置成本。
把异常状态放进主流程
支付中断、库存变化、权限不足、设备离线和订单修改都需要明确的反馈与恢复方式。
02 / PRODUCT MAP
先梳理业务对象与终端关系。
TENANT & APP PLATFORM
租户 · 应用安装 · 导航编排 · 权限 · API · Low-code
商家管理后台
商品、订单、客户、营销、报表、资源与设置
Sales / POS / Terminal
扫码、购物车、会员、促销、拆分支付与退款
Kiosk / KDS / ITS / CDS
自助点单、备菜、出菜、取餐与顾客显示
Storefront & Client App
商品、购物车、活动、预约、结算、钱包与个人中心
Team Portal
打卡、排班、预约处理、服务记录与现场任务
Picoding / XZero
Workspace、数据视图、租户配置、应用市场与发布
SINGLE SOURCE OF TRUTHPISELL SAAS CORE
- Product
- Customer
- Order
- Payment
- Resource
- Staff
SHARED PRODUCT LANGUAGE
Seed / Alias TokensAtom / Pro / PlusBusiness PatternsTerminal Adapters
查看完整 Design System 案例 ↗
查看 Picoding 低代码完整案例 ↗
设计资产 · 系统图谱
先固定对象与关系，再决定页面长什么样。
我用功能图谱把资源、商品、销售场景、渠道、客户、营销、订单处理、支付与履约放在一张图上。它帮助团队识别共用对象，也暴露哪些差异应该由场景层处理。
- 对象层：商品、资源、客户、订单保持统一标识与状态。
- 场景层：零售、餐饮、预约、票务只展示任务需要的信息。
- 终端层：同一动作依据设备与角色切换密度和反馈方式。
03 / DESIGN DECISIONS
四个贯穿多端设计的决定。
导航按任务分层
稳定核心能力放在主导航，渠道和应用按商家配置出现，减少“一次性暴露全部功能”。
降低认知负担详情页采用对象工作台
把客户、订单或资源的状态、关联记录和下一步操作放在同一页面。
减少来回跳转支付必须可感知、可恢复
支付方式、部分支付、钱包权益、设备反馈和失败恢复保持在一条进度链中。
保护高风险任务复用规则，按终端调整布局
筛选、表格、详情抽屉、选择器和状态反馈保持一致，各终端再调整密度、动作位置与信息层级。
支撑多端扩展04 / THEME & CONFIG
一套 Token 与配置，支撑多品牌和多终端。
同一套组件结构可以适配不同品牌、界面密度和终端环境，同时保留一致的状态与交互语义。
我把品牌变量、语义 Token、组件差异和业务配置整理为四层模型：Seed 表达品牌意图，Alias 统一语义，Component Token 管理组件细节，Config 决定字段、密度、权限与操作如何组装。
01Seed
colorPrimary / fontSize / radius / sizeUnit
02Alias
surface / text / border / action / status
03Component
Grid / Navigation / Booking / Checkout
04Config
字段、排序、密度、操作、终端适配
THEME PREVIEW
切换品牌、主题与界面密度。
这个示例展示主题上下文如何影响导航、数据容器、状态和消费者端操作。
colorPrimary#7C4DFF
borderRadiusLG12
controlHeight40
densityComfortable
Recent ordersFilter · Sort
#1048Olivia R.PaidA$86.40
#1047Walk-inReadyA$42.00
#1046Team orderPendingA$128.50
MOBILE CHECKOUTA$90.00
Wallet Pass applied
Credit or debit card
Apple Pay
05 / SYSTEM TO PRODUCT
同一套规则，落在不同业务和操作环境里。
我把组件库的 Atom / Pro / Plus 与产品源文件重新对齐：Atom 保证视觉和状态一致，Pro 提供可配置的通用能力，Plus 沉淀预约、资源、销售与支付等业务答案。
查看 Pisell Design System 案例 ↗同一导航模型
后台保留完整信息架构，门店和移动端按任务收敛；权限与页面标识保持一致。
同一资源状态
桌台、球场与服务位共享可用、预留、进行中和待结算，再由场景决定形态。
同一可用性语义
桌面端优先对比，移动端收敛为月历；售罄、即将满额与电话预约不丢失。
同一支付规则
附加费、钱包与拆分支付共享规则；POS 优先速度，消费者端优先解释与安全感。
06 / REAL DELIVERY
重点不在页面数量，而在同一笔业务如何跨端完成。
01销售工作台商品、服务与订单
02门店终端触控操作与支付
03预约与资源时段、容量与履约
04低代码平台配置、视图与发布
05跨端闭环状态同步与恢复
A / SALES 2.0
把商品、服务、预约与营销放进同一个销售工作台。
左侧支持分类、搜索与快速销售，右侧购物车持续承载客户、组合商品、资源、优惠与支付。信息密度高，但当前订单与下一步动作始终清晰。
- 关键对象
- 商品 / 服务 / 预约 / 客户 / 优惠
- 设计重点
- 跨业务商品卡片、购物车层级、主次动作
- 边界状态
- 修改订单、挂起、冲突优惠、售罄与退款
B / TERMINAL
门店终端优先保证速度、反馈和错误恢复。
Terminal 的销售主界面用大触控目标和持续购物车承载高频操作；结算时再集中呈现钱包、现金、EFTPOS、拆分支付与自定义支付。
没有选择：把所有支付方式平铺在销售页。
最终选择：销售与支付分阶段，但保留总额、客户和订单上下文。
最终选择：销售与支付分阶段，但保留总额、客户和订单上下文。
C / BOOKING & RESOURCE
预约需要同时处理服务、资源、时间和顾客。
我把选择服务、选择资源与时段、补充对象信息、确认报价拆成可回退步骤，同时让购物车持续反馈价格和选择结果，避免用户到最后才发现冲突。
- 支持住宿、宠物服务、课程与系列活动等不同预约模型。
- 桌面端保持对比效率，移动端收敛为逐步选择。
- 资源不可用、价格变化与必填信息在决策发生处提示。
D / PLATFORM & ECOSYSTEM
应用能力可以按租户安装、配置和组合。
低代码工作区和应用分发让不同商家按业务装配能力；组件状态、权限和升级提示则保证配置不会变成不可控的分支。
- Picoding
- Workspace / Base / Record / UI Builder
- XZero
- 租户、导航、应用安装与分发
- 设计系统
- Token、组件状态、业务 Pattern 与主题
E / PICODING · LOW-CODE EDITOR
让业务页面从配置开始，而不是每次重新开发。
Picoding 把页面结构、业务组件、属性配置、数据视图与发布流程放进同一个编辑工作区。商家可以复用 Pisell 的组件与权限规则，组合出订单、客户、资源和运营页面。
查看 Picoding 独立案例 ↗通过页面树和响应式画布组织导航、布局、模块与终端尺寸。
拖入设计系统组件，再配置字段、状态、权限、样式和交互。
同一数据源可以切换 Table、Kanban、Calendar、Gantt 与 Form。
在编辑器中检查角色和状态，发布后进入租户的应用与导航体系。
F / CLIENT WEB APP
将后台配置转换为消费者容易理解的购买流程。
客户端只暴露购买决策需要的规格、履约、附加项和价格；后台规则则负责可售性、库存、优惠与订单生成。这样既保留业务能力，也让消费者看到的是一条清楚的选择路径。
同一业务对象，可以共享规则，但不应该共享同一份信息密度。
G / ANALYTICS & DECISIONS
让经营数据直接指向下一步动作。
同一套订单、预约、库存、门店和设备数据，面向老板、运营人员与店长形成不同视角。经营总览、运营控制和移动决策三类页面共同说明信息架构、指标层级和跨端决策路径。
MERCHANT PERFORMANCE
先看经营全貌，再找到值得追问的变化。
净销售、订单、客单价和复购是入口，趋势、渠道、门店与商品表现解释变化来源，最后把异常或机会带到具体报表和动作。
经营判断
回答收入从哪里来、哪家门店在变化，以及应该继续追哪一条线索。
异常处置
把履约超时、库存不足、容量压力和设备离线收敛成可分派的问题。
随时行动
只保留今天的关键数字、优先级和处理入口，完成后再确认门店结果。
H / STORE OPERATING LOOP
一张订单，在不同屏幕上继续完成。
顾客下单后，KDS 负责备菜，ITS 完成出菜与搜索，Pickup Screen 管理取餐，CDS 展示明细与付款反馈。它们共享同一套订单状态，只在现场承担不同任务。
I / KIOSK · SELF-SERVICE
把零售、预约和票务收敛成一条站立式触控流程。
Kiosk 面向线下无人值守场景，它不是缩小版 POS：用户没有店员协助，界面需要先说明“现在能做什么”，再以大触控目标完成浏览、选购、备注、结算和结果确认。
- 启动
- 欢迎页、语言选择、业务入口与无障碍引导
- 选购
- 普通商品、预约服务、活动票务与组合选项
- 结算
- 持续购物车、支付方式、失败恢复与成功凭证
01Welcome入口与引导
02Browse菜单与选购
03Checkout订单与支付
04Tickets场次与票务
PROJECT FILES
一个业务核心，连接多种终端。
把商家后台、门店设备、消费者端、员工端和低代码能力放回同一张产品网络里。每个界面承担不同任务，但都从 Merchant Core 的业务对象与规则出发。
PisellMERCHANT
CORETenant · Product · Order · Customer · Payment · Resource
CORETenant · Product · Order · Customer · Payment · Resource
查看真实源界面与核心节点支持按终端和能力筛选
Pisell 2.0 Component Library200+设计与代码组件
2.0 应用项目7本页精选节点
Client Web & APP3本页精选节点
Terminal3本页精选节点
Picoding5本页精选节点
XZero1本页精选节点
26 个界面条目
07 / SYSTEM STATES
同时设计正常流程与异常状态。
项目中同时覆盖 Loading、Empty、Offline、Permission、Payment recovery 和业务冲突，确保高频任务在异常情况下也有明确反馈。
状态族典型场景系统反馈证据来源
Loading / Empty仪表盘首次加载、无订单、无 Wallet保留容器结构，解释为何为空并给出下一步Dashboard / ITS / Checkout
Network / Device子机配对、连接中、断开、打印机异常显示设备身份、当前阶段、重试与退出路径ITS / KDS APP / Terminal
Availability / Conflict资源不可用、售罄、即将满额、优惠冲突在选择当下反馈，不延迟到结算时才报错Booking / Promotion / POS
Payment / Recovery部分支付、Wallet 抵扣、附加费、退款、EFTPOS 中断持续显示已付、剩余应付、支付来源和恢复操作Checkout 2.0 / Terminal / Client
Permission / Scope多租户、多门店、角色权限、应用未安装将“不可见”与“不可操作”分开，避免错误暴露能力XZero / Admin / Team Portal
08 / OUTCOME & REFLECTION
最终形成可继续扩展的跨端规则。
从中心 SaaS 到 8 类终端
持续参与商家后台、商家移动端、POS/Terminal、Kiosk/KDS/ITS/CDS、员工端、在线商店与低代码平台的设计交付。
把一次方案变成可配置规则
统一对象和状态，以 Token、Pro 组件、Plus 业务模式与终端适配层减少重复决策，同时保留场景差异。
从需求到研发验收
不仅输出视觉稿，也补充对象关系、配置项、状态机、边界场景与组件对应关系，推动跨端方案落地。
后续方向
继续补充跨渠道的对象状态追踪。
让设计、产品和研发可以直接查看一个商品、订单或客户在不同渠道的字段来源、状态变化与异常策略，降低大型 SaaS 长期演进中的隐性不一致。
协作方式
原型用于快速验证，业务判断和验收由团队完成。
我负责原产品中的业务拆解、交互取舍、视觉设计和跨团队推进，并使用前端原型辅助方案验证。