by Zoe Black

This paper considers the design process for website development. Bearing in mind that the term �design� refers to the design of the whole product and not simply the design of the interface. The design process incorporates all aspects of the lifecycle of the product from its inception, through to planning, information architecture, technical architecture, look and feel development, implementation, testing, fulfilment and maintenance.

What is a web design process?

The ideal web design process should be flexible enough to accommodate a range of developments, while concise enough to allow all roles and responsibilities of team members to be understood. The process should be developed to accommodate input from all stakeholders and to be developed in such a way as allow phases and disciplines to work in parallel to achieve optimum results. This means a combination of a layered approach � which is where one task is commenced only on the completion of its predecessor - and overlapping, an approach whereby tasks and functions are undertaken at the same time. This may sound confusing, but it is essential to incorporate a series of 'layers� or milestones within a project where all parties involved in the process are in agreement, before the next phase commences. Then within each layer are a series of iterative and/or parallel processes occurring, whereby cross discipline resources work collaboratively to achieve common objectives.

Why have processes at all?

Without an agreed process in place, interactive developments can become erratic, objectives are not set (and therefore not achieved) site requirements are miscommunicated, and misalignment of the roles and responsibilities in the team occurs. These all result in an inability to successfully predict milestones and general dissatisfaction and demotivation.

There is no excuse for a lack of method in implementing an interactive product. There have been enough mistakes made in the new media industry to provide sufficient learnings for methodologies to be considered, and made readily available to development teams. The application of a methodology allows a team to operate within a framework which alleviates confusion, for deliverables to be agreed and achieved, for resource and workflow planning to be successful, to handle development obstacles and to maximise communications and learnings. In addition, selection and agreement of the right process will encourage creativity within the project team, and an increase in productivity. There will also be an improving effect on morale and purpose within the project team.

The cone of uncertainty and the pyramid of estimation

Like most projects, there are a number of parts which make up the sum of the whole. Some of these are obvious at the outset, and some of these are defined during the lifecycle. Additionally, some elements are fixed at the outset, and these will determine other elements.

The cone of uncertainty The cone of uncertainty is an idea adapted from Steve McConnell�s �Software Project Survival Guide� and works on the assumption that phases of a development are dependent on decisions that are made in the previous phase. Therefore, the level of uncertainty will be greater at the beginning of a project. The team involved in the process will need to complete the decision making process for each phase before it can fully understand the implications of the next.

The pyramid of estimation As the cone of uncertainty indicates, decision-making is an essential part of the development process, and accurate estimation in the very early stages is virtually impossible, particularly for a complex development. In order to predict cost and time implications of development it is important to understand the �pyramid of estimation� - a concept developed in the course of researching this paper. Cost, time and functionality are all intrinsically linked, and if time and cost are the essence of a project, then functionality is no longer a variable, rather it becomes defined; likewise if functionality is fixed, then cost and time will be determined.

An Interactive Design Process Framework

Phase 1 Scoping

The key stage of any interactive project is scoping. The level of attention that is played in this stage of the process will determine whether or not a project is going to succeed. Elements of the product should be prioritised and the resources required should be identified. It is important to include resources from all necessary skill-sets, e.g. design, technical, production, marketing, usability, information architecture etc

For the benefit of agencies/interactive suppliers, the scoping phase is a phase that should be funded. If it is possible to make a broad estimate of cost based on the initial brief, then 15-25% of this budget should be allocated to scoping. Once the scoping phase has been completed and all stakeholders are satisfied then a more accurate cost estimate can be given. In the long run, being paid to scope before providing a final cost estimate and delivery schedule will provide a more stable and open relationship, and be less painful than having to revise estimates and schedules.

1.1 It all starts with a brief

It is important that a clear concise brief is the starting point for the development. The initial brief should clearly outline what the strategic objectives of the website are. It should also include any available background information on the organisation, its overall business objectives and how the website fits into these, its brand, its target markets, the culture of the organisation, what kind of infrastructure is in place to support the web site development, and other relevant information.

1.2 The devil is in the detail: planning and documentation

The planning stage should define the overall running order for the project. Roles and responsibilities within the process should be defined and communicated universally. Sign-off procedures are an essential part of this process and the sign-off procedure should be agreed by all stakeholders the project.

The output of the planning stage is the initial set of documentation. This should include:

• Technical and Functional specifications
• Brand brief and or creative brief
• Design guidelines and considerations
• Information Architecture map
• Schedule including major milestones for review and amends
• Implementation plan
• Testing strategy

