Business Context

Astra Agro sells Fendt, Valtra, Manitou, and Horsch equipment across multiple regional offices, with a lead-capture form on every product page. Every lead lands in a shared inbox with no regional ownership and no visibility for leadership. Solving that meant building a platform where four distinct roles — Regional Manager, Finance Coordinator, Service Dispatcher, National Admin — could each move quickly without waiting on each other. That need for real speed is what led me toward an agentic workflow.

Speed and Quality

Platforms like this usually take months — designing screens, building and maintaining a consistent design system, keeping four different workflows from drifting apart as each gets built separately. Astra Agro didn't have that runway. The real constraint wasn't the interface itself, it was speed: could a rigorous, on-system, accessible product actually get built fast, without quality being the thing that quietly gets cut to hit the deadline?

Two Agents, Not One Designer

Rather than one general-purpose agent, I built two specialized ones. A design-system agent works directly in Figma — extending tokens, building components, checking accessibility. A second agent builds pages from an approved spec, checking each new screen against what's already built so it stays consistent. Together, they let one designer move at team pace, without design discipline being the first casualty of the deadline.

Dealer Operations Console is an internal platform for Astra Agro, a multi-region agricultural equipment dealer, giving regional managers, finance coordinators, service dispatchers, and leadership a fast, purpose-built way to work with leads generated by the public site. Building four genuinely different role-based experiences at the speed the business needed meant rethinking how the work itself got done — I designed and led the platform using a two-agent AI workflow, covering everything from the design system to the pages built on top of it.

I worked directly with the client to understand the requirements — particularly how role-based access needed to work across the four operational roles, since that shaped nearly every downstream decision. I owned the design system and the HTML prototypes, building both through a two-agent workflow: one agent maintaining the Figma design system and documenting it into a spec the second agent could actually build from, the second building the pages themselves. As pages moved toward implementation, I worked with the front-end developer directly, resolving discrepancies between what the agents had generated and what he actually needed to build it for real.

My Role

Mapping Role Permissions

I worked directly with the client to understand the requirements — particularly how role-based access needed to work across the four operational roles, since that shaped nearly every downstream decision. I owned the design system and the HTML prototypes, building both through a two-agent workflow: one agent maintaining the Figma design system and documenting it into a spec the second agent could actually build from, the second building the pages themselves. As pages moved toward implementation, I worked with the front-end developer directly, resolving discrepancies between what the agents had generated and what he actually needed to build it for real.

Regional Manager

Finance Coordinator

Lead Response. Review new leads in their region, understand what the person is asking about, and respond with the right brochure or technique link for their stated interest.

Financing Handoff — Flag a lead as loan- or rental-interested and route it to the Finance Coordinator with the context already attached, rather than the lead starting over.

Bank Matching — Review a flagged lead's situation and identify which partner bank's financing program actually fits their case.

Partner Documentation Lookup — Check a bank's current loan or credit terms mid-conversation with a lead, without leaving the platform to dig through separate files.

Service Dispatcher

Service Request Assignment — Review new maintenance/repair requests from existing customers and assign the right technician by region.

Equipment History Check — Pull a client's service history before dispatching, so the technician isn't walking in blind to a recurring issue.

Preparing AI-ready requirements for AI usage

...

Requirements weren't always fixed yet.

Personas

Francesca

"I need to be able to create, edit, and approve workflows made by others, because I am responsible in my firm for this."

"I need to see if there tends to be failures, missed deadlines, etc in specific workflows so that I can change how the workflow is being handled by my team."

Edward

"I need to see what factors drive performance, since these help me decide what made us successful."

"I need to be able to determine if the data we have is fit for purpose, so that the people working on Analysis have the best tools available."

Research shaped six personas in total, spanning the full range of people who'd use Studio. Here are two that show the clearest contrast: Francesca, Head of Performance, who works inside the platform daily and manages a team through it; and Edward, the CIO, who barely logs in but still needs complete visibility into what's happening. Together, they capture the core tension the design had to solve — depth and control for the people doing the work, versus zero-effort clarity for the people overseeing it.

Discovery is the platform's search and exploration space — where users find the material they need to inform a decision or build into their own work. It pulls together several very different content types in one place: datasets, visualizations, news, research, scenarios, presentations, and recorded calls and transcripts. Some of this content comes from inside BNY Mellon itself — internal calls and research, for example — while other content, like certain datasets, comes from outside vendors and data suppliers. Users can search across all of it, or filter by things like category, canonical group, and certification status, to narrow down to material they can trust and actually use.

Visualizations alone cover several different formats — charts and graphs, advanced tables, HTML components, dashboards, and full applications — because different tasks called for different ways of looking at the same underlying data. A quick trend check needs a chart; a detailed audit needs an advanced table; a recurring report needs a dashboard someone can return to.

"Discovery"

