Design Engineering Worked Examples

Apply component contracts to settings, asynchronous search, and destructive list actions with explicit recovery cases.

GitHub에서 원문 보기 ↗새 탭
원문 가이드 ENGLISH

Primary role: product interaction recipe collection.

Repository Boundary

These fictional examples connect decisions to expected behavior. They are neither shipped components nor captured product evidence. Values and presentation belong to the consumer; the referenced Layout recipes retain their spatial boundaries.

The separate Interaction Lab implements the save and search contracts as a local web prototype. Its browser observations apply to that exact example and source snapshot; they do not prove a consumer backend or the destructive-action recipe below.

Reusable Method

Choose a matching user task, adapt its state ownership through the Component Contract, and execute the listed failure cases in the consuming application. The decision is incomplete until expected and actual results are recorded separately.

The State Management recipes expand these tasks into explicit pattern stacks and substitution rules, including a multi-step form. These existing scenarios remain at their original anchors.

Settings With Explicit Save

Task: edit preferences, inspect changes, and save intentionally. Compose the SaaS Settings recipe; let its selected patterns own page structure and scrolling. The form owns the editable draft, the operation owns the submitted snapshot, and persistence determines success.

Keep field errors beside their inputs and provide a route to the first relevant error. On network failure, retain all entered values. A successful save of an older snapshot must leave subsequent edits dirty. If leaving the screen can lose changes, define discard/cancel/save behavior and what happens if saving fails.

Test Expected behavior
Submit missing required input Expose the error and retain other values
Submit, edit again, then receive success Confirm the submitted snapshot; preserve later edits
Fail and retry Keep the draft; issue the retry under the declared request policy
Cancel navigation with dirty data Stay on the form with the same draft and a usable focus target

Evidence still needed: keyboard/error announcement, persistence responses, and source-bound runtime capture. A prototype cannot prove real data was saved.

Search With Detail Selection

Task: search a collection and inspect an item without losing the search context. Compose List Detail. Separate query text, submitted query, active request, results, and selected item identity. Displayed detail must name the selected item even when the result set refreshes.

Keep typing responsive; a request for an older query cannot replace a newer result. Distinguish “no results” from loading and failure. On a tight surface, preserve selection and query when navigating between list and detail. If the selected item disappears, choose a documented empty detail or next-item policy instead of silently showing stale data.

Test Expected behavior
Submit A, then B; resolve B before A Results remain for B after A arrives
Receive zero results Show the submitted query and a recovery action
Resize with detail selected Preserve selection and query; keep focus on a logical available target
Remove the selected item remotely Explain its unavailability or choose the documented next target

Evidence still needed: out-of-order response trace, selection identity, tight/wide rendered states, and input coverage. Motion is optional; use Reorder and Filter only when it communicates stable identity.

Destructive Action In A List

Task: remove a selected item with understandable consequences. Separate the initiating control, decision surface, pending operation, and final list update. Choose confirmation or undo from actual reversibility and product requirements. Do not offer undo when the backend cannot restore the item.

Name the affected item and scope. During pending deletion, prevent unintended duplicate operations according to the contract. Failure preserves the item and a recovery path. On success, return focus to an appropriate neighboring item or list heading if the invoker was removed. A dialog's visual exit must not leave a blocker behind.

Test Expected behavior
Cancel confirmation No deletion; return to the invoker
Fail the operation Explain failure and preserve the item
Succeed while filters change Remove by stable identity, not old row position
Remove the final item Present an empty state and a logical focus destination

Evidence still needed: actual operation result, focus trace, dialog semantics, and recovery behavior. Use Modal Transition only for optional presentation.

Implementation Handoff

example: # settings-save, search-detail, or destructive-list-action
consumer_reference: not_applicable
consumer_reference_reason: These fictional examples select no consumer-owned profile or evidence record.
layout_source: # the selected recipe and the consumer's pinned revision
state_owner: # component, screen, and persistence responsibilities
acceptance_cases: # adapted rows above
observed_results: not_run
remaining_evidence: # actual runtime, input, device, and user evidence

Product Story And Media Handoff

Start with an observation sheet for a product homepage: section job, reading order, scene boundaries, changing objects, media crop, and source-confidence level. Record an unknown rendering mechanism as unknown; cinematic appearance alone does not establish video, Canvas, WebGL, or a library.

Decision Product-owned record Verification
Typography and rhythm Heading measure, copy length, spacing, contrast and image ratio Real copy, text growth, narrow windows
Scene composition Subject identity, crop and focal point, transparent layers, background transitions First/middle/last and transition frames
Media export Dimensions, frame order, codec/format, alpha, poster, source/license Decode readiness and failed asset
Runtime budget Download bytes, decoded-memory estimate, cache and concurrency limits Slow requests, repeated reversal, idle work
Static equivalent Every essential message in semantic HTML, explicit reading mode No script, reduced motion, keyboard access

Use the Motion scene contract and compare the Flow and headphones examples. Their shared controller demonstrates content substitution; both are related local examples and establish no independent adopter evidence. Their different typography, colors, and assets remain product choices.

Complete one representative scene before producing an entire video or image sequence. Review its composition and transition framing, then export at the target dimensions. A polished poster does not validate the intervening frames. This section is locally authored practice guidance, not adapted external visual expression.

Persistent Subject And Page Navigation

The Flow story keeps one device shell mounted while its screen content and pose change with progress. The Scene Navigation example carries that same identity principle into a page whose chapter selection changes while document position stays fixed. Background, text, device pose, and screen layers share one state owner. These are local product treatments, not profile values or reusable Layout CSS.

For this page type, add an input map and URL/history contract to the visual handoff. Specify which surface owns wheel/swipe, which copy regions retain native scrolling, how a focused outgoing action is recovered, and how the user reaches ordinary reading. Review intermediate frames as well as the endpoints; semantic availability must not depend on a visual completion callback.

Opinionated Guidance

Preserve the user's work across recoverable failures. Status text should explain the real operation; motion and color alone are insufficient descriptions of what happened.

Platform-Specific Guidance

Native navigation, browser history, component libraries, and platform controls differ. Record the exact implementation of cancellation and focus return rather than copying a screenshot's apparent behavior.

Unsupported Absolutes

Confirmation is not always safer than undo. Optimistic updates are not always appropriate. A worked example does not certify a consumer migration or establish universal usability.

Verification Contract

Execute all adapted acceptance rows plus long text, empty content, relevant constraints and preferences, and every claimed input method. For a migration use the larger Migration Readiness contract. Review these examples when an observed failure lacks an owner or recovery action.

Source, License, And Attribution

Locally authored scenarios and expected-result tables. Repository links provide spatial and evidence contracts, not proof that these scenarios have run.

IA Navigation

Parent: Design Engineering. Next: Interface Craft Decisions.