android-mobile-frontend-design

What this skill does

# Android Mobile Frontend Design

## When To Use
- Use this skill when the request is about: android mobile frontend design, design android screen from scratch, redesign android mobile screen.
- Primary outcome: Design Android mobile frontend experiences from scratch, improve existing screens, and fix UI issues with brand-forward, localization-safe, overflow-safe guidance across Compose and Views.
- Use this skill when the work is design-intent first: hierarchy, rhythm, screen structure, navigation chrome, spacing, surface model, visual direction, overflow safety, or localization-safe mobile UX.
- Reach for this skill before implementation details when the user wants a screen to feel premium, modern, polished, clearer, calmer, more branded, or more mobile-native.
- Read `references/patterns.md` when you need the create/improve/fix routing matrix, Compose-vs-Views handoff rules, or the localization and overflow stress checklist.
- Read `references/scenarios.md` when you want docs-only walkthroughs for new-screen design briefs, OrbitTasks redesign reviews, or overflow/localization repair passes.
- Handoff skills when the scope expands:
- `android-compose-foundations`
- `android-material3-design-system`
- `android-compose-accessibility`
- `android-viewsystem-foundations`
- `android-testing-ui`

## Operating Modes
### `create`
- Use when a screen does not exist yet or exists only as a rough idea.
- Start from user goal, primary task, state model, and mobile hierarchy instead of jumping to colors or components.
- Decide the screen's dominant pattern early: list-detail, feed, form, dashboard, onboarding flow, confirmation flow, or settings surface.

### `improve`
- Use when a screen works functionally but feels generic, cluttered, dated, confusing, or visually weak.
- Audit what to preserve first: task order, user mental model, brand constraints, and the pieces already carrying useful meaning.
- Redesign hierarchy, spacing, affordances, and action emphasis without changing product intent unless the request explicitly asks for it.

### `fix`
- Use when a screen already exists and has concrete UX defects: clipped text, awkward spacing, unreachable actions, poor hierarchy, broken insets, bad RTL, weak loading states, or cramped controls.
- Repair the smallest set of layout and interaction decisions that restores clarity before proposing a full visual overhaul.
- Treat "cut" as clipped, cropped, truncated, obscured, or otherwise visually broken UI and handle it as a first-class failure mode.

## Workflow
1. Choose the operating mode first: `create`, `improve`, or `fix`.
2. Define the screen job in mobile terms: who is using it, what they must complete fast, what they must understand at a glance, and what deserves confidence or calm.
3. Decide the information hierarchy before styling: primary action, dominant content block, secondary actions, supporting metadata, and recovery states.
4. Choose the right mobile shell for the job: top app bar, bottom bar, rail, sheet, FAB, segmented control, tabs, or list-detail split based on device size and task frequency.
5. Build a surface model that is intentionally brand-forward but still Android-usable: density, corner language, depth, color posture, and typography emphasis should express the product without fighting touch ergonomics.
6. Stress the layout against real mobile constraints: long strings, translated labels, multiline text, RTL, narrow widths, large widths, keyboard, system bars, cutouts, split-screen, tablets, and foldables.
7. Validate action reachability, touch targets, hierarchy, contrast, and scanning speed before handing off to implementation skills.
8. Route the implementation correctly:
- `android-compose-foundations` when the design is settled and the work is Compose structure/layout.
- `android-material3-design-system` when the work is tokenization, theming, or custom design-system translation.
- `android-compose-accessibility` when semantics, focus, or assistive behavior needs dedicated work.
- `android-viewsystem-foundations` when the owning surface is XML/ViewBinding/Fragment UI.
- `android-testing-ui` when the design is ready for screenshot or interaction verification.

## Amazing UI Quality Bar
### What "amazing" means in a mobile Android UI
- The first screenful answers three questions instantly: what this screen is for, what matters most, and what the user should do next.
- The screen feels authored rather than assembled from default components: spacing, type scale, color emphasis, depth, and motion all reinforce the same product personality.
- The primary action is obvious without becoming noisy.
- The UI remains attractive under stress: translation, font scaling, keyboard, gesture navigation, split-screen, and large-screen resizing do not collapse the experience.
- The product feels premium because it is confident and friction-aware, not because it piles on gradients, glass, or decorative chrome.

### Practical craft rules
- Use a consistent spacing rhythm grounded in Android's 4dp grid, but let the screen breathe where clarity benefits from more separation.
- Build typography with distinct jobs: overline/kicker, headline, section label, body, metadata, and action text should not blur together.
- Let one element dominate each viewport region. If headline, filter row, cards, and CTA all compete equally, the design has no conductor.
- Prefer fewer, stronger surfaces over many weak cards and dividers.
- Use color to clarify state, action, and trust. Do not use accent color as wallpaper.
- Motion should reveal structure, preserve context, or confirm state change. Remove it if it is only decorative.

### Screen-family best practices
- Lists and feeds:
  make item hierarchy scannable in under a second, keep row density intentional, and make secondary metadata quieter than the decision-driving content.
- Forms:
  keep labels persistent, make validation and requiredness obvious, and ensure keyboard progression never hides the active task.
- Dashboards:
  do not import desktop density by default; group content into a clear narrative of summary, decision, and drill-down.
- Onboarding and empty states:
  one idea per screen, one primary move, and copy that explains value before detail.
- Sheets and dialogs:
  use them for focused decisions or contextual flows, not as a place to hide full screens with broken navigation.

## Design Direction
### Start with mobile intent, not decoration
- Decide what the user must do one-handed, what can live below the fold, and what must stay visible through motion, keyboard, and narrow widths.
- Mobile UI should feel authored, not squeezed-down desktop UI. Small screens punish weak hierarchy faster than any design review does.
- Brand-forward does not mean louder by default. It means the interface feels deliberate, memorable, and specific to the product instead of generic Material scaffolding.

### Pick a clear visual posture
- Use one dominant posture per screen family:
- `confident utility`: dense, clear, fast, highly legible, restrained color.
- `calm guidance`: more air, stronger sectional rhythm, gentle emphasis, friendly onboarding and empty states.
- `premium trust`: layered surfaces, disciplined motion, richer typography, higher confidence for money, health, or irreversible actions.
- `expressive brand`: stronger color, memorable shapes, and signature layout moves, but still touch-safe and readable.
- Keep the posture consistent across related screens. A premium dashboard and a flat, generic detail screen usually means the system is not yet coherent.

### Create mode specifics
- Start with:
- screen goal
- user state and urgency
- primary action placement
- content order
- state planning for loading, empty, error, offline, and success
- Choose the shell around the primary action:
- bottom action areas for flow completion
- floating action only when it is the dominant repeatable action
- sheets for contextual, interruptible actions
- tabs or segmented controls o