Design Project Kickoff: What to Agree on Before You Design
A design kickoff aligns goals, success metrics, stakeholders, and the decision-maker before work starts. The agenda to follow and how to close the meeting.
What is a kickoff for?
It prevents the most expensive problem in a design project: each person carrying a different project in their head. Slack frames it as a meeting in which every attendee should leave knowing what is expected of them (Slack, “How to run effective project kickoff meetings”).
As a designer, the kickoff is also your first chance to ask questions. If the scope or the goal isn’t clear here, you will pay for it in review rounds, screens that have to be redone, and discussions that never close.
What should be agreed on?
These are the decisions that block the work if they are not made at the start:
- Goal. The reason for the project and the specific problem it solves. Umbrex recommends SMART objectives: specific, measurable, achievable, relevant, and time-bound.
- Success metrics. How we will know it worked. Agreeing on this early avoids arguing about the result at the end.
- Scope and constraints. What is in, what is out, with which assumptions, budget, and staffing limits.
- Stakeholders and roles. Umbrex recommends a RACI matrix: who is responsible, who is accountable, who is consulted, and who is informed.
- Decision-maker. Who makes the final call on the design. UX Tools advises against offering the approver role to every stakeholder, to avoid “design-by-committee”.
- Timeline and dependencies. Milestones, review dates, and what needs to exist before starting.
- Risks. What could go wrong. Slack suggests a pre-mortem: imagine the project failed and list why.
What questions should you ask in the meeting?
UX Tools suggests asking about the design context, not only the solution: which problems are already known, why the feature was built the way it was, and which customers would be worth interviewing. Those questions give you research material and stop you from starting with the button.
Some that work well:
- What would have to happen in six months for you to say this went well?
- Which decisions are already made, and which are still open?
- Who can say no to a proposal, and at what point?
- Which users do we need to hear from before designing?
How do you prepare?
Umbrex recommends sending the brief or charter, a draft timeline, the stakeholder analysis, a preliminary risk register, the project org chart, and the agenda with time estimates beforehand. UX Tools suggests something more direct: bring a proposed plan, not a blank slate. That way the meeting discusses something concrete instead of inventing it.
Umbrex’s reference agenda, adaptable to the size of the group:
- Welcome and introductions (5 to 10 minutes).
- Project background and context (10 to 15 minutes).
- Objectives and scope (10 to 15 minutes). Success metrics fit here.
- Stakeholder alignment and expectations (10 to 15 minutes).
- Timeline, milestones, and dependencies (10 to 20 minutes).
- Risks and issues (5 to 10 minutes).
- Communication plan (5 to 10 minutes).
- Next steps and action items (5 to 10 minutes).
- Q&A or open discussion (5 to 15 minutes).
- Closing (5 minutes).
Added up, the blocks run to between 70 and 125 minutes, so in a 60 to 90 minute meeting you will need to trim or merge some. UX Tools suggests a similar order: explain why everyone is there, state the goal, clarify roles, present the timeline, define success, and assign action items at the end. The timings are a guide. The order doesn’t change: first the why, then the how.
Example
Illustrative example: a team is going to redesign the admin panel of a booking platform. In the kickoff, the sales director says the goal is to “improve the experience”. When the team asks the six-month success question, something more concrete appears: reduce support calls about schedule changes. That data changes the scope: the redesign focuses on the schedule screen and leaves reports out. The team also agrees that the operations director approves proposals, within two business days. Without that meeting, the team would have redesigned the whole panel and then argued about why nobody noticed an improvement.
When NOT to hold a formal kickoff
- On small work for a single team. A text change on one screen doesn’t need ninety minutes with stakeholders. A message with a goal and an owner is enough.
- When the project is already underway. A kickoff halfway through should be a realignment meeting, based on the current scope and not the original one.
- If the meeting is only for presenting decisions already made. A kickoff without room for questions doesn’t do its job, and it’s better to say so.
Common mistakes
- Starting from the solution instead of the problem.
- Not defining success metrics and arguing about them at the end.
- Inviting everyone and having nobody decide.
- Leaving without actions assigned, or with actions that have no date.
- Not sending the notes, so each person remembers something different.
How to start tomorrow
Before your next project, write a one-page document with four fields: problem, goal, success metric, and decision-maker. Send it to stakeholders two days ahead and ask them to correct it. In the meeting, review only what is unclear. At the end, send the notes with actions, owners, and the date of the next follow-up. To see how this fits into the rest of the process, check the UX design process and project management.
If part of the kickoff is about aligning people, stakeholder management gives you more tools. And to keep a record of what gets decided, design documentation is the place to do it.