Industry News   In Practice   The Bigger Picture   Digital Marketing   Your Business  

Latest Articles

The Community Glue

Penny Power, Founder of Ecademy, looks at Community Managers and what they can do to help their Social network survive.

more

More Everything - The Ofcom 2008 Report

UK consumers are spending more time on communications than ever before but paying less for the privilege, according to UK telecoms watchdog, Ofcom.

more

Parents Fear For Networked Kids

Internet experts have called on social network sites to do more to protect children as a survey reveals that three-quarters (72 per cent) of parents spy on their children.

more

Related Articles

Related Events

The Website Design Process - a Framework

Filed under: all articles
Tags:
By: NMK Created on: January 27th, 2004
Bookmark this article with: Delicious Digg StumbleUpon

Zoe Black, NMK's Programme Director, outlines a process for the design of interactive products such as websites.

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:

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:

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:

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:

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:

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:

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: 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.



Comments

You must be logged in to comment.

Log into NMK

 Register
Lost Password?
Login

Newsletter

For the latest news from NMK enter your email address and click subscribe:


Subscribe

NMK on the Web