[thelist] SITE BUILDING: plan of attack OR how do you experienced people tackle a from-the-ground-up website?

Chris Kaminski chris at setmajer.com
Sat Jun 22 04:46:01 CDT 2002


Thus spake Chris W. Parker:

> at the company i work for i am a one man
> web-design-network-administration-tech-support-all-around-computer-guy
> team and i am coming up on the redesign of one of our current sites.
> although it would technically be a *redesign* i am going to treat it
> like a from-the-ground-up project since it's going to be so much
> different and hopefully better.

I'm guessing that what you mean is you're going to go through the planning
from the start, rather than just giving the site a facelift. That's the way
things should be done, of course.

However, just in case, I should mention that the current site already has a
variety of stakeholders inside and outside the company. It is important to
get their input so they feel like they have as much interest in the new site
as they did the old. Talk to the people in the company about the site and
what they think about it, put a 'we're redesigning--let us know what you
want' link on your site, etc. The feedback will be invaluable.

Also, be sure to get a very good idea of what content you already have and
how it is used. No sense rebuilding something you already have just because
it is buried 4 levels deep or some such. Jeffrey Veen wrote a great article
on doing this at:

<http://www.adaptivepath.com/publications/essays/archives/000040.php>

Now, as for the planning process, you've gotten some excellent advice
already. My process resembles most of them in some ways, but differs or
expands on enough items that I'm going to lay it out in moderate detail.

I find that the process below works just as well for a 5 page brochureware
site as it does for a 5,000 page e-commerce site or a 50,000 page content
site. The difference isn't in the process so much as the amount of time the
process takes and the amount of documentation generated. For a small
brochureware site, the project definition and information architecture
stages may well take less than a day and generate no more than three or four
printed U.S. letter or A4 pages. For large sites, the process could take
months and generate several hundred pages of specifications.

A good rule of thumb is if it seems like too much trouble to generate the
following documentation, that is usually a good sign that you desperately
need it. Since you already know that you do need it, I'll stop evangelizing
and get on with the process.


1. PROJECT DEFINITION

This is the planning portion of the process you've asked about. Here you
define why you want a site, what it is to do and how it should do it. This
should be completed before you do a single comp or write a single line of
markup.

Incidentally, this is also the phase that should be done internally if
you're hiring an outside firm. You can also get a consultant to help you
through it, but my advice is to at least work through the process briefly on
your own and use the resulting documentation for your RFP (Request for
Proposal) when soliciting bids from outside firms. The successful bidder
will undoubtedly work through this phase again, but that's necessary to make
certain they understand what you want, and to apply their expertise to make
sure the spec is as good as it can be. That's what you're hiring them for,
after all.

Project definition is usually led by a business type (a 'suit') rather than
by a technical or creative person. If the site is being done in-house, this
is usually the site manager or whomever has budgetary responsibility for the
site. If it is done out-of-house, it is the responsibility of the account
executive or producer. In smaller shops, the same person may also be the
project manager or information architect, possibly even the designer and
programmer too.

1. a) CORPORATE MISSION

The first step is to define the company's mission. Some vague 'making the
world a better place through widgets' sort of thing is entirely inadequate.
What you need is a concise statement of what the company does ('makes and
sells widgets'), how it does that ('using state-of-the-art manufacturing
techniques,' 'through select distributors'), who it does it for ('serving
the small businesses and home office market') and what it's value-add is;
that is, why someone would choose this company over one of its competitors
('offering the finest quality and the highest level of customer service'). A
good one will probably be no more than one or two sentences, and certainly
no more than 100 words or so.

A word of warning: every company will say it offers everything: low prices,
fantastic service, high quality, etc. The problem is that there is no way to
offer all of those things. One must strike a balance. The company must
select a balance and effectively communicate this balance to their
customers. This is called a 'brand promise' and delivering on this promise
is what builds a brand and keeps customers loyal to it. It is sometimes
necessary to look at the company's operations to see what their priorities
really are: if the company only has two customer service reps for thousands
of customers, exemplary service may not be part of the brand promise--or if
it is, the company probably isn't delivering on it and needs to either alter
its marketing to more accurately reflect its priorities (perhaps they're the
low-cost alternative, not the high-service one) or change its priorities to
match its stated values. This is, of course, beyond the scope of a Web site,
but if corporate values and the brand promise are out of sync the site will
not be a success whatever you do.

1. b) SITE PURPOSE

