Connected Customer Vision Site

Connected Customer Vision Site Skill Blueprint

Purpose

Use this blueprint to create a reusable Cursor skill for building executive-grade Connected Customer Vision (CCV) sites in either:

• existing project workspaces, or
• new project requests where the site is being created from scratch.

The goal is to deliver a structured, strategic narrative site that supports executive conversations (finance, operations, IT, line-of-business leaders), not just feature-level demos.

Design default (Aug 2026): deliver as a multi-page website by default for customer-facing pre-sales reviews unless the user explicitly requests a single-file variant.

Primary Outcomes

• Translate discovery content into a coherent executive storyline.
• Present complex transformation concepts in a scannable, visual, and discussion-ready format.
• Preserve flexibility for user-supplied artifacts (journey image, external research, customer-specific content).
• Keep implementation maintainable through modular page architecture and reusable content patterns.

Core Architecture Decisions

1) Left-hand navigation (primary IA control)

• Use persistent left navigation as the primary information architecture.
• Favor long-form page titles where needed for executive readability.
• Keep nav order intentional to mirror storytelling sequence.
• Use explicit grouped sections in the sidebar for scanability:
  • Search
  • Overview
  • Vignettes
  • Architecture
  • Appendix
• Increase vertical spacing between grouped section labels (Overview, Vignettes, Architecture, Appendix) to improve scanability during live executive walkthroughs.
• Default the left navigation width to approximately 25% wider than a standard narrow sidebar (about 360-380px desktop) so long vignette titles remain on one line more consistently.
• Require a show/hide navigation control that is always discoverable (desktop and mobile) so presenters can focus audience attention.
• Persist nav state preference (collapsed/expanded) using local storage.
• Use one control only for show/hide behavior (do not render duplicate buttons with the same action).
• Position the show/hide control so it does not obscure sidebar branding when expanded.
• Standardize the toggle interaction to the Siemens EDA pattern:
  • use a text button label (Show Navigation / Hide Navigation) instead of icon-only hamburger on desktop,
  • render the button inside a dedicated desktop top page container (a control row inside main content),
  • give that container a distinct background + bottom border so the control remains legible over all content types,
  • keep explicit vertical space reserved for the control row (never rely on overlay/fixed positioning for desktop),
  • align the button to the sidebar/content boundary when expanded,
  • keep the button at the far-left edge of that control row when nav is collapsed,
  • keep the company name lockup fully visible when navigation is expanded,
  • keep the toggle outside the collapsible sidebar container in the DOM so it remains clickable while collapsed on hosted deployments.

2) Capability search at top of navigation

• Add an in-nav search input for fast capability lookup under the Search grouping above Overview.
• Search should match:
  • capability code,
  • capability name,
  • capability description,
  • and location where capability appears.
• Search results should link directly to the most relevant page/tab.
• Default to a floating, non-blocking results card anchored to the search input so users can select in context without back navigation.
• Support dismiss via Esc, click-away, and explicit close action.
• Preserve query and results state when the card is dismissed and reopened.
• Support keyboard-first selection flow (ArrowUp, ArrowDown, Enter).
• After selection, close the card and render the selected capability inline in the host view.
• Implement a structured capability search index object shape (or equivalent):
  • code
  • name
  • description
  • location
  • pageTitle
  • pageHref
• Avoid acronym-only search indexes; include descriptive text so results are useful for both Salesforce experts and customer stakeholders.

3) Connected Customer Vision (user-supplied)

• Anchor the site around the customer-specific Connected Customer Vision narrative and artifacts.
• Treat user-supplied vision language as source-of-truth input.
• Normalize wording for executive clarity while preserving customer intent.

4) Hero image only on the first page

• Show the hero section only on the opening page (e.g., Connected Customer Vision).
• Do not render hero placeholders or extra dead space on subsequent pages.
• Secondary pages should open immediately with content title and summary.
• Use a left-aligned top section layout (title, subtitle, metadata) rather than centered page wrappers so header content aligns with the broader body narrative.

5) Individual pages over a monolithic index.html

• Use a true multi-page architecture by default (separate HTML files for Executive Summary, Journey, each Vignette, Capability Map, Domains, External Research, and Forward Looking Statement).
• Do not implement all sections as a single in-file tab switcher unless the user explicitly requests single-file mode.
• Keep shared navigation, search behavior, and style assets reusable across pages via common CSS/JS includes.
• Keep content segments independently maintainable and reorderable.
• Enable future expansion without reworking the entire layout.

6) Executive strategic language over tactical implementation language

• Use transformation-level wording:
  • operating model,
  • decision velocity,
  • risk reduction,
  • governance,
  • scalability,
  • measurable outcomes.
• Include enough depth to sustain executive follow-up questions while avoiding low-level implementation noise.

7) Visual journey (user-supplied)

• Include a dedicated Journey page for user-supplied visual map(s).
• Render visual at full readable width with clean containment.
• Keep context framing concise (what the visual represents and why it matters).

8) Vignette titles in navigation

