PulseFlow — Visual Customer Journey Orchestration Canvas DESIGN MODE Enterprise SaaS UX Architecture & Product Design End-to-End Experience Design Specification Product: PulseFlow Experience: Visual Customer Journey Orchestration Workspace Primary platform: Desktop Web Application Target viewport: 1440px and above Design objective: Enable senior CRM and Growth Marketers to construct, inspect, validate, and publish complex multi-channel customer journeys without engineering assistance. 1. Project inputs and requirement classification Input Classification Captured requirement Project name and brief CONFIRMED PulseFlow — Visual Customer Journey Orchestration Canvas Target users and goals CONFIRMED Senior CRM and Growth Marketers; build and publish reliable branching journeys Platform and stack CONFIRMED Desktop Web, React, React Flow / HTML5 Canvas, Tailwind CSS Brand guidelines CONFIRMED Dark slate interface, electric indigo, emerald, amber and rose status colors Scope and exclusions CONFIRMED Node library, configuration inspector, connections, validation bar and publish modal Additional design decisions INFERRED The workspace should behave like a professional visual engineering environment rather than a conventional marketing analytics dashboard. ASSUMPTION Use React Flow as the primary interaction and rendering layer, with HTML-based accessible node content and controls. This is preferable to implementing the entire workspace as a custom HTML5 Canvas because individual nodes and controls need keyboard accessibility. ASSUMPTION The primary workspace uses a single active journey with an editable canvas, collapsible node library and contextual configuration inspector. ASSUMPTION Validation is performed before publication, and blocking validation errors prevent publishing. The exact validation rules remain subject to client approval. Client Input Required The following information materially affects implementation and must not be silently invented. 1. Journey entry rules: Can a journey have multiple entry triggers? Can users enter more than once? 2. Branching rules: Are conditions mutually exclusive? Is a default/fallback branch mandatory? 3. Execution behavior: How should wait timers, time zones, retries and timeout conditions behave? 4. Channel configuration: Which push and email providers are supported? What webhook payload schemas are required? 5. Permissions: Who can create, edit, approve, publish, pause and delete journeys? 6. Publishing behavior: Is publishing immediate, scheduled, approval-based or versioned? 7. Validation rules: Which conditions constitute blocking errors versus warnings? 8. Data model: Which customer attributes, events, segments and condition operators are available? 9. Security and compliance: What consent, unsubscribe, data retention, audit and regulatory requirements apply? 10. Operational recovery: What happens when a channel delivery, webhook or journey execution fails? These questions do not prevent us from establishing the provisional UX architecture below. They must be resolved before production behavior is finalized. 2. Product experience vision 13 Core experience principle: Make every journey understandable, every connection inspectable, and every publication deliberate. The product should allow a marketer to understand three things at all times: - Where a customer enters the journey. - What happens to the customer at each step. - Where the customer goes next, including every possible branch. Primary user journey 1. Open journey workspace Inspect the current journey, its nodes, connections and overall state. 2. Add workflow nodes Select a trigger, condition, action or wait node from the library. 3. Configure each node Enter the relevant parameters using the contextual inspector. 4. Connect the journey Create branches, connect outputs and inspect execution paths. 5. Validate the journey Resolve missing configurations, unlinked conditions and structural errors. 6. Publish the journey Review the publication summary and explicitly confirm deployment. Experience success criteria Goal UX success measure Understandability Marketers can trace every branch visually Configuration accuracy Missing required fields are surfaced before publication Error prevention Invalid or disconnected nodes are clearly identifiable Efficiency Node creation and configuration require minimal navigation Confidence Publication communicates exactly what will happen Accessibility Core authoring tasks are keyboard-operable These are proposed product success measures, not confirmed contractual KPIs. 3. Information architecture 3.1 Workspace structure The application should use a three-region working environment, supported by a persistent top navigation and bottom validation bar. PulseFlow / Journeys / Onboarding Flow Draft Onboarding Journey Saved 3 issues NODE LIBRARY Triggers Conditions Actions Wait timers Journey Canvas Nodes · Branches · Connections Primary working area INSPECTOR Node settings Configuration Validation 3 Errors 1 Warning Validation summary Review issues → Conceptual workspace composition, not a production screenshot.3.2 Navigation hierarchy Region Components Responsibility Top bar Logo, breadcrumb, journey name, status, undo/redo, save, publish Global workspace operations Left drawer Node library, search, node categories Workflow construction Center Infinite canvas, nodes, connections, minimap, zoom Journey visualization Right inspector Node properties, settings, validation Configuration Bottom bar Validation counts, save state, issue navigation Continuous feedback Overlay layer Configuration dialogs, publish confirmation Focused tasks Navigation principles - The canvas receives the majority of the available horizontal space. - The node library is collapsible. - The inspector appears contextually when a node or connection is selected. - Only one primary configuration context is active at a time. - Modals are reserved for consequential operations such as publishing, not ordinary node editing. 4. Screen inventory and specifications The experience consists of six primary screens or workspace states. ID Screen Priority PF-01 Journey Workspace Critical PF-02 Node Library Drawer Critical PF-03 Node Configuration Inspector Critical PF-04 Connection and Branch Editor Critical PF-05 Validation and Issues Review Critical PF-06 Publish Confirmation Modal Critical PF-01 — Journey Workspace Critical screen Purpose: Provide the primary environment for constructing and managing customer journeys. Primary user goal: Understand the complete journey and make changes without losing context. Primary action: Add or configure workflow nodes. Secondary actions: - Rename journey. - Undo/redo modifications. - Zoom and pan. - Collapse or expand side panels. - Save changes. - Open validation issues. - Initiate publishing. Information hierarchy: 1. Journey identity and lifecycle status. 2. Current save state. 3. Workflow canvas. 4. Node configuration context. 5. Validation summary. Relevant states: - Empty journey. - Populated journey. - Draft with unsaved changes. - Saving. - Saved. - Save failed. - Validation errors. - Read-only or permission-restricted. - Published. Next step: Add a trigger node or continue editing an existing journey. PF-02 — Node Library Drawer Critical screen Purpose: Make available workflow building blocks discoverable and easy to insert. Primary user goal: Find the correct node and add it to the canvas. Primary action: Drag a node onto the canvas or select it to insert it. Information hierarchy: - Search field. - Node category. - Node icon and name. - Short node description. - Drag affordance. Proposed node taxonomy Triggers Start a customer journey Entry Conditions Evaluate customer attributes and conditions Actions Execute channel or integration actions Wait timers Introduce delays between journey steps Node inventory Node Category Configuration requirement Event Trigger Trigger Event definition Push Notification Action Push configuration Email Drop Action Email campaign/reference configuration Webhook Action Endpoint and payload configuration Condition Condition Evaluation expression Wait Timer Timing Duration or timing configuration The configuration fields shown above are provisional UX categories. Exact fields, providers, operators and validation rules are Client Input Required. Interaction specification: Trigger → User selects a node → System inserts a node at the relevant canvas position → New node receives focus and selection → Inspector opens. Empty state: Display a concise instruction: "Start by adding a trigger to define when this journey begins." Search empty state: "No matching nodes found. Try another search." Error state: If insertion fails, preserve the existing canvas and show a recoverable error notification. PF-03 — Node Configuration Inspector Critical screen Purpose: Allow users to configure nodes without navigating away from the journey. Primary user goal: Configure a node correctly and understand its current validity. Primary action: Save or apply node configuration. Secondary actions: - Inspect connections. - Duplicate node, subject to product rules. - Delete node with confirmation. - Close inspector. - View validation details. Inspector layout nextflow.admin-intelligence.de Recommended panel structure: 1. Node icon, name and type. 2. Configuration status. 3. Node-specific fields. 4. Connection information. 5. Validation feedback. 6. Apply or cancel actions. Example: Condition node Condition configuration Incomplete Illustrative data — proposed configuration interface Node nameCustomer Eligibility Customer attributeSelect attribute... OperatorSelect operator... Comparison valueEnter value... Configuration required Complete the required condition settings before this node can be considered valid. Cancel Apply changes Configuration behavior - Persistent field labels. - Required fields clearly marked. - Inline validation. - Retain user input after validation errors. - Do not apply invalid configuration silently. - Distinguish unsaved edits from applied configuration. - Explain how configuration affects downstream connections. Important design decision: Prefer an inline inspector over a full-screen modal for ordinary node configuration. This maintains canvas context and reduces navigation overhead. Next step: Return to the canvas and inspect the resulting node state. PF-04 — Connection and Branch Editor Critical screen Purpose: Allow users to create and inspect journey execution paths. Primary user goal: Connect nodes into a comprehensible and structurally valid workflow. Primary action: Connect an output handle to an input handle. Visual connection model overflowacademy.dev Proposed visual conventions: Element Appearance Default connection Electric indigo Selected connection Brighter indigo with increased stroke Condition success branch Labelled output Condition alternative branch Separate labelled output Invalid connection Rose with warning indicator Connection interaction Visible endpoint handles The success/alternative labels are illustrative. Actual condition outcomes require client approval. Interaction specification Creating a connection Trigger → User drags from an output handle → System checks connection compatibility → Valid connection preview appears → User releases at target input → Connection is created. Invalid connection Trigger → User attempts an incompatible connection → System rejects it → Invalid target is highlighted → Existing graph remains unchanged. Deleting a connection Trigger → User selects connection and chooses delete → System requests confirmation if necessary → Connection is removed → Validation state is recalculated. Branch visibility requirements - Branches must remain visually distinguishable. - Branch labels must not depend exclusively on color. - Connection paths must avoid overlapping node labels. - Selected connections must remain identifiable. - Disconnected outputs must be discoverable. - Large graphs must support pan, zoom and minimap navigation. Next step: Validate graph completeness and inspect any unconnected outputs. PF-05 — Validation and Issues Review Critical screen Purpose: Identify configuration and graph problems before publication. Primary user goal: Resolve every blocking issue and understand remaining warnings. Primary action: Navigate to and fix an identified issue. Validation bar Journey validation Blocked 3 Errors 1 Warnings 8 Valid nodes Condition node incomplete Customer Eligibility · Node 04 Error Unconnected branch Alternative output · Node 06 Warning Illustrative validation content Proposed validation categories Severity Example UX treatment Error Required configuration missing Block publication provisionally Error Invalid or broken connection Highlight node and path Error Unlinked mandatory output Highlight missing connection Warning Unused or potentially redundant node Allow review Warning Potentially unintended branch behavior Explain the concern Success Node configuration valid Show valid state Assumption: Blocking errors prevent publishing. Warnings are informational and do not automatically block publication. Client Input Required: The final distinction between errors and warnings, including whether unused outputs are permitted. Validation interactions - Clicking an issue selects its corresponding node. - The canvas pans to the relevant node. - The inspector opens with the affected field or connection. - Resolving an issue recalculates the validation summary. - Validation changes are reflected without requiring a page refresh. Next step: Once blocking errors are resolved, initiate publishing. PF-06 — Publish Confirmation Modal Critical screen Purpose: Ensure users understand the consequences of publishing a journey. Primary user goal: Confirm deployment of the correct journey. Primary action: Publish journey. Secondary actions: Cancel, return to editing, review issues. Proposed modal design Publish journey Review the journey before deployment. JOURNEY Onboarding Journey Configured nodes 8 Blocking errors 0 Warnings 1 Review warning One warning remains. Confirm that the journey is ready for deployment. Cancel Publish journey Illustrative modal. Counts and deployment behavior are demonstration content.Publish state model 1. User selects Publish. 2. System runs the required validation. 3. If blocking errors exist, publishing is prevented and issues are displayed. 4. If validation passes, the confirmation modal opens. 5. User explicitly confirms publication. 6. System processes the publish request. 7. Success or failure is communicated clearly. Required states State UX behavior Validation in progress Show progress and prevent duplicate submission Blocking errors Modal does not offer a usable publish action Ready Show journey summary Publishing Disable repeat confirmation Published Display success and published status Publish failed Preserve draft and show recovery guidance Permission denied Explain missing authorization Client Input Required: Whether publishing is immediate, scheduled, approval-based or versioned, and whether an existing active journey is replaced. 5. Visual design system 5.1 Design direction Inferred Digital Design System: Dark, high-density enterprise workspace with strong information hierarchy, restrained visual effects and consistent interactive feedback. The canvas should feel like a professional orchestration environment, not a conventional dashboard. 5.2 Color tokens #020617 Canvas background Deepest slate #0F172A Primary surface Slate 900 #1E293B Node containers Slate 800 #F8FAFC Primary text Slate 50 #4F46E5 Primary accent Electric indigo #10B981 Active / success Emerald #FBBF24 Warning / draft Amber #F43F5E Error Rose Additional proposed tokens: Token Value Purpose Surface elevated #334155 Hovered controls Secondary text #94A3B8 Supporting information Border #334155 Component boundaries Subtle border #475569 Visible separators Focus ring #A5B4FC Keyboard focus Accessibility refinement: Status backgrounds must not be mistaken for text colors. Use sufficiently light foreground text on dark status backgrounds and dark foreground text on light status backgrounds. Validate actual combinations against WCAG. 5.3 Typography scale Recommended typeface: Inter. Token Size Weight Usage Display 28px 600 Workspace titles H1 24px 600 Main screen headings H2 20px 600 Panel headings H3 16px 600 Node headings Body 14px 400 Standard content Small 12px 400 Supporting text Micro 11px 500 Compact metadata Use 1.4–1.5 line-height for normal text. Do not rely on micro-text for essential instructions. 5.4 Spacing and geometry Use an 8-point spacing system. Token Value Space 1 4px Space 2 8px Space 3 12px Space 4 16px Space 5 24px Space 6 32px Space 7 40px Space 8 48px Recommended dimensions: - Top navigation: 64px. - Node library: 240–280px. - Inspector: 320–380px. - Bottom validation bar: 48–56px. - Node corner radius: 10–12px. - Standard controls: minimum 44px height. - Canvas node spacing: 48–80px, adjustable by layout. 5.5 Component states Every reusable interactive component must define: - Default. - Hover. - Focus-visible. - Active/pressed. - Selected. - Disabled. - Loading. - Error. - Success, where applicable. Avoid using color alone to indicate state. Combine color with icons, labels, borders and text. 6. Canvas architecture and interaction design 6.1 Recommended canvas model Inferred technical recommendation Use React Flow as the canvas interaction framework. Recommended conceptual architecture: PulseFlow Workspace │ ├── Application Shell │ ├── Top Navigation │ ├── Journey Header │ └── Validation Footer │ ├── Journey Editor │ ├── Node Library Drawer │ ├── React Flow Canvas │ │ ├── Custom Node Renderer │ │ ├── Connection Renderer │ │ ├── Selection Controls │ │ ├── Zoom / Pan │ │ └── Minimap │ └── Configuration Inspector │ ├── Validation Layer │ ├── Node Validation │ ├── Connection Validation │ └── Journey Validation │ └── Publish Workflow ├── Pre-publish Validation ├── Confirmation Dialog └── Deployment Feedback Architectural recommendations 1. Keep journey graph data separate from visual presentation state. 2. Represent nodes and edges using stable identifiers. 3. Use custom React Flow node types for triggers, conditions, actions and waits. 4. Store node configuration independently of its rendered appearance. 5. Centralize validation logic instead of duplicating rules across components. 6. Keep inspector state synchronized with the selected graph element. 7. Avoid coupling the publication workflow directly to canvas rendering. 8. Provide a graph-to-validation navigation mechanism. Proposed domain model The following is a provisional conceptual model, not an approved API contract. type NodeCategory = | "trigger" | "condition" | "action" | "wait"; type NodeStatus = | "incomplete" | "valid" | "warning" | "error"; interface JourneyNode { id: string; type: NodeCategory; label: string; position: { x: number; y: number; }; configuration: Record<string, unknown>; status: NodeStatus; } interface JourneyConnection { id: string; source: string; target: string; sourceHandle?: string; targetHandle?: string; label?: string; } interface JourneyDraft { id: string; name: string; nodes: JourneyNode[]; connections: JourneyConnection[]; } Client Input Required: Persistence schema, API contracts, concurrency behavior, supported node types and configuration schemas. 6.2 Core keyboard interactions Keyboard shortcut Proposed behavior Tab Navigate interactive elements Enter / Space Activate focused control Escape Close popover/dialog or cancel active interaction Delete Delete selected element after appropriate safeguards Ctrl/Cmd + Z Undo Ctrl/Cmd + Shift + Z Redo Ctrl/Cmd + S Save draft Ctrl/Cmd + Enter No default publish shortcut; reserve publication for explicit confirmation These are proposed shortcuts and require conflict checks with browser and assistive technology conventions. Keyboard graph navigation React Flow canvas manipulation must not be the only way to understand the journey. Provide an accessible alternative: - A node outline or graph navigator. - A sequential list of nodes. - A connection and branch description. - Keyboard-accessible node selection. - An accessible connection-management mechanism. This is particularly important for users who cannot use precision drag-and-drop interactions. 7. Journey state model and edge cases 7.1 Journey lifecycle Draft Journey is being created or edited Validation Configuration and graph checks Blocked Errors found Return to editing Ready Validation passed Continue to review Publish confirmation Explicit user confirmation Published Active journey This is a proposed UX lifecycle. The actual lifecycle, including pause, archive, rollback and versioning, requires client input. 7.2 Edge-case handling Scenario Required UX response Empty canvas Explain how to add the first trigger Node insertion fails Preserve graph and display recovery message Incomplete node Rose status, inline explanation and inspector navigation Disconnected node Highlight unconnected inputs/outputs Invalid connection Reject without changing the existing graph Duplicate node Apply stable ID and configuration-copy rules, pending approval Node deletion Warn about affected connections Unsaved changes Show unsaved state and protect against accidental loss Save failure Retain local edits and offer retry Concurrent modification Detect conflict and request reconciliation Large graph Maintain navigation performance and provide minimap Validation timeout Show retryable state; do not report success Publish failure Preserve draft and provide actionable recovery Permission restriction Show read-only state or denied action explanation Session expiry Preserve recoverable work where technically possible Browser refresh Restore the last persisted state, subject to persistence design 7.3 Important error prevention patterns Destructive actions Node deletion should not silently remove downstream branches. The interface should explain which connections are affected before confirmation. Unsaved changes The user must be able to distinguish: - Changes currently applied to the canvas. - Changes saved to persistence. - Changes still being processed. Duplicate submissions Publish confirmation must be disabled during an active publish request. Stale validation Any change to graph configuration or connections should invalidate or recalculate the previous validation result. 8. Responsive behavior Although the product is desktop-first, the layout should degrade predictably at smaller viewports. Confirmed primary target: 1440px+ 8.1 Viewport specifications Desktop Primary 1440px+ Three-region workspace. Both side panels can collapse. Canvas receives remaining width. Tablet 768px Canvas prioritized. Library and inspector become overlays or drawers, never permanently compete for canvas width. Mobile 390px Read-only or limited inspection experience is recommended until complex graph editing can be made reliable on touch. 8.2 Detailed responsive rules Component 1440px+ 768px 390px Top bar Full Compact Minimal Node library Persistent drawer Overlay drawer Bottom sheet Canvas Full workspace Main content Pan/zoom inspection Inspector Right sidebar Overlay drawer Full-height sheet Validation Persistent footer Collapsible Dedicated issue view Publish modal Center modal Center modal Full-screen dialog Important: Mobile editing is not part of the confirmed business requirement. The proposed mobile experience is an accessibility and adaptability recommendation, not a commitment to feature parity. 9. Accessibility specification — WCAG 2.2 AA Accessibility is a release requirement, not a visual enhancement. 9.1 Accessibility requirements Area Requirement Contrast Minimum 4.5:1 for normal text Large text Minimum 3:1 UI boundaries At least 3:1 for applicable meaningful graphical objects Keyboard All interactive features keyboard accessible Focus Clearly visible focus indicators Target sizes Minimum 24 × 24 CSS px under WCAG 2.2 AA, subject to exceptions; adopt 44 × 44 px as the PulseFlow design target Labels Every input has a programmatic label Errors Clearly identified and associated with affected fields Screen readers Announce selection, validation and publication states Dialogs Correct focus management and accessible names Motion Respect reduced-motion preferences 9.2 Canvas accessibility The canvas is the highest-risk accessibility component. Recommended requirements: 1. Nodes must expose semantic accessible names. 2. Node status must be announced independently of color. 3. Connections must have accessible descriptions. 4. Users must be able to inspect graph topology without dragging. 5. Keyboard navigation must support predictable node traversal. 6. Connection creation must have a non-drag alternative. 7. Canvas zoom controls must be accessible. 8. Focus must remain visible when selecting nodes. Example screen-reader descriptions - "Trigger node, User Signup, valid." - "Condition node, Customer Eligibility, configuration incomplete." - "Connection from Customer Eligibility, output: Yes, to Push Notification." - "Journey validation failed. Three blocking errors and one warning." Focus management - When the inspector opens, move focus to its heading or first meaningful control according to the interaction context. - When a modal opens, trap focus appropriately. - When a modal closes, restore focus to its invoking control. - After an error, announce the error and provide a direct route to the affected control. 9.3 Contrast verification The supplied palette is a starting point, not proof of accessibility compliance. The following combinations require particular scrutiny: - Indigo connection lines on the deepest canvas background. - Secondary slate text on slate-900. - Amber status labels. - Rose validation labels. - Small node metadata. - Focus indicators against elevated surfaces. Use text labels and iconography alongside colored indicators. Selected connections should also change stroke weight or display an additional selection marker. 10. Interaction and feedback specifications The following patterns should be consistent throughout the application. User action System response Visual feedback Add node Insert node Selected node and inspector Configure node Validate fields Updated node status Connect nodes Check compatibility Connection preview Select connection Show connection details Highlighted edge Delete node Check dependencies Confirmation dialog Save journey Persist changes Saved indicator Run validation Evaluate graph Updated issue summary Publish journey Validate and deploy Processing and result states Notification strategy Use three levels of feedback: - Inline messages: Field-level errors and configuration guidance. - Toast notifications: Save success, save failure and recoverable operations. - Persistent validation bar: Journey-wide blocking errors and warnings. Do not use toasts as the only indication of important errors because they disappear. 11. Technical implementation recommendations Architecture recommendations — not confirmed implementation decisions 11.1 Suggested frontend structure src/ ├── app/ │ ├── PulseFlowApp.tsx │ └── WorkspaceLayout.tsx │ ├── components/ │ ├── navigation/ │ │ ├── TopBar.tsx │ │ └── JourneyHeader.tsx │ │ │ ├── canvas/ │ │ ├── JourneyCanvas.tsx │ │ ├── CustomNode.tsx │ │ ├── CustomEdge.tsx │ │ ├── CanvasControls.tsx │ │ └── GraphNavigator.tsx │ │ │ ├── library/ │ │ ├── NodeLibrary.tsx │ │ └── NodeLibraryItem.tsx │ │ │ ├── inspector/ │ │ ├── NodeInspector.tsx │ │ └── ConfigurationFields.tsx │ │ │ ├── validation/ │ │ ├── ValidationBar.tsx │ │ └── ValidationIssues.tsx │ │ │ └── publishing/ │ └── PublishDialog.tsx │ ├── domain/ │ ├── journey.types.ts │ ├── validation.types.ts │ └── node.types.ts │ ├── services/ │ ├── journey.service.ts │ ├── validation.service.ts │ └── publishing.service.ts │ ├── hooks/ │ ├── useJourney.ts │ ├── useCanvasSelection.ts │ └── useJourneyValidation.ts │ └── styles/ └── design-tokens.css 11.2 State management Recommended separation: State category Examples Domain state Nodes, edges, configurations Presentation state Zoom, pan, selected node Form state Current inspector edits Validation state Errors, warnings, validity Persistence state Saved, dirty, saving, failed Publication state Ready, processing, published, failed The exact state-management library is not specified. React state and context may be sufficient initially; Zustand is a possible option if editor complexity warrants it. 11.3 Engineering quality considerations - Use stable node and edge IDs. - Prevent accidental mutation of the graph. - Debounce non-critical persistence operations where appropriate. - Do not debounce away important validation feedback. - Keep rendering optimized for larger graphs. - Avoid unnecessary re-rendering of unaffected nodes. - Separate graph serialization from UI component state. - Support undo/redo through controlled state transitions. - Protect against stale asynchronous validation results. - Ensure publish requests are idempotent where supported by the backend contract. Client Input Required: Expected maximum journey size, autosave requirements, API latency targets, browser support, persistence strategy and availability objectives. 12. UX quality assurance and acceptance criteria 12.1 Design QA checklist Design review checklist 0/15 reviewed [ ] Workspace hierarchy clearly prioritizes the canvas Information architecture [ ] Node categories are discoverable Node library [ ] Inspector preserves canvas context Configuration [ ] Incomplete nodes are identifiable Validation [ ] Invalid connections are rejected Connections [ ] Branch outputs are distinguishable without color Connections [ ] Unsaved changes are visible Persistence [ ] Publish requires explicit confirmation Publishing [ ] Errors provide a direct recovery path Error handling [ ] Keyboard alternatives exist for graph manipulation Accessibility [ ] Focus indicators are visible Accessibility [ ] Dialogs have appropriate focus management Accessibility [ ] Layout supports 1440px and 768px viewports Responsive [ ] Mobile inspection behavior is defined Responsive [ ] All interactive states have specifications Design system Reset review Interactive review checklist. Checking an item records your review progress, not an independent technical test result.12.2 Acceptance criteria The experience should be considered ready for implementation approval when: ID Acceptance criterion AC-01 Users can discover and insert all defined node categories. AC-02 Each node exposes its relevant configuration inspector. AC-03 Required configuration fields are validated. AC-04 Connections are visually inspectable and editable. AC-05 Invalid connections produce understandable feedback. AC-06 Validation issues link directly to affected graph elements. AC-07 Unsaved and saved states are distinguishable. AC-08 Publication requires successful blocking validation and explicit confirmation, subject to approved rules. AC-09 Publication failures do not silently discard the draft. AC-10 Core functionality has keyboard-accessible alternatives. AC-11 The 1440px workspace maintains usable canvas space. AC-12 Responsive behavior is defined for 768px and 390px. 13. QA outcomes, limitations and technical debt 13.1 Design review outcome Design specification Completed Experience architecture Defined Screen inventory Defined Interaction patterns Defined Visual design tokens Proposed Responsive specifications Defined Accessibility requirements Specified Implementation and runtime QA Not performed 13.2 Checks not performed This engagement is currently in DESIGN MODE. Therefore, the following have not been executed: - React component implementation. - Browser-based interaction testing. - Actual WCAG contrast measurement of every component. - Screen-reader testing. - Keyboard-only usability testing. - React Flow performance testing. - Cross-browser compatibility testing. - API integration testing. - Persistence and concurrent editing testing. - Real publication and rollback testing. 13.3 Known limitations 1. Business logic is not fully specified. 2. Provider integrations are not identified. 3. The final node configuration schemas are unknown. 4. Publication permissions and deployment semantics are unknown. 5. Customer data and consent requirements remain undefined. 6. Mobile editing is not confirmed as an in-scope requirement. 7. Production scalability requirements are not quantified. 13.4 Technical debt to track Priority Technical debt Resolution High Undefined journey validation contract Agree validation specification High Undefined persistence and versioning Establish domain/API contracts High Graph accessibility alternatives Prototype and test accessible graph navigator High Undefined publishing lifecycle Approve deployment state machine Medium Large graph rendering strategy Establish performance benchmarks Medium Undo/redo persistence semantics Define operation history model Medium Responsive editing limitations Validate mobile/tablet expectations Medium Design token contrast verification Run automated and manual audits 14. Final architectural design recommendation Recommended experience direction A dark, three-region visual orchestration workspace built around React Flow, contextual configuration and persistent journey validation. The most important architectural decision is to treat the canvas, configuration inspector and validation engine as three coordinated but independently managed parts of the experience. This avoids turning the canvas into an overloaded form editor, while ensuring that users always understand the state and consequences of their changes. Recommended implementation sequence Phase Deliverable Priority 1 Design tokens and workspace shell P0 2 React Flow canvas and custom nodes P0 3 Node library and inspector P0 4 Connection and branching interactions P0 5 Validation engine and issue navigation P0 6 Publish confirmation and state handling P0 7 Accessibility and responsive refinement P0 8 Performance and browser QA P1 15. Client decisions required before production approval The following five questions should be answered first because they influence the underlying graph model, validation architecture and publishing experience. Product decision register 0/5 answered 1. How should journey entry work? Single entry trigger Multiple entry triggers Client decision pending 2. How should conditional branching work? Explicit Yes/No outputs Multiple condition branches Configurable branching rules Client decision pending 3. What should publishing do? Publish immediately Schedule publication Require approval Versioned deployment Client decision pending 4. How should configuration be stored? Save changes automatically Apply changes explicitly Autosave with version history Client decision pending 5. What is the required mobile experience? Desktop only Mobile read-only Mobile inspection and limited editing Full mobile editing Client decision pending Submit product decisionsPartial answers are accepted. Unanswered items remain Client Input Required. Final status: The PulseFlow end-to-end UX specification is established at design level. It is ready for stakeholder review and subsequent BUILD MODE implementation planning. Production approval remains conditional on resolving the critical client inputs and validating the accessibility and technical requirements.