Turn a need into a testable prototype and interface

A reading-panel prototype has tidy lists and attractive images, but the user needs to find a document, confirm its version, and begin reading. Define the task, inputs, states, and result first, then turn observed needs into implementable interface rules.

The independent panel has course filters, results, and details. All documents are synthetic. The code checks state coverage without creating a design file, browser interface, or image.

Test one explicit assumption

An assumption might concern recognizing the newest version or finding its source. Specify the task, starting point, success, and likely failures. One prototype cannot establish demand, usability, performance, and payment behavior simultaneously.

Sketches compare information structure; interactive prototypes reveal selection and feedback. Error and waiting behavior needs reachable states rather than a final screenshot. Fidelity follows the question instead of serving as evidence itself.

Observe paths, pauses, errors, and requests for help. Ask about decisions without explaining the interface first. A designer's familiarity does not establish that new users understand it.

Express priority through hierarchy

Show names, course relevance, and version status in results; place sources and reading actions in details. Decorative images should not dominate version decisions. Distinguish primary actions, navigation, and metadata without making everything equally prominent.

Long titles, missing labels, and multiple sources belong in the specification. Test them before choosing fixed heights or truncation. Provide an accessible way to obtain full content and preserve essential version information.

On narrow screens, details may become a separate view and filters must not block results. Breakpoints depend on usable content and actions. Touch, keyboards, and enlarged text all affect space requirements.

Specify states and transitions

Loading, empty, success, and error need understandable messages and next actions. Empty results can offer filter changes; errors can offer retry without silently discarding useful results.

Also consider partial success, denied access, stale versions, and saving. Define disabled actions, focus, retained content, and preserved input. These are product behavior rather than implementation guesses.

The offline audit checks four required state names and reports missing ones. It does not judge visual or interaction quality.

required = {"loading", "empty", "success", "error"}
screens = {"loading": "spinner", "empty": "help", "success": "results", "error": "retry"}
assert required <= set(screens)
incomplete = {"success": "results"}
assert required - set(incomplete) == {"loading", "empty", "error"}
print(sorted(required - set(incomplete)))

The actual output is ['empty', 'error', 'loading']. The full dictionary covers all four names; success alone misses three. Its values are teaching labels, not implemented controls or requests.

A named state may still be unreachable. Later implementation needs delayed, empty, and failed requests to verify behavior. Four screenshots cannot establish correct transitions, preserved input, or absence of duplicate actions.

Give components semantic rules

Tokens describe spacing, typography, color, and shape, with names tied to purposes such as body text or destructive actions. Components also need sizes, states, content rules, and accessibility behavior.

A component library provides implementations or styling. A design system adds usage rationale and constraints. Material patterns offer references without prescribing every brand or platform. Choose components according to the task rather than their availability alone.

Figma supports interactive flows; tools such as MasterGo can support design collaboration, subject to current capabilities and licensing. This lesson promises no unverified design-to-code integration. Align design component names with implementation specifications.

Prove accessible operation

Keyboard users need access to filters, results, and details in a sensible order. Focus must be visible, and dismissing overlays should restore it appropriately. Loading and errors need perceivable messages beyond color, icons, or animation.

Provide alternatives according to image purpose and suitable semantics for controls and tables. Contrast, zoom, and screen-reader behavior require actual checks; a drawing cannot establish full conformance.

Motion should explain transitions, with reduced-motion preferences considered. Avoid relying on briefly displayed information. Automated scans support but do not replace structural and task-path checks.

Review assets separately from code

Generated images help exploration but do not create functional interfaces. Screenshots omit errors, focus, and adaptable text, which need real components. Changing a reference's colors does not establish original content or assets.

Record provenance, permitted use, and asset versions. Check lesson illustrations for factual accuracy and meaningful relationship to text. Plausible-looking labels or people are not factual evidence.

Handoff should specify sizes, cropping, alternatives, placeholders, and failures. Missing images should not block primary tasks. Assets and fonts affect performance and layout shifts, requiring later measurement.

Specify actions during loading too. Existing documents may remain readable while new filter results are pending. Explain temporarily unavailable actions, and ensure recovery does not lose focus or jump unexpectedly to the page top. Compare the same task before loading, during waiting, and after failure to expose problems that static pictures cannot show.

Exercise: deliver a reading-panel specification

Define the task and two assumptions, then specify filters, results, details, and basic states. Include long titles, narrow screens, denied access, keyboard use, and failed images. Explain component and token purposes.

Accept it when each state has a trigger, errors differ from emptiness, users can return to results, and version information survives. Specify focus and reading order and list actual UI checks still required. The audit proves state-name coverage; usability and accessibility need observation and an implemented interface.