统一业务对象，适配不同操作环境
后台适合密集编辑，门店终端强调速度，消费者端需要更清楚的引导和反馈。
RECENT WORKB2B2CDESIGN SYSTEM DRIVEN
Pisell · Omnichannel Commerce SaaS
同一笔业务，
如何在不同终端
继续完成。
页顶 60 秒：先统一对象，再谈界面；同一规则跑通多端；决策可走查、失败可恢复。
- 对象模型：先统一订单、库存、客户等核心对象，与研发共用同一套模型，再谈界面。
- 多端：同一业务规则跑通 Admin、POS、Terminal、Web 与预约。
- 判断：设计决策可走查、失败可恢复；我定角色路径、异常状态与验收口径。
MERCHANT CORE
CHANNELS
CUSTOMER
角色UX/UI Lead
全程参与并主导核心体验设计
设计资料6 份源文件
349 个 Figma 页面
产品覆盖7 类终端
Admin / Mobile / POS / Kiosk / KDS / CDS / Web App
系统基础225 页组件与模式
41 Variables · Light / Dark 两个 Mode
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 案例 ↗
设计资产 · 系统图谱
先固定对象与关系，再决定页面长什么样。
我用功能图谱把资源、商品、销售场景、渠道、客户、营销、订单处理、支付与履约放在一张图上。它帮助团队识别共用对象，也暴露哪些差异应该由场景层处理。
- 对象层：商品、资源、客户、订单保持统一标识与状态。
- 场景层：零售、餐饮、预约、票务只展示任务需要的信息。
- 终端层：同一动作依据设备与角色切换密度和反馈方式。
03 / DESIGN DECISIONS
四个贯穿多端设计的决定。
导航按任务分层
稳定核心能力放在主导航，渠道和应用按商家配置出现，减少“一次性暴露全部功能”。
降低认知负担详情页采用对象工作台
把客户、订单或资源的状态、关联记录和下一步操作放在同一页面。
减少来回跳转支付必须可感知、可恢复
支付方式、部分支付、钱包权益、设备反馈和失败恢复保持在一条进度链中。
保护高风险任务复用规则，按终端调整布局
筛选、表格、详情抽屉、选择器和状态反馈保持一致，各终端再调整密度、动作位置与信息层级。
支撑多端扩展04 / THEME & CONFIG
用主题配置适配品牌与使用场景。
同一套组件结构可以适配不同品牌、界面密度和终端环境，同时保留一致的状态与交互语义。
当前源文件已有 1 个 Variable Collection、41 个 Variables 与 Light / Dark 两个 Mode。我将它整理为四层模型：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
不同终端中的实际界面。
A / SALES 2.0
把商品、服务、预约与营销放进同一个销售工作台。
左侧支持分类、搜索与快速销售，右侧购物车持续承载客户、组合商品、资源、优惠与支付。信息密度高，但当前订单与下一步动作始终清晰。
- 关键对象
- 商品 / 服务 / 预约 / 客户 / 优惠
- 设计重点
- 跨业务商品卡片、购物车层级、主次动作
- 边界状态
- 修改订单、挂起、冲突优惠、售罄与退款
B / TERMINAL
门店终端优先保证速度、反馈和错误恢复。
Terminal 的销售主界面用大触控目标和持续购物车承载高频操作；结算时再集中呈现钱包、现金、EFTPOS、拆分支付与自定义支付。
没有选择：把所有支付方式平铺在销售页。
最终选择：销售与支付分阶段，但保留总额、客户和订单上下文。
最终选择：销售与支付分阶段，但保留总额、客户和订单上下文。
C / BOOKING & RESOURCE
预约需要同时处理服务、资源、时间和顾客。
我把选择服务、选择资源与时段、补充对象信息、确认报价拆成可回退步骤，同时让购物车持续反馈价格和选择结果，避免用户到最后才发现冲突。
- 支持住宿、宠物服务、课程与系列活动等不同预约模型。
- 桌面端保持对比效率，移动端收敛为逐步选择。
- 资源不可用、价格变化与必填信息在决策发生处提示。
D / PLATFORM & ECOSYSTEM
应用能力可以按租户安装、配置和组合。
低代码工作区和应用分发让不同商家按业务装配能力；组件状态、权限和升级提示则保证配置不会变成不可控的分支。
- Picoding
- Workspace / Base / Record / UI Builder
- XZero
- 租户、导航、应用安装与分发
- 设计系统
- Token、组件状态、业务 Pattern 与主题
E / CLIENT WEB APP
将后台配置转换为消费者容易理解的购买流程。
客户端只暴露购买决策需要的规格、履约、附加项和价格；后台规则则负责可售性、库存、优惠与订单生成。这样既保留业务能力，也让消费者看到的是一条清楚的选择路径。
同一业务对象，可以共享规则，但不应该共享同一份信息密度。
F / STORE OPERATING LOOP
一张订单，在不同屏幕上继续完成。
顾客下单后，KDS 负责备菜，ITS 完成出菜与搜索，Pickup Screen 管理取餐，CDS 展示明细与付款反馈。它们共享同一套订单状态，只在现场承担不同任务。
PROJECT FILES
一个业务核心，连接多种终端。
把商家后台、门店设备、消费者端、员工端和低代码能力放回同一张产品网络里。每个界面承担不同任务，但都从 Merchant Core 的业务对象与规则出发。
查看 12 张真实源界面支持按终端和能力筛选
Pisell 2.0 Component Library225组件 / Pattern
2.0 应用项目102Admin / Dashboard / Device
Client Web & APP12Consumer / Team
Terminal5POS / KDS / ITS / CDS
Picoding3Workspace / Low-code
XZero2Tenant / App registry
12 个界面条目
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 到 7 类终端
持续参与商家后台、商家移动端、POS/Terminal、Kiosk/KDS/ITS/CDS、员工端、在线商店与低代码平台的设计交付。
把一次方案变成可配置规则
统一对象和状态，以 Token、Pro 组件、Plus 业务模式与终端适配层减少重复决策，同时保留场景差异。
从需求到研发验收
不仅输出视觉稿，也补充对象关系、配置项、状态机、边界场景与组件对应关系，推动跨端方案落地。
后续方向
继续补充跨渠道的对象状态追踪。
让设计、产品和研发可以直接查看一个商品、订单或客户在不同渠道的字段来源、状态变化与异常策略，降低大型 SaaS 长期演进中的隐性不一致。
协作方式
原型用于快速验证，业务判断和验收由团队完成。
我负责原产品中的业务拆解、交互取舍、视觉设计和跨团队推进，并使用前端原型辅助方案验证。