← Back to Mobile app developers

Skill · Version 1.0.0

Mobile design handoff

Turns mobile design decisions into implementable screen flows, state rules and observable acceptance criteria.

mobile-design-handoff

Team members using this skill

See how it helps

When is it useful?

Use when developers need more than static mockups to implement a mobile journey.

What does it help you do?

  • Documents entry points, back behavior and component hierarchy.
  • Specifies inputs, safe areas and platform differences.
  • Includes exceptions, complete state matrices and unverified assumptions.

Try asking this

Prepare a booking-flow handoff with notification entry, cancellation, keyboard behavior and concrete acceptance checks. Specify the same booking entered from a notification and from the calendar. Developers should know the intended Back destination and recovery after a rejected save.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Design Handoff & State Specification

Deliver complete, unambiguous mobile specifications so the mobile developer can implement every screen, interaction, state and edge case without guessing.

1. The standard handoff structure

Structure every mobile design specification and handoff in this order:

  1. User goal & context: who the user is, the trigger/situation, and the measurable outcome of the flow.
  2. Screen flow & navigation map: entry points (tabs, deep links, notifications), screen sequence, modal vs push transitions, and back/cancel behavior.
  3. Screens & component hierarchy: layout structure, reusable vs new components, design tokens, safe-area behavior and responsive rules across phone/tablet sizes.
  4. Interactions & inputs: tap actions, gestures (plus visible alternatives), keyboard types, return-key actions, focus progression and haptic/visual feedback.
  5. Complete state matrix & exceptions:
    • Loading: initial skeleton/spinner, pull-to-refresh, and in-flight button/submission states.
    • Empty: first-time empty state vs zero-results search/filter state, with the next action.
    • Populated & edge content: single item, many items (pagination/infinite scroll), long text, missing optional fields or images.
    • Error & offline: field validation errors, server errors, network loss/timeout, stale cached data indicator, and retry/recovery actions.
    • Interrupted & resumed: behavior when backgrounded, rotated or reopened mid-task.
  6. Platform differences (iOS vs Android): where the two platforms share product logic and where navigation bars, sheets, pickers, permissions or back gestures follow native platform conventions.
  7. Testable acceptance criteria: concrete, observable checks for the developer and reviewer/tester, plus an explicit list of any unverified assumptions or simulated prototype limits.

Before you finish

  • Handoff follows: user goal -> screen flow -> components -> interactions -> states & exceptions -> platform differences -> acceptance criteria.
  • Loading, empty, populated, long-content, offline, error and interrupted states are all specified.
  • No critical interaction or edge case is left for the developer to invent during coding.

Included files 1

  • SKILL.md