Contents
- Context — Four Briefs, One Problem
- Discover — The Marketplace
- Connect — The Instrumentation Framework
- Join — Sign-up Redesign & the Creator/Joiner Split
- Grow — Activation Homescreen & Vision Work
- Reflection
01. Context: Four Briefs, One Problem
New Relic is an observability platform used by engineering teams to monitor system health in real time. Its value is significant — but locked behind a high-friction technical commitment: users must successfully install monitoring agents on their own infrastructure before they see a single dashboard populate.
I joined as Lead Product Designer on the Growth squad in 2021 and was given ownership of Instant Observability (I/O) — a recently launched marketplace of 600+ integration agents. The brief was to improve navigation and discoverability. The reality, surfaced quickly through discovery, was that the marketplace was one symptom of a much larger problem: a high-intent acquisition channel let down by everything that came after it.
Over two years, the work expanded into four connected initiatives: marketplace IA, an instrumentation framework, an end-to-end sign-up redesign, and a vision-level activation homescreen system. This is the story of how each came to be, the design reasoning behind it, and what it produced.
Team: I was the sole designer with end-to-end ownership across these initiatives. I worked closely with Inés (service designer), our UX Researcher, a PM, a PO, the lead engineer responsible for the Guided Install codebase, and the Design System team. There was no dedicated engineering squad — each initiative required building a coalition with the relevant product team.
02. Discover: The Marketplace and a Context-Collapse Problem
I/O existed in two contexts: a public version at newrelic.com for logged-out users, and an in-product “Add Data” version for existing customers. Public I/O had high engagement. In-product I/O had poor activation. Same catalogue, opposite behaviours.
The reason was user context, not UX. Logged-out users were evaluating New Relic — the marketplace was the product for them. Logged-in users were typically already instrumented and had no reason to explore a catalogue of agents they had already installed.
This was a context-collapse problem, not a navigation problem. The same surface was serving two user types with fundamentally different jobs-to-be-done. This insight reshaped the brief and would inform every chapter that followed.
What I shipped
I reorganised the public marketplace IA around technology type and user intent rather than New Relic’s internal product lines, surfaced the most common agents above the fold, and redesigned the agent detail pages to set honest expectations about installation requirements before users committed.
But the real outcome of this chapter was the discovery itself. While auditing the marketplace, I began capturing the installation experiences users encountered after clicking through. What I found there became Chapter 02.
03. Connect: The Instrumentation Framework
The diagnosis
Inés and I formalised an audit of the 15 most common installation flows. The pattern was immediate: the same product was delivering radically different experiences depending on which agent you chose.
Four agents, four different interaction paradigms. No shared components, no shared mental model. Different squads owned different agents and there was no shared design framework for instrumentation, so each team had independently invented their own solution to the same UX problems.
In moderated sessions Inés ran weekly for several weeks, users repeatedly misidentified the “copy script” area as an interactive CLI window — typing into it and getting confused when nothing happened. The component was communicating the wrong affordance.
Building the case
This was self-initiated. Inés, the lead engineer (who had been pushing for a refactor for years without buy-in), and I built the case bottom-up — bringing design evidence to every review session until the problem became impossible to ignore. By the time the initiative was officially greenlit, the design direction was well underway. The initiative proposed itself through the weight of the evidence.
The framework
Mapping the 15 agents revealed a universal five-stage installation structure. Every agent did the same five things — fragmentation came from each squad choosing different components and layouts to express them. The solution was not to redesign each flow but to create a shared vocabulary.
My output: a documented component library and layout patterns that any squad could use to build a consistent installation flow.
Terminal vs Codeblock — the affordance fix. Terminal (top): interactive CLI, dark background with cursor. Codeblock (bottom): clearly read-only, copy-first as the dominant action. I considered a single unified “code” component but rejected it — the affordance difference between “interact here” and “copy this” was too consequential to leave to context.
Selector tiles — three documented variants. Basic (top), Title + Description (middle), Extended (bottom). The rule: use the simplest variant that communicates the choice. Complexity in the component should reflect complexity in the user’s decision, not default to richness.
Technical Steps pattern — numbered steps with a sticky contextual help column. This solved an observed behaviour: engineers opening documentation in a separate tab mid-install and losing their place.
Test connection — moved from CLI feedback to UI feedback. Per-component status with clear next steps for every outcome. I rejected a single pass/fail design because most real installations were partial successes — Infrastructure agent installed but Node.js failed, or Logs skipped intentionally. The per-component table made partial success legible and actionable.
Organisational outcome
The documentation became the first shared standard for instrumentation across New Relic. The framework was adopted cross-squad, interrupting the independent-invention pattern that had caused the fragmentation. The lead engineer shipped the underlying technical refactor he had been advocating for two years.
04. Join: Sign-up Redesign & the Creator/Joiner Split
Two distinct users, one entry point
Through interviews and session analysis, Inés and I identified two distinct user types arriving at sign-up with fundamentally different relationships to the installation step:
Treating these populations as one was generating noise in our activation data that made it impossible to see what was working for either group.
The key design decision: qualify first, not browse first
My initial impulse — visible in early exploration — was to embed the I/O catalogue directly into sign-up. Show users the agent marketplace, let them pick, then install.
The insight that changed direction: invert the sequence. Qualify first — ask users about their stack and intent — then surface a contextual recommendation. This had three downstream benefits: agent recommendations could be genuinely personalised, non-technical users could be identified before hitting the install wall, and if a user skipped installation, we had already captured their stack to resurface later in the product.
Trade-off accepted: qualification-first added a step before the catalogue. The reduction in downstream abandonment outweighed the cost of one additional screen.
The final design system
These designs were completed as commissioned blue-sky vision work at the VP of Design’s request. They define the full design ambition for the sign-up-to-activation journey.
The A/B test, and what it taught me
We launched the embedded I/O experience and the new visual language simultaneously as a staged A/B test. In the first 24 hours, conversion to successful install dropped 2%. Leadership reverted the code.
The test was launched without formally pre-defined success and failure criteria. We had agreed on the primary metric but had not agreed on what drop was acceptable for how long, what leading indicators we’d monitor alongside it, or how we would distinguish a temporary transition dip from a genuine regression.
This was a process gap I own. In an environment where the implicit bar was “do not make the metrics go down,” any drop reads as failure regardless of what it actually indicates. The lesson: designing the decision process around a launch is as important as designing the launch itself. I now treat pre-launch criteria documentation as a non-negotiable deliverable.
05. Grow: Activation Homescreen & Vision Work
Part 1 — The notification system (shipped)
I paired with a junior designer with this project as a mentoring opportunity. We catalogued every type of temporary notification across the platform, mapped ownership and frequency, and proposed a three-tier taxonomy:
Core rule: no more than one notification type active simultaneously. Priority order: Product Tour > Capability Tour > Product Update.
The new product tour applied in context — consistent step counter, back/next/dismiss actions, and a highlight anchor visually connecting the tooltip to the UI element it describes.
This work shipped. The taxonomy became the cross-squad standard for in-product communication.
Part 2 — Vision work: the activation homescreen
The notification work addressed the noise problem. But it surfaced a deeper question: what should a user actually see when they returned to the product after installation? The existing answer was “wherever they navigated to last time.” That was a missed opportunity.
In parallel with the audit, I developed exploratory designs for an activation homescreen and a reimagined in-product Instrumentation Hub. This was vision work synthesised from stakeholder conversations, activation data, and my own product thinking — never commissioned with a specific shipping target, but proposed as the orchestration layer the product was missing.
The four-surface IA proposal
Across these screens I proposed a deliberate IA structure with four destinations, each answering a different user question: