Document Type: Framework
Status: Active
Authority: Data Brain
Parent: Data Brain Canon
Applies To: All dashboards, reporting outputs, visualizations, and decision interfaces across MWMS
Version: v1.0
Last Reviewed: 2026-05-02
Purpose
The Data Brain Decision Surface Framework defines how MWMS presents data in a way that directly supports decision-making.
The goal is to ensure all data outputs:
- reduce cognitive load
- highlight what matters
- enable fast interpretation
- support clear decisions
- avoid unnecessary complexity
This framework ensures MWMS does not produce reports, but instead produces decision-ready interfaces.
Scope
This framework applies to:
- dashboards
- reporting outputs
- visualizations
- performance monitoring systems
- analytical interfaces
- future plugin and UI systems
It governs how data is presented, not how it is collected or stored.
Core Principle
Data presentation must serve decision clarity, not information completeness.
If a user cannot quickly answer:
- what is happening
- whether it is good or bad
- what action should be taken
then the decision surface has failed.
Definition — Decision Surface
A Decision Surface is:
a structured presentation of data designed to enable a user to quickly understand performance and make a decision.
It differs from a dashboard in that:
- it prioritizes action over exploration
- it limits unnecessary detail
- it highlights key signals
- it reduces thinking effort
Decision Surface Structure
All decision surfaces must follow this structure:
1. Primary Metric
- single most important metric
- visually dominant
- clearly identifiable
Purpose:
→ answer: “what matters most?”
2. Performance Context
Must include one or more of:
- comparison to previous period
- comparison to target
- comparison to benchmark
Purpose:
→ answer: “is this good or bad?”
3. Supporting Context
- limited secondary metrics
- simplified representation
- clearly visually secondary
Purpose:
→ answer: “why is this happening?”
4. Pattern Visibility
- trends
- spikes
- anomalies
- relationships
Purpose:
→ answer: “what is changing?”
5. Decision Signal
Must be inferable or explicit:
- continue
- adjust
- scale
- investigate
- stop
Purpose:
→ answer: “what should we do?”
Cognitive Load Control
All decision surfaces must minimise cognitive load.
Rules:
- avoid unnecessary chart types
- avoid excessive data density
- avoid clutter and decoration
- avoid legends where possible
- avoid complex multi-axis visuals
- avoid requiring interpretation training
Cognitive Load Test
Before finalising any surface, confirm:
- can a user understand it within seconds
- can a user explain it without confusion
- does the layout guide attention naturally
If not:
→ redesign is required
Visualization Rules
Standard First Rule
Use standard chart types unless absolutely necessary:
- line charts
- bar charts
- simple tables
Non-standard charts must only be used when:
- they improve clarity
- they reveal patterns not otherwise visible
Pattern First Rule
Visuals must prioritise:
- trends
- comparisons
- relationships
Exact values are secondary.
Visual Hierarchy Rule
- primary metric must dominate visually
- supporting data must be clearly secondary
- color must guide attention, not decorate
Color Usage Rule
- use limited color palette
- use color for emphasis only
- avoid red-green dependency
- ensure accessibility
Text As Data Rule
Text can function as a visualization:
- key numbers should be large and prominent
- contextual information should be smaller
- contrast should guide reading order
Dashboard Type Separation
MWMS enforces separation between two types of surfaces:
Performance Measurement Surfaces
Purpose:
- quick decision making
- KPI monitoring
- low cognitive load
Characteristics:
- simple
- focused
- limited interaction
Analytical Interfaces
Purpose:
- exploration
- investigation
- deep analysis
Characteristics:
- complex
- interactive
- higher cognitive load
Separation Rule
Performance surfaces must NOT attempt to:
- answer all questions
- replicate analytical tools
- include excessive detail
Analytical interfaces must NOT be used as:
- executive dashboards
- stakeholder reporting surfaces
Data Story Integration
Decision surfaces must support narrative clarity.
Rules:
- each surface must communicate a single primary message
- data must be framed with context
- unnecessary information must be removed
- clarity must override completeness
Drift Protection
The system must prevent:
- dashboard bloat
- visual clutter
- excessive metrics on a single surface
- mixing analysis with reporting
- decorative chart usage
- inconsistent layout structures
- unclear primary metric hierarchy
Architectural Role
This framework operates within:
- Data Brain (presentation layer)
- HeadOffice (decision visibility)
- Ads Brain (performance interpretation)
- Affiliate Brain (decision support)
It ensures that all downstream systems:
→ receive clear, structured, decision-ready outputs
Relationship To Other MWMS Standards
This framework works alongside:
- MWMS Architecture Registry
- MWMS Page Naming Standard
- MWMS Document Structure Standard
- MWMS Brain Routing Rule
- Tracking Governance Protocol
Architectural Intent
The Data Brain Decision Surface Framework ensures:
- MWMS outputs are actionable
- decision-making is accelerated
- cognitive load is minimized
- system clarity is preserved
- scaling decisions are improved
The system moves from:
→ data reporting
to:
→ decision intelligence
Change Log
Version: v1.0
Date: 2026-05-02
Author: Data Brain
Change:
Created Data Brain Decision Surface Framework to standardize how MWMS presents data for decision-making and to prevent dashboard clutter and cognitive overload.
Change Impact Declaration
Pages Created:
Data Brain Decision Surface Framework
Pages Updated:
None
Pages Deprecated:
None
Registries Requiring Update:
MWMS Architecture Registry
Canon Version Update Required:
No
Change Log Entry Required:
Yes
END OF DOCUMENT