TechSoup.org The place for nonprofits, charities, and libraries

A Cooperative Approach to Web Design

Key considerations for designing your organization's website

A Cooperative Approach to Web Design 
Elliot Harmon - April 26, 2011
You can build a great-looking, professional website for your nonprofit without breaking the bank or being an expert.You just need to take the time to consider a few key questions.

This article, written by former TechSoup staff writer Elliot Harmon, is a chapter taken from Nonprofit Management 101: A Complete and Practical Guide for Leaders and Professionals, a book edited by Darian Rodriguez Heyman and published by Jossey-Bass (a Wiley Imprint) in May 2011. For more information, visit www.Nonprofits101.org, the companion resource center for the book. To read more about the nuts and bolts of web development, see the companion article How Websites Work.

Introduction

You've probably heard that creating a website doesn't have to be hard. Actually, it can be very hard, but with a few tips and techniques the process can be fairly straightforward and, in fact, enlightening. You can build a nice-looking, professional website for your nonprofit without breaking the bank or being an expert, but only if you take the time to consider a few key questions.

What's your nonprofit's story? In less than fifty words, what's your message? What are you asking your website's visitors to do? For some organizations, building a website may present the first time you answer these questions, and it may require intense discussions about your audience and goals. If your site lacks a clear call to action, then it doesn't matter how pretty it is: it brands your organization as confused and disarrayed; on the other hand, if your website's message is clear, direct, and actionable, then even the most technically crude site can engage with visitors in a meaningful way.

If you're thinking of creating a new website for your nonprofit, you're probably asking who can help you design it and what it will cost. Those are great questions to ask, but the answers will vary depending on the website's purpose. Let's start, then, not with the how of building a website, but with the why.

Critical Skills and Competencies

Before hiring a designer, spend a month or two assembling key stakeholders from inside and outside your organization, discussing the needs of the website with them, putting together a loose outline of the website, and establishing measurable goals: this will inform your request for proposal (RFP) and guide your initial discussions with a designer. Depending on the complexity of the site, actual site development might range from a few weeks to several months. Upon completion, it's key to budget time for training your staff in using and updating the site. Finally, you'll need to schedule updates on at least a quarterly basis. In this chapter, we'll go over each of these steps in more detail.

What's Your Website's Purpose?

In the 1990s and early 2000s, a friend of mine who was working as a web design consultant used to joke that her job was the world's easiest con. All you have to do, she told me, is type up the organization's contact info and pick a background color to match the letterhead. Those days are long gone. Today, your nonprofit's website must increasingly be more than a token presence: the most successful nonprofits are those whose websites are closely aligned with their goals, missions, programs, and metrics.

Why are you designing or redesigning your nonprofit's site? Who is the intended audience? Potential donors? Current donors? Volunteers or evangelists for your organization's cause? People who could benefit from your services? It's tempting to answer, "Everyone," but is that accurate? As most nonprofit websites barely appeal to anyone, one that appeals to everyone is a tall order. Even if the answer is everyone, the way that different segments of everyone interact with your website will vary a lot, and identifying the most important audiences of your website must drive your efforts. The more specific your understanding of how users will interact with your site, the better.

In talking about how nonprofits' websites can shape their relationships with their constituents, I often find myself referring to two corporate websites: Apple and Mighty Putty (see Figure 1). Both sites were designed with the same purpose — to sell a product — and they're both very successful. The difference is not in the desired action, but in the time investment put toward that action. One site tries to sell you a product the moment you visit; the other presents you with dozens of ways to get involved, learn more, and develop brand loyalty — all eventually pointing to a sale. The funny thing is that at least in the nonprofit world, it's a lot harder to be a Mighty Putty than an Apple.

Mighty Putty and Apple Website Images
Figure 1

Some nonprofits try to be Mighty Putties, but most of them fail at it. Political strategy architect Anne Keenan describes her experience with a political advocacy site. Presented with a large donate button moments after signing up for a mailing list, "All of a sudden we'd skipped from flirting to something a little more intimate, and I felt icky and strangely violated."

