Route options: explain preferences and limits

Explain what an avoidance requests

MAPS.ME groups Avoid toll roads, unpaved roads, ferry crossings and highways under Routing options. The Dyrt asks what to avoid while building a route and uses selectable cards before Continue. Both make inputs approachable, but an avoidance label still needs a defined relationship to the actual route calculation.

Decide whether each option is a soft preference, a supported hard restriction or a best-effort request, and communicate that distinction. If no suitable route exists, do not silently relax an important constraint and present the result as fully compliant. Explain the unresolved condition and offer only the supported alternatives, without making the person infer a policy from a detour they did not expect.

Keep current selections visible in the route review. A compact summary can help someone remember why a route differs from an earlier version. Avoid forcing a trip back into settings merely to discover whether a preference was enabled. If a saved default applies to new trips, distinguish it from a one-time choice made inside the current planning flow.

Show the cost of an optimization choice

A Better Routeplanner explains that fewer charge stops can mean longer charging at each stop. Bikemap describes different priorities for Balanced, Fastest, Cycling Paths and Popular, including a cycling-path preference scale. These examples make optimization less abstract by naming a tradeoff rather than presenting one universally superior choice.

Describe the supported objective in plain language. Fastest, fewest stops and least walking can prioritize different things, and a label alone may conceal a meaningful cost. Keep explanatory text close enough to inform selection without turning the option list into an unreadable policy wall. If a recommendation depends on historical, current or manually entered data, preserve that distinction where it affects interpretation.

Do not convert an optimization label into a safety guarantee. A low-traffic preference or a popularity label is not proof that every segment is suitable for every person or vehicle. Review the actual calculated route and disclose supported limitations. The UI should help someone understand what the system considered, not claim certainty beyond its data and calculation model.

Keep trip scope and vehicle inputs explicit

Roadtrippers states that selected options apply across the entire trip and exposes vehicle-related inputs with geographic support limits. calimoto places avoidances beside start, via-point and destination controls before Calculate ride. These workspaces show why route options need both a scope and an explicit relationship to the next calculation.

Name whether an edit affects the full trip, one leg or a future route. If the product supports vehicle dimensions or other consequential constraints, identify the required inputs, units and supported coverage. Do not silently carry incomplete values into a result that looks verified. A geographic support boundary should remain discoverable at the decision point, not disappear behind a reassuring vehicle icon.

Keep recalculation deliberate and visible. After changing a constraint, distinguish the previous route from the pending or newly calculated one. If the source trip changes while calculation is running, tie the result to its input revision. Never attach a late response to a newer trip and imply that it reflects settings the calculation did not actually use.

Do not make every switch mean exclusion

Moovit explains that selected transit types receive higher priority, rather than saying that every unselected type is forbidden. Outdooractive exposes planning options involving lifts, ferries and closures. Those recorded labels show why a switch’s meaning must come from the actual supported policy, not from a generic on/off visual.

Name preference strength and consequences. Prioritizing a mode is different from requiring it, and considering a connection is different from guaranteeing that it is available. If an option changes how closures or other consequential data are treated, provide a clear explanation and appropriate safeguards. The existence of a control is not a recommendation to ignore restrictions or conditions.

Keep exceptional planning behavior separate from ordinary preferences where the risk warrants it. Do not let a person enable an unusual override through an accidental tap in a long list and then forget that it changed the calculation. Explain unresolved data and limitations honestly, and avoid language that encourages reliance on the app over relevant real-world signs, conditions or authoritative guidance.

Distinguish route policy from navigation handoff

Spoke separates Route Preferences from Navigation Preferences and names a navigation app independently of stop timing and vehicle choices. Sports Tracker offers routing modes for the next point and labels Free drawing as No automatic routing. Both make scope important: not every option configures the same system or produces the same kind of route.

Explain which settings apply inside the planner and which, if any, can be carried into an external navigation handoff. Do not imply that another app receives every preference simply because it opens the destination successfully. If only locations or waypoints transfer, say so according to the actual integration. Keep the reviewed route and the external app’s route as distinct results when they can differ.

Name non-automatic modes directly. Free drawing may help someone sketch an intended path, but it should not look like a calculated or validated navigable route. If an option applies only to the next segment, preserve that scope after the panel closes. A project-wide default and a one-segment choice should not share the same unexplained selected badge.

Version the inputs behind each route

Represent destinations, via points, transport context, supported restrictions and soft priorities as distinct inputs. Store the calculation revision and data context associated with the reviewed result. A route should not appear current after a consequential input changes unless the implementation has actually recalculated or can truthfully establish that the result remains valid.

Define unresolved and unsupported states explicitly. Missing vehicle information, unavailable traffic data, conflicting preferences and no supported route require different explanations. Do not substitute a route that violates an important constraint without a clear review step and appropriate safety policy. Preserve the person’s inputs so they can resolve the problem without reconstructing the trip from scratch.

Make options accessible without relying only on colored map lines or icons. Use labelled controls, readable unit values and summaries that survive large text. Keep consequential planning changes separate from distracting in-motion interaction, according to the product’s safety design. The implementation and safety review must establish what can be offered; a polished settings panel cannot create reliable routing capability on its own.

Ask which settings the route actually used

Give a tester a trip with a clear priority and ask them to change one option, calculate and explain the resulting route’s scope. Then change a via point while a calculation is pending. Check whether the old route, pending inputs and reviewed result remain distinguishable without requiring the person to inspect hidden technical details.

Include unsupported coverage, incomplete vehicle data, unavailable current information and a combination of preferences that cannot be satisfied. Test cancellation and external navigation handoff, verifying the actual supported transferred data. Do not treat successful map display as proof of safety or suitability. Use an appropriate routing and safety evaluation for the claims the production feature intends to make.

Measure preference misunderstandings, stale-result use, repeated recalculation and incorrect assumptions about external handoff. A longer route is not automatically a failure when it deliberately satisfies a stated priority. Keep route-quality evaluation separate from interaction clarity, and avoid collecting sensitive trip histories when coarse configuration and error events can diagnose the workflow.

Review priorities and supported limits

Use these checks on a working build, not only on the polished reference state.

• ✓Preferences and hard restrictions have different meanings.
• ✓Optimization choices explain relevant tradeoffs.
• ✓Trip, leg and next-segment scope remain visible.
• ✓Vehicle inputs include units and supported coverage.
• ✓Changed inputs cannot masquerade as a current calculated route.
• ✓External navigation handoff describes what actually transfers.
• ✓No UI label substitutes for routing and safety validation.

Related design decisions

The map and location-picker examples cover choosing places. Route preferences answer a different question: how the planner should connect those places.

Use the calendar and scheduling examples when stop timing and trip plans need a clear relationship to scheduled activities rather than an unexplained duration field.