Where should a multi-step flow stop when a feature is unfinished?
Explore the relationship between configuration access and delivery scope, and explain usable boundaries before users invest time in an unfinished flow.
Exploration · Principles and possible approaches inspired by a project context.
- Business analysis
- Multi-step flows
- Feature availability
Related case: Custom furniture design and quotation system. The project’s availability boundaries provide a starting point for exploring product choices in multi-step flows.
Users see a complete task
An available configuration type suggests that users can configure it, inspect a result and continue to completion. Development may have implemented only the earlier stages while later resources or delivery rules remain unfinished.
The product must communicate that difference instead of requiring users to discover it through failure.
Define what each open stage delivers
Break the task into business outcomes: selecting a type, setting parameters, previewing a result, obtaining a quotation and placing an order. For each stage, ask what usable result the user can rely on.
Some project configurations had parameter and preview work without an entirely open downstream flow. They needed visible development status and an explicit stopping point.
Two different promises
| Policy | Available action | Required explanation |
|---|---|---|
| Closed entry | See a future direction | It is unavailable now, with clear click feedback |
| Limited trial | Use completed configuration or preview stages | Where the flow stops and what the result can be used for |
Choose based on whether the available part provides independent value. A lengthy configuration that cannot be saved or used may not justify an open entry.
A disabled button alone cannot explain whether the issue is permission, missing input or an unfinished feature. Each requires a different next step.
Communicate before effort accumulates
Entry messaging establishes expectations; step boundaries prevent unintended progress; submission fulfills the capabilities already promised. Their terminology and availability state should agree.
If availability changes, define what happens to existing configuration: retain it, allow viewing or require another selection. Clearing everything at the final step leaves users unsure whether their earlier work was valid.
Validate user understanding
Walk through first entry, selection of unavailable options, continuation from limited trials and return navigation. Check whether the user understands the boundary and what happens to their inputs.
These decisions belong in business rules before they become UI and API behavior. Rendering a preview is not, by itself, a promise that an order can be accepted.