<p>Published on <a href="https://blog.prototypr.io/3-tips-to-run-effective-design-meetings-dec2ec238b56?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> jessi reel <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*OaIyG5_2qrIrxZ5Qz-wiwA.jpeg"></p>
<p>We’ve all been there. Some meetings are like magic…you go in with questions, those questions get answered, everybody walks out on the same page with clear next steps. But likely, we’ve all experienced the opposite: you go into a meeting expecting one thing, but it gets sidetracked, and everybody walks out more confused then going in. Some meetings feel like a waste of time, other are highly productive.</p>
<p>So how do you make sure that magic happens? As designers, we can set ourselves and our teams up for success by running well structured meetings. First set clear expectations, ask for specific feedback, and clarify next steps. To do this gracefully, here are some tips for running effective design meetings</p>
<ol>
<li><strong>What type of meeting is it?</strong></li>
<li><strong>Who should be there?</strong></li>
<li><strong>What will happen in the meeting?</strong></li>
</ol>
<p><img alt="" src="https://cdn-images-1.medium.com/max/800/1*ARGWuTNNyqSohhe6eneeMQ.jpeg"></p>
<h3>Tip 1: Be clear what type of meeting it is</h3>
<p>For different points in the design process, we need different types of feedback and input, which is why I like to break design meetings into at least 3 groups: Define, Design, and Develop.</p>
<h4>Define</h4>
<p>Define meetings are the opportunities to kick off a project and set the requirements. They define what is the problem, who are the users, and what are the constraints and timeframes. Personally, the smaller these requirements meetings, the better, for instance: just the PM (or other product owner) and the designer.</p>
<h4>Design Feedback</h4>
<p>Designing is an iterative process, and every team works at different paces. Personally, I advocate for following this general template:</p>
<ul>
<li><strong>Research</strong> — If the problem and users is already defined, take a moment to see how other people are solving this problem, either in your own company or in the industry and beyond.</li>
<li><strong>Sketch </strong>— Explore multiple options and see which ones may fit the need. Sketching can be done collaboratively on a whiteboard in a design meeting or on your own time.</li>
<li><strong>Feedback</strong> — Key to design feedback meetings is being clear what is on the table to get feedback on. Is it the user flow? Focus on that. Is it the layout? Is it the text on the CTA’s? Ask for what you need and don’t get side-tracked.</li>
<li><strong>Refine</strong> — Feedback and refining the designs could take multiple iterations, so be careful how many feedback loops are happening depending on the timeline of the project.</li>
</ul>
<p>Key to <strong>design feedback meetings</strong> is being clear what needs to be decided, and who should be there. Are we confirming that we are meeting requirements? PM should be there. Are we seeing which design option is more feasible, then we need feedback from the developer.</p>
<h4>Develop</h4>
<p>Once the designs have been decided upon, designers should still be involved in the development process. Naturally as things get built, questions about edge-cases come up, or technology limitations require scaling back those designs. It’s important that a designer is a part of those conversations, because nearly every product scales back in the development process, but you don’t want to miss what is most important about the designs. For these meetings, you also don’t need the whole team, probably just the designer, PM and front-end developer.</p>
<p><img alt="" src="https://cdn-images-1.medium.com/max/800/1*hHFXkTwv2cqS4C5q8xt_gA.jpeg"></p>
<h3>Tip 2: Invite the right people</h3>
<p>Key to successful meetings is being clear what the meeting is about, and who should be there. As teams scale up, a team could grow from 3 to 10 people in the course of a year, but most meetings are not effective with 10 people in the room. So who should be in which meetings?</p>
<p>There are number of frameworks for naming the different players in a meeting, the RAPID framework being one of them. Personally, I like the <strong>Decide,Consult, Inform</strong> model better, because frankly, it’s less words.</p>
<h4>Decide</h4>
<p><strong>Decisions makers</strong> are people who can commit resources, time, or money to a project. They decide what it is going to be made and why. Having all the decision makers in the room at the same time is key, so if there is disagreement, they can hash it out right then and there until there is a solution, or can agree to next steps.</p>
<p>The fewer the people, the easier it is to move quickly, hear everyone’s voices, collaborate, and get buy in. Because of this, I often like meetings to be as small as possible. Depending on the team, decision makers may be the the product lead, and the design lead, and engineering lead. For small meetings, like, <strong>define</strong> meetings, or brainstorm or sign-off meetings, having only a few key decisions makers in the room can help speed the process.</p>
<h4>Consult</h4>
<p>On the other hand, if you are on a big team, different people’s opinions need to be heard and listened to at different times in the process. <strong>Consultants </strong>are people whose opinion is valued, but may not have the ultimate decision. A front-end engineer may be consulted, for instance on <em>how long it would</em> take to develop option A vs. option B, as that will inform which options will be chosen given time constraint. Technical feedback meetings in the design iteration phase are important to weigh the options and hear their voices. Their expertise is valued and taken into account, but they are not the final decision maker.</p>
<h4>Inform</h4>
<p>Sometimes, we are not there to make decisions nor offer our opinion. Sometimes we are just lucky enough to be invited. In these cases, we are just there to stay informed. Meetings where people are informed of big changes or demo new products can be larger full-team meetings.</p>
<p><img alt="" src="https://cdn-images-1.medium.com/max/800/1*LvWqWovK7CmfuZ8Bopwk0g.jpeg"></p>
<h3><strong>Tip 3: Follow an agenda</strong></h3>
<p>In addition to having the right type of meeting, and inviting the right people, it’s important to be clear about what the meeting need to accomplish. Most importantly:</p>
<ol>
<li><strong>Which designs are getting addressed</strong></li>
<li><strong>Which decisions are going to be made</strong></li>
<li><strong>What the next steps are</strong></li>
</ol>
<p>As designers, we can set up a clear structure for this by these 4 easy steps:</p>
<h4>1. Send out an email before the meeting</h4>
<p>Send email or update the calendar invite with an outline of the meeting and links to the designs. This gives people a chance to check out the designs and be more prepared for the meeting.</p>
<h4>2. Start with an agenda at the beginning of the meeting:</h4>
<p>Example:</p>
<ul>
<li><strong>Going over designs </strong>for XYZ workflow</li>
<li><strong>Need feedback:</strong> Are we meeting the requirements of the project? AND Which option A, B, or C is better, based on usability and feasibility?</li>
<li><strong>Next steps</strong></li>
</ul>
<h4>3. Summarize feedback &amp; next steps at the end of the meeting,</h4>
<ul>
<li>Cut the meeting off at 5–10 minutes before time is up to summarize and discuss next steps.</li>
<li>Summarize the feedback that was given, and what the decisions were. This way, if you’ve missed something, someone has the chance to add or clarify that feedback.</li>
<li>Ask what the next steps are, and put a name next to each step. Make sure that person commits to that action and give an estimate of the time they can do it.</li>
<li>As a designer, it’s helpful to get better and better at guessing how long a set of design changes might take. Often times stakeholders care less about whether it takes 1 day or 2, and more about the accuracy of when they can expect it from you.</li>
</ul>
<h3>4. Send out a summary email</h3>
<p>Send out an email that shares what was summarized at the end of the meeting:</p>
<ol>
<li>What was discussed</li>
<li>What were the decisions made</li>
<li>What are the next steps: by whom and by when.</li>
</ol>
<p>Sending a summary can be very helpful for people to reference later. It is also helpful if you have multiple projects going on at once to make sure you’ve completed all the committed tasks.</p>
<h3>Be structured and communicate</h3>
<p>Some people are incredibly successful without structure, but for the rest of us, a bit of structure can help to raise our game. In order to be effective at running design meetings, be clear what type of design meeting it is, who should attend and why, and what will happen during and after the meeting. This will set a project up for success, and make good use of your team’s time and talents.</p>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=dec2ec238b56" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/3-tips-to-run-effective-design-meetings-dec2ec238b56">3 Tips to Run Effective Design Meetings</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


3 Tips to Run Effective Design Meetings

Top Stories