George Weiner of DoSomething.org encourages nonprofits to think of their websites as relationship-building vehicles, not fundraising ones: "Most non-Vegas marriages don't happen on the first date, it starts with a reasonable ask and comes after a relationship has been developed. Having a donate button is fine, but donating as your primary or only call-to-action is not a reasonable ask to the vast majority of your traffic." Weiner goes on to suggest ways to court your website's visitors before popping the question: put an inspiring story on your homepage, ask for newsletter signups, and recruit people to volunteer or spread your message.

Can your website spread awareness of your cause directly? If your nonprofit educates people, can your website help you educate more people? If you advocate for changes in the community, can your website strengthen that advocacy? Can your website empower people to evangelize for your cause more effectively? Of course, none of this is to say that your website shouldn't accept online donations. It's only to say that for most nonprofits, donations shouldn't be the primary venue for visitors to interact with your site. Your website should have a donate button, but your website shouldn't be a donate button.

Setting and Measuring Goals

Don't set vague goals for your website. You must be able to clearly articulate the site's objectives in order to put good metrics in place for evaluating its success. If the goal is to increase awareness of your nonprofit, ask yourself among whom you want to raise awareness. Ask what that audience will do when its awareness of your nonprofit has risen, and what metrics you can use to measure those actions. Ask what time frame you'd like to see this change happen in. Ask whether the website will have a different goal in two years from what it has now.

Web designers usually start with the desired outcome of a visit and work backward from there (in web analytics terminology, these desired actions are referred to as "conversions"). Donations may be one of the conversions that you measure, but they shouldn't be the only one. You should also measure newsletter signups, visitors signing up for a service that you provide, and people finding important information on your site.

Many designers work under the premise that users should never be more than one click away from the desired outcome; in other words, no matter what page a visitor is looking at, there should be a prominent link that the user can click in order to perform the desired response. That's because user tests show that each time users are asked to click to another page, a portion of them will leave the site out of boredom or confusion.

The goals for your website should be tied to the goals for the rest of your organization. A good web designer can show you how to measure the percentage of people who click on a link in your email newsletter, for example, or the number of people who seek out more information on your site because of a direct-mail campaign.

Identifying the Stakeholders

Later in the chapter, we'll review tips for working with a designer — be it someone on your staff, a volunteer, or a consultant. Regardless of whether your designer is on staff or not, you'll need someone to act as project manager. If that's you, you'll need a beginner's understanding of web design and development (there are some resources at the end of this chapter to help you get up to speed). If you're delegating someone to be the point person, it should be someone who has some knowledge of the field, as well as the ability to collate the needs of various stakeholders, internal and external.

Well before bringing a designer into the mix, identify the key stakeholders for the project and establish regular communications with them. Which members of your staff should be consulted? That depends a lot on the goals for your site, which we'll discuss in a minute, but it's good to cast a wide net, particularly in the planning stages.

Outside of your primary team, there's a broader group of core users. Remember that your employees aren't the only stakeholders; that's why the core user group should also include key volunteers, evangelists, and allies in the sector. These people feel strongly about your organization and its image: you'll likely be surprised by their perspective on how they talk about your organization and what they need from your website.

How do you maintain communication with this group? Answer: With whatever tools the group is comfortable using. There are numerous online collaboration tools on the market — many of them free to nonprofits — but it doesn't matter how cool your tool is if no one uses it. If some of the stakeholders won't use Basecamp no matter how many times you explain it to them, use email.

Throughout the web design process, conduct meetings once or twice a month to keep your primary team informed, make sure that outstanding issues are being addressed, and discuss any questions that are arising. The larger core users group won't need that many face-to-face meetings, but if possible, there should be one early in the process for generating user stories (see the next section) and another to familiarize them with the site before it goes public. Different types of stakeholders might have wildly different ideas about the website's purposes and audiences, but with some creative brainstorming, you should be able to identify the recurring themes and the most important user stories.

