Wearable Device Interaction Design Guidelines
Let the wearer know whether the device is available, what it is doing, and whether the data can be trusted, and let them keep control of their own tasks and data after removing the device, charging it, disconnecting, or switching devices.
6 principles · 14 rules · MUST 0 · SHOULD 0
Contents
Let the wearer know whether the device is available, what it is doing, and whether the data can be trusted, and let them keep control of their own tasks and data after removing the device, charging it, disconnecting, or switching devices.
Companion files: Design Token · Reference Sources.
1. Scope and how to read
Applies to interaction on watches, bands, and smart rings with a screen, and on screenless body-sensing devices, including the companion apps necessary to complete tasks. Covers initial setup, daily wear, on-device operation, sensing feedback, removal and charging, connection recovery, and device removal. Ear-worn and head-worn devices MAY adopt applicable clauses, but this document does not declare coverage of their entire experience, nor does it prescribe material, structural, or medical-certification requirements.
Products MUST declare their applicable profile based on actual capability, rather than inferring functionality merely from a "watch / ring" name:
| Profile | Must be made explicit | No default assumption |
|---|---|---|
| Screened wrist-worn device | Each entry point (watch face / card / full app), display lifecycle, touch and physical input, font size and focus | A screen does not imply support for always-on display, a crown, an independent network, or effective wear detection |
| Screenless band / ring | Available feedback, control endpoint, offline capability, status query, fault and exit paths | No visual token is mandatorily configured; when the companion endpoint is unreachable, no immediate viewing or remote stop is promised |
| Companion app | The device and subject it belongs to, data timestamp, whether control has been delivered, the continuation entry for an unfinished operation | "Device added" does not mean currently connected or that data is currently synced |
MUST denotes an acceptance obligation; MUST NOT is an equally strong prohibition; SHOULD is followed by default, with deviations requiring a recorded rationale and equivalent verification; MAY is optional. Judgment is made by independent obligation clause; applicability and boundaries qualify the scope; examples and candidate parameter values add no obligations.
Rules, contracts, and the state model are this project's design. Platform materials support only the specific parts noted. Each rule is verified separately for whether users can understand and use it, and whether the implementation provides genuine state and control.
2. Principles and rules
| Principle | Object and direction | Rules |
|---|---|---|
| WD1 Wearing is understandable and adjustable | Body contact, wearing choices, and identity eligibility | WD1-1, WD1-2 |
| WD2 Capability matches the entry point | Device tasks and entry-point information | WD2-1, WD2-2 |
| WD3 Input and output are controllable | Activation, operation paths, and content exposure | WD3-1, WD3-2, WD3-3 |
| WD4 Sensing results are judgeable | Collection purpose, measurement quality, and freshness | WD4-1, WD4-2 |
| WD5 The lifecycle is predictable | Display, power consumption, and ongoing tasks | WD5-1, WD5-2 |
| WD6 Connection and data ownership are recoverable | Device association, progress already formed, and removal consequences | WD6-1, WD6-2, WD6-3 |
3. Full rules
WD1-1Wear position and contact issues have a usable adjustment path
Applies totasks that depend on a specific wear position, orientation, body contact, or continuous wearing.
Requirement: the wear conditions the task needs MUST be stated, and an actually usable check-and-adjustment path MUST be provided. When multiple positions or orientations are supported, user choice SHOULD be preserved, and control and presentation MUST be verified to work under those conditions. When insufficient contact affects the task, the affected part MUST be expressed; requiring tighter or longer wearing MUST NOT substitute for a reasonable adjustment or removal path; comfort or contact states that cannot be observed MUST NOT be filled in as normal.
Boundaries: a device is not required to have a contact sensor it does not possess; when automatic detection is unavailable, provide manual-check instructions. A specific wear problem cannot be diagnosed merely from the absence of data.
Design applicationwhen unstable contact is detected, prompt the user to check the position; when the cause is unknown, state "no valid sample currently" and offer checking the fit and retrying later.
Verificationuser side — can understand and adjust on the left or right wrist, with the hand actually available, and under different fit conditions; implementation side — check the contact facts, that settings take effect, the control direction, and the unknown branch.
CounterexamplesUnder-delivery — worn but there is no data and no explanation; over-delivery — every viewing requires recalibration or continuously tightening the device.
BasisWD-S1; the adjustment path is project derivation.
WD1-2On-body state, identity, and authorization are judged separately
Applies tousing wear state, lock state, or subject information to determine content visibility and action eligibility.
Requirement: on-body, off-body, and reading validity MUST be distinguished; wearing does not constitute proof of the wearer's identity or authorization. Facts MUST be bound to the device; when access eligibility is affected, they MUST also be bound to the current subject. Off-body, lock, subject change, expiry, or a temporary reading loss MUST trigger a re-adjudication of the affected content and unexecuted actions; unknown MUST NOT expand authorization. Out-of-order stale observations MUST NOT overwrite an already-confirmed, newer fact.
Boundaries: without wear detection, use explicit identity and preview rules; do not wait for a reading that does not exist. Public content is not forced into repeated authentication because of this.
Design applicationputting the device back on does not automatically restore sensitive detail; an on-body reading from another device does not lift this device's restrictions.
Verificationuser side — understands the reason for the restriction and the path to regain access; implementation side — inject stale readings, no sensor, account switch, wear by a different person, and out-of-order events, and check that authorization is not expanded.
CounterexamplesUnder-delivery — placing it near skin unlocks the account; over-delivery — viewing public weather also requires repeated login.
BasisWD-S2 only proves the sensor type exists; identity adjudication is project derivation.
WD2-1Every task has a clearly defined execution endpoint and capability fallback
Applies toall core tasks, especially tasks that depend on a phone, network, or local storage.
Requirement: which endpoint executes the task, what capability it needs, and what can be done when that capability is missing MUST be declared. Focus SHOULD be on tasks suited to the on-device endpoint; long input or complex judgment MUST have progress that can be saved, with a continuation path that locates accurately back to the same object. A handoff MUST state the target and the received result, and MUST keep a recoverable state before receipt is confirmed; when the target is unreachable, exiting or continuing later MUST still be possible.
Boundaries: a screenless task MAY be queried and controlled via a companion endpoint, but the limits when that endpoint is absent MUST be made explicit. "Please open the phone" MUST NOT be treated as a successful handoff, and not every simple action needs to be pushed to the phone to complete.
Design applicationa ring can save samples offline while the phone handles viewing; a pause on the wrist completes directly when it can be reliably completed on-device.
Verificationuser side — knows which functions do not depend on the phone and where to continue; implementation side — separately disable Bluetooth, network, required permissions, and the receiving endpoint, and check the outcome and exit path.
CounterexamplesUnder-delivery — an entire saved record becomes uninterpretable once away from the phone; over-delivery — every editing function of the phone is moved onto the wrist.
WD2-2Each entry point provides sufficient and truthful information
Applies towatch face, card, notification, full app, indicator light / sound, and companion app.
Requirement: each entry point MUST make explicit the fields it can display, the actions it allows, the input path, the detail target, freshness, and privacy handling. A screened entry point SHOULD express the object, key state, necessary units, and next step first; key negations or consequences MUST NOT be truncated, and text MUST NOT be shrunk to defeat the user's font-size setting. Screenless feedback MUST have an unambiguous meaning; a transient prompt cannot be the sole evidence for a result that needs to be queried afterward. Necessary information MUST NOT be expressed by color, vibration, or animation alone.
Boundaries: a read-only entry point MAY have no primary action; cancel, exit, and necessary detail are not constrained by the primary-action budget. No uniform glance duration is prescribed.
Design applicationa single status indicator states that the device needs attention, with the companion app available for the specific reason; opening the watch face opens the corresponding activity rather than returning to the home screen to search again.
Verificationuser side — restate the object and state on a real device, with enlarged text, and under limited feedback; implementation side — check entry-point navigation, content semantics, update time, and the actual business facts.
CounterexamplesUnder-delivery — a single flash that cannot be reviewed declares sync complete; over-delivery — the first screen is packed with metrics, requiring the wrist to stay raised continuously.
WD3-1Wake and activation match the user's current intent
Applies totouch, physical keys, device gestures, sleeve interference, wet hands, and touch lock.
Requirement: whether the input that wakes the device also activates controls MUST be stated per platform, to avoid a wake intent incidentally executing an unconfirmed old action. Ordinary single-finger operation MUST have a mechanism to avoid mistouch, cancel, or undo appropriate to the task; an irreversible action MUST NOT execute on touch-down, and protection proportionate to the consequence MUST exist before execution. Device-motion triggering MUST be able to be turned off and have an alternative path; touch lock MUST have an actually usable unlock / end method.
Boundaries: it is not prescribed that every platform's first tap only lights the screen. An essentially necessary touch-down response MUST record the function, the reason, and the mitigation; the exception does not apply to an irreversible submission. How an already-sent business operation is checked is covered in WD6-2.
Design applicationafter locking touch, release it with a platform-supported physical input; a sleeve brushing against it will not delete a record.
Verificationuser side — distinguishes wake, confirmation, cancellation, and lock; implementation side — test touch-then-move-away, wake boundaries, sleeve brushing, and exiting while locked.
CounterexamplesUnder-delivery — a mistouch while raising the wrist submits directly; over-delivery — every reversible action gets a long press plus double confirmation.
BasisWD-S7 supports cancellation and action alternatives; the platform activation policy needs device-by-device verification.
WD3-2Declared supported inputs can complete the corresponding tasks
Applies totouch, crown, buttons, gestures, and assistive-technology paths on both screened and screenless devices.
Requirement: the primary action, exit, stop, and recovery entries MUST be reachable under the declared wear and input conditions. The actual hit area MUST meet the applicable platform requirements and MUST NOT compete with adjacent targets; round-screen cropping and system regions MUST NOT block controls. Platform access MUST record the product form, distribution requirements, source version, and actual unit: when distributed against Google Play's Wear OS app-quality requirements, the WO-V2 48 × 48 dp target requirement is accepted per that scope and MUST NOT be substituted with other cases from general design guidance; watchOS, screenless devices, and companion endpoints each declare their own basis. Non-essential fine dragging or multi-finger operations MUST have an alternative. Focus MUST correspond to the actual object and restore to a meaningful position after returning; the target MUST NOT move while the touch point is held down.
Boundaries: hardware that does not exist is not required; wearing it on one hand does not prove the other hand is available. System-reserved keys MUST NOT be arbitrarily occupied by the product.
Design applicationthe crown and screen reader can reach the start and end of a list, pause, and return; a screenless device makes explicit which controls the on-device endpoint can execute.
Verificationuser side — completes the task and exits using the actual assistive technology; implementation side — check the hit box, focus order, name / role / state, and the independent activation path.
CounterexamplesUnder-delivery — stop is visible but assistive technology cannot activate it; over-delivery — a duplicate set of buttons is stacked for every input type.
WD3-3Sensitive display and deliberate viewing are controlled separately
Applies towrist raise, lock, off-body, always-on, notifications, snapshots, screen reader, and audio output.
Requirement: sensitive content MUST have a preview level and a legitimate path to deliberately expand it; text, images, accessibility semantics, app-controllable snapshots, and automatic audio MUST enforce the same eligibility adjudication. After eligibility is lost, converge promptly, not waiting for a layout change; headphone disconnection MUST NOT automatically route sensitive content to the speaker. An authorized user MUST still be able to view it deliberately through assistive technology. Output limits the platform cannot control MUST be stated truthfully.
Boundaries: wearing the device does not prove no one is nearby; a screen reader's deliberate access is not the same as unrequested speaker output. Absolute protection against bystanders or screenshots cannot be promised.
Design applicationa public summary is readable; after deliberately unlocking, the detail is both viewable and audible, and it converges again after removal.
Verificationuser side — can legitimately expand and exit; implementation side — check off-body, subject change, lock screen, snapshot, and audio-routing changes.
CounterexamplesUnder-delivery — the screen hides a balance but it is spoken aloud automatically; over-delivery — an authorized screen-reader user still cannot view it.
BasisWD-S3, WD-S8 support the privacy direction; output adjudication is project derivation.
WD4-1Collection has a purpose, boundaries, and stop conditions
Applies tocollecting body, location, activity, or other sensor data.
Requirement: the purpose, trigger timing, permission, storage location, retention period, and stop method MUST be made explicit. The request SHOULD appear when the related task needs it; after refusal or revocation, the corresponding subsequent collection that the on-device endpoint can control MUST stop, without blocking unrelated functions. Removing the device, turning off wireless, stopping collection, unbinding, and deleting data MUST each state their consequence separately. A temporary observation MUST NOT be solidified into a long-term preference without being chosen.
Boundaries: stopping collection does not automatically delete historical data; turning off Bluetooth cannot be described as having stopped the device's local collection. When an offline device's stop-collection request has not been delivered, this MUST be shown as not yet in effect; independent collection MUST have a pre-defined local authorization boundary and an enforceable stop condition, and MUST NOT wait indefinitely for reconnection. Merely displaying device status does not constitute new collection authorization.
Design applicationstopping recording states that the local record is retained; when wireless disconnects, the user knows whether an already-authorized recording continues.
Verificationuser side — understands the permitted collection and stop scope; implementation side — check the listening, saving, uploading, and actual stopped collection after revocation, not merely checking a toggle.
CounterexamplesUnder-delivery — collection and upload continue after the user disables recording; over-delivery — a public status query also demands every sensing permission.
BasisWD-S3, WD-S4; permission and storage requirements are project derivation.
WD4-2Validity, quality, and estimated nature are not conflated
Applies todisplaying or using measurement, statistical, estimated, and continuous sensing results.
Requirement: whether a reading is currently valid, whether the quality meets the intended use, and whether the result is a measurement or an estimate MUST be judged separately. Data MUST be bound to the source device, the object, the sample range, the unit, and the observation time. A missing measurement MUST NOT be filled in as zero, normal, or no anomaly; insufficient quality MUST NOT be silently treated as a reliable input. A historical value MUST retain its historical meaning; an estimate or interpolation MUST be labeled and MUST NOT be disguised as an actual measurement. When a quality condition fails, state the affected conclusions and the available next step.
Boundaries: the device being on-body does not imply good contact, still less a valid measurement; when the cause cannot be determined, express it as unknown. Users are not required to read raw sensor logs, and no universal physiological threshold is prescribed.
Design applicationthe chart shows the missing interval and the last valid sample, offering a path to check the fit / wait for a sample.
Verificationuser side — distinguishes no data from a normal result; implementation side — inject poor contact, stale samples, disturbed quality, mixed estimates, and data from the wrong device, and check the chart and the dependent conclusions.
CounterexamplesUnder-delivery — a blank period is drawn as a continuous, normal curve; over-delivery — every measurement requires the user to review the underlying sampling.
BasisWD-S1; the quality model is project derivation.
WD5-1Display lifecycle does not change business facts
Applies toa screened device entering always-on, becoming invisible, or returning to the foreground.
Requirement: display state MUST be kept separate from collection, saving, and sync. Always-on MUST, per field, choose to keep the value, show it as historical, placeholder it, or hide it; a dynamic field whose updates are constrained and would be misread as live MUST be placeholdered or removed. Sensitive fields remain subject to privacy adjudication. After recovery, the state MUST be checked before actions that depend on a new value are enabled; public static information and exit MAY be shown first.
Boundaries: system refresh and watch-face-return timing MUST NOT be written by the product as a live guarantee; a valid "recording" state also needs ongoing evidence. This rule does not apply to screenless devices, but they MUST still correctly express business state.
Design applicationa reliable task state is retained, with a transient pace switched to a placeholder; after returning to the foreground, the real update and any interruption are shown.
Verificationuser side — does not read a frozen value as live; implementation side — replay always-on, background, recovery, and mixed-privacy fields, and check that facts do not change with the theme.
CounterexamplesUnder-delivery — a frozen number is still labeled live; over-delivery — dimming restarts recording or clears all content.
BasisWD-S8.
WD5-2Removal, charging, and resource constraints have explicit consequences
Applies totasks that continuously record or are affected by low battery, storage, or system background limits.
Requirement: the capability and state of collection, persistent storage, and sync MUST be defined separately, and the behavior at removal, charging, turning off wireless, low battery, insufficient storage, and putting the device back on MUST each be made explicit. When a promise changes, the affected part and the gap MUST be stated, retainable results MUST be preserved, and a stop or continue entry MUST be provided. A stop confirmation MUST correspond to the actual scope in effect; without remote-control capability, immediate cessation of collection MUST NOT be promised.
Sampling, batching, and upload SHOULD be controlled according to purpose, avoiding useless sensor listening and always-on display. Power saving MUST NOT silently degrade data quality that a task depends on, and remaining recording time MUST NOT be promised without a reliable basis.
Boundaries: an upload in progress does not prove collection is complete; charging does not imply support for wearing while charging. A reminder MUST NOT force the user to forgo necessary removal and rest.
Design application"Device has saved; will sync once connected"; an interruption interval retains an identifiable gap.
Verificationuser side — can distinguish collection, saving, and sync; implementation side — test removal while charging, insufficient resources, disconnection, and process termination, checking the sampling range, persistence, stop confirmation, and device power consumption.
CounterexamplesUnder-delivery — collection stops in the background but the interface keeps showing recording; over-delivery — the screen and all sensors stay lit continuously just to preserve one status prompt.
WD6-1Association, connection, and sync are each independently verifiable
Applies topairing, account binding, disconnection, reconnection, and multi-device use.
Requirement: discovery, user selection, device association, account eligibility, the current link, and data sync MUST be distinguished; discovering a same-named device MUST NOT directly substitute for the user's selection. Every control and its confirmation MUST be bound to the device, the subject, and the task object. After a connection recovers, the current eligibility and pending state MUST be checked; a task MUST NOT be declared available or synced merely because it is associated.
Boundaries: when there is no connection, the last known state MAY be retained, but its timestamp MUST be expressed. Re-pairing is not required after every brief disconnection.
Design applicationshow "Device added, not yet connected; last synced …" with a genuine reconnection path.
Verificationuser side — can distinguish not-yet-discovered, not-connected, and not-synced; implementation side — test same-named devices, account switching, link disconnection, and late confirmations, verifying no cross-device mix-up.
CounterexamplesUnder-delivery — a successful association displays all data as synced; over-delivery — every disconnection makes the user unbind and re-pair.
BasisWD-S9; binding objects to confirmations is project derivation.
WD6-2Recovery preserves progress; a submitted consequence is not repeated
Applies totasks that promise to continue across screen-off, process termination, disconnection, or a switch of control endpoint, or operations that produce actual consequences.
Requirement: the save scope, timestamp, location, retention period, and recovery entry MUST be defined. Recovery MUST check the subject, device, object, permission, and valid intent; an unconfirmed draft MUST NOT execute automatically. Authorized-and-pending, sent/accepted, succeeded, failed, and unknown MUST be distinguished. Re-submitting the same business intent MUST use the same operation identifier, guarding against duplication from concurrency and the executed-but-unrecorded-result window; independent, separate operations MUST NOT be swallowed.
An unknown result is checked first; automatic retry is used only when idempotency can be proven and bounded-retry conditions hold. When verification is impossible, a query or later-handling path MUST still be retained. After canceling a pending send, reconnection MUST NOT re-send it; reversing an already-occurred consequence MUST be handled separately according to real capability.
Boundaries: save failure and expiry MUST be stated; not every temporary state is promised to be retained permanently. An acceptance confirmation does not mean the task is complete.
Design applicationwhen the phone's stop-recording request loses its confirmation, reconnection first queries the same task rather than blindly toggling it once to "correct" it.
Verificationuser side — understands the recovery point and the cancellable scope; implementation side — test concurrent re-submission, killing the process after remote completion, a late confirmation, offline cancellation, and two independent operations.
CounterexamplesUnder-delivery — recovery replays an operation that already happened; over-delivery — every screen-off discards the draft and demands starting over.
Basisproject derivation; for connection-limit background see WD-S3.
WD6-3Removing a device accounts for control authority and data disposition
Applies tosigning out of an account, unbinding, switching devices, returning a device, factory reset, or deleting records.
Requirement: before the operation, the affected device, subject, local unsynced data, and cloud records MUST be stated, distinguishing revoking association, stopping collection, erasing the device, and deleting cloud content. Irreversible loss MUST have protection beforehand; a completion confirmation MUST be based on actual evidence for each item. When the device is offline, cannot be erased, or the result is unknown, this MUST be expressed as unverified, with a genuine follow-up path provided; it MUST NOT be claimed that all data has been deleted.
Boundaries: retained data MUST still follow the user's choice; collection the user has already revoked MUST NOT be forcibly restored for the sake of sync. Switching devices does not automatically grant the new device every permission.
Design application"Account association removed; device not yet connected, on-device erasure unconfirmed," with an actionable follow-up.
Verificationuser side — knows which results have occurred and which are unfinished; implementation side — verify offline unbinding, unsynced data, subject change, and partial-erasure confirmations.
CounterexamplesUnder-delivery — deleting only the phone's list declares both device and cloud cleared; over-delivery — unbinding indiscriminately erases the entire history.
BasisWD-S9 supports the boundary of association cleanup; data disposition is project derivation.
4. States and events
| Event | Independent facts that must be checked | User-comprehensible result |
|---|---|---|
| Initial addition | User-selected device, association result, account eligibility, link | Added / pending connection, must not be conflated with synced |
| Wearing or adjusting position | On-body, contact, sample quality, subject eligibility | Can start / needs adjustment / no valid sample |
| Wake and entering detail | Platform activation semantics, object, permission, freshness | Current summary or pending update; does not execute an old intent |
| Entering always-on | Per-field validity and privacy, real business state | Static state, placeholder, or hidden |
| Removal / charging / low battery | Whether collection, saving, and sync can each continue | Saved scope, missing interval, and continuation entry |
| Recovery after disconnection | Source ordering, subject, device, pending operations, and confirmation | Continues the original task or verifies the result; does not replay |
| Unbinding or erasure | Control eligibility, local data, and cloud data each have their own result | Completed and unfinished items expressed separately |
5. Acceptance and delivery
A task design record MUST give: user outcomes, applicable devices and entry points, the normal path, necessary facts and capabilities, alternatives/recovery, the adopted configuration and its rationale, and user-observation and mechanism evidence. Before verification, state the pass conditions and uncovered scope explicitly, and record pass, fail, or the reason for inapplicability per rule.
| Required test combination (applicable per declared capability) | User-side evidence | Implementation-side evidence |
|---|---|---|
| Screenless × no phone × wireless off | Knows when viewing / stopping becomes available | Collection, saving, and control delivery are each correct |
| On-body × poor contact × fresh sample | Not mistaken for a valid, normal measurement | Quality and freshness adjudicated independently |
| Left/right wrist × enlarged text × crown / screen reader | Primary task, first/last item, and exit reachable | Hit box, focus, and activated object are correct |
| Wet hands / sleeve × wake / touch lock | Can cancel, unlock, or end | A mistouch does not cause an unconfirmed consequence |
| Sensitive expansion × off-body × audio switch | A legitimate re-access path remains after convergence | Each output's eligibility is handled in sync |
| Low battery × disconnection × always-on / removal while charging | Distinguishes collection, saving, sync, and gaps | Persistence, power consumption, and actual sampling range have evidence |
| Remote success × lost confirmation × killed process | Understands verification and the recovery point | The same intent yields only one consequence; a stale confirmation does not cross to another object |
| Offline unbinding × local unsynced data | Understands the difference between removed and not-yet-erased | The actual result of erasure in each scope is verifiable |
| Ordinary stationary use | A simple task is not slowed by excessive confirmation | Normal-task and abnormal-recovery business semantics are consistent |
Sensitive leaks, repeated consequences, false success, loss of promised-to-be-saved content, and unreachable necessary control MUST NOT be offset by an average score. Readability, mistouch rate, completion rate, recovery success rate, wrist-raise burden, and power consumption are given targets by the product; record the denominator, the failure/interruption counting method, and the sample and device conditions, not only average time spent. Record the gap between comfort and actual capability; simulator screenshots MUST NOT substitute for wear and assistive-technology testing.
Documentation completeness, mechanism validity, and users actually being able to use it MUST each be demonstrated separately. This document provides design and acceptance requirements; it has not carried out device experiments, user experiments, or domain certification.
Implementation acceptance scenarios
The scenarios below turn existing clauses into reviewable acceptance inputs and set no universal performance thresholds. Select by the product's applicable capabilities and supply real devices, users, input sequences, and evidence; record the reason when inapplicable — unexecuted MUST NOT be recorded as passed.
| Clause | Test input and anomaly | Expected behavior and failure criteria |
|---|---|---|
| WD3-2 | A Wear OS entry point uses smaller controls while the system font size is enlarged. | Check the hit area and text against the actual release scope; do not pass by exception using another form factor. |
| WD1-2 | The device is worn by a different person while the old subject's identity is still cached. | Wearing a reading does not lift identity restrictions; sensitive detail is handled per current eligibility. |
| WD6-3 | The device is removed from the companion app while offline, and erasure is requested. | Association removal, device erasure, and cloud-record deletion each give a genuine result. |
For each scenario, check separately the effective values of the configuration, execution records, and user-comprehensible results. Retain versions, goals, event timing, failure scope, and recovery outcomes; externally unknown outcomes are filled in as neither success nor failure.
Corresponds to the Design Guidelines. This dictionary records the design decisions for device tasks; a complete configuration does not mean the hardware, backend, save, or delete mechanisms have actually been implemented.
1. Layers and format
| Layer | Prefix | Content and boundaries |
|---|---|---|
| Visual token | wearable.visual | Color, typography, spacing, and focus when an actual display interface exists; not required on the on-device endpoint of a screenless device |
| Interaction parameters | wearable.interaction | Actions and information budget actually used for presentation; not universal human thresholds |
| Policy configuration | wearable.policy | Decisions on device profile, input, sensing, lifecycle, recovery, and removal |
| Runtime facts | wearable.runtime | State genuinely reported by the source device; not a design token, and MUST NOT be assigned by a theme |
Required means an applicable task MUST make it explicit; it MAY inherit a resolvable decision. Conditionally required means fully configuring it once the corresponding capability is enabled; without the capability, or when inapplicable, a reason MUST be written — do not fabricate a placeholder value. null is not allowed by default; an omission does not simultaneously mean unknown, off, and unlimited.
In the tables below, the short key concatenated with the prefix gives the full field. Counts are integers; durations are non-negative integer milliseconds with a defined meaning; timestamps carry a time zone. Native dimensions keep their real unit and platform, such as dp/pt, and are not interchanged with CSS px. The visual section MAY use DTCG types and aliases, whose dimension uses px or rem; policy, native device parameters, and facts do not masquerade as DTCG types.
Every decision MUST state its owner, scope of applicability, rationale, effective point, execution dependency, and verification evidence or plan. A referenced target MUST have at least id, owner, appliesTo, decision; it MAY point to a specific documentation section. A missing alias or contract, a cycle, a type error, or an unknown enum MUST be reported against the specific field. Stop depending on a capability with a misconfigured field, retain already-saved results, public queries, and an available exit, and do not fall back to broader permissions.
2. Visual and device profile
2.1 Visual tokens
Prefix wearable.visual. Applies only to display interfaces that actually exist within the configuration scope and are controlled by the product; if a screenless device's companion app falls within this configuration scope, it MUST still have its own visual access point.
| Condition | Field | DTCG type | Semantic alias example | Rule |
|---|---|---|---|---|
| Has primary text | primary | typography | {product.typography.bodyStrong}, the key object and state | WD2-2 |
| Has secondary text | secondary | typography | {product.typography.body}, units and freshness must not become illegible because they are secondary | WD2-2 |
| Has text/background | foreground, surface | color | {product.color.textPrimary}, {product.color.surface}, checked as a pair | WD2-2, WD5-1 |
| Has anomaly presentation | statusAttention | color | {product.color.attention}, must also have text or shape | WD4-2 |
| Has adjacent actions | actionGap | dimension | {product.space.controlGap}, avoiding hit-area competition | WD3-2 |
| Has a content edge | contentInset | dimension | {product.space.contentInset}, combined with the round screen and system region | WD3-2 |
| Has a focusable action | focusIndicator | color | {product.color.focus}, outline and size defined by the component | WD3-2 |
These aliases are access points; they must be mapped to an actual set before they can be imported, or the corresponding role MAY be provided by an explicit platform-native style. A theme does not modify permissions, facts, input protection, or the minimum hit area. Typography follows the user's setting; once enlarged, reduce secondary information or scroll — do not force-fit by shrinking text.
2.2 Platform and capability profile
deviceProfile defines the device's body site, available input/output, display capability, sampling and storage capability, control endpoint, and task scope; the actual running capability must still be probed. surfaceProfiles defines, for each entry point, the fields displayed, the executable actions, the input path, the return object, refresh, and privacy conditions. A screenless status channel is also an entry point.
A screened profile MUST make explicit its components, font scaling, actual hit area, round-screen/safe area, focus, and accessibility semantics. For touch targets against the corresponding Google Play Wear OS app-quality requirements, WO-V2's at least 48 × 48 dp is accepted per that scope; a smaller size from other cases in general design guidance cannot serve as an exemption from this requirement. The platform profile records the product form, distribution requirements, verification date, and specific entries, and does not merge different applicable scopes into one default value. For design guidance see WD-S6; for app-quality requirements see WD-S11. Other platforms use verified component bases and device measurements, not dp converted to pt; font size and always-on refresh have no unified value across devices.
3. Interaction parameters
Prefix wearable.interaction. Configured only when actually consumed by rendering or interaction logic; step count, wrist-raise time, and completion rate are review metrics and belong in the application guide.
| Condition/field | Type and legal values | Candidate and rationale | Effect and verification | Rule |
|---|---|---|---|---|
Quick screened entry point / primaryActionBudget | integer ≥0, unit: item, the cap on primary actions highlighted at once | Prototype candidate 1, focusing on a single task; a read-only value of 0 | Takes effect within safe layout boundaries; cancel, exit, and necessary detail are not counted and MUST NOT be hidden | WD2-2 |
Trimmable secondary information / previewFields | integer ≥0, unit: field | Prototype candidate 2, reducing wrist-raise reading; 0 means optional secondary items are omitted | Necessary objects, anomalies, units, and freshness are not constrained; measured against enlarged text | WD2-2 |
A candidate is not an industry-best value, and being legal does not mean it suits the device. Screenless feedback MUST NOT be forced into "a few visual fields"; feedback semantics and the actual mechanism are defined in the inputOutput contract.
4. Policy dictionary
Prefix wearable.policy; every field is a contract reference, and surfaceProfiles is a non-empty array of references. A given contract becoming invalid only constrains the affected task and does not clear other already-saved results.
| Condition | Field | Minimum decision and handling when missing | Rule |
|---|---|---|---|
| Required | deviceProfile | Actual device, wear site, capability, control endpoint; when missing, the device cannot be declared available | WD1-1, WD2-1 |
| Required | surfaceProfiles | Per-entry-point object, information, action, return, and availability condition; a screenless device must also define state and control paths | WD2-2, WD3-2 |
| Has controlled display | visualSystemRef | Typography, theme, component, and size/focus basis; "any native component" cannot stand in | WD2-2, WD3-2 |
| Required | capabilityContract | Per-task necessary capability, division between on-device/companion/network endpoints, alternative/save/handoff, and receipt confirmation | WD2-1 |
| Depends on wear conditions | fitGuidance | Supported wear positions, detectable problems, manual check, adjustment and removal path; do not falsely report normal without an observation | WD1-1, WD4-2 |
| Has input or output | inputOutput | Activation/cancellation, wake semantics, lock exit, assistive path, feedback meaning, and review; without a reliable path, control MUST NOT be promised | WD2-2, WD3-1, WD3-2 |
| Has sensitive data/operations | privacy | Subject and eligibility basis, preview level, legitimate expansion, convergence of each channel after invalidation; unknown does not expand authorization | WD1-2, WD3-3 |
| Collects sensor data | collection | Purpose, trigger, permission, scope, storage location/period, stop and deletion; revocation immediately tightens on-device-controllable collection, and an offline stop-collection request that has not been delivered MUST state the boundary | WD4-1 |
| Consumes measurement or time-sensitive data | dataValidity | Per-type freshness, quality threshold, estimate/missing-data expression, clock comparison, and dependent-action limits; when insufficient, do not treat as a valid result | WD4-2, WD5-1 |
| Controls always-on display | ambient | default and fieldOverrides; per field keep / timestamped-static / placeholder / hidden | WD5-1 |
| Required | lifecycle | Behavior for removal, charging, wireless off, insufficient resources, and recovery; collection/saving/sync kept separate, and state it if there is no ongoing task | WD5-2 |
| Has device association | association | Independent states for discovery, selection, association, account eligibility, and connection, with verification on reconnection and control-endpoint switching | WD6-1 |
| Has an operation with actual consequences | submission | Intent identifier, target binding, success evidence, duplicate-prevention window, bounded retry, unknown exit, and cancellation semantics | WD6-2 |
| Promises recovery / offline queue | resume | Save scope/timestamp/period, subject-device-object binding, recovery check, pending-authorization period, withdrawal, and expiry handling | WD6-2 |
| Unbindable / erasable / returnable | deviceRemoval | Eligibility, local unsynced content, on-device data, and cloud records each disposed of separately, loss protection, and evidence for each | WD6-3 |
A contract does not merely write "handle as needed": it MUST make the input condition, allowed behavior, prohibited behavior, exception next step, and implementation evidence judgeable. When a product enables measurement, dataValidity MUST make explicit where the quality criterion comes from; a sensor quality score is not fabricated out of thin air just because the dictionary has a quality field.
ambient.keep retains only a field that is still valid and can be accurately understood; timestamped-static shows the original observation time and carries historical meaning; placeholder retains the field name with a note that the current value is missing; hidden hides the field and any accessory content the user is not eligible for. Privacy and data validity take precedence over this policy. Missing configuration does not enable custom always-on retention; a system snapshot is handled per the platform's controllable capability.
4.1 Capability dependencies
| Promise | Must have | When insufficient |
|---|---|---|
| Screenless device queryable/controllable | Actual control endpoint, input/output contract, association and link evidence | State that control was not delivered, and the genuine on-device/later path |
| Continuous recording | collection, dataValidity, lifecycle, persistent storage, and resume | State that it has not started or has been interrupted, retaining existing results |
| Sensitive detail | Current subject eligibility, privacy, actual output channel | Retain the permitted summary and a legitimate re-access path |
| Always-on dynamic information | Display capability, per-field dataValidity, ambient; when sensitive, privacy is also needed | Placeholder or hide; do not fabricate a refresh guarantee |
| Offline queued execution | submission, resume, authorization scope and period, duplicate-prevention coverage | Retain only as draft or pending verification; do not send blindly |
| Remote erasure | deviceRemoval, eligibility, actual delivery, and erasure evidence | State clearly as unconfirmed; do not pass it off as complete |
5. Runtime facts
5.1 Unified encapsulation
Facts MUST be recorded separately by specific key. Collections such as capabilities and continuity no longer use a single overall known flag to mask internal unknowns.
| availability | Required content | Semantics |
|---|---|---|
known | value, source, deviceId, observedAt, receivedAt, ordering | An observation that is still valid; known does not mean the state is normal |
stale | known's original fields plus reason | Retains the original value and original timestamp, purely as history; not changed to current |
unknown | source, deviceId, checkedAt, reason; no value/observedAt | The capability exists but cannot currently be judged |
unavailable | source, deviceId, checkedAt, reason; no value/observedAt | No capability, or currently inaccessible; reason distinguishes unsupported/permissionDenied/systemRestricted |
Access involves binding a subjectId; content and operations bind an objectId, and a targetSnapshotId when necessary. ordering provides a same-source, same-session sequence number or trustworthy time ordering; a device restart distinguishes sessions. When there is no trustworthy mapping between cross-device clocks, do not guess old versus new by local time or arrival order — keep it pending verification; freshness is still judged independently. The check instant is not the observation instant, and reconnecting does not make a stale value fresh again.
5.2 Fact catalog
Prefix wearable.runtime. Drawn on per task need; when inapplicable, record it in the profile — do not fabricate unknown just to fill it in.
| Field | value or collection content | Usage limits |
|---|---|---|
wear | onBody/offBody | Does not indicate identity or that a measurement is valid |
contactQuality | acceptable/poor, with evidence and the checked object | Filled in only with a reliable observation; without detection capability it is unavailable |
measurementQuality | valid/degraded/invalid, with data type, sample range, and reason | Independent of data freshness; MUST NOT be inferred from on-body state |
identity | Subject, lock, permission scope | Not verifiable does not expand authorization; switching subject invalidates the old eligibility |
display | interactive/ambient/hidden | Not applicable to screenless devices; does not affect the real collection state |
capabilities | Each capability encapsulated separately; e.g., network reachable boolean, battery 0–100 number | known+false means known to be unreachable; must not be conflated with lacking detection capability |
association | unassociated/pending/associated, with device and associated subject | Does not automatically imply the link exists or business permission is valid |
connection | disconnected/connecting/connected, with endpoint | connected does not prove the business service is reachable |
sync | idle/queued/syncing/synced/failed, with data scope and evidence | synced proves only the referenced scope, not that collection is complete |
continuity | Separate facts for capture and storage; capture=running/paused/stopped, storage=pending/saved/failed | Each item carries a task and time range; a missing interval is recorded separately, not disguised by interpolated samples |
content | Object, field, unit, measurement/estimate nature, validity basis | Original observation time is kept separate from display update time |
preference | Wear side/orientation, preview selection, scope, source, and effective time | productDefault and user are clearly distinguished; layout safety boundaries take effect |
operation | Operation object as in the next section | known means the on-device process is known; it may contain a remote result of unknown |
removal | Operation reference, affected scope, and evidence for each removal action | No single "everything cleared" boolean substitutes for partial unknowns |
5.3 Legal combinations of operations
Every intent MUST have operationId, objectId, deviceId, the applicable subjectId/targetSnapshotId, submission, and outcome. A confirmed result has a receiptRef or verifiable local evidence.
| submission | Legal outcome | Meaning |
|---|---|---|
| draft | notApplicable | Unconfirmed; does not execute automatically |
| queued | pending | Authorized but not yet sent, cancellable; eligibility and period are checked before execution |
| sent | pending/succeeded/failed/unknown | Handed to the execution endpoint; acceptance or a final confirmation may not yet have been received |
| accepted | pending/succeeded/failed/unknown | Accepted by the execution endpoint; not equal to success |
| cancelled | notApplicable | Confirmed canceled before it was sent; will not be re-sent on reconnection |
sent MAY receive the final result directly without passing through accepted; local execution likewise needs reliable completion evidence. A timeout does not automatically become failed. Canceling after sending keeps the original submission and separately records cancelRequest=requested/confirmed/rejected, independently verifying the original result. Reversing a consequence that has already occurred is a new operation.
A retry keeps the same intent identifier; an independent input uses a new identifier. The valid scope of duplicate prevention covers the allowed offline and retry period; beyond the guaranteed scope, verify first — the confirmation for a stale object or another operation does not update the current task. An unknown result for a stop/delete, etc. cannot be declared a failure just because retries have been exhausted.
6. Override and effect
First resolve the task and capability dependencies, then take the actual facts, compute the common allowed range across identity, permission, privacy, and data limits, and finally resolve the entry point and presentation. User choice outranks the product default but does not loosen limits; a theme handles only the visual.
Off-body convergence, revocation, and subject invalidation act immediately on the related outputs and unexecuted actions; layout, orientation, and the ordinary information budget take effect only once the touch point is released and an edit is safely saved. Safely canceling the current input MUST have feedback. Always-on display passes through privacy → dataValidity → ambient in order; a theme does not restore hidden content. Configuration rollback does not clear consequences that have already occurred and does not replay business actions.
7. Complete design configuration example: offline recording on a screenless device
This is a self-contained design configuration for the on-device recording task, not including the companion app's interface theme. The companion endpoint's query and stop entries are made explicit within the profile; actual integration still needs to be implemented and verified — the example must not be taken as firmware that is already runnable. policy's short keys correspond to the dictionary, and their values resolve within contracts; keys inside a contract describe a specific decision and are not new tokens. There is no visual, always-on, or information-budget content here, because the on-device endpoint has no screen.
{
"task": "ring-local-recording",
"policy": {
"deviceProfile": "device", "surfaceProfiles": ["control"],
"capabilityContract": "capability", "fitGuidance": "fit",
"inputOutput": "io", "privacy": "privacy", "collection": "collect",
"dataValidity": "validity", "lifecycle": "life", "association": "association",
"submission": "submit", "resume": "resume", "deviceRemoval": "remove"
},
"contracts": {
"device": { "id": "device", "owner": "Device owner", "appliesTo": ["ring-local-recording"], "decision": {
"bodySite": "finger", "display": "none", "inputs": [], "localFeedback": [],
"controlEndpoint": "paired-phone.device-detail", "requiredCapabilities": ["sampleCapture", "sampleValidityFlag", "persistentStorage", "pairedControl", "localAuthorizationExpiry", "localRetentionExpiry"]
} },
"control": { "id": "control", "owner": "Experience owner", "appliesTo": ["ring-local-recording"], "decision": {
"endpoint": "paired-phone.device-detail", "object": "selected-device.current-recording",
"fields": ["capture", "storage", "sync", "lastObservedAt"], "actions": ["start", "stop", "query", "remove"],
"input": "phone-native-controls-with-screen-reader", "return": "device-list",
"refresh": "query-on-open-and-after-command", "privacy": "privacy",
"whenDisconnected": "Show the last state with its original time; control cannot be delivered — prompt to connect the device to continue"
} },
"capability": { "id": "capability", "owner": "Device owner", "appliesTo": ["ring-local-recording"], "decision": {
"start": "Requires valid authorization, device connection, and persistent-save capability", "offline": "Collect and save locally within the authorized scope; sync once connected",
"unavailable": "Do not start a new recording; retain existing results and a later-query entry", "handoff": "Do not transfer the collection task"
} },
"fit": { "id": "fit", "owner": "Device owner", "appliesTo": ["ring-local-recording"], "decision": {
"position": "Use the wear-position instructions provided by the hardware", "contactDetection": "Automatic contact-quality detection is not promised",
"invalidSample": "Show no valid sample; offer checking the position and removal/adjustment; do not diagnose a specific cause"
} },
"io": { "id": "io", "owner": "Experience owner", "appliesTo": ["ring-local-recording"], "decision": {
"activation": "Activated by raising on the companion endpoint; movable out to cancel", "wake": "No wake on the display-less on-device endpoint",
"stop": "Send stop once connected; show stopped once execution evidence is obtained", "exit": "Returning to the device list issues no new command",
"result": "The companion endpoint retains a reviewable record and supports the screen reader; disconnection does not promise immediate stop"
} },
"privacy": { "id": "privacy", "owner": "Data owner", "appliesTo": ["ring-local-recording"], "decision": {
"subject": "The currently validly bound account", "publicPreview": "hidden", "reveal": "Account eligibility valid and deliberately opened",
"onIdentityLoss": "Converge sensitive content and block unexecuted control; the on-device endpoint handles it per the established collection-authorization period", "automaticAudio": "Do not speak sensitive content automatically"
} },
"collect": { "id": "collect", "owner": "Data owner", "appliesTo": ["ring-local-recording"], "decision": {
"purpose": "A single recording the user actively starts", "data": ["timestamped-samples", "quality-flags"],
"authorization": "Explicit collection authorization with an end time; must be successfully written to the device before starting",
"stop": "Stop new collection on a valid stop command, on-device authorization expiry, or insufficient persistent storage",
"storage": "Device storage isolated per the bound subject", "retention": "When the user starts recording, separately confirm the collection end time and the save-expiry time for samples later than it, successfully written to the device; on save expiry, clear the referenced local samples"
} },
"validity": { "id": "validity", "owner": "Data owner", "appliesTo": ["ring-local-recording"], "decision": {
"quality": "Only samples that pass the hardware validity flag count as a valid measurement; a missing flag is unknown",
"time": "A sample is always displayed by its original observation time; after the link disconnects, the last collection state is not treated as the current state",
"ordering": "Sequence number within the same device session; re-check when the session changes", "gaps": "Mark missing measurements; do not fill with zero or fabricate an interpolated measurement"
} },
"life": { "id": "life", "owner": "Device owner", "appliesTo": ["ring-local-recording"], "decision": {
"offBody": "Produces no valid body sample; when off-body cannot be detected, judge by sample validity alone",
"charging": "In this example, collection stops and is saved; wearing while charging is not supported", "radioOff": "Still collect and save per the established authorization; sync waits",
"storageFull": "Stop new collection and retain the already-saved scope", "powerLoss": "After recovery, read the persistent checkpoint; record the gap truthfully",
"restart": "Historical records are retained; new collection requires the user to start again"
} },
"association": { "id": "association", "owner": "Connectivity owner", "appliesTo": ["ring-local-recording"], "decision": {
"select": "The user confirms the specific device", "states": "Association, subject eligibility, and link are queried separately", "reconnect": "After checking the subject and device, query the original task and pending operations"
} },
"submit": { "id": "submit", "owner": "Execution owner", "appliesTo": ["ring-local-recording"], "decision": {
"intent": "Assign a stable operation identifier to every user command", "dedup": "Device-side duplicate prevention covers concurrency and executed-but-unconfirmed cases; if unmet, disable the duplicate execution path",
"autoRetry": "Do not auto-resend; query the original operation first", "success": "The execution endpoint's confirmation is consistent with the actual recording state",
"unknown": "Retain the unverified state and a query entry once connected", "cancel": "An unsent command can be canceled; canceling an already-sent one is verified independently"
} },
"resume": { "id": "resume", "owner": "Execution owner", "appliesTo": ["ring-local-recording"], "decision": {
"checkpoint": "Show saved only after a sample block is persisted; persist the intent before the command is sent",
"scope": "Saved samples, the bound subject and device, collection authorization, operations, and confirmations", "retention": "Samples follow collect; a pending operation is retained until verified or the user confirms it is finished being handled",
"restore": "After checking the subject, device, and authorization, read the same record; do not replay an unconfirmed intent",
"expiry": "On sample expiry, clear per the agreed terms and state it; a pending result is not falsely claimed as success", "offlineQueue": "Offline control is not queued for execution"
} },
"remove": { "id": "remove", "owner": "Data owner", "appliesTo": ["ring-local-recording"], "decision": {
"before": "State the disposition of unsynced samples and cloud history; the user chooses each separately", "association": "Revoke the account's control eligibility",
"deviceErase": "Execute by connecting to the device and check the erasure confirmation; loss of contact is unconfirmed", "cloudErase": "Request independently and check the actual result",
"recovery": "Show completed items and items pending connection to process; removing the list item does not declare everything cleared"
} }
},
"validation": {
"status": "pending-device-and-user-tests",
"cases": ["no phone and wireless off", "missing quality flag", "removed while charging", "insufficient storage", "stop confirmation lost", "offline removal"],
"failIf": ["false success", "duplicate command consequence", "sensitive exposure", "loss of promised-saved content"]
}
}
This configuration chooses not to auto-resend and not to queue offline control, so it has no retry-period value; it still depends on genuine duplicate prevention and query mechanisms. If a product instead allows re-submission or queuing, the corresponding period MUST be completed and duplicate-prevention coverage guaranteed. validation is a design-evidence record and does not enter the runtime facts.
8. Configuration acceptance
- The conditionally required items for enabled capabilities are complete; the screenless on-device endpoint is not forced to provide visual values, and the responsibility scope of the companion interface is explicit.
- All contracts, aliases, and platform profiles resolve; units are correct, and candidate values have a rationale and a test plan.
- On-body, identity, contact quality, measurement quality, and freshness are independent; when inapplicable, no reading is fabricated.
- Association, connection, sync, and collection/saving each have evidence; immediate control is not falsely claimed while offline.
- State encapsulation and operation combinations are legal; out-of-order events, cross-clock cases, subject switching, and device restarts are handled.
- Privacy tightening is timely, layout safety takes effect, and always-on is adjudicated per field; necessary control is not constrained by the budget.
- Recovery, duplicate prevention, stop, and erasure all have user feedback and evidence of the actual result.
The checks above verify the design's explainability; device behavior, power consumption, and actual use still MUST be verified per the guidelines.
Configuration delivery and validation
The primary-action budget only limits the primary actions simultaneously highlighted at a quick entry point; cancel, exit, and necessary detail must not be crowded out. Screenless devices do not apply a visual field count; the companion endpoint's "stop sent" is not the same as an offline device having actually stopped collecting. The example being legal only shows that this count type holds.
The accompanying executable sample covers only wearable.interaction.primaryActionBudget; every other field is validated item by item against this dictionary — not being covered does not mean inapplicable or already passed. The sample is a positive/negative format example for the selected field, not a product preset that can directly enable every capability. A complete product delivery additionally includes applicability, dependencies, evidence, execution mapping, and the effective boundary of in-progress operations.
When a field name, type, or meaning changes, update the referencing parties and the acceptance samples; an edit that only clarifies wording without changing legal behavior keeps the existing field name. Callers read the resolved effective configuration and do not back-infer authority, measurement, or completion facts from UI controls, animations, or model text. See the corresponding scenarios.
References
For checking the evidence base of the Design Guidelines and Design Token. Platform documentation supports specific platform behavior, and vendor explanations support specific device cases; this document's rule numbering, contracts, state model, combinatorial tests, and candidate parameters are this project's design and are not claimed to be prescribed verbatim by the sources.
1. Body wear and sensing
WD-S1 · Oura: heart-rate recording gaps
Official explanation: Troubleshooting Gaps in Heart Rate Graphs
- Evidence read: the explanation of recording gaps, wear and contact, motion, and other contributing factors.
- Adopted: on-body does not mean continuously getting a valid measurement; a specific, actionable wear-check path should be provided. Maps to WD1-1, WD4-2.
- Boundaries: this is troubleshooting evidence for a specific device; it does not prove all rings have a contact-quality sensor, does not diagnose body state from missing measurements, and provides no universal wear-tightness parameter.
WD-S2 · Android: off-body detection sensor
Sensor: TYPE_LOW_LATENCY_OFFBODY_DETECT
- Evidence read: the semantics and capability description of this sensor type.
- Adopted: off-body detection is one specific observation capability, used where applicable for on-body/off-body events. Maps to WD1-2.
- Boundaries: a device does not necessarily provide this sensor; an on-body observation does not prove identity, permission, comfort, or sample quality. Modeling these facts separately is this project's design decision.
2. Entry points, input, and device lifecycle
WD-S3 · Google: Wear OS design principles
- Evidence read: the focus, quick comprehension, and usage context of on-wrist tasks.
- Adopted: trade off information and actions around the on-wrist task, reducing unnecessary interaction burden. Maps to WD2, WD3.
- Boundaries: screened on-wrist design is not treated directly as a screenless-device solution, and no uniform step count, touch size, or sustained-screen-gaze duration is derived from the principles.
WD-S4 · Oura: Airplane mode
Official explanation: Airplane Mode
- Evidence read: the explanation of collection and saving, reconnection, and sync after wireless is turned off.
- Adopted: this specific device can keep recording without communicating with the phone, so connection, collection, saving, and sync cannot be treated as one and the same fact. Maps to WD2-1, WD5-2, WD6-1.
- Boundaries: offline duration, storage capacity, exit method, or remote-control capability of other hardware is not extrapolated from this. An application guide's time-limited recording scheme needs actual support from this product's device; it is not a restatement of Oura's feature.
WD-S5 · Apple: watchOS design entry points
Design and build apps for watchOS
- Evidence read: the design overview for on-wrist apps and key-content presentation.
- Adopted: put necessary content and the on-wrist task first, and design by platform entry point. Maps to WD2-2, WD3-1.
- Boundaries: an overview cannot substitute for specific controls, input routing, or on-device testing; a uniform rule that "the first touch only wakes" does not follow from this. This document does not claim to have fully read every linked HIG page.
WD-S6 · Google: Accessibility on Wear OS
- Evidence read: design recommendations for text, targets, semantics, and assistive-technology support.
- Adopted: limited on-wrist space still needs to guarantee readable, operable, and accessible paths. Maps to WD2-2, WD3-2.
- Boundaries: sizes, units, and platform applicability conditions MUST be checked against the actual component; this is not a universal threshold for every wear position, input device, or screenless product.
WD-S7 · W3C WAI: input intent and operation alternatives
Pointer Cancellation · Motion Actuation · Dragging Movements
- Evidence read: the explanations and exceptions for pointer cancellation, device-motion input alternatives, and dragging alternatives.
- Adopted: protect deliberate activation, avoiding binding task completion to a single fine-motor action. Maps to WD3-1, WD3-2.
- Boundaries: the above are explanatory pages; for the normative text see WCAG. A native device should verify against its actual input semantics; adopting similar principles alone cannot declare conformance to all Web success criteria.
WD-S8 · Google: always-on and ambient display
Keep your app visible with always-on
- Evidence read: interactive versus ambient display states, update, and power-consumption constraints.
- Adopted: ambient display differs from continuous interactive display; update capability and lifecycle need dedicated handling. Maps to WD5-1.
- Boundaries: a uniform refresh rate for all devices is not derived from one platform's behavior. This document's per-field definition of keep, timestamped-static, placeholder, or hidden is this project's presentation strategy.
3. Association and configuration expression
WD-S9 · Android: companion device association
- Evidence read: the responsibilities of companion-device association and connection.
- Adopted: the association operation itself does not establish an ongoing connection; being associated cannot substitute for being connected or synced. Maps to WD6-1.
- Boundaries: unbinding, account ownership, device erasure, and cloud deletion still need to be checked against the actual system. WD6-3's requirement to verify each separately is project derivation; that all data has been cleared cannot be inferred from removing the association.
WD-S10 · Design Tokens Community Group: the format
- Evidence read: the expression of types, values, groups, aliases, and dimension, color, and typography.
- Adopted: visual tokens MAY use explicit types and resolvable aliases; dimension's format unit is px or rem, and color follows the corresponding structure.
- Boundaries: this is a Community Group format and is not called a W3C Recommendation; native device units, policy references, and runtime facts do not become standard token types because of it. This dictionary is not a full DTCG file; the example is a task design configuration.
WD-S11 · Google: Wear OS app quality requirements
- Verification date and evidence read: 2026-09-19, Visual Experience's WO-V1, WO-V2, and the page's stated app-quality applicability scope.
- Adopted: apps within the corresponding scope respect the system font size; WO-V2 requires touch targets of at least 48 × 48 dp. Used as the release-acceptance basis for WD2-2, WD3-2, and platform profiles.
- Boundaries: platform distribution-quality requirements and general design recommendations are recorded separately; not extrapolated into a uniform size for watchOS, the Web, screenless devices, or every wearable form factor. Re-check the applicable entries at the time before the target app's release.
4. Evidence discipline
- Rule strength is determined by user outcomes and failure consequences; external materials support only the facts and design principles they actually address.
- A vendor example cannot prove the target hardware's capability, and platform documentation cannot substitute for acceptance testing with a real device and assistive input.
- Candidate values such as
primaryActionBudgetandpreviewFieldsneed project verification and are not treated as constants of human capability. - Documentation, link, and configuration checks can prove only expression consistency; wear comfort, measurement quality, power consumption, offline control, and deletion results still require actual evidence.