Once you have the company's mission clearly defined, you need to figure out
how the Web site will support that mission. This is the site's purpose. You
should be able to write a good one in a single sentence.

For example, if the company is a low-cost vendor perhaps the site's purpose
is to reduce customer service costs, or to improve customer service for a
minimal increase in costs, or to reduce price by selling direct to customers
rather than through a distributor, or to reduce the costs of accepting
orders by not needing a live person to accept each one. A good purpose
statment might be something like 'to increase sales by expanding our
geographic market area and decrease support costs by reducing the need for
human support workers.'

1. c) SITE GOALS

The next step is to define the goals for the site. These should be concrete
statements of the things the site is to accomplish, and should include some
reference to how they will be measured and the deadline for achieving
success. The goals are the measuring stick by which you will judge whether
the site is a success or failure. I find that a bulleted list of phrases
works well here, rather than just as sentence. Sometimes an outline is
necessary as each goal may have several components.

Generally speaking, if you have more than three or four points, or more than
three or four sub-points for any point, you're probably biting off more than
you can chew in one round unless the site is already meeting some of the
goals. Don't try to do too many things at once. Rather, roll out the site to
meet the most critical goals first, and then expand it in another redesign
later to begin working on other goals. Otherwise, you risk losing clarity
and ending up with a mishmash that meets none of the goals.

Goals must also be stated in terms relevant to the business at hand. That
is, unless you're working on a content site, simply boosting site traffic is
rather pointless unless that boost also results in increased sales, improves
lead generation or reduces customer service costs. Boosting traffic and
other Web-specific goals may be a means for meeting the site's goals, but
they should never be confused with the goals themselves.

For example, your goal might be 'to generate $5 million in sales to
out-of-region customers annually within the next 3 years' or 'reduce
customer service costs by 10% over the next 12 months.'

1. d) Content Spec/Functional Requirements

Once you know what it is you're trying to do, you must figure out how to do
it. This is where you generate the actual requirements for the site. These
requirements will often be heavily reworked and expanded by the information
architect in the next phase, but need to be at least started by the business
people so the Information Architect knows what it is they are architecting.

A content spec is generally used for a content or brochureware site, while a
functional requirements document is used for an application. Most sites fall
somewhere in between, and consequently the document generated is a mixture
of the two. I just use the term 'content spec' to refer to this hybrid.

A content spec is an outline-form document that lists each item that will
appear on the site. This includes every link, image, logo, snippet of text,
form field, widget and so forth. It really is mind-numbingly detailed, but
without it things will get forgotten or misplaced resulting in more
expensive changes down the line.

The way I work up a content spec is to first define the major categories of
information or functionality and use those as first-level topics. These will
eventually map directly to the top-level navigation items of the site. While
it's fine to start with a set of first-level topics that are based on
corporate business process or organization, you should re-organize them at
the Information Architecture phase to better reflect the way your customers
view your company or the way they will interact with your application.

Below the first-level topics you may have one or more additional levels of
'logical' structure that help to group and organize actual pages. How many
levels and how many items at each level vary widely from site to site.
Generally, if you have only one or two items at any level or under any item,
then it's usually a good idea to scratch that level or item. Likewise, while
the 'ideal' number of topics at a given level is a subject of much debate,
if you have more than 10-15 items at a given level or under a single item,
it's probably an indication that you need to re-think that item and split it
up. The exception, of course, is where you have a library of documents
accessible through a search interface, such as in a 'knowledge base' of
support documents. There several thousand documents at a given level isn't
too many.

Below the sub-topics (if any) you have the actual pages listed by title.
Each page needs to be listed in the hierarchy. Eventually, if you're
developing a static (no CMS) site, you can use topics and sub-topics as
directories on the server, and place the pages accordingly using the titles
as the basis for the filenames.

Below each page you then list each element that will appear on the page.
Rather than listing 'logo, link to home page, search box, link to contact'
on each page, go ahead and put those into their own first-level topics or
sub-topics under the main topic 'global items' and list them on the page as
'header--I. A.' or some such. You can do the same for section or
subsection-specific navigation.

Images are a special case. If the image is strictly decorative, it can be
safely left out of the content spec--in fact, at this stage you won't even
know it exists. If, however, the image conveys specific meaning to the user,
then it should be listed. This is a rather fuzzy distinction, so use your
best judgement: if the page would convey exactly the same information
without the image, then the image is a design element; if not, then it is
part of the content. For example, rules, bullets, or a stock photo of a
happy family would all be decorative. Diagrams, graphs or illustrations of
something described in the copy would be content.

