LaunchDarkly

The Product

LaunchDarkly is a feature management and experimentation platform used by product and engineering teams to release features, run experiments, and make data-driven decisions at scale.

I joined LaunchDarkly’s Experimentation team on a small, fast-moving contractor team scoped around a defined slate of projects. I owned the largest and most technically complex items on that team’s board, and based on that work, my engagement was extended well past the original scope: into cross-functional data architecture collaboration with engineering, and ownership of the design and information-architecture direction for a full redesign of how flag-level data is presented, contributing to the strategic PRD behind it alongside the PM team.

Designing for experimentation at scale

Experimentation platforms introduce unique UX challenges:

• Large volumes of statistical data
• Complex audience segmentation
• Multi-step decision-making workflows
• Collaboration between technical and non-technical teams

The throughline across everything below: taking workflows that required real technical and statistical fluency to use safely, and making them legible without stripping out the power the people using them needed.

---

Owning the largest project on the team: the “Make a Decision” workflow

Stopping an experiment and recording why was an afterthought in the product. Users had one small free-text box, and the product had three separate, inconsistent entry points for ending an experiment. Teams routinely worked around this by explaining decisions over Slack or email instead of in the platform, so the reasoning behind a call lived nowhere durable.

I benchmarked how Statsig, Eppo, and Amplitude handled the same moment and found they all treated the decision itself as a first-class, structured artifact rather than a footnote. I designed a single consolidated “Make a Decision” pattern to replace the three inconsistent modals, renamed the fields for clarity, added markdown support so people could embed links and context, and extended the decision summary beyond the modal itself onto the iterations list and the results page, so the reasoning travels with the historical record instead of disappearing after the modal closes.

This shipped, and was covered in LaunchDarkly’s own product blog, “New Experimentation Tools for PMs Who Test, Learn, and Move Fast” (Nov 2025): selecting a winning variation, adding rationale with rich text and markdown, and exporting the decision record are all described there as live capabilities.

---

Experiment Share via PDF

Product Managers were taking screenshots of experiment results to brief stakeholders who didn’t have platform access, an ad hoc workaround for a platform that already had all the underlying data. I designed a one-click PDF export, working through layout, pagination, and where the export action itself should live in the UI. I also raised a question the initial spec hadn’t addressed: at what point in an experiment’s lifecycle should export even be allowed, since exporting an in-progress, statistically unstable result could mislead a stakeholder reading it out of context.

Shipped, and live in the product today as a “Download PDF” button on the experiment results tab. LaunchDarkly’s own product copy describes it as producing “a sleek, formatted, data-rich PDF that outlines the details of your experiment, complete with key takeaways and experiment results.” The PM on the project framed it as a way to shift LaunchDarkly’s internal brand within customer accounts, from “a platform where engineers do technical things” to a tool Product, Marketing, and Exec stakeholders would use directly.

---

A/A Tests: trust before you test

LaunchDarkly had no first-class way to validate that an experiment setup was actually working before running a real A/B test. Teams could build an A/A test manually, duplicating variations and targeting logic by hand with no guardrails, so most teams just skipped the step and risked shipping A/B tests on top of broken instrumentation.

I designed A/A as a first-class option directly in the experiment builder, working through the harder questions the initial spec didn’t answer: how to distinguish A/A from A/B/n at the point of setup, what the empty and populated preview states should look like, and what shape of inline guidance would actually help someone new to experimentation trust the result.

Shipped behind a guarded release, and live in LaunchDarkly’s product docs today as a “Run as A/A test” checkbox in the builder, matching the design almost exactly. The project outlived my original scope: it was later picked up under its own engineering epic and continued past my initial involvement.

---

Flag Audiences: who saw what, and when

Teams could see aggregate experiment and rollout metrics, but couldn’t answer a much more specific question that came up constantly during incidents and guarded rollouts: which specific user or account received which variation of a flag, and did that person experience a regression. Summary-level data couldn’t answer it.

I worked as a design partner alongside engineering and data platform leads on a project that required understanding the underlying data model, not just the UI on top of it: which of several event tables had the right granularity, what their retention windows and coverage gaps were, and how query performance changed depending on how a lookup was scoped. I designed the resulting audience data experience, unique contexts per variation, filtering, search by key, session replay drill-in, directly against a working engineering prototype rather than a static mock.

