Tips for Leading a Design Project (2024)

If you’re a product designer, you probably lead design projects every day, even if “lead” isn’t in your job title. Whether that’s by gathering user insights to identify the next thing your team could work on, designing solutions to user pain points, or running design reviews, the opportunities to lead your team and influence the direction of your product are present throughout the design cycle. In her book, The Making of a Manager, Julie Zhuo writes:

“Over time I’ve come to learn that leadership is a quality rather than a job. While the role of a manager can be given to someone (or taken away), leadership is not something that can be bestowed. It must be earned. People must want to follow you.”

With this in mind, myself and my colleague, Ted Goas, have compiled tips and insights for leading design projects based on our experiences at Stack Overflow.

Start a project by gathering as much information as possible and talking with your product lead. They may not know all the answers (or have thought deeply about them), so it’s up to you to help lead them to useful answers. The questions below can help guide your conversation. If your team doesn’t have a product lead, consider talking to the people on your team responsible for project management and/or your product’s goals.

• “What’s the goal?” This is the project’s north star. As requirements, edge cases, and opinions pile up over time, the goal helps you focus.
• “What problems do you want to solve, and who do they affect?” This helps you understand why we want to make a change, and who this will affect.
• “How do you envision this working and looking like?” This helps you understand the product lead’s vision and potential requirements. Remember that your goal is to understand their vision (and maybe poke holes in it), not necessarily to execute it as described.
• “What are potential concerns, risks, or sticky areas of the project?” This helps you prioritize design problems and identify additional discovery you might need. This is an area that your product lead may not have thought deeply about, so coming prepared with discussion points can help drive the conversation.
• “What is the project timeline? Where do you expect it to be in a week, a month?” This helps you understand how much time you have, what’s already in motion, and how to plan for your project. Also an opportunity to push back on a timeline, if needed.
• “What do we know so far?” This deepens your knowledge of the project and saves you from doing repeat discovery.
• “Who are stakeholders and potential collaborators in this project?” This helps you understand who you should talk to next.

Decide what discovery you’ll need to do, and bring in the appropriate people. Not all projects require extensive discovery. Below are common discovery methods we use at Stack Overflow, when they’re most useful, and how long they generally take us.

• UX teardowns: Use when there are established or related patterns you can learn from (hint: almost always), and those patterns are easily accessible (generally harder for paid products). 🕓 1–2 days
• Stakeholder interviews: Use when you need to understand what we already know and/or have tried. Stakeholders can include people from project teams (eg. Community) and/or functional teams (eg. Architecture). 🕓 1 week
• User research: Use when you need feedback about UX, UI, and copy, and the project is important enough to warrant an extra week or more. 🕓 1 week (per round of research)
• Expert interviews: Use when your project has lots of history, controversy, and/or complexity. Generally, this means talking to Community (for public Q&A) or Customer Support (for paid products). Make sure to prepare questions, as you would for a user interview. 🕓 1 week
• Data analysis: Use when you have questions about “how many” and “how often.” 🕓 2 weeks (small requests will take less time, but budget at least 2 weeks for most requests, and more for bigger ones)
• Journey mapping: Use when you want a big picture understanding of the user’s experience. This may include off-site things like user emotions or external touchpoints. 🕓1 month (this includes the lead-up to journey mapping, which may include user research, data, etc.)

The product and engineering team at Stack Overflow is fully remote and distributed across the world, so we don’t always have opportunities to meet. That’s why we take special care to make sure that our meetings are a good use of everyone’s time.

For designers, meetings are an opportunity to share information, discuss complex issues, and get alignment from a group of people. Schedule regular design reviews and check-ins with your product team. Regular design reviews give people space to share ideas and make decisions in real-time. More meetings up-front can also mean less surprises later. Use this valuable time to your advantage by setting a clear agenda, moderating the meeting, delegating work, and following up with next steps.

💡Tips for running effective meetings

1. Invite carefully. Invite only who needs or wants to be there. Don’t keep someone if they’re not needed the whole time. A meeting where folks are not actively participating is not fun.
2. Set an agenda and goals. Start each meeting by recapping the agenda and what you hope to accomplish by the end.
3. Take notes during the meeting. Doing this means you have the most complete knowledge of the meeting and are best equipped to guide its outcomes.
4. If the meeting veers down a rabbit hole, firmly guide it back. Saying, “Let’s revisit this later” or “let’s move on” is usually all you need.
5. Set aside at least 10 minutes at the end to talk about next steps and roles. If there were open questions during the meeting (remember that rabbit hole from earlier?), make sure someone is assigned to resolve it.
6. Follow-up in writing after the meeting with next steps, roles, and timeline. People leave meetings and forget things or remember them differently. This protects your project from that, plus it never hurts to reinforce that people are on the same page.

At Stack Overflow, product designers are ultimately responsible for the design that ends up in the browser. For some designers that means handing off a detailed design spec, for others it means pushing code directly. Regardless of your direct involvement in code, take an active role in working alongside engineering to implement designs as envisioned.

💡Tips for working with engineering

1. Lead the communication. Pull engineers in early, talk about your design decisions, ask them for feedback. Speak their language and understand their concerns. A good design-dev relationship starts here.
2. Maintain documentation. Update functional specs with decisions and open questions after meetings and notable chat conversations. Update research summaries as interviews are conducted. Incomplete or outdated documentation can lead people to building the wrong things. Keep your designs and specs up-to-date so it continues to be a source of truth for your team.
3. Don’t forget the details. Remember things like variable states, interactions, validation styles, and microcopy. The more detail the better.
4. Understand HTML/CSS/JS, responsive design, and accessibility. Product designers don’t need to be expert coders, but some basic knowledge goes a long way in shipping a high quality product.
5. Be proactive in QAing designs. Help ensure a test plan exists and ask for access to development sites so you can proactively test features. If you find bugs and can’t fix them yourself (totally normal!), report the issues to your developer team.

You can increase your impact by ensuring that your work ties to product strategy and goals, following up on outcomes of your work, and listening to and sharing the needs of stakeholders and users. The tactics below are potential ways to do this, but this isn’t about a specific tactic or conversation. It’s about making a habit of connecting your work to the big picture, seeking out and sharing info throughout your week, and using this information to identify themes over time.

• Set up a recurring 1:1 with your PM. Dedicated time with your product lead means you’ll better understand the team’s direction. What ideas are they batting around, what questions are they struggling with?
• Join research sessions, or conduct exploratory research. This helps you understand the general tone and needs of users. Research sessions are packed with data, and often only a portion of that data is immediately usable. Capture the unused data in your brain!
• Check your metrics regularly (and if you don’t know already, find out where they are and how to interpret them!). Helps you check your assumptions, follow-up on projects you shipped, and keep track of the big picture.
• Keep up with the conversation on-the-ground (at Stack Overflow, that includes the Community Managers and Support team). Helps you follow-up on projects you shipped, and understand the general tone and needs of users.

Thanks for reading! To learn more about Stack Overflow’s design team, check out our blog. If you’d like to share your own insights about leading design on your team, please leave a comment or email me at donnachoi30@gmail.com.

Thanks to Ted Goas for contributions to this post.