Planning and design systems–how much time you got?

There are few things more impactful than good planning. Planning isn’t all that different for design system teams. But I do think is plays a more important role. Design systems are playing with a different time scale than feature teams. Systems think in years whereas feature teams focus more on immediate outcomes. Feature teams are most autonomous in their focus. Design systems thrive on connections.

It’s those differences that’s made me such a stickler for planning within a design system team. I’m no expert at planning. It’s been one of the most humbling rituals I’ve had the “pleasure” to be a part of. I’ll be in learning-mode until the day I stop working. This post doesn’t have absolute answers. I’m writing this because people in design systems don’t come from a planning background. But we’re on the hook to deliver one nonetheless. I’m hoping this may help someone that’s heading into their first planning cycle.

No one can/should tell another team how they should choose what to plan or prioritize. Especially me. The purpose of this post is focus on _how organizing and constructing your plan.

Things I’ve picked up along the way

I’ve learned a lot about planning. The hard way. Not all lessons learned are correct. Your mileage will vary.

Define work around projects, not people

It’s easy to have each individual define their focus on defining their own work. I prefer focus thinking around projects.. Teams grow, teams shift, teams can get help from other teams. Define for the work to be done independent of personnel. Once defined, it’s easy to prioritize/scope based on team capacity. Overflow can be cut, planned for the next cycle, or pitched as need for more headcount.

Build in a capacity buffer

Support is a big part of what design system teams do. Support takes time. That time takes away from other work. You’re going to have a big math problem, if you’re planning based on 100% capacity.

In an ideal world a design system team has a measurement of how much time support takes up. Subtract that measurement from the team’s capacity when planning. If that measurement doesn’t exist, ballpark it. If the team is allergic to ball-parking, set aside 20%.

Planning complexity scales exponentially based on team size

What works for a team of 5 will begin to buckle at a team of 10. And it’s a hell of a lot more than twice as hard…

The less defined process, roles and responsibilities are, the harder planning will be. Trust me, I know by experience.

Aim to be cycle ahead or behind

Design system work benefits from staying out of the product development fray. It’s difficult, if not impossible, for a design system team to keep up with the pivots and shifts of feature teams. It’s equally difficult for feature teams to wait on a system team to deliver a systems-based solution. Those teams think in an ASAP-level–systems teams can’t.

To combat this, design system teams should either:

• Plan a cycle ahead to enable feature teams to hit the ground running
• Plan a cycle behind to systemize common patterns once the dust settles

Under-promise

Teams often plan based on what the design system team commits to delivering. Meaning, if you say you’re going to deliver that button component, you better damn well deliver it. A design system team’s goals should be attainable–barring unforeseen circumstances.

Feature teams heavily rely on design systems. When a design system commits to work, there’s a good chance another team has planned around that. Missing a commitment can dramatically impact a feature team’s ability to deliver. It’s critical to make good on commitments. Better to underpromise on what’s possible to make sure it gets done. Overdelivering is always an option.

Over-communicate

Did I mention feature teams rely on design systems? That reliance means they need to be constantly kept in the loop. Teams need to be aware of what the design system team plans to take on. They need to be aware of progress. They should be aware when milestones are hit.

Also, plans change. Shit happens. When (not if) those things come up, it’s critical that everyone who relies on the system is aware. Ideally sooner than later.

It’s not a democratic exercise

This doesn’t mean that folks shouldn’t aim for consensus, but it isn’t necessary. The people doing the work outvote the team members who aren’t. Unless that work impact others’–that’ll need coordination.

Planning can be fluffy–especially early in the process. It’s critical to give everyone on the team the ability to push back. Every, “why?” should damn well have an answer. Or at least a hypothesis. If not, that’s a sign to go rethink decisions.

There’s never enough time for it

So make sure to constantly refine your planning process. Starting by documenting your planning process. I’ve also begun to consider planning a nonstop process. The second the team has landed its upcoming plan marks the moment to start organizing the next.

Plans almost always falls apart to some degree the second the rubber hits the road

Don’t be precious. It’s important to stick to the plan–until it’s not. What’s the turning point? That’s for everyone to figure out on their own.

How I currently structure plans

Most companies I’ve worked for use OKRs to structure plans. They’ve worked fine for me. I’ve made some small tweaks the based on experience and preference. There’s nothing wrong with OKRs–hell, they could be better than my tweaks. So take my structure as either a gentle consideration or cautionary tale.

Projects follow a structural hierarchy of: Long-term direction > Theme > Objectives > Projects > Tasks. Each child supports the parent with greater fidelity and concrete definition.

A brief detour on product owners

The following section discusses ownership of responsibilities–with product owner being frequently mentioned. Who should the product owner be? Whoever is willing/able to own the direction of the roadmap. It can be a product manager, a people manager or a lead designer/engineer. Any/all can work. It’s down to culture/people/capabilities.

Long-term direction

Everything starts with a long-term direction. It’s both the least and most required part of planning. The long-term direction is your design system’s roadmap of roadmaps. It charts a multi-year course for where it plans to go and what to achieve. The product owner drives long-term direction with input and influence from senior leadership.

I usually aim for a four to five year plan. I find the long-term direction to be the ideal altitude to work with senior leadership. It’s great for strategic input without disrupting the team’s day-to-day work.

