Dakota

Business questions. Beyond a CSV.

Dakota’s reporting started with statements and CSV exports. Finance, operations and product teams needed a more direct way to explore customer and transaction data inside the platform.

The brief was to let people ask in their own words, without writing SQL or assembling complex filters. But a one-off question and a weekly check-in are different jobs. The experience also needed a place for useful reports to live.

Three ways in. One clear direction.

I explored three interaction models: a classic report builder, a chat and UI blend, and a fully conversational experience. Each could accept the same question; they asked users to work in very different ways.

We chose the classic builder. It moved users toward a useful report with lightweight clarification and fit the dashboard they already knew. A chat-heavy approach added planning and conversation management before the answer.

We gave up a richer conversation history to keep the path from question to report short and familiar.

Flexible questions. A consistent visual grammar.

I designed the output as a system of metrics, summaries, charts and tables. The question could vary; the report was composed from predefined blocks and layouts.

Across five report families, I explored 16 layout variations. This gave product and engineering a shared model for shaping answers, from a single number to a comparative analysis. Engineering confirmed the component-based approach was buildable.

I extended Dakota’s existing design system into reporting: chart treatments, data blocks and hover behavior stayed consistent with the rest of the dashboard.

Design the path around the answer.

A report is only one state in the experience. I mapped how people start, wait, refine, recover and save, so the interface could keep its bearings as the question changed.

Change the question. Regenerate the report.

We chose full-report regeneration: the persistent prompt and contextual suggestions stay close to the result. Asking again replaces the current report, so saving preserves a view worth keeping.

Editing individual blocks would add controls and engineering complexity. Keeping refinement at the question level made the first release more focused, at the cost of granular adjustments.

An unanswered question still needs a next step.

I included distinct states for unsupported assets, unavailable data and timeouts. The prompt remains editable, and example questions stay within reach. Specific feedback helps people adjust the request and try again.

A shipped feature. A system to build on.

The AI reporting feature shipped at Dakota. My contribution brought the interaction direction, report architecture, component designs and key flows together in collaboration with product and engineering.

The central design lesson was about the structure around natural language. A flexible input works best when the result has a consistent shape, the question stays visible, and the next action is clear.