Mobile app design

Mobile App Design

Ship mobile UI that looks deliberate instead of generated. This skill is a working method plus a critique vocabulary — use it both to build and to audit.

Polish is what happens when persistence and taste meet the science of design. Agents have no eyes. You can only compensate with a checklist and a screenshot.

When to use which mode

Situation	Mode
New screen or flow from scratch	Build — run the pipeline below in order
Existing UI feels off, generic, cramped	Audit — go straight to references/audit-checklist.md
One narrow question (color? gesture?)	Read the matching reference file only

Build pipeline

Run these in order. Do not jump to visuals before step 2 is settled — most bad mobile UI is a structure problem wearing a color problem's clothes.

1. Intent before interface

Ask what the user is trying to do on this screen, and design the shortest path to it. A rental app's intent is "find a place" → the search field is the design. The hero image and the wordmark are decoration you add afterwards, if at all.

Write the intent down in one sentence before you write any code. If you cannot, the screen is doing too many things.

One screen does one thing. Settings is settings. The editor is the editor. The home screen is the only routine exception. When you need to add something new, reach for a different screen, not a busier layout.

2. Structure and navigation

Pick the navigation shell first — it constrains everything else. See references/layout-navigation.md for the full decision tree.

Hard constraints:

• Bottom bar: 5 links is the absolute limit, 3–4 is right. More than that means your information architecture is wrong, not that you need smaller icons.
• Every touch target ≥ 44pt. People have fat fingers. This is not negotiable and it is the single most common failure in agent-generated mobile UI.
• Too many top-level destinations? Don't cram — turn the nav into a full page that becomes the home screen (the Notion pattern), which frees the bottom of the screen for a large search field or primary action.

3. Layout: one direction per section

Desktop lays out content in two directions at once — columns and rows. Mobile gets one direction per section. Either stack items vertically, or scroll them horizontally off the edge. Never both in the same section.

This one rule converts most desktop/dashboard layouts to mobile correctly.

Four building blocks exist, ignoring floating menus: cards, text/links, images, inputs. Everything is a composition of those.

• Never double-nest cards. Padding on padding cramps everything. Group with whitespace instead of a second container — whitespace is a container you don't have to pay padding for.

4. Type and space

Counterintuitive but load-bearing: type gets larger on mobile, not smaller. iOS base font size is 17px; macOS is 13px. Squishing desktop type down to fit more on a small screen is the beginner tell.

• One sans-serif family. You will essentially never need a second one.
• Large headings: tighten letter-spacing to -2% to -3% and line-height to 110–120%. This single adjustment makes big text read as professional.
• Space on a 4pt grid — not because 4 is magic, but because everything stays halvable, which is what produces consistency.
• Group related items with tighter spacing; separate groups with more. Proximity is hierarchy you get for free.

Full detail in references/foundations.md.

5. Color

Do not pick colors ad hoc, and never accept a model's first palette — they trend bright, saturated and mutually hostile. Build the four layers in order: neutral foundation → functional accent → semantic → theming. See references/color.md.

The three rules that catch the most damage:

• Backgrounds stay in the background. Neutral, never a bright gradient.
• Icons need no color. Their job is to be a recognizable symbol. Color is reserved for communicating status.
• Dark mode is not inverted light mode. Dark values need roughly double the distance between steps to read as different, and surfaces get lighter as they elevate — there are no shadows to do that work for you.

6. States — the actual product

Designing only the happy path is what separates a mockup from a product.

Every interactive element needs: default, pressed, disabled (hover does not exist on touch), plus loading where an action takes time. Inputs additionally need focus and error with a message.

Every screen needs its empty states — and there are two different kinds:

• First run: full-screen, points at the primary action, one popover explaining how it works. Do not fill it with fake cards inviting the user to do six things.
• No results: imagery, acknowledge the query explicitly, offer suggestions in case of a typo, and give an action to exit the state.

See references/states-feedback.md.

7. Motion and gestures

Motion is where mobile stops feeling like a website in a phone-shaped box.

• Never linear easing. Real things accelerate and decelerate. The curve carries the tone: snappy, springy, or slow and smooth.
• Motion follows the direction of the swipe. Swipe up → content rises in. Swipe back → the background moves left ~35% and animates right.
• Always pair a gesture with a visible control. Gmail lets you swipe to delete and tap into a menu. Gestures are for the initiated; buttons are for everyone.
• Slide-to-confirm for irreversible actions. Purchases, sends, deletions. It is much harder to slide a slider by accident than to tap a button.

See references/motion-gestures.md.

8. Audit before you call it done

Run references/audit-checklist.md. If you can render or screenshot the screen, look at it and critique it against the eight principles — you cannot evaluate balance and whitespace from source code alone.

Hard rules

Only four things are worth refusing to negotiate. Everything else in this skill is guidance — apply judgement.

1. ≥ 44pt touch targets. Always. This is the most common failure in generated mobile UI.
2. Destructive is red. Even when red is nowhere in the brand palette. A delete button in your brand color is a usability failure, not a brand win.
3. Never ship a screen without its empty and loading states.
4. No emoji as interface icons. Use a real set (Phosphor, Lucide, SF Symbols, Material Symbols) at one consistent stroke weight.

The critique vocabulary

When reviewing a screenshot — yours or a model's output — grade it against these eight. They are the ingredients of "I know it when I see it"; detailed treatment in references/foundations.md, applied rubric in references/audit-checklist.md.

Principle	Failing looks like
Contrast	No obvious focal point; everything competes equally
Hierarchy	Wordmark, tagline and card titles fight for the same attention
Alignment	Elements don't share edges or axes
Proximity	Related things not grouped; unrelated things jammed together
Repetition	Three type weights, two icon styles, four corner radii
Balance	Bottom-heavy or lopsided; one dense block dominates
Whitespace	Every pixel working; nothing breathes
Unity	Reads as a template with content poured in

Unity is what emerges when the other seven agree. If a screen reads as generic, one of them is failing — find which.

Treat generated UI as a base to build on, never as the deliverable. The 30-second tell list lives at the top of references/audit-checklist.md.

Reference files

• references/foundations.md — the eight principles, hierarchy, spacing, type, icons, shadows, signifiers
• references/color.md — the four-layer color system, dark mode, semantic color, OKLCH for charts and theming
• references/layout-navigation.md — navigation shells, bottom sheets, contextual actions, cards, screen composition
• references/motion-gestures.md — easing, the three classes of swipe interaction, transitions, long-press, micro-interactions
• references/states-feedback.md — element states, empty states, loading, errors, toasts, onboarding, optimistic UI
• references/reference-ui.html — a working screen implementing the system (color ramps, type scale, states, components). Open it when you need concrete structure rather than description
• references/audit-checklist.md — the full review rubric, including the 30-second tell list