RingCentral · AI Conversation Expert (ACE) · Current

Taking self-serve analytics in ACE from first prototype to production

Frontend design and architecture lead for a new self-serve analytics experience in AI Conversation Expert (ACE), prototype to production in under four months.

Problem: The work was a new frontend surface for ACE that had to fit the existing product, respect each user’s permissions, and ship on a fixed release train alongside backend and data work.
My role: Frontend design and architecture lead.
Key decision: When late requests arrived, I separated true release blockers from improvements, and moved the rest into the next phase to protect the release.
Result: Shipped to production, and I continue to lead the frontend for its next phase.

My role

I built the first prototype, broke the work into deliverable pieces, and owned the frontend end to end, working with product, design, backend, data and QA partners.

I moved to ACE from a different product area, so I learned its domain, users and data while leading the frontend design and architecture in a small cross-functional team.

I worked with backend and analytics engineers on the overall design, including how historical data would reach the dashboards.

What I did

Prototype to plan
Built the first working prototype, then turned it into a planned frontend delivery with a clear order of work across frontend, backend and data dependencies.
Reviewable changes
Kept a large change reviewable: split it into small, focused merge requests that landed together through one release branch.
Permission-aware states
Built permission-aware states throughout, so people see only the actions their role allows and get a clear message when they lack access.
Accessibility
Built accessibility in from the start: keyboard support, accessible names and predictable focus across interactive components.
Product analytics
Added product analytics so the team could see how the experience is used after launch.
Validation and UAT
Validated each build in test environments before release, and led frontend fixes through user-acceptance testing.

Decisions

Scope pressure near release
When late requests arrived, I separated true release blockers from improvements, and moved the rest into the next phase to protect the release.
Work split across teams
Context
Some issues found in testing belonged to backend services.
Choice
I explained where each fix belonged and added a safe frontend safeguard while the backend fix was in progress.
Shipping fast without losing quality
Small reviewable changes, an agreed order of work and environment checks kept a large frontend change safe to merge.
Requirements that kept moving
Context
Scope and product decisions changed during delivery.
Choice
I recorded each decision, checked contracts against the backend specification, and reset the order of work when priorities moved, so the release held.
Coordinating across teams and time zones
Context
The work depended on backend engineers, design, product and a separate analytics team in another time zone, on a data stack that was new to the team.
Choice
I sequenced the frontend around those dependencies and agreed contracts early, so integration did not wait for the last step.

Results

Shipped to production, and I continue to lead the frontend for its next phase.

What this shows

React
TypeScript
Data visualization
Permission-aware UI
Accessibility
Product analytics
Release planning
Cross-team delivery

Next case study

Setting up Marketo and Salesforce inside RingCentral Events

Tech lead for the Marketo integration setup, and main implementer of the refreshed Salesforce setup and engagement sync, in RingCentral Events.

Prototype to plan

Built the first working prototype, then turned it into a planned frontend delivery with a clear order of work across frontend, backend and data dependencies.

Reviewable changes

Kept a large change reviewable: split it into small, focused merge requests that landed together through one release branch.

Permission-aware states

Built permission-aware states throughout, so people see only the actions their role allows and get a clear message when they lack access.

Accessibility

Built accessibility in from the start: keyboard support, accessible names and predictable focus across interactive components.

Product analytics

Added product analytics so the team could see how the experience is used after launch.

Validation and UAT

Validated each build in test environments before release, and led frontend fixes through user-acceptance testing.

Decisions

Scope pressure near release

When late requests arrived, I separated true release blockers from improvements, and moved the rest into the next phase to protect the release.

Work split across teams

Context: Some issues found in testing belonged to backend services.
Choice: I explained where each fix belonged and added a safe frontend safeguard while the backend fix was in progress.

Shipping fast without losing quality

Small reviewable changes, an agreed order of work and environment checks kept a large frontend change safe to merge.

Requirements that kept moving

Context: Scope and product decisions changed during delivery.
Choice: I recorded each decision, checked contracts against the backend specification, and reset the order of work when priorities moved, so the release held.

Coordinating across teams and time zones

Context: The work depended on backend engineers, design, product and a separate analytics team in another time zone, on a data stack that was new to the team.
Choice: I sequenced the frontend around those dependencies and agreed contracts early, so integration did not wait for the last step.