WeChat Mini Program UI/UX
Use this skill for WeChat Mini Program UI work. It is specific to mini program constraints, not generic web UI.
Goals
- - Keep the interface native to WeChat usage habits.
- Preserve a clear page focus and one dominant action.
- Optimize for mobile reading, tap comfort, and short task completion.
- Always handle loading, empty, error, and permission-denied states.
- Produce intentional visuals, but never fight the platform chrome or interaction model.
Workflow
- 1. Identify the target:
- Page type: list, detail, form, dashboard, feed, account, checkout, approval, settings.
- User goal: browse, decide, submit, manage, confirm, recover.
- State complexity: guest/logged-in, empty/contentful, success/failure, role-based actions.
- 2. Read the relevant references:
- WeChat principles and mini program constraints:
references/wechat-design-principles.md
- Design-system workflow and anti-pattern framing:
references/design-system-pattern.md
- 3. Generate a compact page design system before editing code:
- Page focus
- Information hierarchy
- Key components
- Color direction
- Typography scale
- Spacing rhythm
- Motion and feedback rules
- States to support
- 4. Implement in mini program primitives first:
- Prefer WXML + WXSS + built-in components
- Use
rpx for layout sizing
- Respect safe areas and fixed bottom actions
- Keep JS logic state-driven and explicit
- 5. Run a pre-delivery review against the checklist in
references/wechat-design-principles.md.
Output Shape
When designing or implementing, structure thinking in this order:
- 1. Page intent
- Primary action
- Content hierarchy
- State coverage
- Visual system
- Interaction details
Keep this short unless the user asks for a full spec.
Platform Rules
- - Design for narrow mobile viewports first.
- Avoid desktop-like dense tables, tiny controls, and hover-dependent interactions.
- Do not place critical actions where the WeChat top-right capsule area creates conflict.
- Keep navigation obvious. Users should know where they are, what they can do next, and how to go back.
- Prefer one primary CTA per screen section; secondary actions should be visually quieter.
- If a page can fail to load, never leave a blank screen. Show a visible recovery path.
- If data may be absent, design an intentional empty state with next action.
- If permissions or login are required, explain the reason before prompting.
Visual Direction
- - Favor clean, high-contrast, mobile-readable layouts over decorative complexity.
- Use bold visual direction only when it still supports fast comprehension.
- Build around 1 strong accent color plus stable neutrals.
- Use cards, spacing, and typography to create hierarchy before adding extra decoration.
- Keep imagery purposeful. Hero images must not bury the core action.
- Motion should explain state changes, not decorate idle elements.
Common Mini Program Patterns
- - Lists: sticky filters only if they materially help scanning; preserve scroll performance.
- Detail pages: title, summary, trust/context, primary CTA, then secondary content.
- Forms: short sections, explicit labels, inline validation, submit-state feedback.
- Bottom bars: reserve for the most important action only; support safe-area padding.
- Management screens: show role, status, and allowed actions clearly to reduce permission confusion.
Anti-Patterns
- - Web landing-page aesthetics copied directly into mini program task pages.
- Multiple competing CTAs in the first viewport.
- Light text on busy image backgrounds without a reliable contrast layer.
- Long ungrouped forms with placeholder-only labels.
- Blank screens on request failure.
- Destructive actions styled too similarly to primary confirm actions.
- Overuse of gradients, glass effects, or shadow stacks that hurt readability on small screens.
- Dense information blocks without section headers or spacing rhythm.
Implementation Notes
- - Prefer page-level tokens or CSS variables when establishing a new visual direction.
- Reuse existing project patterns if the codebase already has a design language.
- If the existing screen is inconsistent, align it to WeChat principles first, then improve aesthetics.
- When reviewing code, prioritize usability regressions over purely visual opinions.
References
微信小程序UI/UX设计
此技能专用于微信小程序的UI设计工作,针对小程序特有的约束条件,而非通用网页UI。
目标
- - 保持界面符合微信使用习惯
- 确保页面焦点清晰,主导操作明确
- 针对移动端阅读、点击舒适度和短任务完成进行优化
- 始终处理加载、空状态、错误和权限拒绝状态
- 产出有意图的视觉效果,但绝不与平台界面或交互模式冲突
工作流程
- 1. 明确目标:
- 页面类型:列表、详情、表单、仪表盘、信息流、账户、结算、审批、设置
- 用户目标:浏览、决策、提交、管理、确认、恢复
- 状态复杂度:访客/已登录、空/有内容、成功/失败、基于角色的操作
- 2. 阅读相关参考:
- 微信设计原则和小程序约束:references/wechat-design-principles.md
- 设计系统工作流程和反模式框架:references/design-system-pattern.md
- 3. 在编写代码前生成紧凑的页面设计系统:
- 页面焦点
- 信息层级
- 关键组件
- 色彩方向
- 字体排版比例
- 间距节奏
- 动效和反馈规则
- 需要支持的状态
- 4. 优先使用小程序原生组件实现:
- 优先使用WXML + WXSS + 内置组件
- 使用rpx进行布局尺寸设置
- 尊重安全区域和固定底部操作
- 保持JS逻辑状态驱动且明确
- 5. 对照references/wechat-design-principles.md中的检查清单进行交付前审查
输出结构
设计或实现时,按以下顺序组织思路:
- 1. 页面意图
- 主要操作
- 内容层级
- 状态覆盖
- 视觉系统
- 交互细节
除非用户要求完整规范,否则保持简洁。
平台规则
- - 优先针对窄屏移动视口设计
- 避免类似桌面的密集表格、微小控件和依赖悬停的交互
- 不要在微信右上角胶囊区域可能产生冲突的位置放置关键操作
- 保持导航清晰。用户应清楚自己在哪里、下一步能做什么以及如何返回
- 每个屏幕区域优先设置一个主要CTA;次要操作在视觉上应更低调
- 如果页面可能加载失败,绝不要留空白屏幕。显示可见的恢复路径
- 如果数据可能缺失,设计有意图的空状态并提供下一步操作
- 如果需要权限或登录,在提示前说明原因
视觉方向
- - 倾向于简洁、高对比度、移动端可读的布局,而非装饰性复杂
- 仅在仍支持快速理解的前提下使用大胆的视觉方向
- 围绕1个强强调色加稳定中性色构建
- 在添加额外装饰前,使用卡片、间距和字体排版创建层级
- 保持图像有目的性。主图绝不能掩盖核心操作
- 动效应解释状态变化,而非装饰空闲元素
常见小程序模式
- - 列表:仅当实质性帮助扫描时使用粘性筛选器;保持滚动性能
- 详情页:标题、摘要、信任/上下文、主要CTA、次要内容
- 表单:短段落、明确标签、内联验证、提交状态反馈
- 底部栏:仅保留最重要的操作;支持安全区域内边距
- 管理页面:清晰显示角色、状态和允许的操作,减少权限混淆
反模式
- - 将网页落地页美学直接复制到小程序任务页面
- 首屏出现多个竞争性CTA
- 在繁忙图片背景上使用浅色文字,缺乏可靠的对比层
- 长而未分组且仅用占位符标签的表单
- 请求失败时显示空白屏幕
- 破坏性操作与主要确认操作样式过于相似
- 过度使用渐变、玻璃效果或阴影堆叠,影响小屏幕可读性
- 密集信息块缺乏章节标题或间距节奏
实现说明
- - 建立新视觉方向时,优先使用页面级标记或CSS变量
- 如果代码库已有设计语言,复用现有项目模式
- 如果现有页面不一致,先对齐微信设计原则,再改进美观度
- 审查代码时,优先处理可用性回归问题,而非纯视觉意见
参考
- - references/wechat-design-principles.md
- references/design-system-pattern.md