Navigation and information architecture

Helm’s primary navigation asks financial questions. Settings holds the configuration needed to answer them. This keeps a database directory from becoming the product’s information architecture.

Primary destinations

My Situation explains where you stand. Coming shows expected dates. Subscriptions focuses on recurring commitments. People explains loans and shared context. Activity records what happened. Insights reads patterns across history.

Use recognizable names and real-world objects. A user should not need to know a service file or table name to choose where to go.

Place an action deliberately

• Recording a purchase belongs with actual Activity.
• Editing an account’s setup belongs in Settings or its account detail.
• Reviewing an expected bill belongs in Coming.
• Reading a person’s loan belongs with People.

A new label should help answer a question, not expose another implementation layer.

Public entry

Welcome, Privacy, Roadmap and these Guides can be read without a financial session. Authentication pages guide sign-in and account creation. Reciprocal app/docs links should use their canonical custom origins and a meaningful public destination.

Test the route journey

Review direct links, mobile navigation, active state and keyboard focus. An interactive tour should advance only when the requested route and visible target exist; a pathname alone is insufficient for a target-specific instruction.

See route map and first-use guidance to compare the implementation with the user’s journey.