Dividing a configurator wizard into understandable steps

Divide a configurator into steps matching customer decisions, not tables in the management system. Each step answers one recognisable question, shows only relevant choices and ends with clear feedback on progress and consequences.

A wizard is not automatically user-friendly. Ten screens for ten small fields feel slower than one overview; one screen with forty technical options is no more workable. Group decisions by coherence, uncertainty and dependency. Start with choices that determine many subsequent steps.

Order from broad to specific

First ask about use or main variant, then size and functional components, then finish and finally review. An early answer can remove irrelevant later groups. Put rarely used technical exceptions behind an explanation or have an adviser assess them.

Step Customer's question Good content
1. Foundation What do I want to configure? Model, application or main dimension
2. Making it fit Does this fit my situation? Dimensions, mounting and limitations
3. Extending Which components do I need? Compatible functional options
4. Finishing What should it look like? Colour, material and visible details
5. Reviewing What exactly am I ordering? Summary, price and points to note

Use meaningful step names. “Option group 3” helps nobody; “Mounting” or “Finish” does. Show how many main stages follow, but do not make progress misleading if conditions add or skip steps. “3 of 5” must reflect the current journey.

Keep primary navigation within reach on mobile. Put “Previous” and “Next” in a fixed, non-overlapping action bar or directly below the content, and ensure the on-screen keyboard and cookie banner cover nothing. Button text can name the next meaningful step, such as “Choose finish”, so users know what follows.

Make going back safe

Customers should be able to change earlier answers without losing everything. Recalculate dependent choices when a foundational answer changes and explain what is consequently removed. On error, scroll or focus to the relevant group, not just the page top.

Retain progress only as long as needed and explain what “continue later” means. A browser refresh in the same session must not erase everything, but a months-old configuration needs current products and prices checked again. For logged-in customers, deliberate saving may be a separate feature.

Show price changes near the choices causing them and keep a current total in the summary. Animation may draw attention but must not hide the value from screen readers. If delivery time or availability changes, mention that beside the option too and repeat it before adding to the cart.

Fictional example: an acoustic workspace

Office supplier Stilwerk sells modular acoustic workspaces. Its old product page began with material thicknesses and profile codes. In the new wizard, customers first select user numbers and placement, then available dimensions, then desk and cable options, and only afterwards colour.

A freestanding setup shows different mounting from placement against a wall. When the customer goes back from four users to two, two unsuitable desk components disappear from the summary with a short message. The last step shows dimensions, components, quantities, price and a warning that an on-site mounting check may be needed.

Final WooCommerce cart lines are created only after confirmation. If they must go to production, stock and accounting, a clear data flow helps, as described in reliably integrating an online store and ERP.

Stilwerk puts a product owner in charge of the text for each step. Technical codes stay out of the customer view; dimension limits get a short reason and example. When the range changes, testing covers not only the last step but every route affected by the changed choice.

Usability test in six tasks

  1. Have someone without product knowledge create a standard configuration.
  2. Then ask them to change one early choice.
  3. Have the tester explain what the change removed.
  4. Interrupt on mobile and resume after a refresh.
  5. Create an error and observe where the user looks.
  6. Before adding, ask them to state exactly what is being ordered.

For each step, measure not only abandonment but also backtracking and error frequency. Frequent backtracking may indicate uncertainty, poor order or unclear explanation. Combine figures with session observation and support questions before removing a step. If the product process differs greatly from available plugins, compare custom software and standard software.

Avoid minimising steps as a standalone goal. An extra review page may reduce errors and return questions. Measure whether customers complete a correct, understandable configuration and whether operations can process it without corrective work. Speed is only one aspect of quality.

Have Yindle develop your product configurator's decision structure.

For the implementation with real product options and an estimate that does not replace the cart, see Yindle Kit Configurator and the guide to building a WooCommerce product configurator.

Previous insight
Next insight

Start with your question

Where does your team get stuck?

Your first enquiry does not need to be a technical brief. Tell us which systems you use and where work gets stuck. Together we discuss what is possible and which step you can take next.

Discuss my project