Auteur playbook · Mobile application

Design for the interruption, not the ideal session.

A mobile flow must work while permissions are denied, networks weaken, devices sleep, keyboards resize the viewport, uploads pause, and people leave midway through a task.

Complete build process

Five stages from field reality to a dependable release.

Responsive layout is only the visible layer. The playbook treats device capability, permission, local state, sync, and interruption as product behavior.

01 · FRAME

Observe the real task conditions

Define where, when, and how the task happens—not only what the finished screen should contain.

Questions

  • Which hand, device, light, noise, and attention conditions exist?
  • Which permissions and hardware are essential?
  • What happens when the task is interrupted?

Artifacts

  • Field-context map
  • Device and permission assumptions
  • Offline and interruption scenarios

Exit when: the team understands the physical and technical conditions surrounding the user decision.

02 · DIRECT

Specify state before screens

Define capture, draft, validation, upload, sync, conflict, correction, completion, and recovery states.

Work

  • Choose PWA or native capabilities from evidence
  • Map foreground, background, offline, and resumed behavior
  • Define permission-denied alternatives and data retention

Artifacts

  • State and sync model
  • Permission decision tree
  • Supported-device and accessibility matrix

Exit when: every material interruption has an intended state, explanation, and recovery path.

03 · DELIVER

Build one resilient device task

Deliver capture, local preservation, review, correction, synchronization, and confirmation as one slice.

Sequence

  • Local state and draft persistence
  • Permission and device adapter
  • Upload/sync service and conflict rules
  • Responsive/native UI and feedback

Guardrails

  • No silent loss after backgrounding
  • No duplicate submission after retry
  • No unexplained permission dead end
  • No success state before durable save

Exit when: the task remains useful after one ordinary interruption and one network failure.

04 · VERIFY

Test on devices and through failure

Emulators accelerate coverage; supported physical devices verify the behavior people will actually experience.

Test

  • Small and large screens, orientation, keyboard, safe areas
  • Permission allow, deny, revoke, and settings return
  • Offline start, connection loss, slow upload, resume, and conflict

Also verify

  • Screen reader, text scaling, contrast, motion preference
  • Battery and memory-sensitive paths
  • Deep links, notifications, install/update, and store build

Exit when: supported device evidence—not responsive-browser inference—meets the acceptance criteria.

05 · LEARN

Observe device-specific failure

Segment completion, abandonment, crash, permission, sync, and correction evidence by meaningful device conditions.

Review

  • Where drafts are recovered or lost
  • Which permissions cause abandonment
  • Which devices, versions, or networks fail disproportionately

Update

  • Support matrix
  • Device regression suite
  • Recovery rules and next bounded slice

Repeat when: platform updates, device evidence, or real field behavior invalidates an assumption.

Worked example

A field inspector captures evidence in an unreliable environment.

The feature is not “add photo upload.” The product task is a recoverable inspection that remains trustworthy under interruption.

  1. 01

    Begin locally

    Create an inspection draft before requesting media or network access.

  2. 02

    Ask in context

    Explain camera or microphone permission at the moment its value is clear.

  3. 03

    Preserve capture

    Save photos and notes locally with visible upload state.

  4. 04

    Review extraction

    Show AI-extracted details as suggestions the inspector can correct.

  5. 05

    Synchronize safely

    Retry idempotently and reconcile conflicts without duplicate records.

  6. 06

    Confirm truthfully

    Show completion only after the durable remote state is verified.

Result: the field task survives actual mobile conditions instead of succeeding only in a connected demo.

Definition of done

Mobile quality has three environments.

Test the interface, device, and service as a connected system.

Interface

  • Touch targets and gestures are forgiving
  • Keyboard and safe areas do not obscure actions
  • Text scaling and screen readers preserve meaning
  • Progress and recovery are visible

Device

  • Permissions can be denied and restored
  • Backgrounding preserves the draft
  • Storage and hardware failures are handled
  • Supported physical devices are tested

Network

  • Offline behavior is intentional
  • Retries are idempotent
  • Conflicts reconcile visibly
  • Confirmation reflects durable state
Compare product realities

Is the primary user an employee operating a governed workflow?

The internal-tool playbook adds approval, escalation, audit, and operational authority to the same five-stage method.

Open the internal-tool playbook →