Product shots can be problematic. If the same graphic appears on every page
in the site or section, then of course it is part of the 'chrome' and should
be listed in a separate topic with other global or section-wide items.
Sometimes the product shot really conveys no more information than what the
product's packaging looks like. Other times it gives the visitor a sense of
the size, color or usage of the product. It really depends on the purpose of
the site and the page whether a given product shot is content or decoration.
On a brochureware or e-commerce site the shot is much more likely to be
content. Heavily treated images (montages, colorized, posterized, masked,
filtered, etc.) tend to be decorative. Just use your best judgment, and if
you do decide the image is content, be sure to include title and alt text in
the spec once it's written.

Flash movies, audio and video should be handled similarly, and their entries
should include a description of what happens in them. For Flash movies, this
can wind up being an extensive outline in itself.

On pages that feature forms or interactive elements, the individual interfae
elements (buttons, fields, toggles, sliders, etc.) should be listed and
their exact operation described. This includes specifying what sort of input
they expect (numbers only, a valid e-mail address, a click, click and drag,
etc.), any steps that must be taken to ensure that the proper input is
supplied (server- or client-side evaluation, error handling, etc.), whether
the user is required to use them (i.e., required form fields), and what sort
of response the user will get from them.

When specifying interactive elements, don't forget links. Many links may
actually be defined in global or section-wide items that are detailed
elsewhere. For those that aren't, include the destination (listed by
reference to the content spec; i.e., 'navigates to page II. A. 1.,
"Products"' or 'opens image III. B. 17. in a JavaScript pop-up window').
Also be sure to include title text and the actual link text, as well as any
other requirements (i.e., if it must be a graphic button).

For copy, specify both the subject of the copy ('description of product
construction') and length ('500 words').

At this stage, much of the content may still be ill-defined. For example,
you may not know how long the product description is because it hasn't been
written yet. That's fine. Make your best guess and update the spec when you
have the information. You can handle interactive elements the same way.

The main point here is to figure out what you want to build and specify it
in sufficient detail that you could pass this document to a subcontractor
and they could build something reasonably close to what you want with no
other documentation. As development proceeds, your understanding of the site
will undoubtedly grow as you receive additional feedback from user testing,
internal reviews and the like. That's fine. Just update the spec as
necessary when you get better information.

1. e) Technical Requirements

Technical requirements are things like which platform the server must run
on, any performance requirements (10,000 simultaneous users on a database
supplying product data, for example), middleware requirements (ColdFusion,
ASP, PHP, etc.), first-tier browser support (the browsers that must get the
same, or nearly the same, look-and-feel; i.e., NN4.x, IE 4+ Mac/Win and
Gecko-based browsers) and any other specific requirements, such as that the
design must not sprout horizontal scroll bars at resolutions greater than
640x480 or must adhere to the Web-safe palette. Some of the items may be
very general pending input from the technical or design people; for example,
the requirements may simply state that the site will use a CMS without
specifying which one. Once this information is known, it can be filled in.

For many sites, this may be nothing more than a short list. For a Web
application or a site with a DHTML GUI, it may run several pages.

At this point, you have the information required for an RFP if you're going
to solicit bids from vendors, or for review by management to ensure that the
site will meet strategic objectives, as well as any arbitrary desires on the
part of senior management ('I really want a picture of my dog in the
"Employees" section'). You can also draw up a budget and complete project
schedule.

I usually put the corporate mission, purpose and goals in one file called
'goals.txt' or some such, the content spec in another document and the
requirements in a third. I then put all three, together with any supporting
documentation (surveys, links to articles supporting my content/structure
decisions, etc.), a budget and a schedule in a directory called 'specs'
inside a main directory for all site-related files on a server accessible to
all concerned. It is also a good idea to add a version number to each
document so you can be sure that everyone is always reading from the latest
(i.e., 'goals_1-1-0.txt'). This also allows you to keep older versions
around in the same directory to document your process and allow you to go
back to an earlier version if you later discover that you've gone off in a
bad direction.

2. Architecture

There are two components here: a technical architecture that describes how
the data for the site will be stored, and a logical architecture
('information architecture') that describes how the site will be organized
from the user's perspective.

2. a) Logical Architecture

This is the 'information architecture' and is typically the responsibility
of the information architect (or the account exec, project manager or
designer who serves that function). There are three deliverables: a
re-worked content spec, a site map and a storyboard (screenflow) or
wireframes.

