More Collaborative and Meaningful Approach to Product Design Planning
Episode 8, in which we discuss why development sprint planning might not be the best option to plan design initiatives and what to do instead.
Today, we will discuss why development sprint planning sessions do not work particularly for designers and what, as a designer, you can do instead. You’ll learn how to make design planning sessions more collaborative, meaningful, and effective. The concrete game plan, ready to be implemented, is waiting for you at the end of this article.
Designers collaborate with everyone
Designers working in tech are not lone riders. They are part of bigger groups called either Product Teams or Development Teams. Such a group usually consists of software engineers, quality assurance (QA) engineers, and a PM (Product Manager) in a product environment or a PJM (Project Manager) in project-based endeavors. Designers work closely with all of these people but with different purposes.
Usually, the goal of cooperating with a PM would be gathering business requirements, validating ideas through diverse experiments, and testing solutions with the users. Designers excel at facilitating workshops, talking to users and other team members, and cooking up various ideas to solve the stated problem.
When it comes to working with engineers, the main goal is to hand off design artifacts, such as components and views. Designers ensure their work is well documented so it can be translated into code without much hassle. They also collaborate with the software people to establish a similar understanding of technical possibilities and limitations so they can adjust their ideas in order to bring value to the users as quickly as possible.
But the fact that designers collaborate widely and with everyone doesn’t make it any easier when discussing planning.
The engineers' work, usually the most prominent ingredient in the product soup, is usually planned during so-called sprint planning sessions. But is it the best solution to discuss and plan design initiatives during these sessions? Let’s find out. Here’s a quick intro to development sprints for people who have never worked in an agile environment.
Development sprints
Every week (or two), the Development Team sits down together and creates a plan for what they will work on in the next week (or two). This meeting is called Sprint Planning, one of a few scrum ceremonies. The goal of such a sprint should be clear and accomplished within a given period (a week or two). Each team member picks from the backlog a task that will directly contribute to achieving the sprint goal. They meet again when the sprint ends to review their work and check if the sprint goal was met.
If sprint, sprint goal, and backlog are still a mystery to you, check out this article from Atlassian. It will give you a nice intro to development sprints: https://www.atlassian.com/agile/scrum/sprints
I want to make a small interlude and tell a story that inspired me to assemble this article. It happened to me numerous times in different organizations, but I will only mention its newest iteration.
It’s Thursday morning. We are sitting on a sprint planning session and trying to create a game plan for our second sprint in this very fresh product. That’s our third week since we started working in this product team, which is quite a small group of four people – two engineers, a product manager, and me.
The team is discussing the tasks in the backlog and what chunk of work could be completed in the next two weeks. We put Jira tickets into the sprint and started setting up goals. There was one front-end engineer and another back-end-oriented person. Since it was just our second sprint, it absolutely made sense to come up with two goals, one per engineer.
“What goal should we set for you, Arek?” – our PM asked. I responded, “We should validate this thing and have a workshop on that thing.”
Hitting these two objectives in the next two weeks was absolutely on point and vital for the product's future development. But this is the thing: it concerned the future. And quite a distant one. This work wouldn’t influence other members' tasks in the next two weeks.
Design initiatives do not start with shifting components on the canvas
As you assumably already know, a myriad of items must be ticked off before engineers can translate the Figma file into a working piece of code and put it in the production environment. Before your users put their hands on (and judge) your new nifty feature, you should:
Accomplish a bit of research to understand the user’s needs and pains,
Make a problem statement,
Suggest a solution to this problem and validate the usability and other qualities with a usability testing study,
Polish it, and finally, hand it off to the engineers.
That’s, of course, an excerpt from the double-diamond methodology. Please bear in mind that it does not apply to every design project and can not be used as a to-do list template. Find out why it is rather a guidebook from one of my previous articles.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F702ec518-664e-4266-9cb7-5ece49c618be_1400x918.png)
Nonetheless, it might take weeks or months before the designs are ready to be picked up by engineers. Frankly, it should take that long so the team can make sure they are building the right thing. Yet, this requires a bit different approach to planning design initiatives.
Collaborative approach to planning design initiatives
Looking back at my ten years of working in tech, teaming up with your PM and Tech Lead (lead engineer for the product team) as a Product Trio seems to be working best. It brings clarity to the product's general direction and visibility of what the designer is focusing on at the moment. This collaborative approach makes design planning meaningful by enabling darting at the product from many perspectives. It’s much easier to decide what to do next when both business (PM) and technology (Tech Lead) are aligned. All the parties know what comes next to the pipeline. It reduces ping-pong between the design and engineering and brings less uncertainty for the entire product team.
Here’s a practical guide on how to make this work:
Set up a recurring meeting with your Product Trio
Look at your OKRs (or goals) from time to time
Bring data to the meeting
Don’t spend too much time demoing designs
Use a canvas. Or at least take notes
Bear in mind that you are planning things that will hit production months from now
Set up a recurring meeting with your Product Trio
Depending on your and your team's needs, it could be a weekly or bi-weekly meeting. Book a 30 or 45-minute slot. Remember not to put this into the calendar on the same day the team has other scrum ceremonies as sprint planning or retro. Let the folks clear their minds and separate sprint from design planning.
Look at your OKRs (or goals) from time to time
Most organizations use OKRs or other methodologies to set company-wide and team-focused goals. Don’t forget to look at them from time to time and try to align the design initiatives with your quarterly or yearly goals and objectives.
Bring data to the meeting
If you have already observed issues that your users might have had with existing features in your product and would like to spend some time on deepening this matter, bring the data to the meeting. Suggest what are the next steps you should take to improve the experience. Discuss with your Product Trio what kind of experiments you and your team can afford to make this improvement.
Don’t spend too much time demoing designs
There are most likely other slots in your calendar where you can show your designs and ask for feedback. If not, create one and have a recurring design feedback session with your organization's product people and other designers.
Use a canvas. Or at least take notes
To not forget what you discussed and to bring more visibility to your plans and work, use some canvas or at least create a doc for note keeping. Here is a Miro template created by Damian Skotzke that you can use for your next design planning session.
Bear in mind that you are planning things that will hit production months from now
So don’t get discouraged by this thought. This is the reality. More complex features that require extensive research and much engineering effort will take months before your users can put their hands on them.
Now that you have this new approach to planning design work, there is one final point to consider. Should you still be part of development sprint planning sessions as a designer? I’d recommend yes, you should attend these meetings. Nothing will be planned really for you, but you will keep track of what tasks are currently in the pipeline and when to expect the things you carefully researched and designed to be available on production.
Share this article and help us grow
If you found this post useful or entertaining, consider sharing it with one of your design or product management pals!
Tool of the week
Figbruary
Unleash your creativity by crafting something cool each day of February. Figbruary is a fictional month created by combining Figma + February where you can experiment and design things daily to push the limits. For every day of February, there will be a prompt with instructions for you to design and create. Share your work and tag it with #figbruary or #figbruary2024 on X.
This dope movement was initiated by Vijay Verma.