When to Say No to Website Feature Requests at Your Nonprofit

The request always sounds reasonable. "Can we add a chatbot?" "Could we put a carousel on the homepage?" "The programmes team wants a map of all our locations." "The fundraising team needs a pop-up for the year-end campaign." Each request, taken on its own, seems like a small addition. None of them come with a plan for maintenance, accessibility compliance, or how the feature serves the organisation's primary stakeholders.

This is the reality for most Communications Directors managing a nonprofit website. Every department treats the site as a surface for their priorities. Nobody frames their request in terms of stakeholder journeys, governance requirements, or the cumulative effect on site performance and usability. And the Communications Director, who bears the operational burden of every addition, rarely has a documented framework for assessing which requests to accept and which to decline.

The result is a website that grows in every direction, serves no audience clearly, and becomes harder to maintain with every feature added.

Why saying yes is easier than it should be

Saying yes to a feature request is politically safe. It keeps the requesting department happy. It avoids conflict. It demonstrates responsiveness. And in many organisations, the Communications Director does not have the formal authority to decline, only the informal expectation that they will make it work.

Saying no, or even "not yet," requires a rationale that goes beyond personal judgment. "I do not think we need that" is an opinion that can be overruled by anyone more senior. "That feature does not serve our three primary stakeholders and introduces an accessibility risk we are not resourced to manage" is a governance position that demands a substantive response.

The difference between a website that stays usable over time and one that collapses under accumulated features is not the quality of the technology. It is whether the person managing the site has a framework for making decisions that can withstand internal pressure.

The three questions that filter every request

Before any feature is approved, three questions should be answered. These are the same questions that inform a website governance policy, applied to individual decisions.

The first is: which of our primary stakeholders does this serve? If you have completed a stakeholder salience analysis, you know who your top three audiences are. A feature that serves a primary stakeholder group has a strong case. A feature that serves an internal preference, or a secondary audience, or no identified audience at all, does not.

The second is: who will maintain this after launch? Every feature has an ongoing cost. A chatbot needs someone monitoring the responses. A map needs updated location data. A carousel needs fresh content or it becomes stale. A pop-up needs A/B testing, scheduling, and removal after the campaign ends. If nobody is named as responsible for maintaining the feature, it will degrade. And degraded features damage credibility more than absent features, because they signal that the organisation starts things it does not finish.

The third is: what does this displace? A website has finite attention. Every new element on a page competes for the visitor's focus. A pop-up that obscures the donation button. A carousel that pushes the programmes section below the fold. A chatbot widget that covers the contact information on mobile. Every addition displaces something. The question is whether what is displaced is less important than what is added.

If a feature request cannot clearly answer all three questions, it should not be approved. Not because it is a bad idea, but because it has not been assessed against the criteria that determine whether the website serves its institutional purpose.

The features that cause the most damage

Certain feature requests appear across almost every nonprofit website project. They are popular because they feel modern, proactive, or comprehensive. They are harmful because they are rarely implemented well, almost never maintained, and frequently introduce accessibility or performance problems that nobody monitors.

Carousels and sliders are the most common. Research consistently shows that visitors interact with the first slide and ignore the rest. A study of the University of Notre Dame website found that only 1% of users clicked on the homepage carousel, and of those clicks, 84% were on the first slide alone. The Nielsen Norman Group's usability research has documented that auto-forwarding carousels cause banner blindness: users frequently failed to find information even when it was displayed as the first item in a carousel, because the format itself trained them to ignore it. Carousels create accessibility problems (auto-advancing content, insufficient pause controls, poor keyboard navigation) and give every department a slot on the homepage without requiring anyone to prioritise. They are a governance avoidance mechanism disguised as a design pattern.

Pop-ups and overlays interrupt the visitor's journey to deliver a message the organisation considers urgent. The visitor almost never agrees. One Search Engine Land case study documented an 18% jump in mobile bounce rates in the first week after a full-screen pop-up was added, with the site recovering only after switching to a small bottom banner. Google's intrusive interstitial penalty explicitly targets full-screen mobile pop-ups that block content on arrival, meaning they can also harm your search visibility. Pop-ups on donation pages are particularly damaging: they intercept someone who has already decided to give and introduce friction at the worst possible moment. If the message is important enough to interrupt a donor, it is important enough to be part of the page design, not an overlay.

Chat widgets and chatbots promise 24/7 engagement but require ongoing attention to deliver on that promise. An unmanned chatbot that gives wrong answers, or a chat widget that goes unanswered for days, is worse than no chat at all. It tells the visitor that the organisation offers a communication channel it does not actually staff.

Social media feeds embedded on the homepage age faster than any other content type. A Twitter feed showing a post from three months ago, or an Instagram grid that has not been updated since a staff member left, signals neglect. If the social media presence is active, link to it. Do not embed it.

How to say no constructively

Declining a feature request is not the same as dismissing the underlying need. The fundraising team asking for a pop-up has a legitimate goal: they want to increase donations during a campaign. The programmes team asking for a map has a legitimate need: they want beneficiaries to find services. The job is not to refuse the goal but to assess whether the proposed solution is the right one for the website and its stakeholders.

A constructive no sounds like: "The year-end campaign is a priority. Rather than a pop-up that interrupts the donor journey, let us update the homepage hero and add a dedicated campaign page with a clear donation call to action. That serves the same goal without the accessibility and conversion risks."

A constructive no sounds like: "Showing our locations is valuable for beneficiaries. Before we add an interactive map, let me check whether our contact form and programme pages already provide that information in a way that is accessible and maintainable. If they do not, that is the priority."

Every declined feature is an opportunity to redirect toward something that serves the same need without the governance, accessibility, or maintenance cost. The Communications Director who can do this consistently is the one whose website remains usable over years, not just weeks after launch.

Building the authority to make these decisions

None of this works without institutional authority. A Communications Director who can articulate why a feature should not be added but lacks the organisational backing to enforce that judgment will lose every argument to a more senior voice.

The website governance policy is what provides that authority. It documents who makes decisions about the website, on what basis, and how competing priorities are resolved. Without it, every feature request is a political negotiation. With it, every feature request is assessed against agreed criteria.

If your organisation does not have a governance policy, start by documenting the three questions above and getting them endorsed by the Executive Director. That is enough to shift from "I do not think we should" to "this does not meet our agreed criteria." The first is an opinion. The second is a governance position.

Question 1: How do I push back on a feature request from the Executive Director?

With evidence and alternatives. Show them what the feature would displace, what it would cost to maintain, and who would be responsible. Then offer a solution that achieves the same goal with less risk. Executive Directors respond to governance rationale, not design preference. "This creates an accessibility compliance risk" is harder to override than "I do not think it looks right."

Question 2: Our website has accumulated features over years. Where do we start removing things?

Start with anything that is broken, unmaintained, or serving no identified stakeholder. Dead social media embeds, expired campaign pop-ups, chatbots nobody monitors, carousels nobody updates. Remove these first, because they are causing active harm. Then review remaining features against the three questions: who does it serve, who maintains it, what does it displace?

Question 3: Is there a way to test whether a feature is actually needed before building it?

Yes. Before committing to a build, check your analytics for evidence of the need. If the programmes team wants a location map, look at whether visitors are searching for locations. If fundraising wants a pop-up, check whether the current donation page conversion rate is actually low. Data provides a basis for decisions that intuition does not. If no data exists, that is itself a finding: the request is based on assumption, not evidence.

If your website has accumulated features that nobody maintains, or if you need a framework for assessing what stays and what goes, a Blueprint Audit reviews every element of your site against stakeholder priorities and produces recommendations your team can act on.