The key to success for any large-scale Web site redesign is a process that works.
Four years ago, I put together a PowerPoint presentation on the Web design process for the Chico State home page. No one ever looked at it, but it's almost as useful today as it was then. With the benefit of four more years of experience, here's a revised version.
The Short Version (for the attention-impaired)
- Get the right high-level decision-making organization in place
- Assemble the Redesign Team
- Define High-level Redesign Goals
- Establish Scope, Timeline and Budget
- Establish Standards
- Do Your Homework
- Profile Site Users
- Develop & Test Information Architecture(s)
- Develop & Test Visual Designs
- Create and Test a "Protosite"
- Create and Implement Real Site
- Finish Documentation
- Go Live
- Plan for Maintenance
1. Get the right high-level decision-making organization in place
Before you can even begin considering doing a redesign of your home page, you need to have functional, authoritative structures in place for making decisions, and determining and enforcing standards. This should involve people at the highest level possible in order to ensure buy-in as the redesign progresses.
The role of high-level administration should strategic, not tactical, in nature. Their role should be in setting priorities, overall goals, and high-level messaging instead of micromanaging the design, information architecture, labeling, etc.
At Chico State, we have a brand new Web Governance committee, consisting of the CIO and vice presidents.
2. Assemble the Redesign Team
You can't actually conduct a redesign without competent people in responsible positions. Nor can you respond to questions posed by administration concerning the redesign without qualified people on staff.
A large scale redesign like a university Web site requires a number of roles (one person may fill several roles):
- Project Lead
- Technical Lead
- Graphic/Visual Designer
- Information Architect
- Interaction/Usability Designer
- HTML Coder
- Programmer
- Web Server Administrator
- Multimedia Developer
- Photographer
- Accessibility Designer
- Writer
- Content Manager/Editor
- Communications Specialist
- Quality Assurance
At Chico State, we have the design/technical/IA/usability people under two closely related roofs, but lack a close relationship with the Advancement folks.
3. Define High-level Redesign Goals
This step really needs to be a conversation between the administration and the redesign team. The administrators bring an awareness of the university's top priorities, goals, concerns and issues to the table, while the design team brings knowledge of technologies, standards, best practices, other university Web sites, as well as a lot of experience with the Web redesign process that administrators may lack.
A strictly top down approach is likely to result in a site neither well organized, well designed or usable. A bottom up approach is likely to result in a site that lacks focus and fails to meet the top priority needs of the campus.
Example goals might include:
- Create new, fresher, more “hip” look
- Implement strategic goals for university web presence
- Improve navigation/site structure
- Make site easier to use
- Address accessibility issues
- Attract more new students
- Fulfill university core objectives
- Improve site performance
- Make site easier to maintain/change
- Enhance university image/branding
- Increase design consistency across entire site
- Implement new technologies (e.g., WCMS)
The biggest danger in undertaking a project like redesigning a campus Web site is scope creep. Scope creep will kill any project and can permanently damage working relationships on campus. It must be avoided at all costs.
- Establish a clear list of what will and will not be done
- Clearly define personnel to be involved (including timebase and responsibilities)
- Establish clear milestones
- Plan for content lag
- Write a detailed production plan outlining major goals, strategy, resources & timeline
One thing that has saved Web Services from endless trouble and heartache over the years is the fact that we invested a lot of time early on in developing standards (everything from design standards to file naming standards to accessibility standards to labeling standards).
Before you get into do a redesign, you need to develop a comprehensive standards document and make sure that everyone sticks to it. Some standards to consider:
- Coding (XHTML, CSS, file naming, etc.)
- Accessibility
- Security
- Graphic design
- Communications (branding, brand usage)
- Labeling
- Content (writing guidelines, etc.)
You can't fix a problem if you don't know that there is a problem, and you still can't fix a problem you've identified if you don't know what your options are. So this step is two-fold:
- Analyze and test your existing site
- Educate yourself as to what other sites are doing
To better understand your existing site, you should:
- Examine log files for usage and patterns (Google Analytics is great for this)
- Do a page structure analysis
- Create a visual site map to better understand the site’s existing structure
- Conduct usability testing of existing site (to identify specific problems)
- Audit existing content
7. Profile Site Users
Real Web designers profile their site users; the rest of us are just posers. Profiling (in this case profiling is good) allows you to role play in a sense; to get inside the heads of your users and see your site from their perspective. This is vital for administrators and designers who have a radically different view of the campus Web site than a 17 year-old high school student looking for a place to go to college.
Some steps in profiling:
- Categorize users (currents students, faculty staff, alumni, etc.)
- What are their characteristics?
- Demographics
- Browser versions used
- Internet access (broadband/modem)
- Develop personas for testing/designing purposes
- 6-8 should be sufficient
- Why personas?
- They personalize the users you are designing for
- Helps you visualize how each persona might approach the site
- Used in testing scenarios (how would Davin the art student use this feature?)
Now we start to get to the meat of the process.
- Examine what other universities have done
- Develop taxonomies
- Do card sorting tests
- Conduct task analysis for common tasks that have poor task modeling on current site
- Develop site maps
- Develop and test wireframes
- Conduct user scenarios to keep IA on track
- Get feedback from administration on IA finalists
To most people, this phase is the only phase of a redesign. Certainly, it is the most visible.
- Develop design concepts
- Refine into designs (must follow wireframes)
- Insure that designs stick to the architecture
- Get feedback (e.g., focus groups)
- Get approval (powers that be must sign off on the design)
The purpose of testing a protosite is to give people a chance to use the site before it goes live. This allows you to work out a lot of bugs in design, IA and usability before subjecting it to the entire campus. Some universities do a public "beta" with the protosite in order to get a wider range of feedback. Protosites are easy to set up if you have a WCMS.
- Create skeleton site (ising proposed visual design, navigation & site structure)
- Multiple alternate designs can be tested
- Conduct usability testing with real users
- Refine design and structure based on results
This is the final dress rehearsal before going live and the last chance to tweak designs, templates and content. This is where the QA and testing really kicks in to find bugs and problems, make sure that all pages are accessible, make sure that all pages work with supported browsers, etc.
You might consider making this site available to users as well for testing and feedback. Using a tool like Google Analytics, you can get valuable information about how people are using the new site even before it officially goes live.
12. Finish Documentation
Haha! Documentation is never finished. Documentation should have started no later than step 4 (Establish Standards). We use a wiki for all of our documentation and I can't recommend that approach highly enough.
- Style Guide (fonts, colors, page dimensions, banners, etc.)
- Production Standards Guide (file naming conventions, code standards, CSS, etc.)
- Page Templates (can be in WCMS)
Finally. Couldn't we have just hired a student to do a new home page and left it at that?
- Freeze all design and content
- Complete QA testing
- Plan announcement strategy (vitally important! - people HATE surprises)
- Consider phased, or soft, launch
- Have a “What’s Changed” page
- Transfer to live server
- Party!
Actually, this should be done long before the site goes live. If you have a WCMS, maintenance will be part of that project's implementation plan.
- Get post-launch feedback from users
- Fix bugs, serious problems
- Determine who is responsible for maintaining what
- Train departmental editors (make them familiar with standards, and with maintaining site integrity)
No comments:
Post a Comment