Kaiya Data

The problem

From the docs

How might we help new users onboard their data into the product, and streamline the pro user’s workflow?

• The Business View is the product. Missions, apps, insights and dashboards all read from one. Every user goal ends in creating one, directly or indirectly.
• Building one meant two tools. A five stage pipeline, Connect, Dataset, Prepare, Business View, Refresh, and beside it a separate chat builder, Kaiya Architect.
• So the customer never builds it. Tellius’s own team sets up the data and the Business Views for every customer, which caps how fast the product can grow.

What the research found

Who. Two in-house builders who set up Business Views for customers, in July sessions on how they work today. The June concepts came first, built from the shipping module and the leadership brief; the sessions were booked when the builders were free and changed the direction that followed. No customer admin has been reached yet. Plus weekly syncs with the head of product and the VP of product.

What we needed to learn. How a Business View really gets built, where the AI helps or fails, and what self-serve would take.

Finding 1 · Customers never build their own Business View. Tellius’s solutions and customer success team sets up the data and the views for every account. In the VP of product’s words, the company is rate-limited by that team. So the design has to work for someone who has never seen the pipeline.

Finding 2 · The experts route around the AI. Both builders said Kaiya Architect is not helpful for building real views. On messy pharma and CPG data they cannot fix what it drafts inside Architect, so they finish the job in the old module. So the draft must be correctable in place, or experts will keep leaving.

Finding 3 · Two assistants for one object confuses everyone. A pipeline, plus a second chat called Kaiya Architect, next to Kaiya Missions and Kaiya everything else. The head of product’s conclusion was to retire Architect: it should just be Kaiya. So one assistant, one surface.

Findings 1 to 3 come from the builder sessions. Findings 4 to 6 come from the product syncs with leadership: working hypotheses the customer test below has to confirm, not user evidence yet.

Finding 4 · Intent decides the interface. When someone knows exactly what to change, they want direct controls. When they are asking for help, they want a conversation. So the chat leads, and direct edits sit one tab away.

Finding 5 · Bulk edits are slow in chat. Each model call takes about a minute, so retyping ten columns one at a time costs ten minutes. So precise, repeated edits need a direct path.

Finding 6 · Building is rare, asking is daily. A Business View is set up a handful of times in a customer’s life, then queried every day. So creation should not be a destination of its own. It belongs inside the chat people already use.

One caution shaped how these were weighed: builder feedback tends to track whichever customer is loudest that week, so each finding was checked against the product goal of eighty percent out of the box.

Finding or hypothesis	Design decision in V9
Customers never build	Onboarding is a conversation that starts from the goal, not the pipeline.
Experts route around the AI	Every draft line is correctable where it appears.
Two assistants confuse	Kaiya Architect retired. One Kaiya builds the view.
Intent decides the interface (hypothesis)	Chat leads, Editable details beside every step.
Bulk edits are slow (hypothesis)	Direct edits in the details panel, no model call per field.
Building is rare (hypothesis)	Creation lives inside the everyday chat, ending in Approve and Run.

Before and after

Before · pipeline, with Kaiya Architect bolted on

After · V9, the chat builds the Business View

1. Kaiya Architect stops being a button in the corner. The chat is the builder.
2. Five pipeline tabs and a node canvas become one conversation with a details panel.
3. Joins are sentences: each rep covers many dealers, revenue counted once, the join holds at 41,310 rows.
4. Validation is a step, not a tab. Kaiya shows the numbers and asks the user to confirm what they know.

Watch it run

The accepted V9 prototype, recorded end to end. Working HTML, not a mock.

Nine prototypes, and what each one left behind

Each prototype tested one bet about how a Business View should be created. The record below shows the moment that made each one different, what survived, and the reason it went no further. Click any frame for full size.

1. 

   01June · week 1

   Altitude

   The bet

   One view at three altitudes. Talk reads it in plain language, Shape shows the model, Build exposes the pipeline.

   Carried forward

   Joins written as sentences, with Looks right and Change on every line.

   Why it went no further

   Three modes for one object is three things to learn, and Architect still sat in a panel beside the view. The June review kept its clarity as the default and folded Glass Box's transparency underneath.

2. 

   02June · week 1

   Glass Box

   The bet

   The Architect proposes, the user decides. Every decision is visible with its real consequence, like 1,180 reps kept or 5 dropped.

   Carried forward

   See why on every decision, and consequences stated as real counts.

   Why it went no further

   Showing every decision made everyday work feel like an audit. Right for high-stakes data, too heavy for a first five minutes. The review's call: one model with both instincts.

