Planning; everyone’s favorite past time
Planning phases in the product lifecycle can range from inspiring to mundane. Lately, I’ve learned a lot about how to breathe life into the planning process that I’d like to share. My experience is centered around design systems, so you’ll see examples and resources tailored to that type of work.
Start by dreaming
You might call it a North Star, a vision, a goal — whatever the tool or framework, it’s crucial to have a shared picture of the desired future to check any and all planning against. Your vision is your measurement to see if each action along the way fits. If we know where we want to be by the end of the year, we can analyze every piece of work to make sure it’s driving us in the right direction.
I highly recommend this guide (embedded above) from Dan Mall about design system strategic planning. He cites dreaming as the main way planning becomes fun, and I wholeheartedly agree. I won’t regurgitate all his wisdom because he’s a top notch communicator. He also shares a goal creation framework, based on Shawn Blanc’s Focus Course program, that can help teams get to their defined vision together. Half the battle is getting to a shared vision that’s down on paper and easy to find. Have the dream, communicate it, align around it, and then break that dream down into short term goals.
Focus, focus, focus
What happens when all of our dreams are a bit different? Or when we start moving towards our shared dream but we all prefer different routes? Or when new requests for components come in or a new product teams needs support extending the design system? Or ideas are raised about how to impact testing or team-wide design process or support strategy or new hire onboarding or or or….wait. All these things are valid, but we have to find the opportunities that align with our dreams.
“You can do anything, but not everything.”
— David Allen from Getting Things Done, also lifted from Dan Mall’s video above 👆
Teams need a way to pay attention to distractions without letting them bump the train off the rails. These distractions are all opportunities, but those opportunities need to be weighed against everything else so we keep steering towards our goal. My favorite approach to capture the noise without sacrificing vision is design thinking (revolutionary, right?).
Working through ideas, defining problems, finding the right things to implement and validating assumptions is good for all products, including design systems. Prioritization grids can be an incredibly effective tool to capture everything while finding focus on the ideas that are most important and attainable.
Once a team identifies the right things to focus on, this should be validated with their audience. For design system teams, this means product teams consuming the system. Validating could look like interviews, socializing plans around for feedback, or posting roadmaps publicly and awaiting response.
Validation is also crucial when it comes time to prototype and ship those ideas. In my team at U.S. Bank, we build validation in to our component creation process from beginning to end and then back again. We need to constantly ensure what we’re making and planning aligns with what teams or customers need. But won’t validation take time? Funny you should ask…
Let’s slow (some) things down
“I learned, a long time ago, about a particular saying from the continent I grew up on: ‘the times are urgent; let us slow down.’”
— Bayo Akomolafe from A Slower Urgency
It’s crucial to tune in to what product teams are up to and bring that understanding in to design system planning. It’s also crucial to slow down and avoid the common pitfall of trying to keep up or keep ahead of product teams. In reality, products ship faster and the system moves slower. We need better processes for creating product and surfacing the right reusable pieces that have been tested in real life.
“Successful design systems move more slowly than the products they support. That’s a feature, not a bug. The slower pace doesn’t mean that design systems have to be a bottleneck to shipping product.”
— Josh Clark from Ship Faster by Building Design Systems Slower
I would take this quote one step further and say that systems attempting to match or out-pace product teams do become a bottleneck to shipping product. If a product team is 1 month away from releasing a new feature and they need a new component to finish out the flow, the design system can either drop everything to create that component or set the product team up to create that themselves. Typically, creating a general-use component takes much longer than creating a business-line specific version that only has to account for one set of requirements. If the design system team races to keep ahead of the feature release, the product team will most likely miss their deadline while they wait for a completed component. In the meantime, a competitor releases the same feature, and we’re all a bit deflated.
Product teams move fast and innovate, and design system teams move slow and standardize. You could also say product teams move in a lively method and design systems are all about steady progress. Stewart Brand published the concept of pace layers in 1999 to unpack how different layers of society follow a common path, but do so in different speeds and styles. Likewise, there are concentric layers to the pace of an organization.
In the product design world, the fast, outer layers are product or feature teams. Their charter is to innovate and ship features that grow the business. The slow, inner layers are governance and design systems, which should be working to stabilize (or scale) the proven output of innovation. Even slower inner layers could include forces like risk, market trends, compliance and regulations.
When slow layers try to out-pace fast layers, the circle morphs into a linear race. This can be beneficial for a short time as design system and product teams work together to extend the system. But system work should be more careful curation than innovation. When it comes to planning, pace layers should be embraced so innovation output gets captured for reuse in the design system.
Now that I’m thinking about it, the pace theory probably explains why parenting can be so exhausting. Children are definitely outer-layer lifeforms, constantly growing, learning and innovating. Parents are inner-ring all the way, and their job is to create a stable home for all the frantic exploration. Keeping pace between rings can be a blast temporarily, but it’s not sustainable. Or maybe that’s just me 😬.
Go forth, dream, plan, and let it crumble
From my own experience, the purpose of planning is not to set upcoming actions in stone. The main reason we plan is to share those plans and get feedback and alignment. Feedback might look like excitement or confusion based on how plans line up with the audience’s needs and expectations. We should have flexibility to absorb that input from the community and course correct to increase value without compromising vision.
It’s important to recognize that too much rigidity can create comfort, but it can also create apathy. Too much flexibility can create excitement, but it can also breed chaos which can stifle effectiveness and lead to burnout. The right balance creates a team culture where individuals know how to have impact, they’re free to self-start and challenge themselves, and the work can adjust to align with larger objectives.
We make our best attempts to predict the right opportunities that line up with our vision, our business and our audience. All of it can change and shift, grow and shrink. As things change around the team, plans should be nimble enough to support the big picture, and inspiring enough to motivate teams of people. And if you figure out how to do that, please let me know.
Happy planning! 🍻
