[thelist] RE: common key to good sites

Joshua Olson joshua at waetech.com
Sat Jan 29 11:41:05 CST 2005

Ok, my turn... 

Before you can define what makes a good site, you have to determine who you
are asking.

If you ask a business owner what makes their site a success, then they may
tell you that they look for return on investment.

Ask a developer the same thing and they may say that the site is successful
if it doesn't contain any bugs that need to be corrected after launch.

Ask a blogger and they may measure success by how many comments get posted
about their entries.

Ask the designer and he may tell you the site was a success if the developer
and client didn't mess up the layout before and after the site went live.

Ask a user and they may tell you it's finding what they are looking for

Ask an owner of a Humane Society and they may say the site was a success if
they were able to find a good home to a stray puppy through the website.

Bottom line... does the site accomplish the goals of the person you are
asking, no matter what those goals may be.  That being the measure, the
question is this: what are the keys to getting there.

Quick load time?  No.  
Snazzy graphics?  No.  
Really thinking about what you are trying to accomplish in the long rung and
deciding what can be done in the short run to move in that direction? Yes.
Knowing your audience and what they are looking for?  Yes.  
Building for all conceivable future options from day one?  No.  (this is
also known as over-engineering and can easily destroy a project)
Keeping it simple?  Yes.
Taking complete ownership for your part of the puzzle?  Yes.

That last one is really important.  I've seen a lot of projects get blown
away because the various players disengage from the project.  Example:

The client writes the check to build the site and drops the ball on
producing valid content for the site.  
The UI designer allows the developer and client to change the way the
navigation and forms work without putting up a fight.  
The project manager doesn't insist that the client explain the way that the
client will measure success of the site.
The developer fails to ensure that every required client platform is
supported from day-1.

These are only a few of the things that can kill a project.

But I digress... :-)

Bottom line, manage the expectations of the various people involved (the
client, the designers, the users, etc) and make them feel like they are
getting exactly like what they came to the site for.

Joshua Olson
Web Application Engineer
WAE Tech Inc.

More information about the thelist mailing list