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.

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.
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
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
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
Run a pre-delivery review against the checklist in references/wechat-design-principles.md.

When designing or implementing, structure thinking in this order:

Keep this short unless the user asks for a full spec.

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.

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.

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.

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.

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.