Redesigning the Overwolf Developer Console, starting with the Production Channel
The Production Channel worked, but developers couldn't tell where they were in the release process. As the first feature of a full Developer Console redesign, I restructured the stages and gating logic, increasing self-serve completion by 21 points and reducing the Developer Relations team's release workload by 75%.
Self-Serve Completion rate
+21pp
Releases completed without DevRel help
Developer Relations effort
−75%
Support Requests
−63%
Project Snapshot
TIMELINE
July–September 2023 (part of the Console redesign, 2023–2025)
ROLE
Lead 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 2023, 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 goes 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 the impact.
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
Self-Serve Completion rate
68%
Releases completed without DevRel help
Developer Relations effort
8h
Weekly time spent
19
Release-related contacts per 100 attempts
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.
Developers Console (Not DS aligned)
OW 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, identifying and defining the key stages: "Ready for release", "Review", and "Production", along with their associated 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.
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.
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)
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.
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 yet cover).
I worked with engineering to add these patterns to the component library rather than build one-off solutions in 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 ecosystem rather than just one screen.
Old Production
Redesigned Production
The redesigned New release flow rollout in action
A walkthrough of the full release flow, from initial release through phased rollout.
What to notice:
Upload starts the flow without losing context
The Review stage appears only when a review is required
Production remains locked until requirements are met
The release rolls out in phases
RESULTS
The numbers
Self-Serve Completion rate
+21pp
68%
89%
Releases completed without DevRel help
Developer Relations effort
−75%
8h
2h
Weekly time spent
Support Requests
−63%
19
7
Release-related contacts per 100 attempts
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 DevRel team for higher-value work
A 75% reduction in DevRel time spent on release support enabled the team to 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 ecosystem, 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."
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.
