Skip to content Skip to navigation

Website Redesign Checklist

Posted by: 
68
Post date: 
October 18, 2012
Topics: 
Web Development
Overview

This checklist is intended to help small departments assess their needs for website re-design and leverage as many Stanford and low-cost opportunities as possible.

The "Roles" section lists all of the potential roles in an ideal redesign. Some of these are areas of focus rather than actual job titles, but each could easily take up a great deal of time. With a small staff, some individuals will fulfill several roles, and some roles will be filled by outsiders.

The "Checklist" is provided in the rough order that one might approach these tasks. However, it is quite likely your own project will evolve into a different order, and many stages will involve iteration and overlap. The checklist is not exhaustive, and you should feel free to remove or change items.

Roles

Strategies for filling these roles include creating fictional personas, representatives who advocate for sets of stakeholders, reaching out to campus IT colleagues for evaluation and advice, and utilizing services provided by campus departments or groups. Roles that may be fulfilled by the same individual have been placed near each other.

  • Content creator
  • Content strategist
  • Project manager
  • Decision maker  - with authority
  • Internal stakeholders
  • Business needs analysis
  • Compliance (with internal rules or external regulations)
  • Designer (Aesthetics, GUI, UX)
  • Usability Testing
  • Accessibility
  • Quality Assurance testing
  • Information Architect
  • Developer / Programmer
  • SEO (Search Engine Optimization) and Analytics
