13.04

Product Pages

Three page types that document what Visualist does. All are always-on, on-nav, and built for depth over conversion pressure.

Product pages live under the Product nav and document what Visualist does. They are always-on, built once, and maintained as the product evolves. Three types: Pillar (introduces a product area), Feature (goes deep on one feature), and Integrations (shows tool compatibility). All three are built for depth, not conversion pressure.

B1
Pillar
On-navBrand
What it is

A Pillar page introduces one of the three product pillars: Relationships, Projects, or Growth. It establishes what this pillar covers, how it fits the broader OS, and which Feature pages live beneath it. It is the index for its pillar area.

When to build or update

Build one per pillar at launch. Update when the scope of a pillar changes or when new Feature pages are added beneath it.

Visitor state

Evaluating product depth. Already interested in Visualist, trying to understand whether a specific part of the product fits their workflow.

Content structure

Pillar headline naming the area and its job. How this pillar fits the OS (one paragraph). Feature overview (name and one sentence per feature). Vai's role in this pillar. Soft CTA at the end only.

CTA guidance

"Try it free" or "Start your trial." One CTA at the end. No secondary CTAs per feature block.

Brand correctness

Use official feature names from the product overview. Hubs not "client portals," Concierge not "AI chat." Do not lead with "AI-powered." Do not list roadmap features as live.

Not this

Not a Feature page: introduces the area, does not go deep. Not a homepage. Not a sales page.

Brief fields required
Pillar. Relationships / Projects / Growth
Feature pages in this pillar. confirmed list from product team
Vai's role in this pillar. confirmed against product overview
Roadmap items to exclude. confirm at brief date
Example pages
Slug Page title
/product/relationships Relationships · Visualist
/product/projects Projects · Visualist
/product/growth Growth · Visualist
B2
Feature
On-navConversionAEO
What it is

A Feature page goes deep on a single Visualist feature: what it does, how it works in a real workflow, who benefits most, and why it matters. Visitors arrive wanting to understand one specific feature before committing to a trial.

When to build or update

Build when a feature ships or reaches a quality standard worth showcasing. Update whenever the feature changes. Archive Feature pages for deprecated features.

Visitor state

Evaluating a specific feature. They know what they are looking for and want to understand whether this feature handles their specific workflow moment.

Content structure

Feature headline naming the feature and its job. What it does, immediately (first 50 words). Workflow moment from a specific persona's working day. Capability breakdown (2-4 sub-capabilities). Vai's role if applicable. Social proof matched to a vertical. Soft CTA.

CTA guidance

"Try it free" or "See it in action." One CTA at the end. A secondary link to a product demo is acceptable if one exists.

Brand correctness

Use the official feature name exactly as listed in the product overview. Do not describe proposals or roadmap features as live. Taste memory nuance: Vai learns how professionals work, not yet how things should look.

Not this

Not a Pillar page. Not a technical specification. Not evergreen without maintenance.

Brief fields required
Feature name. exact name from product overview
Parent pillar. which pillar this page sits under
Sub-capabilities to cover. confirmed list from product team
Target vertical. which field benefits most
Vai's role. confirmed against product overview
Social proof. any customer signal tied to this feature
Example pages
Slug Page title
/product/projects/hub Hub: your project space and client portal · Visualist
/product/relationships/concierge Concierge: AI-powered client communication · Visualist
/product/studio Studio: the creative editor for boutique professionals · Visualist
/product/relationships/bookings Bookings: let clients schedule directly with you · Visualist
B3
Integrations
On-navSEOAEO
What it is

The Integrations page tells a visitor that Visualist works with the tools they already use. It is a trust-building page. Each integration entry needs more than a logo: a sentence on what the connection actually does for a boutique creative studio workflow.

When to build or update

Build when there are at least two live integrations to show. Update every time a new integration ships. Never list planned integrations as live.

Visitor state

Tool-aware and evaluating fit. They use a specific tool and want to know whether Visualist works alongside it.

Content structure

Framing statement (one sentence establishing Visualist connects to existing tools). Integration entries (for each: tool name, what the connection does, why it matters in a boutique studio workflow). The compounding argument (how connected tools prevent scattered information). Soft CTA.

CTA guidance

"Connect your tools" or "Start your trial." Tied to the page's context.

Brand correctness

Only list live integrations. Each description must name a specific workflow benefit. Do not lead with a logo wall.

Not this

Not a comparison page. Not technical documentation.

Brief fields required
Live integrations list. confirmed from product team
Per-integration workflow benefit. what the connection actually does
Coming-soon integrations. list to label separately, not to feature as available
Example pages
Slug Page title
/product/integrations Integrations: Visualist works with the tools you already use · Visualist
/product/integrations/google-drive Google Drive and Visualist · Visualist
/product/integrations/email Email and Visualist · Visualist