Best Practices in Web Development: Part 1

August 25, 2008

Topics: Web Development.

  • Part 1 (Contracts, Site Requirements, Information Architecture)
  • Part 2 (Hosting and Security)
  • Part 3 (Navigation, Scent)
  • Part 4 (Semantics, Structure vs. Design, Universal design)
  • Part 5 (Interaction, Errors, and Administration)

This is the beginning of a five-part series highlighting the entire process of developing web sites for clients. Best practices don’t just start with construction: for a small business or independent contractor, they start long before that. Through the course of these articles, I’m going to cover issues including:

I’ll probably touch on other issues as I think of them or they appear relevant, but these 15 points will be the bulk of the article series. Although these articles are written as if the actions are performed in a strict chronological sequence, it’s important to realize that the real process of building a web site is much more fluid than any written description. Some issues can be dealt with at any point in the process, others need to be addressed repeatedly — don’t take the order I’m writing in as any kind of commandment!

Preparing a Contract

Your project starts with a contract. Before the contract is created, there may be a variety of proposal aspects — either the client delivered a request for proposals, requested your services specifically, or chatted you up in the pub…but the project doesn’t start until you have a contract.

There are good ways of going about contracting a project, and there are bad ways — this is well outside my area of expertise, but it bears mentioning: don’t work without documentation, however casual.

Now, one of the challenges of establishing a work contract in many web development projects has to do with how much work you should really do prior to going under contract. There’s a bit of a Catch-22 in place purely by the nature of the process: in order to establish an effective and project-specific contract (which you should have,) you need to undergo a discovery and requirements phase. However, this process is time-consuming. You should really only undergo this process when you’re already under contract!

Hence the establishment of a contract with two parts: the first part, signed prior to discovery phases, should establish the terms of discovery and requirements establishment, and note that the complete terms of the contract will be appended in a separate appendix following the discovery phase.

Now, this isn’t altogether necessary for small projects: a basic website can usually be estimated without a complex process.

Regardless of the scope of project, there are various terms which should always be covered in your contract:

  1. The scope of work: what’s included in this contract.
  2. The process for extending the contract, should additional requirements be established. (It WILL happen.)
  3. Estimate of costs with a statement of the terms of the estimate.
  4. Notification of late payment fees and deposit required.
  5. Ownership of end products. By default, your design work and other materials produced by you in the course of a project are yours. However, it’s a good practice to turn copyright ownership over to the client. Many clients will require it!
  6. Responsibility for creation or purchase of content: video, audio, photographic, written.
  7. Definition of the completion of the contract. (I usually specify the launch of the site.)
  8. Terms of maintenance, warranty coverage, correction of errors.

In addition to these issues, you should give a close read to a few articles by Sarah Bird at SEOmoz. She’s published several articles recently on contract clauses she recommends — although she’s speaking from the perspective of an SEO firm, most of these issues are highly relevant to a web design and development company as well!

  1. Limited Liability Clause
  2. Indemnification Clause
  3. “Opportunity to Cure” Clause
  4. Manage Client Expectations: Include a Warranty

Establishing Site Requirements

Before spending any significant time working on any development aspect of a project, you should sit down and establish a list of site needs. (Actually, you can do this standing, too.) Sometimes clients have little concept of what their web site can do; sometimes they have totally unrealistic concepts of what you should easily accomplish. Either way, you need to sit down with them and find this out!

  1. What does the site need to do for them? Find out what business model this site will be reflecting. Is it advertising driven? Sales driven? Lead generation?
  2. What is their plan for growth? Do they intend to build a community around their business? Will they be offering online support for products or services? Is AdSense all they need, or do they need to be able to manage advertising at a more granular level?
  3. What kind of dynamic information might the site be able to offer/use? Will the site generate an RSS feed? Will it be articles, product information, service updates — or all of the above? Do they want to import information from an external source?
  4. What will their relationship be with their user base? Will the site be exclusively used to allow visitors to communicate to the business, or will it be a two-way conversation? Will they offer additional features for their users — widgets for their own websites, applications, etc.?
  5. What kind of site integration might be required? Do contact forms need to connect with a pre-existing database? Will integration with existing business systems be part of the process?
  6. Who will be responsible for updating the site? Do they have a professional web person to deal with updates? Will you be expected to take that on? Will they be taking care of it, but with untrained support staff? Do content edits or new content items need to go through editorial review?
  7. What kind of media might they use on the site? Images and text can be assumed, but what about audio and video? Streaming or static? Do they have the facilities or personnel to take care of captioning and transcription?

Now, the vast majority of sites require very little of this. A standard site might consist of a blog, 5-20 content pages, and a contact form. However, it’s always better for your sanity — and your contract — to have any additional needs figured out in detail before any work is done.

Once you’ve established what is required from a functionality perspective, you can sit down and convert that into a technical requirements document, specifying software required, custom programming to be done, programming languages required, databases needed, and any external information the client will need to supply.

Information Architecture

With this information, you can dive into planning your information architecture. Information architecture is, on a grand scale, a rather theoretical concept of modeling the organization of information. However, from a practical perspective, information architecture is the process of deciding how to organize the documents on your site. Depending on the type of information stored, the organization of the documents may be radically different.

The most important thing about information architecture is to think like a visitor: somebody who doesn’t already know everything about the site. This is one of the reasons it’s best to deal with content organization early in the process: you can think about content in the abstract, rather than thinking about the actual content documents you’ve spent the last month dealing with in reality.

Considering the documents in the abstract allows you to easily focus more on issues of content relationships, subject areas, and organizational logic instead of getting wrapped up in notions of familiarity.

I can’t really tell you how to organization your information — it’s fundamentally an issue of content categorization and labeling, and will depend tremendously on the information you’re working with. You can organize by type of information (Photos, Video, Articles, etc.); you can organize by section (About the business, Services offered, Contacting us, etc.). You can do both, and cross-reference between sections — it depends on your needs and the needs of your users.

Information architecture doesn’t merely apply to the organization of pages and sections of your site, however: it also applies to the organization of information on the page. This is equally important, allowing you to generate a logical map of information on the page. This will be covered in more detail in a later article in the “Best Practices” series, however!

Web Development Best Practices: Part 2 (published on Wednesday, August 27th) covers hosting expectations for a high-quality web site and introduce issues of security on the web.

Have something to contribute?




« Read my Comment Policy

4 Comments to “Best Practices in Web Development: Part 1”

  1. I am tester by profession and I would say that this kind of details even help us to build our test strategy. Why not to out all these in a eBook and offer it from this blog?

  2. Hey thanks for sharing this info Joe. The Info architecture bit is good reading. I’m struggling with this aspect of a site right now actually.

  3. Thanks for mentioning that, Tedd – it’s certainly true! In my own practice, I develop every site on a CMS; I haven’t done a static site in years. This is partly because it’s easier for the client to take a role in publishing or changing their site, and it’s partly because it’s easier for ME to manage the site, if that’s necessary. As such, it’s easy for me to forget how important it is to discuss the client’s need for involvement — my normal plan is to assume they will want to be able to update the site themselves.

    In part 5 of this series, I do address client training and long-term site management, but bringing this aspect of development into the initial requirements phase is very important.

    Thanks!

  4. Great start.

    One additional consideration in your “Establishing Site Requirements” should include what are the client’s expectations and requirements regarding back-end development, if any.

    For example:

    Do they want a CMS allowing them to change their site?

    Do they want a back-end to add/delete product to their site?

    Do they need training for any of this?

    All site development should consider if the client is going to be involved and responsible for the end-result of their site.