We Need a New Web Site: Doing Your Redesign Right

We Need a New Web Site: Doing Your Redesign Right

I actually think I heard one (or both?) of these presenters at last year's NTEN--quite fortuitous since I only heard the very end of their session last year!

The Development Process: RFP
Identify stakeholders, conversations with stakeholders, and what do you really need? Out of that will come the RFP. Highlight different features/functions that are necessary in the RFP. 5-7 page document.

RFP Selection Process
If you go out of house (most nonprofits do): get a short list (5-7 firms) and get RFPs from 3-5. Request not just credentials but solutions to particular problems you want to solve. If you can tell vendors their budget, tell them, so that vendors aren't guessing what solutions are too expensive/too modest.

Discovery process: End goal is a statement of work. Set the breadth of the scope. You will have to revisit your RFP conversation... there will always be a key person who raised another issue, vendor will give you a better idea of what's possible, etc. etc. Set up a parking lot of items that are not a priority right now, but can revisit later; website is scalable and can be added. No design at this point; just paper.

Functional spec: Take breadth of that scope and go into the depth. The "What"--as in what is going to be built? Identifies audiences, personas; each piece of functionality. Then build wire frames and content inventory. Allows one to look at pages from content layout standpoint--no pictures, colors, graphic design, etc. Important to go through that before design, because design is emotional--won't pay attention to content.

Information Architecture: THE most important step in web design. Should not be skipped. Wireframes are NOT the sitemap. Wireframes are not hand-drawn. Break down flow of site and how people are going to go through it. Designers love wireframes because they don't have to think about the IA of the page, and know what IA the client expects.

Design
Now come the pretty pictures (and everyone has an opinion.) By far the most emotional and difficult phase. The people who said "I don't care about this" suddenly do. Keep the cooks in the kitchen to a small group. Come with good sites/elements from other sites you'd like to emulate.

Development
The longest phase of the project -- could be an equal amount of time to the planning phase. Client role is to be available during reviews, answer questions, and a little quality assurance.

Typical Timeline (these can overlap):
Integration 2-4 weeks
Content migration: 4-6 weeks
Custom development: 4-6 weeks
Quality assurance: 4-6 weeks
Stabilization: 2 months, and there WILL be bugs.

Now we're ready to manage the site... or, we think we are...

Support and management of site is at least as important. How does workflow work? Who repairs things when it breaks? Who manages what parts of the site? Work with vendor for ongoing support, care and feeding of website. Especially important with web 2.0 "stuff." Determining processes and producing content are equally important to the redesign.

Top 10 dirty little secrets of software vendors:
* Buying a CMS is still harder than buying your first house! There isn't even a uniform definition for CMS. Knowing how you use content will help you decide what solutions are best for you.
* Most CMS vendors don't help customers be good website managers.
* Most CRM, CMS, Hosting and web analytics implementations STILL go unsupported after launch.
* Open source solves the wrong problem -- everybody uses and installs open source because they think it's free. Who is going to support and maintain the solution will determine whether free and open source software is a good option. FOSS shouldn't be used if it's only to solve a budget issue (because FOSS costs money to implement and maintain.)
* Customers overpay for features that they'll never use, and rarely deliver the results they really need.
* Buying CMS to have a better website is like buying a mop to keep the kitchen clean. If you don't use it, and use it effectively, it's not going to improve the website.
* Implementation is easy; management is hard.
* Most organization have few, infrequent site management software users. Training is ongoing, and planning the training system is part of maintaining the site. Effective adoption/rollout is very important.
* Companies buy software based on ROI, but don't ever measure it.
* Content migration sucks. It will take you more time to automate the process (probably) than to manage the page. Worst part of the project, and it's hard, and anyone who tells you it's easy are lying.

Launch and Rollout
* Usability: beyond the software solutions and website. Whatever solutions you fit, the interfaces are appropriate for the audiences you want to reach (e.g. tech savvy vs. folks who aren't as familiar with tech.)
* Review, measure. Iterate. Web sites are a process, not an end game. Launch small iterative launches. Launch what you can effectively and well; your audience will tell you what they want. Measure the five or ten most important things to your organization and keep a dashboard.

Go for best of breed, not "all in one" solutions.

Budgets
Small: $10,000-50,000
Large: $50,000-100,000

Time is money. These projects take time.
Negotiate rates but hours are hours. Compare apples to apples.
$20/hr to $200/hr.

Erin's Note: This is all helpful information, but I'm finding a great deal of it a reiteration of the presentation I saw last year in DC. The description suggested to me that this might be a workshop for folks who had gone through the design process, and how one would know if they are just tweaking, or really required a real redesign.

The presenters here are spending a great deal of time saying that FOSS is not free, and one can spend as much money on proprietary licensing as on implementing FOSS. I have to say that this has not been our experience--the proprietary solution we used before was MUCH more expensive and more restrictive than our Drupal solution, even with a great deal of customized work, and while Drupal has limitations, it is more flexible than the solution we used before. This sentiment has already generated rumblings in the audience in the back of the room, and it will be interesting to see how this plays out in the Q/A and comments time.

I was a little disappointed in this presentation. The two takeways listed in the NTEN program--knowing when tweaking, instead of a complete redesign, is appropriate; and managing redesign implementation--were really not addressed. We heard about why managing redesign implementation was critically important to making a redesign successful, but we never went through how this would happen with the same kind of clarity and depth as the redesign process. Though the redesign checklist was thorough and excellent information, consistent with my own experience, it really dominated this session, and was almost the same presentation I remembered in DC last year.