# Minutes of Meeting — Enterprise Brain Design System Direction
**Date:** March 5, 2026  
**Source transcript:** [Mar 5, 2026.txt](Mar 5, 2026.txt)

**Attendees:** Yeshwanth Reddy Yerraguntla, Manisha Gundapuneedi, Vara Kumar Jagarapu

## Act I — 00:00 to 00:04, a fixed page will not work

The meeting began with a basic contradiction: Enterprise Brain is meant to feel personalized, but traditional UX starts from a known persona and a known journey. Manisha argued that a static dashboard cannot solve a system that does not yet know who is arriving.

> *"We won't be able to do all the possible dashboard."*
> — Manisha Gundapuneedi _(~00:01:35)_

> *"We don't know what is the user, what he needs and all that."*
> — Manisha Gundapuneedi _(~00:03:34)_

The team quickly moved away from pages and toward landing states, archetypes, and generated output. The first screen has to feel right before the system knows much about the person using it.

## Act II — 00:04 to 00:09, design language before page layout

Manisha’s strongest point was that the team should define the language of the product before defining the pages themselves. Tokens, widgets, warnings, insights, and navigation patterns come first; pages are the byproduct.

> *"We will be giving a design system or a design language."*
> — Manisha Gundapuneedi _(~00:04:37)_

> *"It can be widget, it can be an error state, it can be an insight, it can be a warning."*
> — Manisha Gundapuneedi _(~00:04:37)_

The design team also folded loading and latency into the design problem itself. If the backend is still thinking, the user still needs a clear, intentional experience.

## Act III — 00:09 to 00:18, drill-down and dynamic navigation

The conversation then moved to depth. Manisha was explicit that the user may go multiple levels deep, and the UI should not pretend the journey is fixed.

> *"The depth the user can go is three levels or four levels."*
> — Manisha Gundapuneedi _(~00:32:03)_

> *"How we are going to establish that pattern?"*
> — Manisha Gundapuneedi _(~00:33:53)_

That opened the question of how the user gets back from a drill-down state. Breadcrumbs might work in some places, but the team is really designing a pattern for a dynamic return path, not a single widget.

## Act IV — 00:18 to 00:26, archetypes and generated output

The later middle of the conversation focused on how the same data can look different for different people. A visual user might want charts; a logical user might want tables; the same query should be able to render differently depending on the archetype.

> *"The same query but output is different."*
> — Manisha Gundapuneedi _(~00:03:34)_

That is why the team kept talking about a design language rather than a fixed dashboard. The page needs to be built from controlled components so the backend can choose an output class without the UI becoming random.

## Act V — 00:26 to 00:37, styling and boundaries

The end of the meeting turned practical. The team wanted styling rules, component behavior, and graph constraints that make the dynamic page feel deliberate rather than improvised.

The goal is not to freeze a final visual identity. The goal is to make sure the product can generate a useful, navigable experience even when the exact content is changing underneath it.

## Todos

<todo>
  Define the atomic design system tokens, components, and visual variables for the hyperpersonalized dashboard.<br/>
  <span class="owner">Manisha / design team</span>
  <span class="deadline">Next week</span>
</todo>

<todo>
  Document the drill-down and return navigation pattern for multi-level user journeys.<br/>
  <span class="owner">Vara / UI team</span>
  <span class="deadline">Before the next design review</span>
</todo>

<todo>
  Map the first 10 to 15 scenarios that the design system must support, including briefings, bottlenecks, and mixed chart/table outputs.<br/>
  <span class="owner">Manisha / Yeshwanth</span>
  <span class="deadline">Current sprint</span>
</todo>

<todo>
  Prototype smooth chart-to-chart and chart-to-table transitions using the current graph library.<br/>
  <span class="owner">Frontend team</span>
  <span class="deadline">Before the next demo</span>
</todo>