• Use full vignette titles (not generic labels like "Vignette 1/2/3").
• Examples:
  • "The Order That Almost Didn't Close"
  • "The Capacity Nobody Could See"
  • etc.
• This improves executive scanability and contextual recall.

9) Capabilities embedded in each vignette using naming convention

• Each vignette should include a structured capability section.
• Use a consistent naming convention:
  • CODE: Capability Name
  • short executive-value description.
• Keep naming and descriptions aligned with the broader platform taxonomy.

10) Capability summary and sequencing

• Add a cross-vignette capability summary page.
• Include an initial delivery sequence (e.g., Phase 1/2/3) based on:
  • business urgency,
  • dependency order,
  • value realization speed,
  • and implementation risk.

11) Map capabilities to Salesforce domain groupings

• Maintain a page that organizes referenced capabilities under domain umbrellas (e.g., Data & AI, Service, Integration, Analytics, Field Service, Revenue/Order, etc.).
• Clearly identify:
  • capabilities used in vignettes,
  • additional adjacent capabilities for expansion.

12) Place External Research and Forward Looking Statement at end of nav

• Navigation order should place these two items at the end:
  • External Research (user-supplied and customer-contextual),
  • Forward Looking Statement (standardized legal content).
• For Forward Looking Statement pages, when the user provides mandatory legal wording, render that language verbatim and in full (no paraphrasing, shortening, or omission).
• External Research pages should use the same card-density and visual cadence as capability architecture pages (multi-card sections, executive framing, and balanced narrative depth).

13) Shared layout and page parity requirements

• Every page should include the same left-navigation structure and grouped IA.
• Use one persistent show/hide navigation control with local storage state shared across pages.
• Include capability search on every page so users can jump directly to relevant vignette/context pages.
• Ensure active page highlighting in navigation is accurate per file path.
• Keep shared page chrome consistent (brand treatment, nav behavior, and spacing) so context does not shift between pages.
• Include a consistent previous/next page flow navigation element at the bottom of each content page to support executive walkthrough pacing.
• Include the customer company name in the upper-left of the navigation pane on every page (enforced branding target for customer-facing meetings).
• Include a persistent Salesforce logo near the top of the navigation pane (before Search), directly below the company/context lockup on every page, using the standardized raster file public/salesforce-logo.jpg.
• Render the logo in a compact .logo-pill wrapper and apply the baseline sizing spec:
  • .logo-pill { border-radius: 3px; padding: 5px 9px; }
  • .brand-logo { height: 20px; }
• Do not use SVG for this logo slot; if public/salesforce-logo.jpg is missing, create it from the approved Salesforce cloudmark image before implementation.
• Provenance: the canonical cloudmark source is the approved Salesforce raster image supplied for this skill baseline (Aug 2026); replacement logos must match that mark and color treatment.
• Use Siemens EDA-style nav treatment: unboxed navigation text items with a clear active-state indicator (e.g., accent left rule and/or weight), rather than bordered button-style nav rows.
• Avoid desktop hamburger overlap with branding; reserve icon-only hamburger behavior for mobile menu states.
• Do not use fixed-position desktop nav toggles that can overlay hero/header text; reserve explicit vertical space for the control row.
• Keep the desktop control row sticky-safe (position: sticky; top: 0;) only when it does not introduce overlap; maintain a dedicated control-row background container at all times.
• Keep .main-content as the remaining flex region (flex: 1 1 auto; min-width: 0;) so content fill and wrapping remain stable as sidebar width changes.

14) Domain-level Trailhead enrichment (when MCP is available)

• For Salesforce capability domain pages (for example Agentforce, Data 360, Headless 360, Observability, Embedded AI), include a Trailhead Resources (Public) topic section using the same executive card style as other domain content.
• Prefer live curation through the official Trailhead MCP server:
  • use content_search to identify the most relevant public resources,
  • choose a balanced mix across content types (typically module/project/trail),
  • prioritize architect/developer/admin relevance based on audience.
• Each resource card should include:
  • exact Trailhead title,
  • 1-line business-relevant rationale,
  • type + estimated duration,
  • direct public Trailhead URL.
• Do not dump long resource lists. Default to 3-6 curated cards per domain.
• If Trailhead MCP is unavailable, use resilient public Trailhead keyword links as a fallback and label them as temporary until MCP curation is restored.
• Extend this pattern beyond domain pages to sequencing pages when present:
  • add a phase-based learning pathway on capability-map-style pages,
  • add a COE enablement pathway on operating-model-style pages.

Recommended Information Architecture

1. index.html = Executive Summary (hero-enabled opening page)
2. journey.html = Journey (visual transformation map)
3. vignette-1.html ... vignette-N.html = Vignette pages (full titles with numbering)
4. capability-map.html = Capability Map / Sequencing
5. salesforce-summary.html (or equivalent) = Salesforce Capability Domains
6. external-research.html = External Research
7. forward-looking-statement.html (or equivalent) = Forward Looking Statement

Content and UX Standards