3. 

   03June · week 2

   Aperture

   The bet

   One object at two depths, Speak or Build, with sample data first and a journey across day 0, day 1 and day 100.

   Carried forward

   One object, an always-on changes log, and a validation bar that is never silent.

   Why it went no further

   Speak and Build were still two surfaces that had to stay in parity, and Architect was still a named second assistant. The July research would argue against both.

4. 

   04July

   Unified build, reviewed with leadership

   The bet

   Borrowed from how Claude, Replit, Lovable and Harvey handle a long build: chat beside a canvas, one stage at a time behind a progress ring, two lenses on the same model.

   Carried forward

   A side panel instead of pop-ups, propose then approve, and one vocabulary shared by chat and canvas.

   Why it went no further

   A persona switch split one product into modes, and the ring plus two lenses was a lot of chrome. The rule that replaced it: one mature user, depth adaptive, never a mode.

5. 

   05August · style test 1 of 3

   Style 1, write drawer

   The bet

   Keep the page read-only and put every edit in a drawer, so reading stays calm.

   Carried forward

   The page as a read-only record of what Kaiya built.

   Why it went no further

   The drawer covers the very thing being edited, so users edit blind and look in two places. Each style build ended with a test that fails it if the style is broken, so the comparison stayed fair.

6. 

   06August · style test 2 of 3

   Style 2, editable artifact

   The bet

   Let the user edit the artifact directly, in place, in the chat, or in a modal.

   Carried forward

   Direct editing for precise changes, later reused as Editable details.

   Why it went no further

   It quietly became a second builder, the problem being solved. And every editable surface is another copy of state to keep in sync, the failure the builds kept hitting.

7. 

   07August · style test 3 of 3

   Style 3, everything in the chat

   The bet

   Every input happens in the conversation. The view appears inline as read-only blocks.

   Carried forward

   The chat as the one place to act, and the transcript as the record of every decision. Chosen in a leadership review against the other two, by product leadership and the build lead, not by users.

   Why it went no further

   Not dropped, merged. On its own a long transcript loses orientation, and large artifacts were cramped inline, so it needed a home for the view beside the chat.

8. 

   08Late August

   Duet builds, V7 and V8b

   The bet

   The chat leads and the view answers. V7 asked the goal before reading any table. V8b opened on a views library with a review queue.

   Carried forward

   Goal questions before tables, honest source handling, and Kaiya saying it will not pick a source for you.

   Why it went no further

   V8b made governance the front door. Building is rare and asking is daily, so a library and review queue belonged behind the chat, not in front of it.

9. 

   09September

   V9, accepted

   The bet

   One chat builds the Business View: ask the goal, scope the tables, check the numbers, build. A details panel opens only when there is something to look at.

   Carried forward

   Everything above: sentences from Altitude, See why from Glass Box, one object from Aperture, the side panel from July, the chat from Style 3, the goal questions from the Duet builds.

   Verdict

   Accepted. This is the direction taken ahead.

The calls that could have gone another way

With the team

• Lead designer, working directly with Abhishek, head of product, and Vinod, VP of product.
• Part time and remote across a USA and India time gap: recorded research, weekly syncs, decisions in writing.
• Every build step carried a written acceptance check. Always measurable, such as fits at 1440 by 900, never a word like tighter.

Where product and build pushed back, and what changed.

• One edit at a time, or a batch? The head of product pushed for batching edits, because every model call takes about a minute and ten column changes would mean ten minutes of waiting. My position was one at a time, because a batch of changes to a large view is hard to check. The design does both: precise, repeated edits go straight into Editable details with no model call, and the chat accepts one request that covers many columns.
• One copy of state. The early builds kept a separate copy of the changes on each surface, so one count read 2 while another read 4. The rule that came out of it: every surface reads from one list of changes, and the details panel is a view of the chat, never a second source.

Where it stands

V9 is the accepted design, handed off as a working prototype and the stepwise build prompts that produce it. The open question is the one the research could not answer: whether a customer admin, not a Tellius builder, can build a view alone. Kaiya is the one assistant everywhere, and creating a Business View is a conversation.

The test V9 still needs.

The validation that gates the build is designed and ready to run:

• Who. Five customer admins from CPG and pharma accounts who have never used the pipeline.
• Task. Connect a warehouse and build a Business View that answers one of their own questions, with no Tellius builder in the room.
• Pass. At least four of five reach Approve and Run alone, inside 30 minutes, and a builder does not have to rebuild the view afterwards.
• What would prove V9 wrong. Fewer than three of five finishing alone, or builders rebuilding most of the views. Then the chat-first bet fails and the hypotheses above go back on the table.