The long-term direction won’t perfectly lay out what each year will look like. That’s impossible. The goal is to form a point of view to work towards–knowing that point of view will constantly evolve. This point of view helps the team understand how each planning cycle intends feeds into the next.

The fidelity and accuracy of the roadmap drops exponentially over each year. That’s expected. Again, the long-term direction’s purpose isn’t to be accurate, it’s to define an actual direction.

Planning starts with a review the long-term direction. That review helps inform the plan’s upcoming theme.

Theme

A theme is used to help focus a team’s work for the cycle. The theme is typically defined by mangers/product owners on the design system team. It’s guided by company business goals and senior leadership. A planning theme provides a lens to put all projects through and a filter for efforts that are on the fence. Not all work will fall perfectly under a theme, because reality doesn’t work that way. That’s absolutely OK.

Objectives

Objectives represent a distinct goal in service of the planning cycle’s theme. Each objective contains a collection of projects that feed into the goal. Objectives can be defined by the product owner or be driven by senior team members. All team members should have heavy input in the definition of objectives. Some objectives won’t map to the plan’s them. As mentioned, that’s OK. Just be honest about it.

I like objectives to have their own goal/success measure as I find this a better altitude to report upward. I also think it’s important to show how all the projects in an objective map to an single definition of success. This creates extra work from how I’ve seen others set up OKRs, but I’ve found it useful.

Projects

Projects are what I use instead of key results. I find it easier to wrap my head about this mapping. Projects are where the rubber hits the road. I like using projects because they’re exactly what the name suggests. They’re a logical chunk of work with clear boundaries that cleanly map to the objective it’s a part of. Projects are typically defined by the product owner and people who’ll work on the project.

Each project in the objective should also have a clear goal/success measure(s). Those goals should clearly feed into the success of its objective’s goal.

Projects are defined through a one pager or requirements doc that outlines what the hell you plan to do. A project should have an owner who’s responsible to drive the work forward. The project’s requirements doc are written by the product owner and/or the project owner. At the very least, the person who owns the project needs to be heavily involved.

Tasks

Once each project has definition and goals, the job is to scope out the work as granularly as possible. Ideally, down to the task level. This is akin to pre-visualizing a project.

The project owner should work with all involved to define tasks. Tasks have an assignee, rough level of effort and requirements. The product owner and the project owner weigh in on prioritization and requirements. Assignees need to own the level of effort.

How does this usually play out?

Planning follows a pretty straightforward process. First define the high-level direction. Then scope out the tasks to support that direction. Next, sequence the work out across the length of the roadmap. Afterwards, you tweak the roadmap based on capacity and dependences. Then you use any overflow and learnings to pre-plan the following roadmap. Lastly, you socialize it across the company.

Defining

The team works to set a theme for the roadmap and then work to set objectives. The goal of this step is to make sure we’re all bought in to spending a large part of our year working on what’s suggested. I usually stub out skeleton projects to act as a conversation starter. The skeletons don’t need requirements or finalized goals. They only need to kick help start the conversation. This high level definition is shared with the team for review and spirited gut-checks.

Scoping

Once the high level plan has been established, the team goes into scoping mode. The goal of this step is to get all the work to be done defined, prioritized, assigned and level of effort estimated. This is the onerous project of defining all the work that needs to be done for each project. The more granular the tasks are the defined, the better. Have I mentioned it’s a lot of work? Because it is.

Sequencing

Once tasks are created and assigned, it’s time to map them across the planning cycle. Each team member sets an order and rough start dates for their workload. This step makes sure projects are scheduled accordingly when there are hard deadlines. It also ensures that work flows in the right order. Meaning all design tasks need to be sequenced ahead of development. But most of the time, each team member is able to map this to their own personal roadmap based on how they prefer to work.

Rejiggering

Once tasks are scoped and sequenced, it’ll be clear what the team has time for and what’s got to go. Tasks that can’t fit within capacity are cut and project scope is reduced. Objective and project goals are adjusted to reflect what’s been removed.

Future planning

What do you do with all that work that got cut from the current plan? You log it for the next planning cycle. The scope and goals set for the upcoming roadmap should impact the next roadmap. And knowing what will have to spill over is a big part of shaping that future outlook.

So don’t feel like all those created tasks that were cut was a waste. Quite the opposite–it’s helping the team prepare for the next planning cycle.

Evangelizing

Once the roadmap is set, it’s time for the road tour. A design system’s roadmap has the potential to impact so many teams. So, it’s important to plan and roadmap as visible as possible. Share it in meetings. Share it in email. Share it on Slack. Share it at happy hour. Share it over and over. People should be tired of hearing about your plan.

Our team typically posts the planning document which contains a all the gory details. It lays out the theme, objectives, projects and tasks. It’s paired with a Gantt chart that shows the sequencing of work by each project. All this is capped by a summary document which outlines the plan in a conversational tone. I’ll also sometimes go as far as reaching out to teams to see if they have questions/concerns.

Without fail, something is going to come up a week after planning ends. Teams will then ask why the design system team can’t take on a specific project. That’s when you point back to the plan that everyone’s tired of hearing about.

Planning is a lot of work

Make no mistake, I don’t enjoy planning by nature. This isn’t what I get out of bed for. But good planning is can turn a team clinging on for dear life into one that’s hyper-effective. As much as I recoil from the tedium of the work, I love the outcomes produced. Like many other things that are hard work, the payoff is worth it.