# Mobile UI UX Design

> Designs mobile app UI/UX like a senior designer in 2026—maps project modules, features, and use cases to flows and screens; centers target audience, user behavior, device compatibility, and smooth interaction. Use when designing screens, flows, wireframes, navigation, onboarding, or UX improvements for Flutter/mobile apps, or when the user asks for UI/UX design, user journeys, or mobile experience work.

- Skill: `fuzail-git/mobile-ui-ux-design` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add fuzail-git/mobile-ui-ux-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fuzail-git/mobile-ui-ux-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: FUZAIL-GIT (https://skillmd.com/u/fuzail-git)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/fuzail-git/mobile-ui-ux-design

---


# Mobile UI/UX Design (2026)

Design mobile experiences that feel intentional, fast, and trustworthy. Never decorate first—understand the product, the people, and the paths they take.

## When to apply

- New screens, flows, or features
- UX audits or redesigns
- Navigation, onboarding, or empty-state work
- Before large UI refactors

## Workflow

Copy and track progress:

```
UX design progress:
- [ ] Phase 1: Product discovery
- [ ] Phase 2: Audience & behavior
- [ ] Phase 3: Information architecture
- [ ] Phase 4: Interaction & motion
- [ ] Phase 5: Compatibility & accessibility
- [ ] Phase 6: Deliverable (spec + implementation notes)
```

### Phase 1: Product discovery (required)

Explore the codebase before proposing UI. Do not assume features from names alone.

1. **Routes & modules** — `lib/core/routes/`, `lib/modules/`, navigation config (GetX routes, go_router, etc.)
2. **Controllers / state** — What data exists, what loads async, what can fail
3. **Existing widgets** — `lib/core/widgets/`, module `widgets/` — reuse before inventing
4. **Services & models** — Core capabilities, limits, and edge cases
5. **App purpose** — `pubspec.yaml` description, onboarding copy, README if present

Produce a short **product map**:

| Module | Primary user goal | Key actions | Dependencies (data/API) |
|--------|-------------------|-------------|-------------------------|
| … | … | … | … |

### Phase 2: Audience & behavior

Define who uses the app and how they behave in context—not generic “users.”

**Audience snapshot** (3–5 bullets):
- Who they are (role, technical level, urgency)
- Primary context (on-the-go, distracted, one-handed, low light)
- Motivation (solve problem X in under Y seconds)
- Trust bar (security, privacy, professional vs casual)

**Behavior lenses** — apply all four:
| Lens | Question |
|------|----------|
| Intent | What did they open the app to do right now? |
| Anxiety | What makes them hesitate or abandon? |
| Habit | What should become muscle memory? |
| Recovery | How do they fix mistakes without losing work? |

**Jobs-to-be-done** — one line per core flow: “When I …, I want to …, so I can …”

### Phase 3: Information architecture

1. **Primary navigation** — 3–5 top-level destinations max; secondary actions in context, not chrome
2. **Screen hierarchy** — hub → detail → action; avoid deep stacks without wayfinding
3. **Progressive disclosure** — show summary first; details on demand (sheets, expand, tabs)
4. **Empty, loading, error, success** — design all four for every async surface
5. **Cross-module links** — e.g. list → details → report; preserve back-stack mental model

Deliver:
- User flow diagram (mermaid or ASCII)
- Screen inventory with purpose per screen
- Navigation map aligned to existing routes (extend routes only when IA truly needs it)

### Phase 4: Interaction & smooth UX

**2026 mobile UX principles** (default stance):
- **Clarity over density** — one primary action per view; scannable hierarchy (title → context → action)
- **Predictable motion** — transitions match navigation depth; no gratuitous animation
- **Immediate feedback** — optimistic UI where safe; skeletons for >300ms loads; haptics on confirm only
- **Thumb zone** — primary actions bottom-aligned; destructive actions require deliberate placement
- **Gestures as enhancement** — never hide sole path to action behind swipe-only affordances
- **Trust surfaces** — explain AI, permissions, and data use in plain language near the decision point

**Motion defaults** (Flutter):
- Push detail: 280–320ms, `Cupertino` or subtle slide
- Modal/sheet: 240–280ms
- List stagger: ≤50ms delay, respect `reduce motion`

**Micro-interactions** — specify: trigger, duration, easing, reduced-motion fallback.

### Phase 5: Compatibility & accessibility

Check before finalizing designs. Full checklist: [reference.md](reference.md).

Minimum bar:
- [ ] Safe areas, notches, home indicator
- [ ] Small phone (≈320pt width) and large phone / fold inner display
- [ ] Dynamic type / text scaling to 200% without broken layout
- [ ] Dark mode parity (not inverted colors only)
- [ ] Touch targets ≥ 44×44 logical px; spacing for motor difficulty
- [ ] Screen reader: labels, headings, live regions for async updates
- [ ] Offline / slow network states
- [ ] Platform norms (iOS back gesture vs Android system back)

### Phase 6: Deliverable format

Present designs in this order:

```markdown
## UX summary
[2–3 sentences: goal, audience, design stance]

## Audience & behavior
[Snapshot + JTBD]

## Flows
[Mermaid or ASCII]

## Screen specs
### [Screen name]
- Purpose:
- Entry / exit:
- Layout zones: (header | content | sticky footer)
- Primary / secondary actions:
- States: empty | loading | error | success
- Copy notes: (tone, trust, errors)
- Reuse: [existing widgets to extend]

## Compatibility notes
[Device, a11y, platform]

## Implementation notes
[Files to touch, route names, controller concerns]
```

When implementing in Flutter:
- Match project patterns (GetX controllers, existing theme, `lib/core/widgets/`)
- Prefer extending module widgets over new global components
- Keep animation durations consistent with `app_pages` transitions where applicable

## Anti-patterns

- Generic dashboard clutter without a clear primary task
- Feature parity desktop layouts squeezed onto mobile
- Hidden navigation (hamburger-only) for apps with >3 main areas
- Modal stacks without dismiss affordance
- AI or security UI that obscures what data is sent
- Skeleton screens that never resolve; spinners with no message
- New design system colors/fonts that ignore `ThemeData`

## Additional resources

- 2026 patterns, compatibility checklist, wireframe conventions: [reference.md](reference.md)
- Example deliverable snippet: [examples.md](examples.md)