While most people touched Discovery at some point, it was used most heavily by the power users — analysts and specialists making high-stakes financial decisions day to day, who needed to move quickly across large amounts of material without losing precision.

My Workspace is where users manage the data that actually belongs to them — datasets bought or shared with them by the organization, plus the visualizations, scenarios, portfolios, watchlists, and bookmarks they've built or saved. Everything here is something they can act on directly.

For datasets, users can view the full data, filter it, and use an "Analyze" option to turn a plain table into a chart, graph, or other visualization — either from a template or from whatever they've currently got selected. They can also add new data themselves, either by building a new data model from scratch or importing one from the company's shared data catalog.

"My Workspace"

On its own, a single model shows a specific, fixed result. But financial decisions rarely come down to one number in isolation — analysts need to compare models against each other to understand what's actually driving a result, and to make better predictions. My Workspace's visualization builder is where that happens: creating a new visualization takes users into a dedicated working environment where they can pull in different pieces — dates, assets, or entire models — and combine them into one view. A common pattern was layering a benchmark model (shown as a reference line) against other data pulled from different models, so users could directly compare characteristics side by side rather than looking at each model in isolation.

Connecting models

Early versions of the roadmap treated "connecting models" as a nice-to-have feature. Research with power users showed otherwise — a single model's output in isolation wasn't especially useful to them; what they actually needed was to compare models against each other to understand what was really driving a result. That insight elevated model-connecting from a minor feature to one of the platform's core initiatives, and shaped the visualization builder described above.

Monitor was built for the personas who wanted the opposite of Discovery and My Workspace — no setup, no digging, just a clear picture of what's happening. Edward, Francesca, and Betty all described versions of the same need: everything should be visible at a glance, without them having to go looking for it.

The core of Monitor is a timeline view of selected models, dashboards, and saved views, showing whether everything is running normally or something has failed or hit a technical interruption. Users can filter that timeline by warning severity — critical, major, or success — as well as by data vendor and by when an issue occurred, so someone checking in briefly can quickly narrow down to what actually needs their attention.

"Monitor"

Notifications inside Monitor cover two different kinds of signals: errors and warnings — flagged with a yellow "something to be aware of, though not necessarily broken" indicator — and updates, which cover collaboration activity, like someone requesting an edit to a model, application, or visualization. This meant Monitor wasn't just a health check on the data itself, but also a way for oversight users to stay aware of what their team was doing, without having to be inside the platform daily.

This covers the version of Monitor built around data performance during my time on the project. A later iteration added dedicated Events and Activities sections, which I wasn't involved in designing — worth a brief mention for completeness, but outside the scope of what I can speak to in detail.

Challenges

Bridging the gap between expert knowledge and plain requirements

The people using Studio were deeply skilled in finance, but often struggled to describe what they actually needed in plain terms — they knew their work intimately, not how to translate it into a design problem. This meant I couldn't just take requirements at face value. I had to dive into the subject matter myself — understanding what people were actually doing and why — before I could design something that felt genuinely useful rather than technically correct but disconnected from their real workflow.

Designing within existing technical constraints

Some of the platform's core capabilities — creating new models, building new visualizations — were already built on specific existing technology before I joined the project. That meant constantly balancing what I believed would create the best experience against what the current development approach could realistically support, and finding workable middle ground rather than designing in a vacuum.

Staying consistent across a distributed team

Studio was built by a larger design team, with different people owning different areas of the platform. Keeping Discovery, My Workspace, and Monitor consistent with each other — and with the rest of the platform — meant constantly checking my decisions against a system I didn't fully control alone.

Design System

I started building Studio's design system back in 2021, when Figma's own capabilities — especially around variables and shared libraries — were far more limited than they are today. Even without today's tooling, we set up a proper foundation: components and styles lived in a shared Figma library, documented in ZeroHeight, and mirrored in Storybook so design and development stayed in sync.

This wasn't a solo effort. Other designers on the team were building against the same system, so we held regular design system sessions to review new components, catch inconsistencies, and keep the library up to date as the platform grew. I also worked directly with developers on implementation — making sure what shipped in code actually matched what was documented in the library, and adjusting the system when a component needed to work differently in practice than it did on paper.

Governance in Design Systems

Consistency standards

How data visualizations, status indicators, and terminology stayed uniform across the platform, since inconsistency could lead to misreadings in a context where accuracy mattered

Reuse discipline

Working within existing patterns rather than introducing one-off solutions, so new features didn't create ambiguity for users who'd built trust in how the system behaved

Change process

Design changes moved through review with stakeholders accountable for accuracy before shipping, which meant validating decisions were defensible, not just usable

Working inside a financial institution meant design decisions carried weight beyond the interface. Governance here wasn't about maintaining a component library for its own sake - it was about keeping visualizations and workflows consistent and defensible for expert users making judgment calls that fed into financial reporting.

Accessibility and clarity minimums

Non-negotiable baseline given the audience and the stakes of misinterpretation