Making releases self-serve on a multi-tenant developer platform, starting with the Production Channel

Impact

Project Snapshot

Timeline

July–September 2022 (part of the Console redesign, 2022–2025)

Role

Senior Product Designer (end-to-end individual contributor)

Team

PM, 2 Engineers, Developer Relations, Data Analyst

Platform

Web (desktop & mobile)

Users

App developers

Intro

A platform every Overwolf developer depends on

Since 2022, I’ve led a full redesign of the Overwolf Developer Console, where in-game app developers publish and manage their apps. I rebuilt 16 features in 5 sections, 9 from scratch and 5 fully redesigned. The Production Channel came first.

Every app release on Overwolf passes through it. Developers upload builds, complete review steps, set rollout percentages, and ship to users. When the process isn’t clear, every developer on the platform feels it.

Challenge

Developers were able to ship apps, but lacked clear direction

The Production Channel lacked clear progress indicators and a clear system state. Additionally, mandatory review applied only to some developers, but the UI did not indicate who was affected or why.

As a result, developers could not anticipate the next steps, leading to increased DevRel involvement and a release flow that functioned but was not understood.

What we couldn’t change

• Ensure backward compatibility with current workflows.
• Maintain mandatory review processes for designated applications.
• Operate within the established framework (React-Admin).

Guardrail

Ensure that the updated design does not reduce the efficiency of experienced developers.

Where we started

Discovery

Support requests revealed a mismatch, not a missing feature

In the first two weeks, I reviewed support requests with the Developer Relations team. The same question kept coming up: “What do I do next?” Developers weren’t asking for missing features. They were asking where they were in the process.

As features were added over time, each made sense on its own, but together they blurred developers’ picture of the system.

They expected a linear path. Upload, review if needed, then roll out. The interface didn’t reflect that, and the gap was a mismatch between their mental model and the structure, not a lack of functionality.

Mental model breakdown

Developers were unsure of their position in the release flow, the next available actions, or expected outcomes. This uncertainty led to backtracking and repeated questions about next steps. The gating logic and flow were not clearly represented in the UI.

Inefficient success

Developers completed releases, but the interface did not reflect these changes. For example, a partially rolled-out release displayed no value in the percentage field and lacked clear next steps, requiring developers to guess the appropriate action.

Design system misfit

Components, typography, iconography, and spacing were inconsistent across other Overwolf products.

Developer Console (not DS aligned)

≠

Overwolf client (DS aligned)

Collectively, these issues did not stem from missing features but from unclear orientation caused by flawed UX patterns.

Solution

Map the release stages, then make the sequence visible

I created a detailed map of the entire New release flow and defined its key stages. Ready for release, Review, and Production, each with its own rules.

Four decisions to surface what the process was hiding

Each decision addressed the same core issue, a lack of clarity in the release flow. These decisions were considered from different perspectives, including navigation structure, gating visibility, mental model alignment, and system consistency.

1. Accordion-based progressive disclosure

To help developers stay oriented and understand the full process, I evaluated three options, including a step-by-step wizard, a left-rail vertical stepper, and accordion-based progressive disclosure.

The accordion approach wins because it let developers view the entire flow, identify their current stage, and move to the next step without leaving the page.

The wizard flow was rejected for obscuring context, and the vertical stepper was dismissed for treating stages as isolated destinations.

2. Conditional visibility per user kind

The mental model breakdown also affected gating logic. Mandatory review applied only to certain developers, but the UI presented the same interface to all. Developers could not tell whether a review was required for them.

I used conditional visibility so that when a review is needed, the Review stage appears and Production remains locked. When no review is needed, the process skips Review, and Production opens immediately.

Initially, engineering opposed this due to added complexity, but after a joint discussion, we agreed on a workable implementation.

Review by Overwolf team (Mandatory)

Review by Overwolf team (Optional)

3. Keep rollout management separate from release creation

There was an internal opinion to bundle phased rollout controls into the New Release flow. However, developer feedback showed they view initial release and ongoing rollout management as distinct tasks.

I advocated for keeping phased rollout controls in the Public Releases pane, with an explicit visual relationship between the two interfaces.

The tradeoff was maintaining two locations for related controls, but the separation aligned with developers’ mental models and reduced cognitive load during the critical initial release process.

4. Design system alignment over custom solutions

Inconsistency was hurting learnability across Overwolf products. I ran a pattern-divergence analysis, classifying each inconsistency as a “system gap” (a legitimate need the library didn’t cover yet).

I worked with engineering to add these patterns to the component library rather than build one-off solutions inside the Production Channel.

The tradeoff was speed. Routing fixes through the shared library and aligning with engineering took longer than solving them locally, but it meant that every pattern I added improved consistency across the console rather than just one screen.

Old Production

Redesigned Production

The redesigned New release flow in action

A walkthrough of the full release flow, from initial release through phased rollout.

What to notice

1. Upload starts the flow without losing context
2. The Review stage appears only when a review is required
3. Production remains locked until requirements are met
4. The release rolls out in phases

Results

The numbers

Guardrails held

Experienced developers navigated the new structure more effectively than before. The guardrail was not only maintained, it was surpassed.

Moderated sessions with 5 developers post-launch demonstrated faster task completion across experience levels.

Six hours a week back to the DevRel team for higher-value work

A 75% reduction in DevRel time spent on release support let the team reallocate about six hours per week to higher-value activities, including onboarding, growth, and partnership development.

For Overwolf, a more self-sufficient developer base reduces operational costs and signals a healthier developer community, as developers who release independently are more likely to ship regularly and stay active on the platform.

How we know

Metrics were collected as follows. Self-serve completions and support request volumes were tracked using internal event tracking for six months after launch.

DevRel effort reduction is based on team self-reports and should be viewed as an observational, not an experimental, study. No A/B test was conducted. Attribution relies on rollout timing and the lack of other significant changes to the release flow during the measurement period.

”

“Now I clearly see where I am in the process. I used to get confused a lot.”

App developerPost-launch feedback

How the work spread

The accordion-based progressive disclosure pattern was also adopted by the Testing Channels feature, which I designed from the ground up and documented in the design system for reuse across Overwolf products.

Reflection

What I’d do differently

Without early direct access to developers, I relied on support request analysis, which identified what was failing but not why. Conducting interviews earlier would have revealed the mental model gap sooner and reduced the time spent distinguishing symptoms from root causes.

What I took from this

• Mapping the user flow beats symptom tracking. Support data showed where users struggled, but comparing the flow to the interface revealed why. Without that step, I would have fixed the surface rather than the root cause.
• When engineering flags complexity, a shared prototype resolves it faster than discussion. For conditional visibility, the prototype clarified the path and turned a blocker into a contribution to the design system.