Running an Effective Design Kickoff Meeting
Taylor Palmer ·
Communication
UX designers don’t work in isolation, so collaboration and communication are vital skills.
Communication is one of the most underrated skills for a UX designer. I believe the very beginning of a project is the best time to establish that communication.
Assuming a team has already chosen its next project, how does that project begin? Most development projects begin with design (or should), and design should begin with a solid kickoff.
- What makes a good kickoff
- Knowing your team
- Before the kickoff
- The project kickoff agenda
- Kickoffs as a data-gathering exercise
- Facilitation tips
- Next steps
What makes a good kickoff
A good project kickoff meeting can make or break a project. Without one, teams can end up confused or bitter over misaligned expectations. Projects can miss deadlines and go off the rails. Poor experiences will reach customers (or worse, experiences may never reach them at all).
A project kickoff meeting should:
- Create awareness that the project is happening
- Convey why this project is important to do right now
- Identify roles, responsibilities, and key decision-makers
- Coordinate timelines and deadlines so teams can work together
- Determine how the group or team will define success
- Outline next steps
Knowing your team
Project kickoff meetings can and should look different across different organizations and teams. When planning the length of a kickoff meeting you may want to consider the experience level of the team, the types of stakeholders involved, and even the personalities of the team members.
Because every company is different, you may find kickoffs run by a Product Manager, Product Owner, Scrum Master, Project Manager, or someone else. If that’s working for you, great! Do what works. Some of the following ideas might be good proposals or enhancements to your existing process.
Even if those meetings are happening, however, they may not reach the level of detail necessary for you to confidently begin your research or design efforts. In this case, you may want to consider another kickoff specifically for design, or saving a portion of that initial meeting to discuss design.
Before the kickoff
It’s important to find a home for the project documentation. Where do you usually outline decisions, requirements, and open questions? I’ve often called these documents “one-pagers” where anyone wanting to know more about the project can quickly jump in to find an answer to their question. However your team does this, it’s ideal to create this document before kickoff so you already have a spot to take notes about kickoff decisions.
As with any meeting, send over anything that might help the group move quickly during your time together. I highly recommend bringing a proposed plan to a kickoff rather than a blank slate. It’s much easier for a group to critique an existing plan than start from scratch. This is your chance to propose timelines and constraints that benefit design, then work with other team members to tighten those up.
Sending out the one-pager, an agenda, or some other outline will help participants gather their thoughts before the kickoff.
The project kickoff agenda
This is a sample agenda of how you could run a kickoff meeting. Adjust it based on the size of the group and the communication styles of the participants (if known). If meetings tend to run long and it’s hard to stay on track, consider which parts the team could do asynchronously before meeting together (as mentioned above).
View this agenda as a free Notion template 📝
- Clearly explain to everyone why they’re here (“I’ve done my best to gather the right team members to begin discussing our plan for the _____ project.”)
- State the goal of the meeting (“With the time we have today, I’d like to discuss the details and scope of the _____ project and how we’ll be working together.”)
- Explain the urgency or priority of the project (“This is a great time to be working on this because we recently noticed an increase in customer inquiries about this.”) and share data if you have it.
- Clearly outline roles and responsibilities, or ask for them if they’re not known. (“I’ll be leading research and design starting next week, and I’ll work closely with our Product Manager. Do we know who will be leading the implementation of this project? Who can help me find out?”)
- Present a timeline and gain consensus (“I’m planning to start interviewing customers next week and hoping to have designs wrapped up 3 weeks later. We’ve planned for 6 weeks of implementation time. Is there anything we’ve overlooked in this timeline?”)
- Determine how the group or team will define success for this project, if that’s already known (“We’re aiming to increase the number of __ in our product. Are there any other metrics we should be considering?”). In some cases, these types of metrics may emerge during or after research in this project.
- Near the end of the meeting, align on action items and assign ownership and timelines. “Based on what we discussed, it sounds like we need to do A, B, and C. I’m going to do A, is anyone available to help with B and C? Can you have those done by the end of the week?”
If your team isn’t already running some sort of pre-planned development methodology (like agile or scrum) you may need to discuss how often you’ll have check-in or planning meetings, as well.
Depending on your team there may be other items worth adding to your agenda.
Kickoffs as a data-gathering exercise
This is something I personally like to do in my kickoff meetings. It could be a separate meeting or data-gathering exercise depending on time or number of participants. I like to pull in stakeholders from other departments as early as possible to help mold the project and feel more ownership.
This could be another meeting, or an asynchronous exercise (like a survey, whiteboard workshop, or simple email thread). One of the benefits of a meeting is that the participants can more easily build on each others’ ideas. For example, a Support team member could corroborate the anecdotal evidence presented by a Sales team member about what they’re hearing from customers.
The important part is that these team members feel heard and that you can use the information they have to offer.
Here is my outline from a kickoff I ran with cross-functional team members from several different parts of the company:
- Introduce the project and explain why it’s being worked on now
- Ask the group for any problems they’re already aware of (anecdotes about customers being confused, or things we already know about the data, etc)
- (If the feature or experience already exists) Why was it created this way? What technical constraints require it to be this way? What has changed since this was initially planned and implemented?
- Who is using this feature? How are they using it? (Analytics, call recordings, anecdotal evidence, etc)
- Are there any customers that would be great to talk to about this?
- Is there anyone in their departments or elsewhere in the company who is particularly expert on this topic
- Ask participants how you should involve them going forward.
Avoid offering the position of approver or decision-makers to prevent a design-by-committee situation. Instead, focus on how they prefer to receive updates or decisions about progress. Some individuals prefer specific details while others may only want to know when the project is complete and publicly available.
Facilitation tips
If people are resistant to even the idea of the project, let them know that you would be happy to discuss that with them personally. You could also pull in the necessary decision-makers who may have helped get this project on the roadmap. In the long run, it will be beneficial to turn these individuals into allies.
Don’t be afraid to cut off conversations if they get off track. You might say something like, “This is really great, and I’m going to take note of it to come back at a later time, but there are a few things I need to cover so I’m going to steer us back to the agenda.”
Take lots of notes. You should already have project documentation, so share those notes out (especially with anyone who wasn’t able to attend). Ideally, this is a living document that serves as “home base” for the project. Others can critique it to help it take shape as the project progresses.
Next steps
Once you’ve helped your team to align on priorities and timelines, it’s time to get started! With clear roles and responsibilities, everyone on the team should feel empowered to push their work forward.
If you feel like you’re losing touch with the project, or that it’s at risk, consider using similar tactics to check in with your immediate team. Review the same responsibilities and timelines and discuss if anything isn’t working. Clear, open communication can shield a project from confusion and delays.
As you continue working together as a team, mold your kickoffs into something that works well for your unique team composition. This format may work well, or you may find that something totally different is more beneficial to your team (such as merging kickoffs with another meeting, like weekly planning). Do what works best for you.
If this was helpful, consider giving the Twitter thread some love:
