Turning the 1CD vision into a delivery plan
Connecting design ambition with scope, ownership, and a practical way for the team to plan the work.
- UXD & DPM
- Cisco – Jan 2024 to Oct 2024
The starting point
One Cisco Design Language brought a broad design direction into Magnetic. Turning that direction into everyday work meant more than adding tasks to a board: the team needed to understand outcomes, dependencies, and what could be planned together.
My contribution was translating between the design vision and the operating plan, in partnership with design leadership and the people responsible for the work.
My contribution
I led
Development of the pilot operating approach, planning materials, and facilitation of scope and workflow conversations.
I partnered
With design leadership and workstream owners on priorities, ownership, sequencing, and how the model should evolve.
I worked hands-on
On planning structures, Airtable guidance, presentation materials, and retrospective synthesis. The visual direction and component-design decisions remained with the design leaders and practitioners.
The challenge
A direction is not yet a commitment
A broad initiative can include palette exploration, token naming, accessibility checks, documentation, and component work. Those activities depend on different expertise and decisions.
The program challenge was to make the work understandable enough to plan while leaving room for design exploration and ongoing system maintenance.
The approach
Translate ambition into meaningful scope
I used the team’s 1CD planning work to connect initiatives with more specific outcomes and tasks. Color work illustrated the need: palette, accessibility, naming, and documentation questions had to become visible in the plan.
01 · Design direction
What should the experience become?
02 · Scoped outcome
What body of work moves us toward it?
03 · Owner and dependency
Who contributes, and what needs a decision?
04 · Planning commitment
What can the team take on next?
Pilot before extending the model
The initial sprint approach focused on 1CD. I worked with leadership on how to prepare additional areas without treating the pilot as proof that one format would fit every kind of design work.
Distinguish delivery from ongoing responsibilities
Planning conversations surfaced a useful distinction between work with a finish line and recurring system responsibilities. That informed the discussion about how to represent scope and capacity without hiding maintenance work.
What we learned
Clarity helped; complexity got in the way
The pilot retrospective reported better individual visibility and more intentional planning. It also identified unclear relationships between work items, too many views, and dependencies that complicated estimation.
01 · Keep
Individual visibility and planning ahead.
02 · Simplify
Views, work relationships, and recurring upkeep.
03 · Account for
Design reviews, dependencies, and ad hoc work.
My follow-up responsibilities included simplifying views and clarifying workflow guidance with leadership and the team. These were concrete improvement actions, rather than a declaration that the model was finished.
What took shape
The program work produced a pilot planning approach, materials connecting design scope with delivery discussions, and retrospective-backed actions for the next iteration.
This case is about shaping and coordinating the plan. The separate Magnetic backlog case follows how those lessons informed a broader readiness model and the Codex review skill.
Pilot feedback & future measures
Retrospective votes highlighted what the team wanted to keep and improve. For the next iteration, I would pair that feedback with the delivery measures below.
Votes for individual visibility
Designer-specific views received four positive votes in the 1CD pilot retrospective.
Votes for planning ahead
Defining Epics and Tasks in advance received two positive votes.
Votes flagging view overhead
Too many Airtable views to maintain received two votes. This points to an opportunity to simplify.
Proposed measures for the next iteration
Scope with an owner
Proposed: active scoped outcomes with an accountable owner and next decision ÷ active scoped outcomes. Shows leadership where ownership is unresolved.
Decision turnaround
Proposed: median time from raising a decision to recording its resolution. Shows where alignment is slowing work.
Commitment reliability
Proposed: agreed commitments completed by the review date ÷ commitments due, with scope changes visible. Informs sequencing and delivery discussions.
Baseline and targets to be agreed; no measured improvement is claimed.
What I carry forward
Translate without over-prescribing
The program structure should help people see how their work contributes to the design direction. My role is to make scope, ownership, and dependencies discussable—and to change the process when the team’s experience shows it is too heavy.