Shipped in phases and launched publicly as Flag Audiences (the project’s internal codename was “Identity Lens”). LaunchDarkly’s own product blog, “Introducing Audiences: See who your flags are really impacting,” frames the exact problem I designed for: “When incidents happen or performance drops after a rollout, one of the first questions teams ask is: ‘Who was impacted?’”

---

Approvals at Experiments: reusing what already worked

This one started as a self-directed discovery project, not a design execution task. The experiment builder was meant to be a single, seamless flow, but two pieces still lived outside it: turning a flag on, and defining the experiment’s audience through targeting rules. Both could only be edited from a separate flag screen.

I scoped and compared two full solution paths: building a dedicated approval workflow specific to experiments, versus bringing flag editing directly into the builder and reusing LaunchDarkly’s existing flag-approval system underneath it. I recommended the second path on an explicit feasibility principle: reuse as many existing components and patterns as possible to keep engineering cost low.

Recommendation adopted as the direction for the next phase of the audience/targeting work.

---

Flag Monitoring & Observability: my most senior project

A year of incremental additions (user feedback, audience data, metric charts, flag history) had left flag-level insight scattered across disconnected tabs with no coherent structure. Separately, LaunchDarkly’s observability data (errors, logs, traces, session replay) lived entirely in a different part of the product and wasn’t scoped to individual flags at all.

I designed a consolidation of flag-level data into a single page (renamed from “Monitoring” to “Impact”), merging audience, feedback, and the newly-integrated observability data behind a consistent filter and drill-down model. I also renamed the “Targeting” tab to “Control,” since most users never touch targeting rules, they just roll flags to 100%, so the old name undersold what the tab actually did. I presented two competing information-architecture directions with explicit tradeoffs rather than picking one unilaterally, and solved a smaller edge case affecting about 2% of customer flags: high-volume flags need event sampling, so I designed a “Sampled” indicator to prevent anyone from mistaking a partial dataset for a complete one.

This project was handed to me to take further than its original scope, and I owned the design and information-architecture direction end to end. The accompanying PRD, business goals, a competitive analysis against Statsig, Optimizely, Datadog/Eppo, Amplitude, and Mixpanel, and the adoption metrics tying the redesign to driving usage of LaunchDarkly’s separate observability SDK, was a collaborative document across the team that I contributed to, not one I wrote solely. Shipped, and confirmed live in LaunchDarkly’s public “Feature monitoring” documentation, which now describes exactly the redesigned experience: flag-scoped errors, logs, traces, and session charts, grouped by variation. As I moved on to focus on AI Config work, I wrote up the direction as a formal handoff document for the designers picking up the next phase.

---

InspectDarkly: hackathon prize winner

Built during LaunchDarkly’s internal hackathon (“Moonshots XXII”), working as UX designer alongside an engineer. The problem: switching flags meant bouncing between your app and the LaunchDarkly dashboard, comparing experiment variations side by side wasn’t possible in-app, you couldn’t tell which flags were active just by looking at a page, and creating a flag took too many steps for a simple UI change.

We designed and built a browser companion extension that overlays flag indicators directly on the live page a developer is viewing, lets them toggle flags and variations instantly without a reload or redeploy, preview different user contexts, compare experiment variations in a side-by-side split view with inline metrics, and create new flags without leaving the site. We demoed it against a fully built mock storefront spanning three eras of e-commerce design to prove it worked across very different UIs, not just the demo app it was built for.

Won a prize at the hackathon.

---

Design system and research tooling

A few additional projects, some shipped, some not, sit outside the core experimentation work above:

• Designed a cross-product, extensible filter component intended to replace the app’s fragmented, team-by-team filtering patterns with one consistent system. Designed, not built by the time my engagement ended.

• Built a Figma plugin, on my own initiative outside assigned project work, to automate part of the manual process for adding new custom icons into the design system.

• Started exploration work on reusable journey-mapping templates for behavior visualization and research documentation. Early-stage; I left the team before this project was completed.

---

Outcome

I joined a contractor team scoped around a defined set of experimentation projects and ended up owning the largest and most technically complex ones. That led to my engagement being extended into deeper work: partnering directly with data engineers on the architecture behind flag-level observability, and eventually owning the design and information-architecture direction for a full redesign of how flag data is presented, contributing to the product strategy behind it alongside the PM team. Several of these projects are publicly documented in LaunchDarkly’s own product blog and docs, and one won the company’s internal hackathon. Throughout, the work was the same kind of problem each time: take a workflow that required real technical and statistical fluency to use safely, and make it legible without stripping out the power the people using it needed.