Document Type: Standard
Status: UI Design Standard
Version: v1.1
Authority: MWMS HeadOffice
Applies To: HeadOffice interface and all Brain dashboard pages
Parent: HeadOffice UI – Navigation & Page Architecture
Last Reviewed: 2026-03-15
Purpose
This document defines the visual and structural standards for cards and panels used across the HeadOffice interface.
Cards and panels are the primary building blocks of the HeadOffice UI.
Without standardisation, these elements can quickly become inconsistent, making the system feel fragmented and unprofessional.
This document ensures that:
• all pages share a common visual language
• metrics are presented clearly
• information hierarchy remains consistent
• the interface feels like a unified system
The goal is to make HeadOffice feel like a professional internal system console rather than a collection of plugin pages.
Scope
This standard applies to:
• HeadOffice interface cards and panels
• Brain dashboard pages
• summary-card design across MWMS reporting views
• panel structure for intelligence and visibility surfaces
• visual consistency rules for dashboard component design
This document governs the core component design language for cards and panels across HeadOffice UI surfaces.
It does not govern:
• operational execution controls
• backend data architecture
• live campaign actions
• authority rules by themselves
• Brain-specific metrics by themselves
• advanced visualisations requiring separate approval
Those remain governed by HeadOffice, the relevant Brain pages, and supporting architecture or specification documents.
Definition / Rules
Core UI Components
The HeadOffice UI uses two primary components:
• Cards
• Panels
Each component has a specific role.
Cards
Role
Cards display high-level summary signals.
They provide fast system awareness without showing detailed data.
Cards appear in:
• the Global Dashboard
• Brain Executive Summary sections
• key system overview areas
Cards should always present single metrics or status indicators.
Card Content Structure
Each card must contain three elements:
• Metric Title
• Metric Value
• Optional Status Indicator
Example structure:
Opportunities In Intake
18
or
Capital Exposure
$12,400
Status: Watch
Cards must remain simple.
They are not mini-reports.
Card Layout Rules
Cards should follow consistent visual structure across all pages.
Recommended visual characteristics:
• rectangular layout
• consistent padding
• strong metric value
• smaller descriptive title
• optional status indicator beneath value
Cards must remain visually consistent regardless of page context.
Card Quantity
Cards must remain limited in number.
Recommended range:
4–6 cards per section
Too many cards reduce readability and weaken signal clarity.
Card Purpose Rule
Cards must only show high-level signals.
They must not display:
• detailed tables
• large text explanations
• multiple unrelated metrics
• long descriptions
Cards exist to provide quick insight.
Detailed information belongs in panels.
Panels
Role
Panels present domain intelligence and operational visibility.
Panels may contain:
• data tables
• lifecycle visualisations
• experiment summaries
• classification summaries
• alert lists
Panels appear beneath executive summary cards.
Panels represent the working intelligence layer of the page.
Panel Content Structure
Each panel must include:
• Panel Title
• Panel Content Area
Optional:
• short description line under title
Example:
Opportunity Intake
Recent opportunities entering the Affiliate Brain evaluation queue.
Panel Layout Rules
Panels should follow consistent visual characteristics:
• clear section title
• content area beneath title
• consistent margin spacing
• visually separated from other panels
• structured internal layout
Panels may vary in size depending on the complexity of the data displayed.
Panel Quantity
A Brain page should typically contain 3–6 panels.
Too many panels reduce clarity and increase cognitive load.
Panels must represent the core intelligence areas of that Brain.
Card vs Panel Distinction
The difference between cards and panels must remain clear.
Cards answer:
What is happening right now?
Panels answer:
Why is it happening and where should we look deeper?
Cards show signals.
Panels show structure.
Panel Grouping
Panels should be grouped logically when possible.
Example grouping:
• Pipeline Panels
• Experiment Panels
• Risk Panels
• Financial Panels
Grouping improves readability and helps the viewer understand system structure.
Panel Titles
Panel titles must remain:
• short
• clear
• domain specific
Examples:
• Opportunity Intake
• Evaluation Queue
• Campaign Health
• Experiment Registry
• Capital Exposure
• System Alerts
Avoid overly technical titles or implementation language.
Information Hierarchy
All pages must follow this hierarchy:
• Page Title
• Section Title
• Cards
• Panels
• Tables / Detailed Content
This hierarchy ensures that the most important information appears first.
Spacing and Layout
Spacing between components must remain consistent.
Recommended layout pattern:
• cards appear in a horizontal row
• panels appear in a grid beneath the cards
• panels should align visually across the page where possible
Spacing should prioritise readability over density.
Status Indicators
Status indicators communicate system state.
They should appear on cards and sometimes in panel headers.
Recommended states:
• Healthy
• Watch
• Risk
• Stable
• Degraded
These states must be used consistently across all pages.
Colour Usage
Colour must represent system meaning, not decoration.
Recommended system:
• Green — Healthy
• Amber — Watch
• Red — Risk
• Blue — Informational
Colour should be used sparingly.
Overuse of colour reduces signal clarity.
Typography
Typography should follow a clear hierarchy.
Recommended order:
• Page Title
• Section Title
• Card Metric Value
• Card Title
• Panel Title
• Table Labels
Metric values should be visually stronger than labels.
This ensures quick readability.
Tables Inside Panels
Tables should remain readable and structured.
Tables may include:
• Name
• Status
• Stage
• Metric Value
• Date Updated
Tables must avoid excessive columns or dense text.
The goal is quick scanning.
Panel Interaction Rules
Panels may allow limited interactions such as:
• sorting
• filtering
• time window selection
Panels must not perform operational actions unless explicitly approved by governance.
HeadOffice pages remain primarily observational.
Design Consistency Rule
All cards and panels across the HeadOffice interface must follow the same design language.
This ensures that:
• new pages integrate smoothly
• Brain pages feel unified
• the system feels intentional
Ad-hoc visual designs must be avoided.
WordPress Constraint Rule
The HeadOffice UI currently exists inside WordPress admin.
This means the interface must operate within certain technical constraints.
However, the UI must still aim for the experience of a modern internal system dashboard.
Even inside WordPress, the system must feel deliberate and professional.
Future Design Evolution
Future improvements may include:
• interactive data visualisations
• heatmaps
• pipeline flow diagrams
• advanced alert dashboards
• executive summary automation
These features require separate structural approval.
The card and panel standard remains the foundation of all UI development.
Final Rule
Cards and panels are the building blocks of the HeadOffice interface.
They must remain:
• consistent
• structured
• clear
• professional
A disciplined design system ensures that MWMS continues to feel like a governed intelligence platform, not a loose collection of dashboards.
Drift Protection
The system must prevent:
• cards becoming overloaded mini-reports
• panels drifting into inconsistent layouts across pages
• Brain dashboards using conflicting component logic
• visual decoration overriding signal clarity
• operational controls being embedded into observational components without approval
• future UI additions ignoring the shared design language
Cards and panels must remain predictable, readable, and governance-safe.
Architectural Intent
HeadOffice UI – Card & Panel Design Standard exists to define the foundational component language for MWMS dashboard surfaces.
Its role is to ensure that summary signals and deeper intelligence areas are presented through a consistent, professional structure so the HeadOffice interface feels unified, readable, and intentionally governed across all Brain pages.
Change Log
Version: v1.1
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original purpose, component roles, card and panel rules, hierarchy, spacing guidance, status and colour rules, typography guidance, interaction limits, WordPress constraint rule, future design evolution note, and final principle. Added standard document header, Parent field, Scope, Definition / Rules structure, Drift Protection, and Architectural Intent sections.
Version: v1.0
Date: 2026-03-13
Author: MWMS HeadOffice
Change: Initial creation of HeadOffice UI – Card & Panel Design Standard defining the visual and structural standards for cards and panels used across the HeadOffice interface.
END – HEADOFFICE UI – CARD & PANEL DESIGN STANDARD v1.1