Improving the release flow in the Overwolf developer console
The release process was confusing due to unclear stages, hidden gating logic, and limited visibility into progress. I redesigned the flow to clarify each step, increasing self-serve completion from 68% to 89% and reducing DevRel support requests by 75%.
Self-Serve Completion rate
+21pp
Releases completed without DevRel help
Developer Relations effort
−75%
−63%
Release-related contacts per 100 attempts
Project Snapshot
TIMELINE
July-September 2023
ROLE
Lead Product Designer (end-to-end, IC)
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. This platform helps in-game app developers manage publishing and track their workflow.
The project covers 16 features in 5 sections, with 9 built from scratch and 5 completely redesigned. The Production Channel was the first big update to release management in this effort.
The Production Channel is essential because every app release on Overwolf goes through it. Here, developers upload builds, handle review steps, set rollout percentages, and ship updates to their users. If this process is not clear enough, it impacts all app developers.
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
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
Support Requests
19
Release-related contacts per 100 attempts
DISCOVERY
Developers' support requests revealed that the release process workflow didn’t align with their expectations
In the first two weeks, I reviewed support requests with the Developer Relations team and found that unclear stage relationships and next steps were the main sources of confusion.
As new features were added, the interface grew more complex. While each feature made sense on its own, their combination disrupted developers’ understanding of the system.
Developers expected a linear process: upload, review if needed, then roll out. The root cause was a mismatch between developers’ mental models and the interface structure, not missing features.
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
Because inconsistency was preventing learnability across Overwolf products, I ran a pattern-divergence analysis, classifying each inconsistency as a “system gap” (a legitimate need not yet covered).
I worked with engineering to choose which patterns to add to the component library, enhancing this process and future experiences across the ecosystem.
Old Production
Redesigned Production
The redesigned New release flow rollout in action
This video provides a walkthrough of the entire release flow, from the initial release to phased rollout management.
RESULTS
The numbers
Self-Serve Completion rate
+21pp
68%
89%
Releases completed without DevRel help
−75%
8h
2h
Weekly time spent
Support Requests
−63%
19
7
Release-related contacts per 100 attempts
Guardrails held
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
Let’s collaborate
Senior, Lead, or Founding Designer roles.
Complex B2B preferred. AI-augmented teams welcome.
On-site or hybrid. Israel-based.
