One mistake a lot of organizations get drawn into is focusing on the organization’s requirements on a website. No, really.

It seems like a strange sentiment, because why else would you build a website or application? The problem is that when you circulate requirements for the website, people focus on their own jobs and what would best represent how they think about their job. What they often don’t do is focus on the organization’s goals.

Your goals and your requirements aren’t synonymous by any means. Requirements are often just a wishlist of features collected piecemeal by people who take a moment to think about what they might want a website to do before going back to their main job.

The problem is, unless you’re building a site for use by your employees, they aren’t really the users of the site. The people the organization is trying to reach are the ultimate users of the site, and its their requirements that should drive the features of your website or application, not yours.

Instead, you should start with a list of your goals generally as an organization, and then the goals you have for the website. Those goals are the ones that usually triggered the decision to invest in a site or application in the first place, such as increased engagement with volunteers, reaching out to a broader base of smaller donors that aren’t feasible by traditional means, or convincing a key demographic that they should support a policy.

The goals for the website should logically support one or more goals of the organization. Goals are the “why”, and requirements are often the “how.” The tricky part is that each person in your organization also has a job that supports your organization’s goals. (Well, they should, right?) The tricky part is that the requirements they have to do their job better don’t usually map very well to what the ultimate users of your site will need to support your organization’s goals. So simply collecting their requirements and turning them into an RFP is a recipe for a site that makes everybody internally satisfied, but goes over with a big thud with the people you’re trying to reach.

This is another reason it’s a good idea to approach web developers with problems rather than solutions. The problem you have is that you have goals and you need to use the web to help you meet them. It’s the web developer’s job to help you figure out how to do that. Your staff should certainly be involved, but they have jobs of their own and shouldn’t be specifying your website for you.

This approach can also prevent some political problems, as specific requirements related to jobs can be conflicting, and wish lists are inevitably larger than budgets. Getting everybody’s input on goals and feedback on proposed solutions is easier than dealing with hurt feelings when a cherished feature doesn’t make the cut.

There are several techniques for getting to the heart of what users need, and they get to the heart of better ways to work with web developers. But by remembering the end users are the ones who hold the key to getting the right requirements for your site, you’ll set yourself up for success, and potentially avoid some internal conflicts.