Product prototyping

Choose a question

A useful prototype answers something specific: can a person compare two records, recover a failed action, or continue a task when a phone unfolds? Write that question before choosing the screen. Define the starting state, the action, and the observable result. If the task takes several screens, keep the same records and unfinished input between them.

Use an interface study when its behavior is close to your question. The foldable phone tests continuity between outer and inner screens. Calendar tests date selection and editing. CSV reconciliation tests comparison and exception review. Each is a working browser example with its own stated limits.

Keep the difficult states

A complete-looking screen is only one case. Put representative data into the prototype before evaluating its layout. These cases should be easy to reproduce during a session:

• Empty: explain what belongs here and provide the first useful action.
• One record and many records: test selection, scanning, long labels, and a narrow viewport.
• Loading and partial data: preserve useful content and distinguish pending work from an empty result.
• Failure: keep the draft, explain which action failed, and make retry explicit.
• Restricted access: show the permitted task without implying that hidden records do not exist.

Carry the decisions forward

The visual constraints are defaults, not restrictions enforced against your application. You can override the tokens, change a component, or copy its source. Keep a record of intentional exceptions so a second team does not have to guess which decisions still apply.

React prototypes can become application code, but a convincing interaction does not supply a backend. Replace sample data with adapters, enforce permissions in your service, define persistence, and test the resulting keyboard and screen-reader paths. Vlak remains a young library; inspect the component and its tests before relying on it for a critical workflow.