Dazzle © Branding - A Symphony of Innivation
How I helped turn a fragmented scramble to "add AI" across MongoDB into a single, research-backed experience.
Role
Company
Category
Timeline
Our Mission
We believe in the power of design to inspire and make a meaningful impact.
We aim to transform ideas into captivating designs.
We strive to bring creativity and functionality together, crafting solutions that resonate with your audience.
Problem
Business Context
AI-powered chat was rapidly becoming an expectation across developer tools. Internally, this created urgency and risk: several MongoDB teams had already begun building their own embedded assistants in isolation, each with its own visual language, copy, and interaction patterns. Left unchecked, this would have meant:
Duplicated engineering and design investment across teams
Inconsistent user experience as customers moved between MongoDB surfaces
No shared source of truth for how "the assistant" should look, sound, or behave
Growing confusion with our existing support tool, Intercom, which visually and functionally overlapped with the new AI assistant on the same screens
Constraints
Read-only, advisory-only guardrail. The skill was explicitly scoped to never apply schema or index changes on its own — a hard security requirement, not a UX preference, meaning every design decision had to work within an advice-only interaction model.
Atlas-only initial scope. Workload-aware recommendations (using
$queryStatsand slow query logs) were limited to Atlas M10+ clusters; non-Atlas and on-prem customers would only get generic best-practice guidance, not workload-tailored advice.Skills can't share resources or reference each other. An early idea to split "schema design" and "schema optimization" into two skills was explicitly rejected — skills need to be fully independent, so splitting would have meant duplicating content and risking agents choosing the wrong skill entirely.
Process
sample bullet point
Sample 2
