Release Plugin
Internal Developer Platform - Release Plugin
Streamlining release workflows, ensuring developers can quickly track deployments, approvals, and release statuses with ease.
OVERVIEW
What is this all about?
PROJECT VISION
For engineers across our enterprise, managing releases is often unpredictable, fragmented, and inefficient. The current release management experience lacks the integration, visibility, and automation needed to support a seamless development workflow. At best, teams navigate a mix of disconnected tools and ad-hoc processes; at worst, they face delays, uncertainty, and unnecessary friction that slow down innovation.
OUR GOAL
Our challenge was to transform release management into a cohesive, intuitive experience—one that not only streamlines the process but also lays the foundation for a fully integrated development environment. By embedding robust release management practices into our IDE/IDP initiative, we are creating a platform that empowers developers with stability, efficiency, and confidence in every release.
Approve releases with ease
Answer required audit/cyber requirements and approve your release without friction
Action releases with confidence
Use the PAR activity trail to track Artemis activity and make a decision with confidence
Communicate with asset owners
Communicate directly with release owners to gain context on the release
BACKGROUND & HYPOTHESIS
Consolidating tools, simplifying approvals, and enhancing deployment tracking will lead to faster release cycles and reduced bottlenecks.
Over the years, we have witnessed a sustained growth in tools and processes that support the Software Development Lifecycle (SDLC). While that growth may be great, it has created an ecosystem of disconnected, yet required tooling and platforms, forcing developers to constantly context shift throughout their work day.
At the end of the day, we believe our developers want to maintain flow state and limit the cognitive load in orchestrating processes over disconnected tools
Why did this effort start?
At the start of the year 2024, one of the core initiates that our CEO had set was to improve the developer experience as a whole and start treating our internal developers the same way we treat our external customers. In March of the same year the Developer Experience team (DevX) begun socializing a project called the IDP (Internal Developer Platform) which was supposed to provide developers a one-stop shop for their development needs.
The key goal with this project is to "Automate everything but the creative problem solving in developing software." In the target state, developers will spend the majority of their time in two primary screens IDE and IDP
The IDP serves to connect and consolidate tooling interfaces into a seamless experience across the SDLC
About 7 months of planning and execution, the IDP platform was stood up with mostly out of the box features. After much deliberation, planning, and a build vs. buy analysis, our leadership team decided that we should prioritize the Release Plugin.
The ability for developers to ship code is paramount to the developer workflow and thus critical for an end to end experience for the IDP. After working with our product partners, we were able to come up with an MVP experience definition for the capabilities and features the plugin should have upon release.
RESEARCH
Understanding the current state of affairs
To kickoff this workstream we wanted to do some sensemaking between the IDP Ideal, MVP, and current One Pipeline experiences for ICs, Approvers, and Escalators
Where do we start?
To help kick off this workstream, we wanted to get a better understanding how all of the systems worked. Our product and engineering partners help walk us through the experiences for reach of the primary personas
Screenshot of a zoom call where the engineering and product leads gave us a walkthrough the different flows
Over a period of about 2-3 days, we were able to better understand the OPL UI current state with regards to the release process
We then refined the screenshots into a more digestable deliverable to help socialize with our partners
Current State Release Flow: One Pipeline Users
Current State Release Flow: One Pipeline Users
Current State Release Flow vs. MVP: OPL Users
LO-FI WIREFLOW
To help ensure we were aware of any edge cases and designing for the ideal experience, I was able to create a detailed wireflow, depicting what goes on at each step.
First half of the wireflow
Second half of the wireflow
JTBD Validation
We conducted 8, 30 minute Jobs-to-be-done (JTBD) interviews with developers to validate if we were on the right path with regards to the flows us and our engineering and product partners worked on.
JTBD that were validated
IDEATION
Sketching out the interface
To bring there ideas to life, I created rough UI sketches allowed me to quickly iterate, experiment with layouts and interactions, and identify opportunities for improvement, laying the groundwork for refined prototypes.
RELEASE PLUGIN HOME PAGE/STEP 1
Snapshot of how the Cancel release interaction might look within the release plugin. Resiliency material change, audit-required buttons are going to be behind an accordion, practicing progressive disclosure
RELEASE PLUGIN HOME PAGE/STEP 2
Continued snapshot of the experience shown above. User clicks the the accordion and the audit questions are exposed underneath
DESIGN ITERATIONS
Designing for the ideal state
I started exploring a couple different UI concepts with our product and engineer partners.
CONCEPT 2
Our product team informed us that the audit questions must live on the page at all times. So I explored how that might look and feel on the UI.
I started to explore a release tracker component on within the left most column of the layout, as well as putting secondary metadata within that same column
CONCEPT 3/USABILITY CONCEPT TESTING
After some refinement with our product partners, we decided to go with the following concept. We used the a 9:3 layout with the approach of presenting the main/actions needed content in the middle of the page while the secondary/additional meta data is within the adjacent, smaller column.
Release activity at the top of the page so that user are aware of where they are within the releases process.
Clearer, individual modals for each of the CTAs with contextual information so that users are well equipped when approving or canceling a release
Resiliency material change questions added per audit requirements. The questions needed to in front of the user — behind no interactions.
Release activity and PAR activity further down the page, giving approvers more context to what the release is all about.
Usability testing was successful, however users identified opportunities to improve clarity and context across touchpoints
Users struggled with the release plugin due to a lack of contextual information, inconsistent communication channels, and repetitive task fatigue, making the workflow inefficient and frustrating.
Verbatims from the interviews
Clear callouts for improvements
There are opportunities to make improvements based on feedback from developers and product partners.
FINAL DESIGNS
Improving the design based on feedback and given direction
Our first designs relied on modals for the user experience and the release information was a bit too far below the fold. The page was lacking contextual information and it was hard to communicate between involved parties.
BETTER CONTEXTUAL INFORMATION
Users expressed the need for systems that adapt to their workflows and provide contextually relevant information
Alert at the top of the page thats contextual to the user's role (PAR Approver, ESC Approver, and Dev). This puts the CTAs front and center
PAR activity and release information now higher and detailed justification providing transparency and accountability
BULK APPROVER MULTIPLE RELEASES
Users frequently operate on "autopilot" due to the repetitve nature of their tasks, such as release approvals.
Designed a feature where PAR approvers can quickly approve multiple releases without friction.
MOBILE DESIGN
Expanding the project scope to mobile
Started off as a nice to have, but towards the end of the PI, we learned that a decent junk of approvers use mobile to approve and deny releases. This was a bit alarming to hear, as there was no mobile version created as of yet!
Two videos demoing key flows and one screenshot of the mobile PAR activity
While this was out of scope for the beta release, our product and engineering partners were receptive to the designs and could see them being prioritized and implemented during the next PI.
FEEDBACK FRAMEWORK
Measuring success
In order to determine if our work was impactful, we needed a way to determine how well our design changes are impacting the user. While tracking user metrics, we also needed to be sure we were helping the business succeed as well.
The primary OKR that our business partners are trying to meet with this initiative is to reduce the time spent in deployment by 7%
For the user metrics, we used our established Google HEART (HAT in our case) framework as our foundation. Our internal user tracking software would not be integrated into the IDP for the closed beta, so we were limited on the user metrics we could collect. We had to rely on the UMUX-lite metrics, NPS, and surveys.
The NPS will help us gather overall user satisfaction and qualitative feedback if we decide to ask
The UMUX-lite will help us gather data on overall usability and task effectiveness, helping us understand how well the product is meeting our user's expectations.
TAKEAWAYS & NEXT STEPS
Not everything can make it into the MVP
There were some tradeoffs we had to make as far as what feature will make it into the MVP, but we from design are very happy with the direction this release plugin is going. Being the first plugin for the IDP was such a great experience and I am very grateful to be able to contribute something so impactful to the company. It's a rewarding feeling know that design, product, and tech teams are going to be looking at the we I and the team did a beacon of how to design and develop plugins in the future.
Prioritize high leverage items
There was a lot of work that needed to be done, but it was important to prioritize items that the enterprise needs rather than lower impact features.
Its okay to be flexible
There were numerous pivots and what I like to call "fire drill designs" which shortened or lengthened timelines based on needs and constraints.
Speak to users throughout the design process
Many people believe you only talk to your users at the start, however, we were able to tackle real problems due to constant developer feedback
Scalability is ideal
We were able to contribute a few components back to the IDP design system, enabling development teams to build with less overhead.
At the time of writing, the Release Plugin has been live for about 3 months. The prior release experience has been deprecated and users have been using the IDP primarily. Early data is showing…
3 month NPS score is 55 (96 respondants)
71 UMUX lite score (31 submissions)
Time from release to deployment reduced by 2%
Thanks for reading! Looking for more?
Check out one of my other case studies!
Improving how diabetics measure their blood sugar and make informed decisions
Dexcom - 2021
Let's craft an experience together
CONTACT
NAVIGATE
Work
About
Resume
© 2025 Ronnie Jones
Fueled by Espresso