Website Development Explained
Website development has come a long way since the mid-90s when the Web explosion took place. Early websites were often written by individuals and were text-only affairs; nowadays sites are frequently constructed by professional web design houses employing teams of developers as well as graphics artists, usability, accessibility, search engine and database specialists all collaborating to produce and maintain websites responsible for millions of dollars of annual revenue for their owners. Of course, not all website development and design is undertaken at this level; many design houses are manned by a few people whose duties frequently overlap. And there are millions of websites authored by individuals either for small businesses or, increasingly, as weblogs promoting the authors’ lifestyles and perspectives on life, politics, news.
Initial website process and planning
Unless buying an off-the-shelf site or populating a template weblog, a professional web presence will invariably involve a number of development phases and site revisions before, during and after go-live. Following a preliminary meeting to gauge the size and scope of the project and gain an understanding of the business model, principle objectives are identified and, unless a vanity site, market strength and competitors are identified along with promotional and search engine strategies together with various metrics to establish a baseline against which to measure objectives success.
A decision will be taken whether to include a content management system (CMS) providing the client with a degree of autonomy to update certain areas of the site themselves rather than rely on the developer to supplement of change page content at a future date. A classic example of such a feature would be an ecommerce site with an administration back-end where product lines are updated, or the CMS may comprise a simple interface for staff to change news features, special offers or other promotional content.
Project documentation
Irrespective of site size or complexity, a requirements document is set forth describing goals and objectives to be achieved by the website. Sometimes the client will have prepared the document prior to the initial meeting. This may be in the form of an invitation to tender with an outline of project scope or it may be a detailed requirements specification. Frequently, however, this task will fall to the developer to understand and embrace the content, issues raised and spirit of the meeting and deliver an interpretation as the basis for further discussion. The paper should also identify role responsibilities; an appendix identifying all project players against deliverables.
Once the requirements document has been – inevitably – revised and approved, a functional specification is drafted detailing how the points of the requirements document will be achieved on the website and its supporting mechanisms. This is a rather more detailed document itemising all site pages together with their purpose and user classification – whether for public consumption or visible only to site management staff.
Functional Specification
A separate document, the functional implementation, will describe the high level mechanics of development against item ownership and schedule the development phases and deliverables benchmarks. It is basically an implementation timeline and may further be supported by a number of Gantt charts and dependencies relationships. The implementation document may also contain deliverables sign-off stages.
Such documentation may seem inappropriate for smaller ventures but more protracted projects will benefit greatly from clear statements of requirements, implementation, ownership and schedule. If and when a project goes of the rails the documentation will serve both as a reference to identify errant responsibility and as a focus to regroup and continue.
