Understanding an organization’s needs is one of the most exciting parts of technology consulting. Unfortunately, it’s also be one of the most challenging parts of technology consulting!
In my work designing and developing websites for nonprofits in Seattle, I’ve spent countless meetings, emails, and phone calls ascertaining the website needs of my clients. Oftentimes, those needs don’t always align with the website features they say they want.
The lessons I’ve learned the hard way can help your organization avoid the mistakes I’ve made and make technology decisions that support your mission.
What Do You Really Need?
A few years ago, a conference talk introduced me to the ideas of Richard Saul Wurman, an architect who helped start the field of “information architecture.” In his book, The Nature of Recreation, Wurman wrote:
A common obstacle to understanding and communicating our needs, and to realizing solutions to them, is our habit of asking for a specific product we have used or seen (even if it has been a failure) rather than analyzing our need.
When building a nonprofit website, a “need” is the reason an organization has for building a website; a “product” (or “solution”) is the feature or design that best addresses that need. I frequently find that my client or me skips to selecting solutions—like an event registration form, infographic, or interactive map—before sufficiently assessing the need that the project is intended to solve.
“Mobility, Not Highways”
Wurman was kind enough to create a fable that illustrates this idea. The fable is set in a town which has many needs that they are struggling to meet because they jump to solutions:
“The issue was learning, not schools.
“The issue was safety, not the number of police.
“Mobility, not highways.”
The town’s ideal mobility solution might be walking, rail, or hovercraft(!), but if highways are the only mobility solution you know, it’s easy to short-sightedly build more of them. (This sounds awfully familiar to anyone who’s been in Seattle for the past few years…)
If I were to rewrite this fable about nonprofit websites, it might go like this: The issue was fundraising, not the size of the donate button. The issue was capacity, not content calendars. User engagement, not slideshows.
If we always jump to solving problems in familiar and comfortable ways, we may—to use another metaphor—try to jam a square website into a round series of tubes!
User Engagement, Not Slideshows
An extremely common request for nonprofit websites is to have a big slideshow at the top of the home page. You probably see the problem by now: The request is for a solution before identifying a need!
Slideshows, or “sliders,” are almost never a good solution for nonprofit websites. Even when they are technically sound—which is quite rare—the primary “need” they often address is an organizational one: giving everyone space on the homepage. Does that help the user? Is that really a need you want to invest in and prioritize over others?
Identifying needs is a crucial task when making honest and sound technology decisions for your organization. Without doing so, you may find yourself investing staff time and precious resources on solutions that don’t help you achieve your mission.
To Avoid Problems, Don’t Start With “Y.” Start With “why?”
When someone tells me they want a slideshow on their homepage, I always ask, “Why do you need that?” With that question, I’m trying to avoid the “XY Problem” from tech support:
“You’re trying to do X, and you thought of solution Y. So you’re asking about solution Y, without even mentioning X. The problem is, there might be a better solution, but we can’t know that unless you describe what X is.”
This is awfully similar to Wurman’s warning to avoid “asking for a specific product we have used or seen…rather than analyzing our need.” The slideshow is the premature “Y” in the “XY.”
So I ask “why?” of my clients all the time to find the “X.” (Sorry clients! I ask it with love.)
Taken to the extreme, when starting on a new project, I like to ask people why they need a website at all! It’s not that I don’t think they do, but I want to start the conversation from a place where we’re discussing needs and not solutions; find the X, not the Y.
It’s About Working Together
Defining the needs and goals of your organization when starting a technology project will save time, reduce frustration, and vastly improve any project’s result.
When I’ve found myself debating the merits of two mutually-exclusive decisions—”We should have a red button!” “No, it should be maroon!”—I try to back up and remember why we’re talking to begin with. Does one color emphasize the brand better? Are users more likely to see a button if it’s a certain color? (And can we test that?) Is this just a matter of personal preference?
Three Tips to Improve Nonprofit Technology Project Collaboration
So here are three concrete ways you can improve the results of your next project:
- Always start new technology projects with a planning phase. Even if it’s informal, make sure to identify the organization’s needs that this project will address.
- Refer back to your goals when making decisions. Particularly if there’s disagreement, remind your team why this project is important for the organization and evaluate decisions with that in mind.
- Ask “why?” Any time someone suggests a particular idea or solution—especially early in a project—ask them to describe how that meets your organization’s needs.
Collaboration—especially on nonprofit technology projects—can’t be successful without identifying the needs of your organization. Identifying a need doesn’t guarantee that collaborators will immediately agree on how to solve the problem, but having that debate in terms of needs rather than solutions makes the discussion less contentious and the chances of finding a good solution much higher.