• Keep page summaries concise, strategic, and meeting-ready.
• For Forward Looking Statement pages, apply a dedicated legal readability treatment (constrained line length, increased line spacing, and clear section contrast) without modifying legal wording.
• For the opening page, include an Executive Stakes by Persona mapping as a best-practice section (e.g., CRO, CIO, RevOps, Sales Enablement) to anchor business relevance before solution details.
• Use clean sectioning for skimmability:
  • Current State
  • Future State
  • Value Driver
  • Capabilities
• Keep typography aligned across sidebar groupings and search elements so Search feels like a first-class navigation section.
• Keep top section/header content left-aligned across pages for visual consistency with section content.
• Add bottom-of-page progression links ("Previous" / "Next") when a guided walkthrough pattern is requested.
• Use responsive layouts that preserve readability on laptop and projector displays.
• Support reduced-motion preferences and keyboard navigation.
• Preserve high-contrast design choices for boardroom environments.

Additional Items to Include (Beyond Original List)

• Collapsible navigation state persistence: required; remember user preference (show/hide nav) with local storage.
• Content governance rule: do not include confidential customer data in reusable public templates.
• Asset handling pattern: separate user-supplied visuals/documents from baseline template assets.
• Reusable content model: define tab/page objects so teams can swap in new customer vignettes quickly.
• Narrative continuity checks: ensure each page transitions logically to the next in executive storyline order.
• Legal/content boundaries: keep standardized forward-looking language separate from customer-provided claims.
• Legal text fidelity: mandatory legal statements must be reproduced exactly from the user-provided legal source artifact.
• External research depth standard: avoid thin summary pages; include company scale, financial trajectory, market tailwinds/headwinds, competitive framing, and Salesforce-relevance implications.
• Future extensibility: reserve slots for roadmap, ROI assumptions, and decision/next-steps content.
• Learning enablement continuity: when Trailhead MCP is available, refresh domain resource cards periodically so public links remain current and relevant.
• Formatting baseline: run a final formatting pass (Prettier or equivalent) across HTML/CSS/JS before handoff to keep future diffs maintainable.

Skill Authoring Guidance for Cursor

When converting this blueprint into a Cursor skill:

• Trigger on requests to build:
  • "executive site",
  • "Connected Customer Vision site",
  • "vignette narrative site",
  • or similar.
• Enforce required checks before final output:
  1. true multi-page file structure is present (not single-file tab simulation),
  2. hero on first page only,
  3. left nav + capability search available on every page,
  4. navigation grouped into Search / Overview / Vignettes / Architecture / Appendix (or closest equivalent),
  5. single show/hide navigation control present (no duplicate buttons) and state persistence working,
  6. first page uses Executive Summary naming and includes Executive Stakes by Persona mapping,
  7. full vignette titles in nav with numbering format 1. <Title>, 2. <Title>, etc.,
  8. capabilities embedded in each vignette,
  9. capability sequencing + Salesforce domain map,
  10. External Research + Forward Looking Statement as trailing nav items,
  11. previous/next page flow navigation present and ordered according to the agreed storyline,
  12. customer company name appears in upper-left navigation on every page,
  13. persistent Salesforce logo appears near the top of the sidebar immediately below company/context lockup using public/salesforce-logo.jpg (raster format required) and follows the baseline logo spec: .logo-pill { border-radius: 3px; padding: 5px 9px; } plus .brand-logo { height: 20px; },
  14. capability search uses structured objects containing description and location fields (not code/name only),
  15. capability search uses a floating, non-blocking results card and keyboard selection flow to avoid back-navigation friction,
  16. navigation items use Siemens EDA-style active indicator treatment rather than bordered button rows,
  17. desktop nav toggle uses Siemens EDA positioning/label behavior, sits inside a dedicated top page container, reserves non-overlapping layout space, and does not mask sidebar branding or page headers,
  18. mandatory forward-looking statement text (when provided) appears verbatim and complete,
  19. sidebar group labels include enhanced vertical spacing for clear section separation,
  20. External Research page uses architecture-page-equivalent card density and executive narrative depth,
  21. Forward Looking Statement page uses legal readability typography while preserving exact legal text,
  22. sidebar collapse uses sticky-safe self-clipping (width: 0 + overflow: hidden) on the sidebar element rather than grid-column collapse,
  23. nav toggle is implemented outside the collapsible sidebar container so it remains clickable in collapsed state on hosted deployments,
  24. desktop control-row container has a distinct background treatment and is rendered on every page for parity.
  25. when Salesforce capability domains are present and Trailhead MCP is available, each domain page includes a curated Trailhead Resources (Public) section with title, rationale, type/duration, and direct URL cards.
  26. sequencing/operating-model pages include phased Trailhead learning pathways when those pages are part of the narrative.
  27. final delivery includes standardized formatting across site HTML/CSS/JS assets.
• Encourage modular implementation and reusable content dictionaries over static hardcoded blocks.

Definition of Done

A CCV site is complete when it:

• is executive-ready in tone and structure,
• supports focused reading with explicit show/hide nav control and persisted state,
• includes user-supplied visual and research content in the right places,
• provides both vignette-level and cross-vignette capability strategy,
• and can be reused as a repeatable delivery pattern across accounts.