From 69b80f50945d76a5ac4ddd9685975468c9bf2dc9 Mon Sep 17 00:00:00 2001 From: Heath Rutledge-Jukes <72709588+hjukes99@users.noreply.github.com> Date: Mon, 11 May 2026 13:03:47 -0500 Subject: [PATCH] Add living interfaces article draft --- ... Static Dashboards to Living Interfaces.md | 210 ++++++++++++++++++ 1 file changed, 210 insertions(+) create mode 100644 Articles/From Static Dashboards to Living Interfaces.md diff --git a/Articles/From Static Dashboards to Living Interfaces.md b/Articles/From Static Dashboards to Living Interfaces.md new file mode 100644 index 0000000..93ae23c --- /dev/null +++ b/Articles/From Static Dashboards to Living Interfaces.md @@ -0,0 +1,210 @@ +# From Static Dashboards to Living Interfaces: How AI Is Redefining the Way We Display Data + +Dashboards became the default interface for business data because they solved a real problem. Teams had too much information scattered across databases, spreadsheets, tickets, events, and internal tools. A dashboard gave that information a stable home. The same charts loaded every Monday. The same filters sat in the sidebar. The same metrics told the team whether revenue, churn, uptime, support volume, or acquisition spend was moving in the right direction. + +That model still works when the question is known in advance. + +It breaks down when the question changes faster than the interface. + +AI is exposing that break. Once users can ask natural-language questions over operational data, the fixed dashboard starts to feel like a frozen answer to a previous question. A product lead asks why trial conversion dropped in the Midwest. A finance lead asks which accounts explain the variance in forecast. A support lead asks which open tickets are likely to violate SLA by Friday. Each of those questions needs different data, different grouping, different emphasis, and different next actions. + +Plain text is not enough for that. Static dashboards are not flexible enough either. The next interface pattern is a living interface: a UI generated from the user's intent, the available data, and the actions the system can safely perform. + +## Why Static Dashboards Worked + +Traditional dashboards are strongest when three things are stable: + +- The questions are known. +- The schema is predictable. +- The audience agrees on what matters. + +That is why dashboards fit executive reporting, infrastructure monitoring, sales pipeline reviews, and product analytics so well. The dashboard designer can decide ahead of time that revenue belongs in a line chart, funnel conversion belongs in a step chart, incidents belong in a table, and account health belongs in a scorecard. + +The result is efficient. Users learn the layout once and return to it repeatedly. Teams align around shared definitions. A dashboard also has governance benefits: the metric is calculated in one place, reviewed once, and reused across the organization. + +But those strengths are also constraints. A dashboard encodes past assumptions into UI. It assumes the designer knew what people would need to ask later. It assumes the best shape for the answer is known before the answer exists. + +That is not how a lot of modern work happens. + +## The New Shape of Data Questions + +The questions people bring to AI systems are usually not dashboard-shaped. + +They are conditional: + +> Show me enterprise accounts where usage is rising but renewal risk is also rising. + +They are comparative: + +> Compare the top three drivers of churn this quarter against last quarter, but ignore accounts below $10k ARR. + +They are investigative: + +> Find the support pattern behind last week's spike and tell me which customers are still affected. + +They are action-oriented: + +> Build a follow-up list for customer success and draft the first outreach note for each account. + +A static dashboard can answer pieces of those questions, but the user has to do the composition manually. They click filters, export CSVs, open another tool, skim a table, copy notes into a doc, then decide what to do. + +The AI application can do more than return a paragraph. It can produce structured state: entities, metrics, anomalies, confidence, recommended actions, approval requirements, and links back to source data. That state wants an interface. + +If the answer contains accounts, it may need a sortable table. If it contains competing hypotheses, it may need a comparison layout. If it contains actions, it needs buttons, forms, and confirmation states. If it contains uncertainty, it needs evidence and warnings close to the claim. + +The UI should follow the shape of the result. + +## What Makes an Interface "Living" + +A living interface is not a randomly generated page. It is a constrained UI assembled at runtime from approved components. + +The application still owns the design system. It still decides which components are available, which actions are allowed, which data can be shown, and which operations require human approval. The AI does not get arbitrary code execution. It gets a controlled interface vocabulary. + +That distinction matters. The goal is not "let the model build anything." The goal is "let the model choose the right approved surface for this specific job." + +A useful mental model is: + +```ts +type LivingInterfaceInput = { + userIntent: string + dataContract: { + entities: string[] + metrics: string[] + dimensions: string[] + sourceLinks: string[] + } + allowedComponents: string[] + allowedActions: string[] + safetyRules: string[] +} +``` + +The application can validate every part of that before rendering. It can reject unsupported actions. It can require source links for claims. It can force destructive operations through confirmation. It can render the result with the same components the rest of the product already uses. + +OpenUI fits this pattern because it starts with a component library. Developers define the components the model is allowed to use, OpenUI generates instructions from that library, the model responds in OpenUI Lang, and the renderer turns that structured output into UI as it streams. The important part is the boundary: the model is generating interface structure inside a system-defined contract. + +## One Dataset, Four Interfaces + +Imagine a revenue dataset with accounts, plan type, ARR, product usage, support volume, renewal date, health score, and recent notes. + +A static dashboard might show: + +- ARR by month +- churn by segment +- health score distribution +- accounts renewing this quarter + +Those are useful views. They are also generic. Now compare four questions asked over the same dataset. + +**Executive question:** "What changed in the forecast this week?" + +The best UI is probably a short variance summary, a waterfall chart, and a ranked list of accounts that moved the number. The action is review, not edit. The interface should privilege confidence, materiality, and source links. + +**Revenue operations question:** "Which deals are incorrectly staged?" + +Now the UI should look more like a work queue. Each row needs the account, current stage, evidence for why the stage may be wrong, suggested stage, and an approve or dismiss action. The user is not reading a report; they are cleaning data. + +**Customer success question:** "Who needs outreach before renewal?" + +The UI should group accounts by urgency, show risk reasons, include recent support context, and offer draft message actions. The answer is only useful if the user can act without rebuilding the context in another tool. + +**Product question:** "Which feature adoption pattern predicts expansion?" + +The UI needs a cohort comparison, a scatter plot or table, caveats about correlation, and a way to inspect the underlying accounts. The user needs exploration, not a single conclusion. + +All four questions use the same data. None should be forced into the same dashboard layout. + +That is the core shift. Dashboards organize data by predefined metric. Living interfaces organize data by user intent. + +## The Implementation Pattern + +The practical pattern is not mysterious. It has four layers. + +First, the app retrieves and normalizes data. This should be boring, typed, and testable. The model should not be inventing numbers or querying production systems without guardrails. + +Second, the app creates a data contract. This is the structured result the UI can render: records, metrics, evidence, warnings, and allowed actions. + +Third, the model selects an interface shape from the allowed component library. It might choose a KPI summary, a table, a chart, an approval queue, a timeline, a detail panel, or a combination of those. + +Fourth, the renderer displays the interface and sends user actions back as structured events. + +For example: + +```ts +const AccountRiskCard = defineComponent({ + name: "AccountRiskCard", + props: z.object({ + accountName: z.string(), + arr: z.number(), + renewalDate: z.string(), + riskReasons: z.array(z.string()), + recommendedAction: z.enum(["review", "draft_outreach", "assign_owner"]), + sourceUrl: z.string().url(), + }), + component: ({ props }) => , +}) +``` + +The model can now use `AccountRiskCard`, but only with the props the application allows. The design system stays intact. The action set stays explicit. The app can validate the generated UI before it reaches the screen. + +This is a better division of labor than asking the model to produce HTML or asking the user to read a wall of prose. + +## Where Static Dashboards Still Belong + +Living interfaces do not replace every dashboard. + +Stable operational metrics should still have stable homes. A team should not need to ask an AI model for the current error rate, burn rate, or pipeline coverage every time. Shared dashboards are useful precisely because they are consistent. + +The better migration path is to treat dashboards as starting points. A dashboard shows the canonical view. A living interface handles follow-up questions, exception handling, investigation, and action. + +For example, a support dashboard might show ticket volume by priority. When the user clicks a spike, the AI can generate a temporary investigation surface: top affected customers, common error messages, likely root cause, unresolved tickets, and suggested owner assignment. Once the investigation is done, the surface can disappear or be saved as a reusable view. + +The dashboard remains the map. The living interface becomes the vehicle. + +## The Real Tradeoffs + +Generated interfaces introduce new engineering responsibilities. + +**Validation:** The UI structure must be checked before rendering. Unsupported components, missing required props, unsafe action payloads, and malformed links should fail closed. + +**Trust:** Claims need evidence. If an interface ranks customers by churn risk, each row should expose the signals behind the score. Generated UI without provenance is just a prettier hallucination surface. + +**Design-system boundaries:** The model should not be choosing colors, spacing, or visual hierarchy from scratch. It should assemble approved components. Brand consistency comes from the component library, not from prompt instructions. + +**Accessibility:** Dynamic UI still needs labels, keyboard behavior, focus order, and semantic structure. If the component library handles this correctly, generated layouts inherit the right behavior. If not, the system can scale inaccessible UI very quickly. + +**Cost and latency:** A generated interface may take more work than a static chart. Streaming helps because users can see partial structure earlier, but teams still need budgets, caching, and fallbacks. + +**Auditability:** If the UI can trigger actions, the system needs logs that capture what data was shown, what action was offered, what the user approved, and what was executed. + +These constraints are not reasons to avoid generative UI. They are the shape of doing it seriously. + +## A Simple Adoption Plan + +Teams do not need to rebuild their analytics stack to try this. + +Start with one high-friction workflow that already happens after a dashboard review. Good candidates include churn review, incident triage, sales forecast changes, support escalation, security alert clustering, or billing exception cleanup. + +Then define three things: + +1. The data contract: what records, metrics, and evidence the workflow needs. +2. The component library: which approved UI pieces the model can use. +3. The action contract: what the user can approve, reject, edit, or export. + +Do not start with an open-ended prompt like "make a dashboard." Start with a bounded job like "render a renewal-risk review surface for these 12 accounts." The narrower the workflow, the easier it is to validate quality. + +Once that works, expand laterally. The same account risk card might show up in renewal reviews, expansion planning, and support escalations. The same approval table might handle CRM cleanup, invoice exceptions, and content moderation. Living interfaces become more valuable as the component vocabulary grows. + +## The Dashboard Is Becoming a Conversation Starter + +The old dashboard asked users to adapt their questions to the available interface. + +The new pattern lets the interface adapt to the question. + +That does not mean every screen becomes fluid and unpredictable. The best AI interfaces will probably feel more structured than chat, not less. They will have familiar components, strict validation, clear evidence, and explicit actions. The difference is that those components will be assembled when the user needs them, around the task in front of them. + +Static dashboards will keep their place for shared, recurring truth. But more and more of the valuable work happens after someone asks, "Why did that happen?" or "What should I do next?" + +That is where living interfaces matter. + +AI can already produce structured analysis. The next step is giving that analysis a surface people can inspect, trust, and act on.