To respect my non-disclosure agreement, certain details in this case study have been simplified, modified, or omitted. This case study focuses on my design process, problem-solving approach, decision-making, and contributions, while ensuring that no confidential product information is disclosed.

Redesigning Release Operations for Cisco's Enterprise Teams

From scattered spreadsheets and Jira workarounds to a unified, role-based release system - cutting planning time by 45% and release errors by 30%.

Client:

Cisco (via MSys Technologies)

Domain:

Enterprise Release Operations

My Role:

Product Designer

Platform:

Internal Web App

Users:

PMO, Engineering, QA Teams

The Challenge

Cisco's release process was running on a patchwork of Jira exports, spreadsheets, and manual PMO coordination across multiple product teams, subsystems, and time zones. No single source of truth existed for release status, cutoffs, or ownership.

The result: release managers spent hours each week chasing updates, critical cutoffs were missed, and confidence in the release process was low. Leadership had no reliable visibility into whether a release was on track until it was too late to course-correct.

Design problem:

How do you replace deeply embedded workarounds, built across years of team habit with a system people will actually trust and use?

How I approach

My starting point was understanding why existing tools weren't working, not just what to replace them with.

I ran stakeholder interviews with PMO leads, engineers, and QA managers to map how releases actually moved through the org versus how they were supposed to. I walked through live Jira workflows, audited the spreadsheets teams relied on, and identified where handoffs broke down.

Three things became clear: teams were working around the tools, not with them. Role responsibilities were ambiguous. And visibility collapsed at the exact moment it was most needed during active release windows.

I used competitive benchmarking to pressure-test assumptions about what "better" could look like, then brought findings back to stakeholders to align on what the system needed to solve first.

Research, Strategy & Design Principles

The core strategic shift was architectural: instead of bolting onto Jira's ticket-first model, I designed the system to be release-first, organizing everything around the release lifecycle (plan → execute → monitor) rather than individual tasks.

This unlocked three design principles that drove every decision:

Progressive disclosure by role.

PMO, engineering, and QA needed the same system but at different depths. The UI adapts to role-based permissions without fragmenting into separate products.

Time as structure.

Aligning the interface to weekly planning cycles made the system feel familiar and reduced the learning curve for teams already working in weekly rhythms.

Design system as foundation.

Building on Cisco's enterprise design system wasn't a constraint, it accelerated delivery and ensured the product felt native to Cisco's ecosystem from day one.

Defining the Workflow & Solution

Before:

Release managers toggled between Jira, spreadsheets, and email threads to construct a picture of release status. Role responsibilities weren't enforced, anyone could edit anything, which meant nothing could be trusted. Cutoff dates existed in someone's spreadsheet, not in the system teams worked in daily.

After:

I restructured the entire information architecture around the release lifecycle - planning, execution, and monitoring, rather than mirroring Jira's flat ticket structure. Role-based permissions were defined and enforced at the workflow level, so each user sees exactly what they need to act on. Cutoff dates and governance indicators were surfaced inline, where teams already work, not buried in a separate view.

The key design decision was resisting the temptation to "just clean up" the existing workflow. The old model was fundamentally broken, incremental improvement would have preserved its failure modes. A clean architectural reset was the right call.

Design System & Accessibility

Working within Cisco's enterprise design system required more than applying components, it required knowing where to extend it and where to hold the line.

For standard UI patterns (forms, tables, navigation), I used the system as-is to maintain consistency and accelerate developer handoff. For release-specific interactions - status signalling, cutoff indicators, risk flags, I introduced purpose-built patterns that remained visually coherent with the system while solving problems the system wasn't designed for.

Accessibility was treated as a constraint from the start, not a post-design audit. All status colours were paired with icons and labels to ensure information was never conveyed by colour alone.

Hi-fi UI

Translated validated workflows into pixel-perfect, production-ready interfaces optimized for enterprise clarity.

Metrics & Impact

Metrics are validated through stakeholder walkthroughs and live release-cycle feedback across 10 members teams over 3 months.

Validation & Iteration

Validation in an enterprise context looks different from a consumer product. There was no opportunity for formal usability testing, access to users meant working with active PMO and engineering teams during live release cycles.

I structured walkthroughs around real release scenarios, not hypothetical tasks. This gave feedback that was grounded in actual stakes and surfaced issues that would never appear in a test environment.

What changed based on feedback:

→ The current week's visibility was too low; teams were losing context during long releases. I increased visual weight on the active window.

→ Cutoff and governance indicators were surfaced higher in the hierarchy after teams repeatedly missed them in early builds.

→ Subsystem grouping was simplified after scanning tests showed engineers were spending too long finding their scope.

→ Dashboard risk signals were redesigned from status labels to a tiered visual system after PMO leads said labels required too much interpretation under pressure.

Reflection & Learning

The hardest part wasn't designing the system, it was earning trust from teams who had built workarounds they relied on. In enterprise environments, a broken release has real business cost. People protect their processes.

The lesson I carried forward: make the new system feel less risky than the old one. That meant involving PMO leads in architectural decisions, making rollback paths visible in the UI, and launching with a template library so teams could onboard without abandoning what was familiar.

If I could revisit one thing: I'd instrument adoption from week one which teams migrated, at what rate, where drop-offs happened. We had strong outcome metrics, but the adoption story was reconstructed after the fact. Better instrumentation would have made the case for scaling faster.

Other Case Studies

See All Projects