Conceptualizing Your Website

The bridge between the goals you've established for your site and the site design itself comes in the form of user stories, sketches of how and why users will interact with the website and the appropriate results of those interactions. If your organization already has a website, many of your user stories may come from how users currently interact with your site and whether they're getting the information they need. Questions that your organization frequently gets are another source, as well as discussions you have with your stakeholders.

User stories don't need to be complicated; they're just short, specific examples of how people should get the information or services they need from your site. Here are some examples:

  • Adam learns about our nonprofit by word-of-mouth and finds our site through a Google search. He reads the story of our nonprofit, watches a testimonial video, and signs up for our mailing list.
  • Bonnie visits our site to respond to a fundraising letter. She chooses from three donation levels and donates with a credit card.
  • Carl notices an interruption in services provided by the organization. He visits the site and immediately finds an updated service schedule and contact information.

With your goals and user stories in hand, you can start to draft the information architecture, a simple outline of what content will appear on the website and how it will be arranged. Here's a minimal example, though your own may not be much more complicated than this:

  • Homepage
  • About Us
    • Our Story
    • Mission
    • Programs
    • Board
  • Events and Services
    • Calendar
  • News
    • Board Meeting Minutes
    • Blog
  • Contact Us
  • Donate

Assemble your core team and engage them in the process of answering these key questions:

  • Does the information architecture reflect the most important user stories?
  • Will new content or sections need to be added in the future?
  • Who will create the content for each section?

Referring back to your user stories and information architecture, put together a wireframe, a visual representation of the elements of your website. The wireframe can be a Microsoft Word document, an Illustrator graphic, or even a pencil drawing. The wireframe isn't really a literal instruction for the designer; it's more of a visual aid to use in your discussions with both designers and stakeholders (see Figure 2). It's a way to think about key user stories and how site design will guide users to appropriate actions.

Website wireframe
Figure 2

The wireframe presents the same components as the information architecture, but arranged visually. The wireframe will become the skeleton of your nonprofit's website.

Web Content Management Systems

A web content management system (Web CMS, or just CMS) is a piece of software installed on a web server that delivers many types of information in a consistent design. CMSes are designed to integrate disparate features like blogs, forums, and wikis into a seamless user experience and enable easy site updates.

Most CMSes have browser interfaces: that means there's no need to install web editing software on every computer you'll use to update the site; you can add or edit content directly from any web browser. Most modern CMSes include a WYSIWYG (what you see is what you get) editor, meaning that you can format text and add links without getting your hands dirty in HTML code.

When you enter content into your CMS interface, the CMS translates that content into code to be interpreted by the end user's web browser. As such, CMSes enable you to keep your site up to date without employing a professional designer on an ongoing basis. A CMS uses instructions received via an online editing interface to automatically create HTML and CSS code, which is then interpreted by a visitor's web browser as viewable content (see Figure 3).

CMS Workflow Diagram
Figure 3

Most experts would recommend that you use a CMS for all but the very simplest of websites. There are numerous "open source" and proprietary CMSes on the market. Open source CMSes are usually free, and maintained by a community of users rather than a single software company. Proprietary CMSes usually cost money, but that price may include support or other perks.

Open source CMSes are more flexible than their proprietary counterparts and less reliant on the livelihood of software companies and service providers. Also, it's generally easier to migrate content from one open source CMS to another than between proprietary systems. There are a few open source CMSes to choose from that are thoroughly used and well-supported in the nonprofit community. Idealware has put together an authoritative guide to the big four open source CMSes: Drupal, Joomla, Plone, and Wordpress. You can find the URL for downloading the guide at the end of this chapter.

Of course, no one solution is right for every organization. Putting my personal preference aside, I'd encourage you to understand what you're paying for when you use a commercial system. If you choose to go with a proprietary CMS, it should be because it offers functionality that you need or vital compatibility with your existing systems, not because of a sales pitch.

