Web Re-design Checklist
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

Internal stakeholders

Business needs analysis

Compliance (with internal rules or external regulations)

Designer (Aesthetics, GUI)

UX (User Experience)
- with authority

Usability Testing

Accessibility

Cross-platform, issues, mobile (smartphone, table), desktop etc

Information Architect

Coder / Web Monkey / Programmer

SEO (Search Engine Optimization) and Analytics
Checklist
1. Admit that you have a problem.
o
Consensus among stakeholders that re-design is necessary.
2. Identify and list biggest problems with current site by polling
internal stakeholders.
o
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.
o
Can any be fixed in short order, before the re-design? Note
that a re-design can take 6 months – 2 years.
3. Take the analytics from your current site and develop a 1-2 page
summary of current site usage. Rank pages by traffic.
4. 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.
o
List provisional replacements of all roles
o
If considering non-Stanford resources, you may still want
to leverage Stanford knowledge and recommendations of
outside contractors. See Outreach section.
o
Note that it is up to YOU to evaluate referrals for how
well they fit your needs.
5. If you decide to bring a paid consultant on board:
o
Create an RFP
o
Get as many of the right type of applicants as possible
o
Get bids on hourly rates and flat fees as well as an
estimate of the extent of the work
o
Do not let the consultant drive the bus
6. Identify and list all categories of users.
7. For each user category create a persona and stories of how they
use the site.
o
For each persona outline 5 tasks. EG what does a student
need from your site. 1) to log in, 2)to get class info.
Etc. Your users will determine your business needs.
o
You may also wish to survey current users
(https://itservices.stanford.edu/service/survey)
8. For each user category list ideas for user testing – where can
you find examples of this user and what will motivate them to
test your new site?
9. Content: List all the types of content on your site. For each
type, give the creator, source (database, post directly), and
maintainer.
10.
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?
o
[link to class on content]
o
The ebook Writing for the Web is available through
SearchWorks (http://searchworks.stanford.edu).
11.
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?
12.
Should you use a web framework, such as Drupal? Votes for:
o
Many users posting content directly to the site (the
content does not live anywhere else).
o
A site that you wish to imitate uses Drupal (such as a
Stanford site with a particular look and feel)
o
13.
Your site will be very modular and likely utilize modules
already developed at Stanford, such as a calendar of
events.
Have a plan for various bottlenecks.
o
Stakeholders silent – ask for simple ratings of features,
arrangement of priorities, statements of what is important
o
A bad idea is holding sway – Generate a number of possible
solutions and broaden the question.
o
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.
14.
Schedule the unexpected – Build in time to deal with
unexpected development tasks that are recognized only after the
site is mostly finished.
15.
How will you get analytics? Google Analytics or some other
service?
16.
Where will you host? Onsite server, campus AFS, or hosting
provider?
o
17.
Simplest: Stanford Sites
(https://itservices.stanford.edu/service/web/stanfordsites)
or WordPress
(https://itservices.stanford.edu/service/web/wordpress)
How will you backup your website?
18.
What is your version control strategy, so that you can roll
back to a particular design if one doesn't pan out?
o
Subversion, Git, others
19.
SEO (Search Engine Optimization). Page design should make
it clear to search engines what each page is about. Site should
have a sitemap.
20.
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.
21.
Develop a visual design for the site that incorporates all
the different types of pages you will have.
o
22.
Include a plan for mobile (smartphones and tablets)
(https://itservices.stanford.edu/service/web/mobile)
Put together a functioning prototype of the site.
o
You may wish to start with non-functioning prototypes if
the development team has enough experience and imagination.
o
Most people need a live, functioning site in order to give
good feedback.
o
Prototype should be easy to change – things will get moved
around.
23.
Get the prototype critiqued, internally or externally.
24.
Fix problems, possible go back to other steps until it
looks reasonably polished.
25.
User testing
o
Read about usability
(http://www.useit.com/alertbox/20030825.html)
o
Designate some usability laboratories – a conference room
in your office, or perhaps computers on campus if your
prototype is remotely accessible.
o
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.
o
Do iterative testing followed by development. With each
round, fix any problems you can, so that subsequent testers
are not distracted by them.
Links

SOAP (Stanford Online Accessibility Program)
(http://soap.stanford.edu)

Stanford Self-Help Web Design Resources (
http://itservices.stanford.edu/service/web/design)

SearchWorks (http://searchworks.stanford.edu) is a search engine
for Stanford University Libraries. It has an incredibly simply
interface to a complex array of online resources.

Top 30 Mistakes (http://www.webpagesthatsuck.com/top-30-webdesign-mistakes.html) is helpful to inoculate against certain
habits, and to illustrate why a particular design choice is bad.

UX at Stanford (http://ux.stanford.edu) is a point of contact for
help with the user experience side of your website.
Outreach

Explore the campus web services website
(http://itservices.stanford.edu/service/web/) and contact them
directly with questions.

TechCommons (http://techcommons.stanford.edu) is a Stanford-only
wiki with solutions to common technical tasks.

The su_webmasters mailing list (su_webmasters@lists.stanford.edu)
is for all campus web developers.

The staffers mailing list (staffers@lists.stanford.edu) is for
all Stanford employees, and is therefore one of the widest nets
you can cast on campus.

Communities of Practice at Stanford (http://cop.stanford.edu) is
a nexus for organizing groups of campus individuals working on
similar tasks and technologies in different departments.