Streamlining the Frostbuster submission process for developers

context

A critical internal tool, largely untouched for two decades. Two distinct user groups. One broken process.

Frostbuster is triggered when a CVS or GIT branch is locked during a code freeze but a fix is still required. Developers submit a request for branch access using the Frostbuster form, and once approved by a panel of reviewers, they can merge their code into the specific release branch. Access expires at midnight EST on the day the request was made.

NSP Developers are the primary users. They work on fixes for code they own, provide details for raised Jira tickets, submit Frostbuster tickets, and merge their requests once approved. Reviewers (a panel of 3-4 approvers) evaluate the risk of each defect fix and approve or decline access. QAs also play a supporting role, creating and verifying the Jira tickets that trigger the process.

The project ran over 5 weeks following a Define, Design, and Test roadmap, including a survey of 33 developers, interviews with 3 users, mapping the current flow, designing a new flow, design reviews, and user workshops with both developers and reviewers before moving to development.

problem

Developers face an inefficient process when implementing necessary code changes after a code freeze, resulting in excessive effort for both developers and reviewers. How might we reduce the manual effort and time it takes to submit and process a Frostbuster request?

A UX-Lite survey of 33 developers scored the current Frostbuster experience at 60.60 out of 100, indicating the process works but has clear room for improvement. Ease of use scored 3.3/5 and usefulness scored 3.6/5, confirming that while the process is necessary, it creates friction.

The overall pain point was excessive manual effort spread across multiple tools and sites. Four specific issues were identified: a stream dropdown with 70+ options causing frequent selection errors and rejections; developers needing to navigate to a separate Confluence page to copy 10-20 questions and paste them into Jira; a Frostbuster table cluttered with unused columns that reviewers largely ignored; and date sorting by month/day instead of year/month that made it hard to find recent requests.

process

Research and discovery

Research began with a survey of 33 developers to measure perceived ease-of-use and collect open feedback, alongside walkthroughs of the existing Frostbuster tool with 2 reviewers and 1 developer. This gave a dual perspective on where the process broke down for each user group before any design work began.

Design proposals

Four key changes were proposed to directly address the pain points. First, automating request details: developers paste a GIT merge request link, and the system fetches stream and defect information via the GIT API, eliminating manual entry errors. Second, pre-populating the defect template: once a defect type is selected, the corresponding Confluence template populates automatically and responses post directly to the Jira defect as a comment.

Third, optimizing the table view: an info panel surfaces all relevant request details inline, reducing reliance on navigating to Jira. Fourth, adding date-based filtering so reviewers can sort by today, past 1 day, past 3 days, or all requests within the month, directly addressing the workarounds reviewers relied on to find recent submissions.

User workshops and iteration

One-hour workshops were run with two separate groups: 6 developers and 2 reviewers, conducted both in-person and remotely. Developer feedback confirmed that automation was the most valued feature for reducing error. Reviewer feedback revealed that past 3 days was the most relevant filter range, and that resubmitting due to incorrect fields was a shared frustration. This led to adding an Edit request feature, allowing developers to modify rejected requests without starting over.

outcome

A redesigned Frostbuster that removed 12 steps and reduced clicks by 35%.

Comparing the current and redesigned developer flows, the new experience reduced the submission process from 34 steps to 22, removing 12 steps and cutting clicks by 35%. The redesign consolidated information scattered across multiple tools into a single, guided flow with automation handling the most error-prone parts of the process.

Next steps include usability testing with a coded prototype, a follow-up UX-Lite survey targeting a score of 4/5 on both ease and usefulness, and longer-term work to streamline automations, refine template questions with reviewers and QA, and update support resources.

reflections

The impact of collaboration

This project was an example of what a research-driven design process can look like when UX research and UX design work closely together. Having research directly inform each design decision created accountability, ensuring that every change addressed a real, documented user pain point rather than assumption.

Collaborating closely with developers, reviewers, designers, and researchers helped define the scope of what was feasible within the timeline. Knowing what we could and could not do made the design work more focused and grounded.

Changing the co-op project experience

This project marked the first time a UX research co-op and a UX design co-op collaborated together on the NSP team at Nokia. The team was impressed with the results, and the cross-disciplinary pairing is something they are carrying forward into future co-op cohorts as a model for how research and design can work together from the start.