All key stages throughout the process should include an element of revision to the documentation if required.

1.3 How is it going to be used � walkthrough and prototype

Once the initial specifications have been agreed, it is important to draw a walk through. All members of the team should at this stage be encouraged to contribute potential problem areas and obstructions. The next stage is to build a prototype. A prototype is a minimised version of the product, which contains an indication of the functionality on a rough framework. Additionally the interface elements should be considered here.

1.4 Is it usable?

The final stage of scoping is usability, with the prototype tested using a select group of end users. This stage of scoping is invaluable � if end users find a particular piece of information difficult to locate or a task to fulfil, then something is wrong. At the end of usability testing it is important to review each of the steps before moving onto Phase 2. Problems that arise in prototying or usability testing should be considered and the documentation revised, or the problem should be noted with the discussions and considerations that arise as a result.

Phase 2 Development and testing

Phase 2 is the industrious phase, this is where the blood, sweat and tears are spent. Providing Phase 1 has been undertaken thoroughly, Phase 2 should be relatively straightforward. However, there are sometimes events outside the control of team members, which can cause problems.

2.1 Get the detail right � revise the documents

The very first step of phase 2 is to ensure that all documentation has been revised, and approved. Although this may seem like a simplistic statement it can sometimes take weeks to get sign-off from the right individual.

Steve Mconnell suggests a Planning Check Point Review as part of his process, this is a review meeting which when applied at this stage works particularly well as a review of all of the items covered in Phase 1. The following review agenda is based on McConnell�s:

• Is the original product concept still available?
• Will it be possible to develop a product that matches the strategic objectives of the project?
• What is the estimated total cost?
• What is the estimated overall time for development?
• Is the business case for the product still justified, now that a more accurate costing and schedule are available?
• What are the major risks to the project, and can they be surmounted?
• Are the walkthrough and prototype compatible?
• Should the project go ahead?
• Does the project need to be re-scoped?

The Planning checkpoint review should act as a sign off milestone for the project. For an agency it is imperative that individual/s signing off during the review at this stage have full authority to do so.

2.2 Do it damn it � development

Provided all the paperwork has been approved, budgets are cleared, the prototype is working, the user group testing has been successful, the next step is to get down and do the work. The key element here is the team, which needs to be communicating well, motivated, with clear direction and support. Some quick guides to development team motivation are:

• Ensure that key objectives of the project are clearly communicated, and where possible individual objectives are set and are alligned with the overall project objectives.
• Ensure that communication is facilitated across all disciplines within the team.
• Ensure that project leadership is provided by experienced individuals. The project leader will need to be able to communicate with all disciplines of the team, and also need to be able to identify resource allocation issues. The project leader has the responsibility for the timely delivery and budget control of the project, and be required to make decisions from time to time which effect the tasks and objectives of all team members.
• Ensure that wherever possible individual tasks are aligned with the personal areas of interest (within reason). Where possible it is important to encourage development of skills within a working project environment. Individuals will usually respond well to tasks that stretch their skill-sets, as long as they feel that the tasks are both realistic and relevant to the overall objectives.
• Ensure that a suitable working physical environment is established, which facilitates communication, but also encourages concentration.

An essential way of monitoring progress during development is project tracking. Tracking is achieved by further breaking down the schedule into discrete elements that are undertaken by individuals or specific disciplines, and monitoring the status and progress of each one. Tools such as Microsoft Project are specifically designed to facilitate this process, and useful ways of monitoring how a specific task is going, and it�s relationship and/or dependencies with other tasks. It is important for the team to have an overall picture of the entire development, specifically the dependency of other team members on the progress of their tasks. Project tracking is also a useful way of capturing knowledge from a project, reporting on the status of individual tasks and what influences there have been on that task. Also key to successful project development is change control. All requests for changes from clients and or management should go through the agreed change control procedure.

2.3 Test it, test it, and test it � beta test

Web sites have traditionally been tested at the end of development as a discrete stage in isolation. Ideally, however, by the time the project reaches the beta test stage, each individual element of the development should have already been tested in isolation, leaving the beta test as the �dress rehearsal� of the entire production. Where possible it is wise to test products with external agencies, or testing houses. It is important to fully document all issues that arise during testing, with a numbering system for logging issues and faults.

2.4 Fix it � bug fixes