Checklist
  1. Admit that you have a problem.
  • Consensus among stakeholders that re-design is necessary.
  • Identify and list biggest problems with current site by polling internal stakeholders.
    • Create a simple 10-item rating quiz for team members to apply to your site. Have them apply it to at least three comparable sites (competitors) on the web.
    • Can any be fixed in short order, before the re-design? Note that a re-design can take 6 months – 2 years.
  • Take the analytics from your current site and develop a 1-2 page summary of current site usage. Rank pages by traffic.
    • Attempt to identify any obvious results from the data and articulate what this could mean for your website redesign (for example, if you found that 90% of all your visitors are coming from indirect sources and landing on sub-pages, then this means that traffic to your homepage is a lot lower than you think. Do you need a new SEO strategy to increase direct traffic to your homepage? Or do you de-emphasize your homepage as far as priorities? Or do you work to get the content people are looking for visible on the homepage?)
  • Assemble an internal team. Your initial team may simply be a focus group. Your team probably will not cover all of the roles. Discuss missing roles with team.
    • List provisional replacements of all roles
    • If considering non-Stanford resources, you may still want to leverage Stanford knowledge and recommendations of outside contractors. See Outreach section.
    • Note that it is up to YOU to evaluate referrals for how well they fit your needs.
  • If you decide to bring a paid consultant on board:
    • Create a Request for Proposals (RFP) that outlines the basic requirements for your website redesign.
    • Get as many of the right type of applicants as possible
    • Get bids on hourly rates and flat fees as well as an estimate of the extent of the work
    • Do not let the consultant drive the bus
  • Identify and list all categories of users by creating user personas.
    • Create “personas” that articulate all users. Some examples: senior faculty, prospective freshmen, senior staff, peer institutions, etc.
    • For each persona, give them a name and photo (if possible). List their age and their role, and any special circumstances that makes them unique to other users.
  • For each user persona, articulate how they use the site.
    • Try to understand what each user is wanting to do on your website. Think from the user’s perspective, and ideally talk to real people who fit that persona.
    • For each persona outline 5 tasks. EG what does a student need from your site? Answer: 1) to log in, 2)to get class info, 3) to send an email to a faculty member, 4) to discover office hours for their faculty, 5) to learn about courses they might want to take. Your users will determine your business needs.
    • More about personas (http://wiki.fluidproject.org/display/fluid/Persona+Creation)
    • You may also wish to survey current users (https://itservices.stanford.edu/service/survey)
  • For each persona list ideas for user testing – where can you find examples of this user and what will motivate them to test your new site?
    • Helpful tip: go to where your users are and provide incentives. For example, if you are looking for faculty, staff, and students, Coupa café by the library might be a good place to stand. Perhaps giving away $5 Coupa gift cards might incentivize your users to take a survey or participate in user testing.
    • You can also conduct user testing online using online tools, and promote your tests through listserves etc.
  • Content: List all the types of content on your site. For each type, give the creator, source (database, post directly), and maintainer.
    • Try to articulate all aspects of each kind of content. For example, a news story might include:
      • Publish date
      • Summary text
      • Full text
      • Source
      • Link to original article
      • Author
  • Content creators: Who are they and are they equipped to create good content, keep it up to date, and refresh it when it needs to be refreshed?
  • Content strategy. Evaluate what makes each type of content "good" for your users. How often must it be updated? How do you check for accuracy? How will you update it?
    • Consider your content maintainers. Often a good content strategy will fail if there is no consideration for the people who are adding and updating content on your site. Be realistic, or propose to increase staff capabilities.
  • Consider using a Content Management System (CMS) such as Drupal or Wordpress. CMS make it much easier to maintain your website. Drupal has been widely adopted across Stanford, and there is central support for this on the free Stanford Sites service (sites.stanford.edu). Reasons to consider using Drupal:
    • Support for multiple users posting content directly to the site, and possible mapping to webauth and workgroups
    • Centrally created and maintained themes are available to departments building Drupal sites on Stanford Sites and elsewhere.
    • Stanford-specific Drupal features (module plugins) are being developed and maintained for the university, such as the Stanford Events Importer.
    • Drupal is free and open source software.
    • There is an active Drupal community at Stanford that can be a support network.
    • There are classes through Tech Training on editing, maintaining, and administrating Drupal sites.
  • Set up a timeline and share it with the project team
    • Spreadsheet
    • Cloud based project management software
  • Have a plan for various bottlenecks.
    • Scope creep: at every step you are feeling the scope of the site increase. Articulate clearly what people are proposing as a change or new feature. Try to articulate this in terms of time and money and show how each change affects the overall timeline and budget. Have a conversation about priorities to understand what needs to happen vs. what we would like to happen. Remember your users and business needs, and balance this with stakeholder input.
    • Stakeholders silent – ask for simple ratings of features, arrangement of priorities, statements of what is important
    • A bad idea is holding sway – Generate a number of possible solutions and broaden the question. Discuss consequences of the idea starting with the positives. Change the "idea" into just the positives and brainstorm ways to accomplish those objectives.
    • Team member(s) not attending or performing functions as needed or on time
      • discuss rearrangement of team with decision maker.
      • Google docs (shared with team members) may be one way to prompt interaction – it sends notices when documents are updated.
      • Stanford Box accounts are open to everyone.
  • Schedule the unexpected – Build in time to deal with unexpected development tasks that are recognized only after the site is mostly finished.
  • How will you get analytics? Google Analytics or some other service?
  • Where will you host? Onsite server, campus AFS, or hosting provider?
  • How will you backup your website?
  • What is your version control strategy, so that you can roll back to a particular design if one doesn't pan out?
    • Subversion, Git, others
  • SEO (Search Engine Optimization). Page design should make it clear to search engines what each page is about. Site should have a sitemap.
  • Given your content, stakeholders, users, and visitors, develop a list all the different types of pages you will have and how they will serve people.
  • Develop a visual design for the site that incorporates all the different types of pages you will have.
    • Every unit at Stanford can benefit from the Stanford identity. Consider the guidelines on identity.stanford.edu. See how to use the Stanford signature, free fonts, colors and photos.
    • Include a plan for mobile (smartphones and tablets) (https://itservices.stanford.edu/service/web/mobile). Themes available centrally through Stanford Sites are responsive.
    • Sketch wireframes of the layout of your site, showing how content might be layed out on the homepage, landing pages, and subpages. Make sure to create wireframes of every unique kind of page on your site. Do this as a sketch first.
    • Then create “high fidelity” comps of your design using a tool such as Photoshop or Illustrator to see what your site will look like (you only need to do a small set of comps to understand how your design will work across the site). OR use an existing theme provided by the university.
  • Put together a functioning prototype of the site.
    • You may wish to start with non-functioning prototypes if the development team has enough experience and imagination.
    • Most people need a live, functioning site in order to give good feedback.
    • Prototype should be easy to change – things will get moved around.
  • Get the prototype critiqued, internally or externally.
  • Fix problems, possible go back to other steps until it looks reasonably polished.
  • User testing
    • Read about usability (http://www.useit.com/alertbox/20030825.html)
    • Designate some usability laboratories – a conference room in your office, or perhaps computers on campus if your prototype is remotely accessible.
    • Get small groups of testers (4-6 people, one-on-one interview format, where you watch them interact with the site) who represent subgroups of your users, visitors, and stakeholders. You can offer free merchandise, coupons, or other rewards. Friends and family who fit the profile of some of your users are usually willing to help. There are probably many people on campus who fit profiles applicable to your site.
    • Do iterative testing followed by development. With each round, fix any problems you can, so that subsequent testers are not distracted by them.
  • Launching
    • Establish a launch plan. Who needs to know about the site before it launches? If your project is a redesign that significantly changes the design, navigation or functionality of an existing website, consider how to let the audience know about the upcoming changes. Should a beta site launch for comments and feedback before it replaces the existing site?
    • Get stakeholder approval for a production launch date. Ideally the launch window will be during a period of light traffic to the site (such as early morning hours) and on a day when IT support of your hosting environment is available to assist if something goes wrong. Avoid launching on a Friday.
    • Redirect URLs as needed.
    • Links Outreach