AI-Powered Analytics
Enterprise UX • Activeviam
OVERVIEW
When our company integrated AI into our analytics platform, there were no internal design patterns to draw from and no prior AI product experience on the team. I was the sole designer, working in real time alongside a product manager and AI lead engineer, for a product used by financial institutions.
How might we make AI behavior transparent and trustworthy enough for non-technical users in a high-stakes financial context?
MY ROLE
Sole UX/UI designer
COLLABORATION
PM and AI Lead Engineer
TIMELINE
6 months
THE FEATURES
Three features introduced in parallel, each solving a distinct part of the AI integration challenge:
• AI chat interface: natural language interaction with the analytics platform
• Thought-chain UI: transparency layer showing the AI's reasoning process
• Auto-explain: right-click triggered root cause analysis of data values
1. BUILDING THE FOUNDATION: THE AI CHAT INTERFACE
The first version was intentionally minimal, a chat input, a loading state, an error state. We wanted to learn how users interacted with AI before adding complexity.
The problem testing revealed was simple: when the AI responded, users saw a one-line label and nothing else. No process, no reasoning, no signal of trust. That gap became the brief for the thought-chain.
2. ADDING TRANSPARENCY: THE THOUGHT-CHAIN
Core design challenge: calibrating how much process to show a user who isn't technical.
I defined two distinct audiences within the same interface:
Did it succeed?
Is it working?
Is it done?
END USERS
What was called?
What argument?
How long?
DEVELOPERS
I mapped how existing products handled AI transparency (ChatGPT, Perplexity, Cursor, LangSmith, Zapier) and identified three UI pattern categories for thought chains: Linear Trace, Nested Collapsible, and Timing Breakdown.
UI PATTERNS FOR THOUGHT-CHAIN VISIBILITY
LINEAR TRACE
NESTED COLLAPSIBLE
TIMING BREAKDOWN
DECISION
Linear trace as the base pattern, with collapsible action nodes that carry data payloads. Thinking steps and the answer node stay flat. Their value is in the label, not hidden content.
KEY DECISIONS
• Collapsible only on action nodes with payload — not all steps
• Auto-collapse completed nodes during live streaming — chain tidies itself as it runs
• Final answer node visually terminates the chain — distinct treatment, no ambiguity about completion
• Copy written for non-technical users — present continuous verbs, no jargon
3. DESIGNING FOR ACTION: AUTO-EXPLAIN
Three decision points, each showing the rejected option vs. the chosen direction and the reasoning behind it.
DECISION 01 — WHERE DOES CONFIGURATION LIVE?
✗ REJECTED
• Widget cog icon — couples AI preferences to a single widget; config should be session-wide
• Top nav (Insert / AI menu) — too far from the trigger point; creates navigation distance after a canvas action
• Global dashboard settings modal — buries a contextual feature in general settings
✓ CHOSEN
Icon in AI chat panel header — config is scoped to AI behavior, lives inside the AI tab as a sub-screen, never takes the user out of Panel 2.
DECISION 02 — THE CONFIGURATION GATE: FIRST-TIME USERS
✗ REJECTED
Hard block requiring setup first — blocks first-time users from experiencing the feature at all. Poor adoption curve.
✓ CHOSEN
Inline warning with escape hatch — "Run with all hierarchies? May be slower." Two actions: Run anyway or Configure. Users experience the feature immediately.
DECISION 03 — PRESERVING INTENT WHEN THE USER CLICKS CONFIGURE
✗ REJECTED
• Warning on a blank new page — opening a page implies commitment; user lands confused and must navigate back
• Keep context menu open during config — fights OS and browser conventions; technically fragile and visually awkward
✓ CHOSEN
Persistent banner pill + cell memory — context menu dismisses naturally. Selected cells stay highlighted. Banner reads "Auto explain 2 selected — Configure in AI panel →" until preferences are saved.
AUTO-EXPLAIN PROTOTYPE
OUTCOME
All three features are in active development. The thought-chain design has been implemented and is being iterated on with the engineering team. Auto-explain design decisions have been documented and are currently in the engineering hand-off phase. Formal user feedback is forthcoming as the features move toward client release.
REFLECTION
• Designing for AI without prior experience meant leaning heavily on research and pattern analysis — studying how other products handled transparency, progressive disclosure, and trust before making any design decisions.
• Working without direct user access meant decisions were validated internally rather than with end users. The patterns I chose are defensible, but the real test comes with client-facing release.
• The Auto-explain open questions — per-dashboard vs. per-user preferences, empty states — are documented and unresolved. They're the first things I'd address in the next design cycle.