Configuration Setup Design

This guide separates two ways to structure a multi-page configuration experience:

Valid through any page — users can quote or order as soon as their current selections form a valid configuration.
Must complete all pages — users must visit or complete every page before they can quote or order.

Comparison

Consideration	Valid through any page	Must complete all pages
Starting point	Begins with a valid, priced base configuration whenever possible.	May begin incomplete and relies on every page being completed.
Navigation	Users can move between pages and skip pages containing only optional choices.	The configured page sequence controls progress.
What makes a configuration valid	Explicit requirements, compatibility rules, mappings, price data, and approvals.	Page visits or completion are treated as evidence of validity.
Required decisions	Required only when product or commercial logic requires them; conditional requirements appear when triggered.	A decision may be required only because its page is part of the flow.
Price	Shows the current accurate price as soon as a valid configuration exists and updates after each priced change.	Price may be withheld until later pages, even when earlier selections can be priced.
Best use	Products with a meaningful standard configuration, optional enhancements, or users with different levels of expertise.	A short, truly linear process where every step supplies an essential decision and cannot be represented as explicit requirements.
Primary risk	Incomplete rule, mapping, or pricing setup could permit an invalid transaction.	Unnecessary friction, abandoned configurations, and a false sense that navigation proves correctness.

Recommended Approach: Valid Through Any Page

Use this approach whenever a meaningful base configuration can be offered. Pages organize choices; they do not define product truth. The user may stop when the current configuration meets the need, and the system determines whether that configuration is valid, buildable, accurately priced, and ready for release.

Gold standard: a car configurator

A well-designed car configurator is the gold standard for this approach. It starts with a valid, priced base vehicle. Each selected option updates the configuration and price, while optional categories remain available without preventing the user from understanding the current result. The user does not need to visit every category or select every available option before receiving a meaningful price.

Apply the same standard here: navigation supports discovery, but explicit rules determine whether the current configuration is valid, buildable, and ready for release.

Design requirements

Start with a valid, orderable base configuration and visible starting price whenever possible. If that is not possible, identify only the minimum essential selections needed to establish one.
Allow users to move between pages without completing unrelated optional pages, preserving their selections.
Make required decisions visually distinct from optional enhancements.
Express compatibility, dependencies, prohibitions, and conditional requirements as explicit rules. Do not use page order to stand in for those rules.
When a selection creates a requirement, identify the requirement immediately and direct the user to the relevant decision.
Update the displayed price when a priced selection changes. Include defaults and automatically required dependencies.
Block quote or order release only for an actual validity, buildability, commercial, or approval issue. State the precise corrective action.

Examples of conditional requirements

A high-power option requires a larger power supply.
A component above a thermal threshold requires active cooling.
A regional certification requires a compatible cord or accessory.
Redundant storage requires an additional drive or controller.

In each case, the requirement is created by the selected option—not by the existence of a later page.

When All Pages Must Be Completed

Requiring all pages is appropriate only when every page captures an essential decision that cannot be established by a valid default or clear conditional rule. The reason for each required page must be documented in the product or commercial definition.

Before using this approach, confirm that:

Every page contains a genuinely required input for every configuration that reaches it.
The requirement remains valid if pages are reordered, hidden, or presented in an expert experience.
A missing decision is reported as the specific missing requirement—not simply as an instruction to complete pages.
The full flow is necessary for validity, not merely helpful for guidance or discovery.

If a page contains only optional preferences, it should not prevent release. If a page is relevant only after a prior choice, use display control and a conditional requirement instead.

Release Gates

Navigation should remain flexible; transactional release should fail closed. Prevent release when any applicable condition exists:

A required attribute has no value.
Selected values form an invalid combination.
A required item mapping or downstream item is missing, blocked, obsolete, or invalid.
A required dependency is absent.
Required cost, price, currency, quantity, approval, or version data is missing or stale.

Messages must identify the actual missing requirement or conflict. “Complete all pages” is not an adequate validity message.

Testing

Test the product model at legitimate stopping points, not just along the longest navigation path:

Verify the base configuration is valid, buildable, mapped, and accurately priced.
Verify users can stop after each meaningful set of valid selections without visiting remaining optional pages.
Verify each optional selection changes price and downstream output correctly.
Verify conditional requirements appear when triggered and resolve when satisfied.
Verify invalid combinations are blocked with a useful explanation.
Verify navigation does not create, remove, or corrupt configuration state.
Reconcile configuration, quote, order, bill of materials, routing, and build outputs.

Design Review Questions

What is the minimum valid configuration?
Can it be built and accurately priced without visiting every page?
Which decisions are always required, and which become required only after another selection?
Is each requirement expressed as product or commercial logic rather than navigation behavior?
Can users stop at every legitimate satisfaction point?
What prevents an invalid configuration from being released?
Have valid early-stop configurations been tested end to end?

Principle

Let the user stop when satisfied. Let deterministic rules decide whether the result is valid. Let testing prove that every valid stopping point produces the correct price, transaction, and build definition.