Shutterstock Image Editor

How I helped turn a fragmented scramble to "add AI" across MongoDB into a single, research-backed experience.

Role

Design Lead

Design Lead

Company

Shutterstock

Shutterstock

Category

Web, Mobile App, B2C, B2B

Web, Mobile App, B2C, B2B

Timeline

2025

AI, Software

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 $queryStats and 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

When I took I examined direct user feedback calling out the complexity, usage and click data showing which features people actually relied on, competitor analysis, and a fresh look at the existing customer base that led to revisiting personas. Together, this pointed to a clear opportunity to cut the bloat, simplify the IA, rebuild the UI to feel approachable rather than intimidating, and support light mode, dark mode, and full brand customization for API and enterprise partners. Product was a close partner throughout — you and the product team ran a full-site feature audit together and your PM co-ran six rounds of usability testing with you. 🔲 NEED INFO on engineering's specific contribution here — what constraints or feasibility tradeoffs they surfaced, or what they built that shaped the design, would round this out nicely. Jobs to be done 🔲 NEED INFO Testing surfaced at least one real pivot: usability testing showed that static labels on the left-side menu weren't necessary, so that direction was dropped in favor of a simpler pattern. 🔲 NEED INFO — this is the only explicit pivot in the current write-up. A stronger process section would name a couple of other directions that were tried and rejected, and why — that kind of "here's what we tried first, and why it didn't work" detail is often the most memorable part of a case study.

  • sample bullet point

    • Sample 2

App Modal
App Modal Zoom