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
2. Primary action
3. Content hierarchy
4. State coverage
5. Visual system
6. 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#

• references/wechat-design-principles.md
• references/design-system-pattern.md