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.
- Routes & modules —
lib/core/routes/, lib/modules/, navigation config (GetX routes, go_router, etc.)
- Controllers / state — What data exists, what loads async, what can fail
- Existing widgets —
lib/core/widgets/, module widgets/ — reuse before inventing
- Services & models — Core capabilities, limits, and edge cases
- 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
- Primary navigation — 3–5 top-level destinations max; secondary actions in context, not chrome
- Screen hierarchy — hub → detail → action; avoid deep stacks without wayfinding
- Progressive disclosure — show summary first; details on demand (sheets, expand, tabs)
- Empty, loading, error, success — design all four for every async surface
- 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.
Minimum bar:
Phase 6: Deliverable format
Present designs in this order:
## 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
- Example deliverable snippet: examples.md
1---2name: mobile-ui-ux-design3description: 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.4---56# Mobile UI/UX Design (2026)78Design mobile experiences that feel intentional, fast, and trustworthy. Never decorate first—understand the product, the people, and the paths they take.910## When to apply1112- New screens, flows, or features13- UX audits or redesigns14- Navigation, onboarding, or empty-state work15- Before large UI refactors1617## Workflow1819Copy and track progress:2021```22UX design progress:23- [ ] Phase 1: Product discovery24- [ ] Phase 2: Audience & behavior25- [ ] Phase 3: Information architecture26- [ ] Phase 4: Interaction & motion27- [ ] Phase 5: Compatibility & accessibility28- [ ] Phase 6: Deliverable (spec + implementation notes)29```3031### Phase 1: Product discovery (required)3233Explore the codebase before proposing UI. Do not assume features from names alone.34351. **Routes & modules** — `lib/core/routes/`, `lib/modules/`, navigation config (GetX routes, go_router, etc.)362. **Controllers / state** — What data exists, what loads async, what can fail373. **Existing widgets** — `lib/core/widgets/`, module `widgets/` — reuse before inventing384. **Services & models** — Core capabilities, limits, and edge cases395. **App purpose** — `pubspec.yaml` description, onboarding copy, README if present4041Produce a short **product map**:4243| Module | Primary user goal | Key actions | Dependencies (data/API) |44|--------|-------------------|-------------|-------------------------|45| … | … | … | … |4647### Phase 2: Audience & behavior4849Define who uses the app and how they behave in context—not generic “users.”5051**Audience snapshot** (3–5 bullets):52- Who they are (role, technical level, urgency)53- Primary context (on-the-go, distracted, one-handed, low light)54- Motivation (solve problem X in under Y seconds)55- Trust bar (security, privacy, professional vs casual)5657**Behavior lenses** — apply all four:58| Lens | Question |59|------|----------|60| Intent | What did they open the app to do right now? |61| Anxiety | What makes them hesitate or abandon? |62| Habit | What should become muscle memory? |63| Recovery | How do they fix mistakes without losing work? |6465**Jobs-to-be-done** — one line per core flow: “When I …, I want to …, so I can …”6667### Phase 3: Information architecture68691. **Primary navigation** — 3–5 top-level destinations max; secondary actions in context, not chrome702. **Screen hierarchy** — hub → detail → action; avoid deep stacks without wayfinding713. **Progressive disclosure** — show summary first; details on demand (sheets, expand, tabs)724. **Empty, loading, error, success** — design all four for every async surface735. **Cross-module links** — e.g. list → details → report; preserve back-stack mental model7475Deliver:76- User flow diagram (mermaid or ASCII)77- Screen inventory with purpose per screen78- Navigation map aligned to existing routes (extend routes only when IA truly needs it)7980### Phase 4: Interaction & smooth UX8182**2026 mobile UX principles** (default stance):83- **Clarity over density** — one primary action per view; scannable hierarchy (title → context → action)84- **Predictable motion** — transitions match navigation depth; no gratuitous animation85- **Immediate feedback** — optimistic UI where safe; skeletons for >300ms loads; haptics on confirm only86- **Thumb zone** — primary actions bottom-aligned; destructive actions require deliberate placement87- **Gestures as enhancement** — never hide sole path to action behind swipe-only affordances88- **Trust surfaces** — explain AI, permissions, and data use in plain language near the decision point8990**Motion defaults** (Flutter):91- Push detail: 280–320ms, `Cupertino` or subtle slide92- Modal/sheet: 240–280ms93- List stagger: ≤50ms delay, respect `reduce motion`9495**Micro-interactions** — specify: trigger, duration, easing, reduced-motion fallback.9697### Phase 5: Compatibility & accessibility9899Check before finalizing designs. Full checklist: [reference.md](reference.md).100101Minimum bar:102- [ ] Safe areas, notches, home indicator103- [ ] Small phone (≈320pt width) and large phone / fold inner display104- [ ] Dynamic type / text scaling to 200% without broken layout105- [ ] Dark mode parity (not inverted colors only)106- [ ] Touch targets ≥ 44×44 logical px; spacing for motor difficulty107- [ ] Screen reader: labels, headings, live regions for async updates108- [ ] Offline / slow network states109- [ ] Platform norms (iOS back gesture vs Android system back)110111### Phase 6: Deliverable format112113Present designs in this order:114115```markdown116## UX summary117[2–3 sentences: goal, audience, design stance]118119## Audience & behavior120[Snapshot + JTBD]121122## Flows123[Mermaid or ASCII]124125## Screen specs126### [Screen name]127- Purpose:128- Entry / exit:129- Layout zones: (header | content | sticky footer)130- Primary / secondary actions:131- States: empty | loading | error | success132- Copy notes: (tone, trust, errors)133- Reuse: [existing widgets to extend]134135## Compatibility notes136[Device, a11y, platform]137138## Implementation notes139[Files to touch, route names, controller concerns]140```141142When implementing in Flutter:143- Match project patterns (GetX controllers, existing theme, `lib/core/widgets/`)144- Prefer extending module widgets over new global components145- Keep animation durations consistent with `app_pages` transitions where applicable146147## Anti-patterns148149- Generic dashboard clutter without a clear primary task150- Feature parity desktop layouts squeezed onto mobile151- Hidden navigation (hamburger-only) for apps with >3 main areas152- Modal stacks without dismiss affordance153- AI or security UI that obscures what data is sent154- Skeleton screens that never resolve; spinners with no message155- New design system colors/fonts that ignore `ThemeData`156157## Additional resources158159- 2026 patterns, compatibility checklist, wireframe conventions: [reference.md](reference.md)160- Example deliverable snippet: [examples.md](examples.md)
FUZAIL-GIT