Working with a Designer

You may have access to a volunteer who can help you build your new website for free, but before you go too far down that path, make sure that that person is qualified to design a serious nonprofit website. Have him show you examples of work he's done, share your plans for your new site with him, and ask him what technologies he'd use. If you're working with a volunteer, that doesn't mean that you shouldn't check references.

Some consultants — particularly those sympathetic to your nonprofit's mission and message — will offer a clean, professional, basic website for around $1,500 to $2,500; many will quote prices between $2,000 and $10,000. This is not to say that you shouldn't pay outside of that range, but if you do, be sure you know what you're paying for. If you're paying for custom coding or integration with existing systems, you can expect a higher price; otherwise, you may be paying more for a designer's reputation and ego than for the service provided.

Your first and most effective source for finding potential designers to work with is referrals from nonprofit colleagues. Ask your contacts who designed their website, especially if it's in line with what you're looking for. Ask for referrals on NTEN's online community. Be sure to solicit proposals from at least two or three vendors before you make a commitment. There's a wealth of great information on the Internet about putting together a request for proposals (RFPs) for a web design project; I've compiled some good places to start at the end of this chapter.

Regardless of who you're working with, be sure that training is included in your plans (if a consultant's proposal doesn't include training, that's a bad sign). The designer should educate you and your staff on updating content and customizing the site's design; in fact, the people who'll be updating content regularly should add the initial content to the site. It's good practice, plus it'll save you on consulting fees.

Collaboration or Paint-by-Number?

Some nonprofits think of web design as a paint-by-number process, in which the ED or another decision maker creates a list of needs for the website, hands the list to a designer, and approves the final site eight weeks later. The problem with that mentality is that if you don't play an active role in site development, there's no way to be sure the finished website will work the way you imagined it; conversely, even if what you're imagining is possible, an experienced designer may be able to help you find a more elegant alternative that achieves the same goal.

That's why I suggest what I call a cooperative approach. Work with a designer with whom you're comfortable collaborating and sharing ideas back and forth. Think of conceptualizing the site and designing it not as two distinct steps in a web design project, but as intertwined processes that can learn from and inform each other. You may be working with a communications department, a consultant, or a volunteer; perhaps you'll design the site yourself. Whatever the case, a cooperative approach will ensure that the website's design and content work together toward serving your greater goals. Through iterative improvements and regular check-ins, you can work with the designer to build a site that reflects the best of all of your skills.

Bring your user stories, information architecture, and wireframes to your first meeting with the designer. Talk about your goals for the site and what you've identified as the key user actions. Remember that nothing is set in stone; be open to the designer's ideas. Combining your knowledge of your audience and mission with her design experience, you should be able to work together on a great website.

Case Study: When Impressive Doesn't Work

My friend Molly is the manager of marketing and communications for the East Bay Music Collective (EBMC), a small nonprofit opera company in the San Francisco Bay Area. EBMC has been struggling with its website for years, and it's all because seven years ago, the organization was wowed by a nice-looking design.

In early 2003, EBMC's executive director was looking to build a website to advertise the company's 2003–2004 season, and she wanted to help brand EBMC as a slick, sexy company with a site as shiny and impressive as those of major movie studios or clothing companies. Using Craigslist.org, she managed to find a young designer in art school willing to build the site for free.

And sure enough, the website was gorgeous. The volunteer had built the entire site in Adobe Flash, complete with rolling menu items and animations. The site offered music samples from each opera in the season and videos of rehearsals. It was easy to buy tickets, easy to make a donation, and easy to invite your friends.

I sensed all was not well when it came time to advertise for auditions for the 2004–2005 season. Rather than incorporate the announcement into the fancy site, someone at EBMC had just moved all of the old content down a few lines to make room for a plain-text announcement. "We don't even own Flash," Molly told me. "We have had no idea how to add something to our page."

