Note: This is the first in a series of posts about the Nonprofit Web Design Process. See the end of this post for a linked index of other posts in the series.
No matter how big or small the design project, Stakeholder Discovery is always the first step. Sometimes it’s a quick, half-hour phone call and other times it’s a two day on-site visit. The key purposes of Stakeholder Discovery are, in priority order:
- To align the entire project team around goals for the project
- To give each stakeholder a chance to communicate their own, specific needs or wishes
- To transfer information from the client team to the design team
Now, if your nonprofit designs something in-house, purpose #3 is null and void. It’s still of utmost value though to get all of your stakeholders in a room to articulate what you’re trying to do and to build consensus across the team.
I always let the client inform how we structure the Stakeholder Discovery. They will always know best whether we should have one group or multiple groups and who will make most sense in a room together. Generally, I like to start by meeting with the core project team and then follow that meeting with more focused discussions that allow subject-matter experts to talk about their specific input.
Early in my career, I would show up for Stakeholder Discovery armed with a battalion of questions, meticulously arranged by topic. Questions like:
- What are the key values driving your organization’s mission?
- What specific actions would you like your users to take when visiting your site?
- What is the one key message you would like your target audience to take away from the site?
- How do most people find out about your current web site? What methods of promoting your site already exist?
- What content is most important on your current site right now?
- What metrics will demonstrate a successful project?
Over the years, I’ve found it works better for me to have a broad list of topics to cover instead of specific questions. This approach allows the stakeholders to really drive the discussion and it tends to flow more smoothly this way. With the questions, I often found myself diverting a great conversation just to make sure I had all of my spaces filled in. For most projects, my topics list will include:
- Goals for the Project
- Key Messages to Convey
- Target Audiences and what we know about them
- Key Content for the site, including new content
- Marketing plans for the site
- Branding and design assets
- Landscape/Other websites you like
- Success metrics for the Project
This list will vary depending on what we’re designing, of course, but it’s a good baseline to start from.
Tips for leading the Discussion
Guiding the discussion through these topics requires authority. When the discussion starts to wander into unrelated topics or things start to get “in the weeds”, the person leading the discussion needs to be able to speak up to keep things on track. I often lead Stakeholder Discovery remotely and when that’s the case, it’s important to have a loud speakerphone so the participants can hear me interrupt!
You also want to respect your participants’ time. Create an agenda that dedicates certain amounts of time to each section to help you gauge when it’s time to move to the next topic. Don’t be afraid to schedule follow-up discussions to dive deeper into topics that may be of interest to some folks in the room but not to everyone.
Finally, take good notes. If possible, you may want to assign a scribe that is not leading the discussion to take notes so the leader can focus on asking follow-up questions and keeping conversation flowing.
After the Stakeholder Discovery, it’s important to provide a summary of what you learn to make sure you’ve captured everything and to help solidify the consensus building across all stakeholders. I tend to use PowerPoint to do this since quick, concise slides are more likely to be read and referenced throughout the project than a long, narrative summary. I also find that creating slides forces me to synthesize what I learned into really tangible direction for the next steps of the project.
Once this step is complete, it’s on to User Research. Based on what I learn during Stakeholder Discovery, I identify what knowledge gaps we have to recommend the best mix of User Research activities. Stay tuned for my next post to learn about using Analytics data as a form of User Research.
Other Posts in this Series
- Stakeholder Discovery [this post]
- User Research
- Surveys and Interviews
- Card Sorts
- Usability Tests
- Content Strategy
- Information Architecture
- Visual Design
- Solution Design