01
Real-time
The foundational UX argument for the project. Yesterday's data drove the wrong calls today. Real-time changes the behavioral posture from reactive to proactive.
The framework I built for designing BI dashboards as decision tools — starting with what decisions need to be made, not what data is available. The non-obvious thing: dashboards fail not because of bad data engineering, but because they're designed as data displays rather than decision tools.
Most BI dashboard projects fail not because of bad data engineering. They fail because they were designed as data displays rather than decision tools.
A data display is organized around data structure — tables, categories, system outputs. A decision tool is organized around decision structure — urgency, anomaly, comparison, trend. When someone opens a dashboard in a real-world moment, a campaign is underperforming, a budget needs reallocation, a lead spike needs explaining — they're not browsing. They're looking for a specific answer to a specific question under time pressure.
Most dashboards start at Technology ("what can we show?") and stop. The pyramid forces you to start at the bottom ("what decisions need to be made and by whom?") and let Technology serve that question — not define it. Hover any segment to see what it delivers.
The structural insight: the pyramid was the stakeholder alignment tool, not just a design deliverable. Getting People, Business, Vision, and Technology leads to agree on the pyramid before any wireframes were drawn — that's organizational design, not UX design. And that's where the real leverage was.
These were the negotiated scope of the platform — what was in, what was explicitly out, and why. Each is a UX decision before it's a technical one.
The foundational UX argument for the project. Yesterday's data drove the wrong calls today. Real-time changes the behavioral posture from reactive to proactive.
Same underlying data, different representations per role. Executives get trend summaries. Field workers get task-level specifics. One source, two reading modes.
Don't make users context-switch between a campaign tool and a finance tool to understand ROI. Bring the budget data to where the campaign decisions are happening.
Leads data doesn't belong in a separate CRM view. It belongs adjacent to the campaign data that generated it — the connection is the insight.
The "so what" metric. The number that made the business case for the entire platform. Everything else was a means to this end.
The success metric wasn't "users log in." It was "decisions get made faster, with better information." That's a different design brief.
Better-informed decisions and strategic planning. The measure of success isn't "users can find the data" — it's "users make faster, better-calibrated calls."
Raw data isn't information. Information requires interpretation. The dashboard's job is to do the first layer — surface anomalies, contextualize numbers, remove noise.
Help organizations spot trends to capitalize on opportunities and address problems early. Required designing for comparison, not just display.
More collaborative analysis through increased information sharing. Shareable, commentable, linkable — not a static PDF that dies as an attachment.
Eight capability modules, organized in two rows. The top four are what the platform knows. The bottom four are what users do with that knowledge. Each module can stand alone — the value is in the full landscape view.
The most significant UX shift was Campaign Management: the ability to start, pause, or stop campaigns directly from the dashboard. It collapsed the loop — see data → make decision → take action, all in one view. Every other module is in service of making that final step possible without context-switching.
Each principle is concrete enough that a teammate could review a screen and tell you whether it's followed or not.
Most dashboards mirror the org chart: marketing here, finance there, CRM in another section. The integrated dashboard organizes by urgency and decision type — what needs attention now is always at the top, regardless of which system generated the data.
Every insight should have an adjacent action. Underperforming campaign? Pause from the same view. Budget overspending? Reallocation one click away. The further the gap, the more decisions get deferred.
A test: if a stakeholder opened this at 3am because something went wrong, would they find the relevant information within 30 seconds? This filters out everything decorative — every nested menu, every chart that exists for completeness rather than utility.
Executives read the headline. Operators drill down. Finance monitors budgets. Rather than three dashboards, one surface with progressive disclosure — depth that expands on demand. Nobody has to switch platforms.
If a user has to remember that leads come from Salesforce, budget from NetSuite, and campaigns from HubSpot — the integration has failed. The dashboard's job is to make data provenance invisible and decision context obvious.
The dashboard was campaign-management-shaped, but each underlying move applies to any system that has data in multiple places and decisions getting made across multiple tools.
Those are different questions, and most BI projects confuse them. Starting with "what data do we have?" produces data displays. Starting with "what decisions get made under pressure?" produces decision tools.
Getting People, Business, Vision, and Technology leads to agree on the pyramid was organizational design, not UX. The real leverage was in the alignment artifact, not the wireframes that came after.
The success metric was "decisions get made faster, with better calibration." Not "users log in." That distinction reshapes the entire design brief — what to measure, what to prioritize, what to cut.
A dashboard that shows you what to do but forces you to go somewhere else to do it is a half-built product. Closing the insight-to-action gap is the whole game.
The transferable principle: the problem is never "we don't have the data." It's always "we don't have a shared view of the data, organized around how decisions get made." That's a design problem.
Adjacent applications: financial services (portfolio performance + client data + market feeds → one advisor view), healthcare (patient outcomes + resource allocation + operational data → one clinical director view), retail (sales + inventory + marketing performance → one category-manager view), enterprise SaaS (product usage + support tickets + revenue → one customer-success view). Different domains, same shape of problem.
I run strategy engagements for enterprise BI, decision-support tooling, and regulated platforms — pyramid alignment, design principles, and the system that ties them together.
damleaalvee@gmail.com →