Rebuild or Refresh Your Website: How About Neither?

The big question: Is it time to rebuild your site or can you do with a refresh?

Answer: Maybe neither. Maybe you’re asking the wrong question.

As I’m breaking down my experience at NTEN’s, Nonprofit Technology Conference last week, I’m recalling a lot of the conversations that I had, which were often centered around that seemingly big question. The notion looms exceedingly large in the nonprofit world, as who has that five, maybe six figure, budget to redo their site? Or more daunting: who has the time? Because in addition to being in charge of the organization’s site, you also coordinate the entire marketing effort, and you plan events too.

So the drip, drip, drip of your slightly broken, out-of-date, not-quite-meeting-your-needs website is constantly in your ear, like a leaky pipe somewhere in your wall that you can hear clearly when everything else is quiet, and you know is going to be harder to find than it will even be to repair. And it’s going to cost a lot. So let’s just let it keep dripping and we’ll deal with it when we have enough saved - or when it becomes a real emergency.

But like your website, you’re going to have to fix that pipe eventually. You can’t do without it.

Your Website: A Tool, Not a Product

Much like pipes are just a tool to bring fresh water to your home, your website is a tool allow you to interact in some way with your constituency.

So, it might not be the technology of your website that’s stuck in the past - it could be that your organizational thinking about what a website is, is stuck there as well. The idea that a website is a product in itself is a natural outgrowth of the “brochureware” era, where sites were just an extension of other printed marketing materials.

Marketing is still a very important part of what a website can do - but it’s very likely that either through passive analytics, or more dynamic user interactions, your website is engaging your key constituents in ways that go beyond the one-way transfer of static information. Chances are - if you are like most nonprofits - a part of your website, or some web tool you have created, helps you to carry out an aspect of your mission.

But (except in some rare circumstances) the website itself isn’t the mission - and that’s an important distinction. Whether it’s addressing hunger and poverty, building sustainable community infrastructures, preserving natural resources, or helping LGBT teens feel like they are not alone, your stakeholders support your organization not because you have a high-quality website, but because you provide a high-quality response to the issue(s) you serve.

So why do we treat websites like an end product? Why do we ever say “We need to redo our website?” Would we ever say that we need to “redo” our development department? Or our volunteer program? Rather we should say, “Let’s adapt our website, learning from our successes and recovering from our failures.”

Neither Rebuild nor Refresh

I get that twitchy feeling when I encounter organizations sitting on a horribly broken web experience because they are “saving up” for a website overhaul. They know it’s broken, but they also know they don’t have the money or bandwidth to deal with it. Rather than using that time to think about what they could be doing on the web, they spend it making excuses for their outdated website. I can say that bluntly because, well… been there, done that.

So just like that leaky pipe: yeah, it would be great to have all new copper pipe throughout the house. That would keep you happy for years. But in the meantime, let’s fix that leak. There’s probably a simpler solution to your web problem and it’s probably cheaper than a rebuild.

But what about a “refresh,” you say? A new theme… a better branded experience. I’m not a fan of that either. In most cases it’s a cop out to uncovering the real problem. Not that there’s any problem with a prettier website or a fancier UI - but a pretty broken web experience is still just a broken experience.

The alternative answer to a rebuild or refresh could be something like a new section to your existing site - a place where you can experiment with new design or new content. I’ve seen cases where a small static site with three pages is a good first step to rethinking an organization’s web presence.

It starts by thinking small and lean.

Do a Lean Discovery

We’ve gotten in the habit of doing a “lean discovery” to start a project - and it’s particularly useful in the case where you might be teetering on the edge of rebuild or refresh. It’s not quite a full-blown discovery with lots of stakeholder meetings and research; there’s a built-in assumption that the team we are working with has a pretty good idea about the demographic they serve and what their current web presence does and doesn’t do (this is almost always the case with established nonprofits).

From our perspective, we “time box” these discoveries at about 20 hours, which keeps things affordable for clients, forcing us to limit the scope and keep things simple (this has benefits down the road too, as we don’t discover too many things to do). The result is a targeted list of improvements (with well-defined costs) for the site.

To do a “lean discovery,” we have three requirements:

1. It seeks to achieve a business goal. That’s right, “business.” Nonprofits have business goals too and they’re often more efficient in achieving them than for-profit businesses. And before we get started too quickly, “Driving more users to my site” is not a business goal. It should be simple, like: “I want to capture more signups to my mailing list” or “I want to increase the number of available volunteers” or “I want to decrease the number of errors that our social workers make when entering data about their encounters.” If the business goals are well defined, you may have room to cover two or three in a single discovery.

2. The goals are framed in human-centered terms. Just like your organization, a web project should motivate “people” not “users.” While Human-Centered Design is a whole other topic, it’s important to note that we deal in personas rather than user roles. We can work a lot better to motivate a “recent retiree looking to fill free time” than “an anonymous user who lands on the volunteer page.” Roles are fine in technical terms - we need to know who gets permission and access to what; but they don’t tell us much in terms of why someone comes to or uses your site and what they hope to achieve. You can learn more about personas from Alan Cooper’s prolific work on interaction design.

3. The goals must be testable This really follows from the previous two, but we need some way to know that we’ve achieved positive results. If we met our goals, we can then look for ways to replicate our success elsewhere. We may even be able to demonstrate to stakeholders that we are on the right track and that with just a little more budget we can do even more. If we didn’t meet our goals, we can correct course or even abandon ship before we’ve spent too much of our precious resources.

“We just went through a redesign and we just didn’t get what we wanted.” Those words echoed through the halls at NTC (and every place nonprofits gather). It’s the sign of a broken process, and an avoidable one if we shift the way we think about our websites. But it’s also a recoverable scenario, and possibly an opportunity to rethink the way we rebuild or refresh our sites.