- Video and Demos
- Sponsor Green Travel
- Get Involved: Green Action
- Frequently Asked Questions
- Website Development Tutorial + SpaceShare Contracting
- Preparation Basics
- Avoiding Problems, Nonprofit Client Perspective
- Should You Hire SpaceShare?
- Websites Developed by SpaceShare and Allies
- About Us
- Contact Us
- Vision & Plan
- People at SpaceShare
- Volunteer, Intern or Work at SpaceShare
- Our Logo & Tag-line
Following are some questions that I would recommend exploring *after* you do a very basic sketch of your website development plan. We can't answer these questions for you, but think that your answers will help both your planning process & and your web team, whether it is SpaceShare or someone else. If you are a website or developer who has encountered problems you think you could avoid next time, tell us what you'd do differently!
Executive Director's Watchlist
Areas where ED's should typically pay more, or less, attention.
Areas where ED's should typically pay more, or less, attention.
Project ManagementHow will the project be managed? Who is responsible to keep the project on schedule -- and do they have the power to do so? Does the contracted tech team have primary responsibility to manage the project, or the nonprofit client?
Do You Know What You Want To Say:
Content vs Web Design
Can you sketch significant content for your site, even if you're not artistic enough to design it? Do you have a good idea of the audience you want to reach, and the message you want to send? If you want web 2.0 can you loosely describe a couple imaginary conversations? Unless you are hiring a content developer as well as a web developer, you should have some of your content -- on paper is fine -- before you start getting techy.
It's often good to leave more of the tech aspects to the techies: create your wish list of experiences that you want your audience to have, and content that you want them to see. In my experience, many non-tech people faced with the task of designing a website spend far too much time on what they don't understand, but leave pieces that the techy can't help with poorly defined.
If you aren't in a position where you could sketch sample content for the brochure-like parts of your website, it's not time to bring in tech help.
Warning Sign: Do you not have sample content, but have a good idea of the details of color or design that you want the designer to implement?
Warning Sign: Look again at your favorite sites -- do they all have graphic elements related to their theme? Photos of their organization in action? Pictures of the fundraiser, of volunteers? Have you provided images of similar quality and greater quantity to your web developer?
Too early to hire a web developer: if you don't have a decent selection of photos and content (in any format), you should be hiring someone for content and photo development first, then discuss how to structure them into a website.
Cooks in the Kitchen
There is a big difference between having a clear description of your website for someone to develop vs asking the designer to brainstorm, discuss and create with you. Either way works.
Nonprofit as Lead-Cook
I'm your technology sous-chef: you'll develop a recipe, and I should chop up the vegetables and follow it.
Probably before you ever hire your web designer, you've already developed a project management approach. You know the design you want and the content you want. You might want tech advice, but you'll make the final decisions about user interfaces and take responsibility for it.
Lots of Cooks
Who is the "lead chef?" For Project-E, they had a number of design elements and category structures already developed and wanted me to build that out exactly as-is. Some of those elements didn't work well with each other or extend to a larger site, and if they had tried to come up with a complete design they would have realized it.
Double bonus disaster points for:
- having a committee each member of which is empowered to tell the design team contradictory specifics.
- you have a clear idea of web technicalities (your designer's key role), and a fuzzy idea of the content, audience or goals (your key role).
Developer as Lead-Cook
I'm the chef: you tell me what you like and don't like, and I'll develop the recipe, inviting your feedback as we go.
The developer will also handle project management. You hire a developer and then a range of people describe their wishes, and the developer describes a variety of ways these can be met, and you willing to listen to suggestions that some ideas might be harder to translate onto a browser.
Power Struggles in Web DesignOne of the paths to a failed website is to have members of your organization that don't have a single point of view use the web development process as an arena to struggle for priorities. It seems to be a common "method" of avoiding confrontation within organizations, decisions are never forced to a conclusion at a staff meeting.
What should be emphasized on the front page? It's all too common for a nonprofit not to have a single voice and make decisions or compromises internally. Leaving it to the web developer to balance out the relative power within your organization of different voices tends towards disaster.
Interacting with the Web Team
Have you told the web team how you'd like to interact with them? Or asked how they like to interact? Does your organization have a clear method of decision making?
Personally, I like to maintain checklists and timelines that we pass back and forth, editing as we work. Often I create an intranet section on the website visible only internally, so notes can be developed. This also creates a searchable record for future work on the site. For larger projects, this can be organized into a simple project management tool.
I've found many clients prefer a "throw it at you" approach, lots of small meetings or emails, where suggestions don't follow the previous conversations about a subject. This is survivable, it's not the end of the world, but it doesn't create as clear a track record, and perhaps more important, it makes it harder to keep focused... we lose some of the "why" from the brainstorm sessions. It's also not a good approach if you are busy (it's basically a form of procrastination), or on a tight budget.
Hiring Tech Help Too Early or Too LateIt's too early until you
- Figure out what you like, what you want, and who your audience is?
- Sketch out some of the components that might go on your homepage. Does your organization agree on priorities?
- Sketch out some of your static content.
- Have some idea of your priorities and budget constraints.
- How much of a Content Management System do you want? Who enters content, and how much tech experience do they need? How much do you trust everyone who can edit any part of your website?
- What functionality do you want: calendars, complex searches? Something that might be unique and require coding?
- Likely budget vs functionality.
Writing and answering an RFP is perhaps the most challenging aspect of designing a website, and unfortunately it comes first. If you don't want to talk to recommended designers one at a time to find one that you can work well with (certainly what I'd prefer, and the best way to function on a small budget), hire someone for a few hours to help narrow down your goals intelligently. It's too late if you already have
- Significant design elements and user interface locked in (particularly when you have design elements before discussing the audience you wish to reach).
- You can't find websites that are examples of what you are looking for.
- The web team will have multiple points of contact who are empowered to give instructions. It's very good to have many people involved in describing their needs or providing brainstorms -- but not web-specific instructions.
- If you've worked with a web designer in the past and things went wrong, can you explain the designer's perspective of why things fell apart? Asking a new designer to begin in the middle of a failed process and rescue the work rather than start with discussions about audience and goals.