All problems or defects that have been identified during testing need to be addressed. Using the Fault log, the team can address each item specifically, and choose to either fix the problem or not. It is important to document all changes that are made to the product at this stage.

Phase 3 Launch

3.1 It�s got to be 100% - final testing

Once bug fixing has taken place it is important to undergo a final test. It is often the case that the act of fixing bugs in the product can create new problems. Sometimes, problems are identified during the testing and fixing stages which, should they be addressed will take the schedule past the desired launch date. If this is the case a decision will need to be made as to whether to release on-time with defects or push back the launch date. Here, it is important to consider the following:

• How many issues need to be resolved, and how long each one will take
• How many issues have already been resolved and how long it has taken to do each one
• Which issues are essential to be fixed
• What are the implications of not fixing each outstanding issue

3.2 It�s alive � launch it

Once the decision has been made to go live with the product it is a good idea to implement a launch procedure plan. The plan should be a brief checklist such as the following:

• Where is the product being delivered? Ensure that details of technical and administrative contact are easily accessible to the whole team.
• What product is being delivered? Ensure that the correct version of the product is being delivered, and that an exact back up is stored securely.
• Are there are specific delivery requirements? Such as delivery on CD-ROM, or a specific type of connection.
• Have any irrelevant files been removed? During the course of testing and fixing, old versions of files often remain in the file structure of sites - it is important to check that all these files are removed before delivery.
• Is copyright cleared on all material used in the product?
• Has the correct sign-off procedure been followed, and is all relevant release documentation authorised?

3.3 Let�s get constructive � debrief

In order to gain maximum learning from the project, and also to ensure that all relevant information for future developments is captured, a project debrief is essential. The debrief should be undertaken within 2-3 weeks of the launch. Following is a list of the items which should be identified and discussed in the debrief:

• Project Schedule: Did the project team meet the major and minor milestones within the original scope, this should be a binary yes/no answer, and following that, what factors contributed to this outcome.
• Project budget: Did the project meet the original budget, and what factors caused this outcome? (There will of course be cross over between budget and schedule factors � however this is not always the case � it is therefore necessary to undertake these points separately.)
• Functionality: What changes have been made to the original functionality, and what where the reasons? What functional changes still need to be made, and why? What areas of the project need to be improved?
• Process: Was the process fully executed, if not why not, and what effect did this have on the project?
• Other learnings: Are there any other learnings which have been gained from the project, and what are they?
• Documentation: Has all the documentation been completed and stored?

Phase 4 Nurture

4.1 Fly my pretty � monitoring and maintenance

The Internet is a dynamic medium, and in order to establish a compelling web presence, attention needs to be paid to the ongoing maintenance and continual improvement of the site. To this end, a comprehensive plan for maintaining and updating the content of the site is essential. In addition, a programme for monitoring user behaviour and capturing useful user feedback should be complied. Feedback and statistics in combination with learnings from the development will enable constructive and accurate improvement objectives to be set.

Summary and Conclusions

The design framework detailed in this paper has been designed for website developments of varying sizes. It consists of four basic phases � with a number of stages in each phase. The underlying principles of the process are:

• Communication is essential for success
• Leave plenty of time at the beginning of the project for planning
• Make sure that testing is undertaken throughout the development
• Leave plenty of time for quality assurance at the end of the project
• Motivation of the team will facilitate creativity and innovation
• Consideration of the end user will produce a more appropriate product
• Web sites need to be maintained
• Documentation is necessary for longevity and post-project learnings

Any design process needs to consider both company size and company vision. It is pointless implementing a process, which is so resource intensive that it makes projects unprofitable. Additionally processes need to be developed with both the strategic objectives of the organisation, and the organisation culture in mind. Enforcing a strict methodology onto a relaxed and �freeform� work force is likely to have a negative reaction.

When implementing a process it is crucial to consider the employees to whom the responsibilities of fulfilling the functions fall. Where possible employees should be included in the development, as well as the implementation of the process. Where possible reward schemes should be incorporated to encourage following procedures accurately, and for constructive recommendation for improving processes. It is important to remember that developments in technology and society will inevitably have an effect on organisations� and their staff � therefore a constant drive to improve existing and develop new ways of doing things is necessary for both corporate and individual development.

The design process needs to facilitate and not hinder communication, and the communication needs to flow both throughout the team, and throughout the organisation. An essential component to both a successful communication and the success of the design project is good leadership; a project leader needs to be able to communicate throughout the whole team, and to balance corporate and team level objectives.