2. a) i) Content Spec

The IA should go through the content spec from the perspective of the user
and re-organize it so it makes sense from the perspective of someone
visiting a Web site. Very often, company employees are so close to the
actual business processes that they can't think about things as an outsider
would. For example, where an employee sees two separate departments (say,
sales and order entry) the customer sees only 'buy stuff.' Likewise,
technical people tend to see tasks in terms of discreet program components
('input' and 'update database,' for example) where a user sees tasks
('change the shipping address').

Structuring the site according to the way a user will interact with it is
critical for usability, and it is this structure that should be reflected in
final documentation of the site.

2. a) ii) Site Map

The site map is the typical Visio-style boxes'n'lines diagram of the site's
pages and how they link to one another. One page is fine for a small site;
for larger ones the map may be several pages, usually one with whole
sections represented by a single box, and then 'close ups' of those boxes
that are themselves mini-site maps.

Each box need only include the name of the page (which is also the text of
the item in the content spec that represents the page, and the page's title)
and lines showing the main navigation path. Nav bars can be represented as a
circle or some such with lines branching to each page linked directly from
the bar. Arrows can be used to show whether two pages are linked to each
other, or if one of the pages contains a link to the other, but the other
contains no link to the first.

Index cards with the name of each page can be used to try different
structures quickly, and also to allow users or employees to show how they
would organize the site. User feedback at this point is very valuable, and
can head off problems down the road.

The idea here is to give a quick overview of the structure for those who
don't have time to read the whole content spec (i.e., the executive suite)
and to give a sense of the global navigation.

2. a) iii) Screenflow/Wireframe

This is also developed by the IA. For content-based sites with simple
interaction, wireframes of each type of page the site will be required are
probably sufficient. These simply consist of boxes representing the areas of
the page that will be occupied by the various content items (logo, nav,
text, images, form widgets, etc.). The purpose here is just to get an idea
of the relative importance of the various elements and how they need to fit
together. By doing a wireframe, you allow stakeholders to get a visual sense
of how things will fit, and are able to show them that they /can't/ have 20
different promotions above the fold along with the main nav, search, logo,
slogan, a picture of the corporate headquarters, the latest stock price,
etc. It also takes some of the load off of later design reviews, since the
basic layout will be agreed upon without the distraction of arbitrary taste
issues ('I hate red,' 'I like curves,' 'drop shadows are cool,' etc.).

Note that the wireframes do not codify a design grid necessarily, and it is
entirely possible the layout will change somewhat at the design stage. The
main goal is just to agree upon a basic ordering of elements so the designer
doesn't waste time with 'the logo needs to be bigger' nonsense.

For a site with a complex UI or lots of forms, you should develop a
screenflow diagram. This is analogous to a storyboard in film or animation.
It is a series of wireframes that show the path a user takes though a site,
or the steps a user will follow to accomplish a given task. One screenflow
should be developed for each task, possibly with branches to show different
outcomes based on different input. As with the wireframes, screenflows
aren't etched in stone because a designer (or programmer or whomever) may
come up with ways to combine steps, or technical barriers may require the
actual steps to be altered.

In both cases, user testing is possible using only the diagrams by having
them point to the link text on the page then showing them the appropriate
diagram for the page they've selected.

2. b) Technical Architecture

The Technical Architecture is developed by the server/network administrator.
This is where decisions are made regarding databases, middleware, platform,
bandwidth and hardware requirements, etc. It proceeds in tandem with the
development of the logical architecture. While the logical architecture may
have technical implications, the two should remain as independent as
possible.

I don't really have the expertise to analyze this step properly, so I'll
leave it as an exercise for the reader.


>From here we start getting into actual implementation. Others have described
various processes for design (sketching, surfing similar sites, paging
through design annuals, walking around outside, sifting through collections
of images, etc.) and coding (pseudo-code, flowcharting, data models and the
like) so I'll leave that for the time being.

All I will add is that the documentation from the planning phase isn't
'finished' until the site is, and in fact should be updated even after the
site launches to reflect changes, additions and refinements made during the
maintenance phase of the site.

HTH


chris.kaminski == ( design | code | analysis )

------------------------------------------------------------
    Actually, the "stamp tax" bit was a
    businessman who tricked the working
    class into dying (as is always done)
    "for their country."
    -------------------------------------<< Andrew Grygus >>




More information about the thelist mailing list