How to plan a product or service configurator

Use a configurator for compatibility decisions

Choose this format when selections affect which later choices are valid. A fixed package comparison should present stable criteria side by side. An assessment maps answers to a category or score. A calculator turns inputs and formulas into a numeric estimate. A configurator instead maintains a valid set of options while the visitor builds a product, service or project request.

Write the outcome in one sentence: “The visitor leaves with a valid, reviewable configuration for X.” Decide whether that configuration is an inquiry, a saved draft or an order. Do not call it an order or confirmed specification when a person must still check feasibility. The interface should state what is decided, what remains subject to review and how long changing option information remains current.

Create the option-dependency matrix first

List each option with a stable identifier, visitor-facing label, group, availability, prerequisites, exclusions, default and business owner. Avoid encoding the same rule separately in page copy, interface code and an internal spreadsheet; designate one maintained source and generate or reconcile the others. Record why the rule exists so a later editor does not remove an important constraint because it appears arbitrary.

Build a matrix with options on both axes. Mark combinations as allowed, required, excluded or conditionally allowed, then add the condition and rule priority. For services, include capacity, location or eligibility constraints only when they are suitable for automatic evaluation. If a rule depends on professional judgment, route the configuration for review rather than translating that judgment into a misleading yes-or-no result.

• Option ID, label, group and plain-language purpose.
• Prerequisite: selections or facts that must exist before this option becomes valid.
• Exclusion: choices that cannot coexist, with the reason shown to the visitor.
• Consequence: fields, steps, lead time or outputs this option changes.
• Resolution: what happens to a conflicting prior selection and whether confirmation is required.
• Owner and review trigger: who approves rule changes and which source initiates an update.

Translate dependencies into readable rules

Write each rule as: when these conditions are true, apply this consequence, explain this reason and offer this resolution. Include priority for cases where several rules apply. For example, “When installation is remote and on-site commissioning is selected, require a travel review; explain that location affects engineer availability; offer submit-for-review.” Keep business wording beside the technical expression so non-developers can inspect it.

Decide how the tool handles a change to an earlier answer. Silently deleting later selections makes the configuration difficult to trust. Identify the conflict, name the affected choice and let the visitor confirm a sensible correction. Preserve unaffected work. A rule must produce the same result when the same valid inputs are evaluated again; if timing or stock changes the result, show when that external state was checked.

Make every state understandable and revisable

A multi-step flow should announce its purpose, required information and progress. W3C’s guidance for multi-page forms recommends logical grouping, instructions and opportunities to review information. Use visible labels and native controls where possible. Keep chosen options readable outside color or imagery, and do not require pointer precision to operate essential selections.

When a choice is unavailable, explain why and how to make it available. WCAG guidance on error suggestions supports providing corrections when they are known and do not undermine the purpose or security of the content. Ensure selection targets meet the site’s accessibility target, keyboard focus remains visible, and changes to availability or summaries are announced without unexpectedly moving focus. Provide a review screen where people can revisit each group.

Hypothetical example: configuring a workshop package

Consider a hypothetical training provider offering on-site workshops. A visitor chooses audience size, delivery format, exercises and accessibility support. The dependency matrix states that a hands-on equipment exercise requires on-site delivery and a maximum group size. Selecting remote delivery makes that exercise unavailable with a direct explanation and suggests a simulation-based alternative.

If the visitor later increases the group beyond the maximum, the tool flags the conflict and offers to split the group or replace the exercise; it does not erase the selection. The final summary lists chosen options, assumptions and two items requiring staff review. Submission creates a configuration request rather than a confirmed booking. This is a hypothetical planning example, not a Kinetivy client result.

Test combinations and assign rule ownership

Turn the matrix into a compact test set. Cover each individual rule, rule intersections, boundary values, revising earlier choices, browser refresh or return, keyboard operation and a configuration with no optional selections. Ask someone outside the project to explain why each disabled option is unavailable. Compare the submitted summary with the visible final state and ensure hidden stale choices do not reach the business.

• Confirm every catalogue option has an owner, current label, availability state and dependency record.
• Test allowed, required, excluded and conditional combinations, including conflicting rule priorities.
• Revise early selections and verify that conflicts are explained before dependent choices change.
• Check labels, instructions, keyboard access, focus, target size, errors and dynamic announcements.
• Verify the final summary states what is confirmed, what needs review and which assumptions apply.
• Record rule versions, source changes, review dates, monitoring, rollback and support ownership.