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.

Designing Release Operations for Cisco's Enterprise Teams

From scattered spreadsheets and Jira workarounds to a unified, role-based release system, cutting release 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 ran on a patchwork/on-demand 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 cost wasn't just inconvenience, it was risk. A missed cutoff or an untracked dependency could delay a release for a project, and leadership had no reliable way to see whether a release was on track until it was too late to course-correct. Release managers were spending hours each week chasing updates instead of catching problems early.

Design problem:

How do you replace deeply embedded workarounds, built across years of team habit with a system people will actually trust and use, in an environment where a missed cutoff has real downstream cost?

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 exactly 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, when a delay is most expensive to catch late.

I used competitive benchmarking against [Jira, Kendis, ClickUp, Plutora] 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.

To understand where trust in the release process broke down, I structured interviews around four themes: how releases get planned, how teams track health and risk, how governance and compliance get enforced, and how cross-team coordination actually happens day to day.

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 mattered because the business risk lived in the release timeline, not in any single ticket.

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, a deliberate choice over a fully custom timeline model, because adoption speed mattered as much as flexibility.

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 which mattered for trust and adoption inside a large, security-conscious org.

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 design system required balancing consistency with the specific needs of a release-critical tool - status clarity, data density, and role-specific permissions.

For content that lives inside enterprise design systems, I made accessibility a non-negotiable input rather than a final pass. From color contrast to status indicators that don't rely on color alone, this was built in from the start, not retrofitted.

High Fidelity User Interface

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