Emails were exchanged with the old volunteer, but he never quite followed through with making any updates. He was out of school and trying to make it as a professional Flash developer; EBMC was low on his list of priorities. Over the next four years, I watched with bemusement as the Flash site—still stuck in 2003—moved further and further down the page to make way for more and more announcements. Finally, the executive director accepted that there was no way to revive the old site. She put Molly in charge of the redesign project, and Molly found a Drupal developer in the Bay Area who, being an opera fan, was willing to create a simple site for about a thousand dollars; more importantly, he trained Molly and a few other staff members on how to update the site.

The new site's not only more functional than the old one; it's actually more attractive, too. As staff begin to post new updates and blog entries, the number of visits and conversions is slowly going up. Visitors recognize the new EBMC site as reflective of an actual, small organization they can engage with, not the entertainment empire its old site pretended to represent.

Web Design Dos and Don'ts

  • DON'T hire a colleague's kid to design your site because he helped you download "Battlestar Galactica."
  • DO check references (even for volunteers), especially previous nonprofit clients.
  • DON'T clutter your homepage with too many links and choices.
  • DO present a clear message with clear calls to action, not a watered-down compromise among several different messages.
  • DON'T spend extra money on proprietary systems and custom code if it's not crucial to your site's needs.
  • DO include training in your design contract, and make sure you've allocated appropriate staff time to maintain the site.
  • DON'T create a website that conceals your organization's size, staff, or personality.
  • DO publish a staff list, real contact information, board meeting minutes, and your IRS Form 990s.
  • DON'T forget about your website once it's up — schedule regular updates.
  • DO plan to revisit and update at least once a quarter. Measure your website's performance against its goals and make adjustments as necessary.

Conclusion

Your nonprofit's website is your first line of interaction with many people; as such, its primary job is to be an inviting place that draws people in and connects them to your cause and organization. The best way to ensure that's the case when designing a website is to define clear goals for your site, conceptualize a site based on how real users will interact with it, and measure your site's performance.

At every step of the way, there are temptations to stray from your goals — to make a site that's pretty but not functional, to make a site that your staff can't update, to buy custom code that you won't be able to maintain. Keep your focus on the user: your site is an opportunity to engage, not an opportunity to advertise.

Web Design Resources

What Should a Website Cost?
In this excellent webinar recording, Allen Gunn walks viewers through scoping and planning a website, writing an RFP, identifying key needs and stakeholders, working with consultants, and ongoing maintenance.

How to Write a Website RFP
In this recorded session from the Nonprofit Technology Conference, Community IT Innovators staff members walk you through the process of writing an RFP, finding designers, and negotiating a contract.

Comparing Open Source Content Management System
This free Idealware guide offers best practices for using a CMS; compares the key features of Wordpress, Joomla, Drupal, and Plone; and lists consultants and firms working with each system (access requires an email signup).

OpenSourceCMS
This site lets you play with pre-installed CMSes to see what they look like from an administrator's perspective.

Will You Marry Me? What Not-for-Profits Get Wrong on the Web
DoSomething.org Chief Technical Officer George Weiner explains what he thinks is wrong with most nonprofit websites.

Tips for Designing (or Redesigning) a Nonprofit Website
This article outlines key questions to ask and key stakeholders to involve when designing a website.

A Nonprofit's Guide to Building Simple, Low-Cost Website
In this chapter, I've focused primarily on CMS-based sites; this article offers great tips and resources for developing non-CMS sites.

A Few Good Web Analytics Tools
Learn what tools to use for measuring your website's performance and what to measure.

W3Schools
An essential bookmark, this site offers dozens of HTML and CSS tutorials.

CauseWired
Tom Watson, New York: Wiley, 2008.
One-third how-to manual and two-thirds pep-talk, Tom Watson's book will get you excited about how nonprofits can use the Internet to connect and empower their audiences.

All these resources, plus nonprofit management tips of the week and more, can be found at NonprofitWizard.org.

Image: Designing, Shutterstock