glance → deepen → act.

attention, please!

dynamic island lives in peripheral vision to keep ongoing tasks legible without stealing focus, and only asks for full attention when intent is clear.

the pain
research data shows people stumble on ongoing tasks (music, timers, maps): too many notifications, too much app-switching. live, glanceable surface that updates in place can solve the pain.

the intent
build a continuous, interactive strip at the top that shows essentials by default and expands on press-and-hold for quick actions—optimizing the glance → deepen flow and cutting context switches.

the approach

this case study distills the critical inputs behind the dynamic island motion language and my approach to building it. it covers policies, process, and the key milestones from prototype to ship.

raci matrix

ownership is aligned with responsibilities: policies → hi, feasibility → eng, accessibility → a11y, release → pm. every row links to its artifact (tokens, redlines, spec) and a concrete sign-off.

decision
description
r
a
c
i
motion policies & state model
rules + states (minimal → compact → expanded) incl. 1-up/2-up focus handoffs
am
hi
pd, eng, a11a
pm, qa
surface eligibility + copy/ia
when island vs banner vs app; primary/secondary info + truncation
pd
hi
am
eng, a11y
gestures + affordance cues
tap vs press/hold, hinting; includes haptics/audio pairs
eng
hi
am, pd, a11a
pm
motion tokens + reduced-motion
durations/easing/staggers and rm variants for every transition
am
hi
eng, a11y
pm, qa
landing frames + tokens as code
redlines at rest; json mapping/naming/versioning for delivery
am
hi
eng, ui
pm, qa
cross-surface coherence + visual tone
lock screen/standby/island parity; iconography/weight/emphasis
am
hi
pd
eng
performance budget + feasibility
lock screen/standby/island parity; iconography/weight/emphasis
eng
eng
am, hi
pm, qa
accessibility semantics + contrast
voiceover labels, focus order, hit areas, color/contrast
a11y
a11y
am, eng, hi
pm, qa
qa automation + release gate
pixel/timing diff harness, device matrix; rc criteria
qa
pm
am, eng, a11y, hi, qa
–
telemetry + post-ship tuning
glance→expand, time-to-useful, mis-taps; token tweaks; spec pack
pm
pm
am, eng, qa, a11y, hi
–

the process

the timeline below breaks the work into phases, from early policy and state definition through eng/a11y/qa passes to launch. each step notes my responsibilities and the exit criteria we used to keep the project moving.

motion system specs

my final output was a shippable motion system: token set, state diagram, motion references, landing-frame specs, reduced-motion variants, and a qa/a11y–friendly structure that engineering could build and test against.

state model and events

states
‍minimal — smallest, glance-only.
compact — glance + primary value (progress, countdown, status).
expanded — controls and details.
suspended — temporarily covered by higher-priority ui.
expired — activity finished; collapse and confirmation.

‍events
‍activity starts / updates / ends.
tap (open app), press-and-hold (expand island).
second activity appears (2-up).
reduced motion toggled on/off.

only defined transitions are allowed (for example, compact → expanded, expanded → compact), which keeps behavior predictable.

behavioral policies

eligibility
‍only ongoing, time-sensitive tasks (music, timers, navigation, live updates).
no decorative content.
‍
‍layout invariants
‍each state lands on a fixed template with defined alignment, spacing, typography.
motion can deform within the shape, but resting geometry must match the template.

‍status bar integration
‍island shares space with time, wifi, battery, network.
policies define when those indicators compress, shift, or stay pinned.
transitions use smooth easing so the status bar never “jumps” or jitters when the island changes state.

‍concurrency (1-up / 2-up)
‍at most two activities visible.one primary, one secondary; primary always reads as “in focus.”
tapping secondary swaps roles via a controlled focus handoff.

‍accessibility
‍every transition has a reduced-motion counterpart.
same states, same information, calmer motion.

motion tokens

durations
enter / expand: ~180–220 ms
exit / collapse: ~140–180 ms
small confirmations: ~90–120 ms

quicker end of the range for frequent, low-stakes updates (minimal ↔ compact); longer end for larger state changes (compact → expanded) where users need a moment to parse new controls.

easing
state changes: standard cubic in/out (predictable, easy to implement).
continuous updates (progress, countdown): linear.
subtle spring only on small elements, never on the whole island.

stagger and layering
icon, primary text, secondary text offset by ~20–40 ms.
this enforces reading order: identity → main info → detail.
on denser transitions, combine stagger with brief crossfades or light blur, then return to a sharp landing frame so there are no messy “in-between” states.

reduced-motion deltas
shorter durations inside the same bands.
no springs, no overshoot; simple in/out curves only.
same start and end frames as the standard version.

tokens exist both as a table and as json/config mappings so design, engineering, and qa talk in the same numbers.

landing frames and templates

templates per state
minimal — fixed footprint, one-line content.
compact — defined icon/label/progress layout, safe margins, and status bar relationship.
expanded — control grid, hit targets, text hierarchy, and top-of-screen footprint.

redlines
each key state has measurements for spacing, alignment, rounded corner radii (pill and any “infinite” corners), control sizes, tap areas, and type styles.
the motion rig is derived from these templates: transitions can stretch and mask, but must snap back to the redlined geometry at rest.
any drift in the build versus these frames is treated as a defect.

usage
engineering implements layouts against redlines and the state diagram.
qa compares motion frames and reference clips against these landing frames at known timestamps.

1-up and 2-up behavior, reduced motion, and validation are all wired into the same system: focus handoffs between primary and secondary activities use controlled masking/crossfades so elements never clash, every key transition has a reduced-motion variant with the same states but calmer timing, and a small set of reference flows (including 2-up and rm) is used by qa and a11y as the ground truth for timings, landing frames, and expected reading order.

what worked

template-first approach
treating minimal / compact / expanded as fixed templates with redlines gave everyone a hard target.

‍early concurrency focus
designing 1-up / 2-up focus handoffs early (who is primary, how swaps animate, how status bar behaves) removed a whole class of late bugs and mis-taps.

paired reduced-motion from day one
defining rm variants alongside the main transitions kept accessibility changes small and local instead of becoming a separate rework track.

shared tokens
one token table for durations, easing, and stagger meant design, eng, and qa talked about the same numbers instead of “feels too fast / slow.”

what created churn

late copy and layout changes
small edits to wording or hierarchy in compact state often broke truncation and spacing, forcing re-authoring of motion and redlines.

a11y feedback arriving after polish
when accessibility review happened too late, reducing motion or adjusting hit areas meant touching transitions that were already tuned.

ambiguous “nice to have” animations
any flourish that wasn’t clearly tied to a policy (for example, a timing or priority rule) tended to get debated and eventually cut.

what i’d change

lock policies and states earlier
treat the policy + state diagram as a formal gate; no polished animation work until that’s signed by hi, eng, and a11y.

ship tokens as code up front
expose the motion tokens in a config/json file from the first engineering spike, and add basic checks so drift from design values is visible.

per-family amplitude caps
define separate “ceiling” for media, timers, and system notices so expanded states never over-emphasize low-value events.

artifacts

this project frames dynamic island motion as a system with clear rules, states, and tokens that can be built, tested, and iterated over time. my contribution was to turn loose templates into a motion language that engineering, qa, and a11y can rely on. the same approach scales to other system surfaces where attention is limited and interactions need to stay predictable and accessible.

motion tokens as a base rig

motion rig (tokens plus templates) became the base for a wide range of apps. now playing, timers, navigation, calls, and other live activities all plug into the same expand/collapse behavior, so dozens of different experiences inherit one coherent dynamic island motion language.

copyright © 2025 alex mamay
▲ scroll Up