From requirements to a designed web page: best practice & process

Obviously different sites have different objectives based upon business and customer needs. However, you might broadly categorise sites into two groups. One group includes sites which have a much more tactical brand and marketing purpose. These might include competitions, games, special promotions, micro-sites and similar. Simple, static ‘brochure ware’ sites can also be included in this broad group. These types of site often have a limited shelf life and are designed to meet a particular purpose for a finite time span. For these reasons, the maintenance and evolution of such sites is less important. Equally, there is a lower requirement for well defined processes to support such sites.

The second, much larger, group of sites serves longer term strategic objectives. These sites are more complex, perhaps in multiple languages, with a higher volume of content turnover and more contributors. These types of site are likely to grow in importance. They require processes to optimise efficiency and quality. The larger or more complex such sites get, the greater the requirement for a robust content model, information architecture and page templating. Without these elements it quickly becomes uneconomic to maintain and evolve such sites.

Clearly, sites cannot be rigidly classified according to just these groups. Each site will sit somewhere on a continuum between these two poles. However, it is important to realise the difference in approach required as sites graduate towards one, or the other, pole.

There are two quite different forms of ‘creativity’ that are required when designing pages for these two groups of site. For the first group the creativity required is perhaps more what is more commonly thought of as ‘creative’ and focuses most on look and feel, branding, layout, colours, fonts and so on. The second group of sites requires this too but there is a further requirement to think creatively about functionality and understand how the front end (the page that the user ultimately experiences) ties in to the back end.

In this latter case, creativity needs to occur whilst mindful of the parameters set by the underlying content model. In this case there is much creativity required in exploiting the way that the presentation layer interacts with the content layer via business logic, templates and rules. This is not a form of creativity that is solely the domain of an interactive designer but is the joint responsibility of a multi-disciplinary Web development team. This kind of creativity requires a fusion of business acumen, customer insight and an in depth understanding of the medium and its technology. Unlike the actual design of the point of interface with the end user, most of this creativity is ‘invisible’, like the majority of the iceberg that is not seen below the surface.

Assuming we are talking about the second group of sites mentioned above, and assuming you have the right mix of skills in your development team, what is the process to follow in moving from a set of requirements to a designed Web page? I would propose the following:

***1. Business and Customer Requirements.***
Draw up a list of business requirements and customer ‘requirements’ i.e. things that you know from your customer research work which the customer really wants. Use these to drive your initial conceptualisation of what the customer offering might be and how this might best be supported online.

***2. Audits***
If the first step looks at the requirements in abstraction, at this stage you should look through what is actually available and possible given the resources of the project. Do content and functional audits both on any existing sites and on competitor sites to benchmark best practice. Audit existing customer behaviour through both qualitative and quantitative analysis.

***3. Recommendations***
By mapping the requirements against the audit results, and given project resources, come up with a set of recommendations for the customer experience, including content and functionality.

***4. Content model and site map***
At this stage do not define the final content model, including details of every content object, attributes, metadata etc. However, do start to build a working ‘skeleton’ and a framework which works at a content class level. Closely aligned to this you should also develop the first ‘site map’, showing the content sections of the site. This is likely to iterate through the project in its details but not so much in its top level categories.

***5. Customer journeys***
Begin to model examples of customer journeys. You might use UML practices to construct use case scenarios. This is sometimes supported by other techniques such as action/response tables for more precise definitions of the expectations of the system and ‘wire framing’ of pages in PowerPoint. Begin with the ideal customer journeys (i.e. what you would like the customers to be doing), then look at the likely most common customer journeys before addressing exceptions, deviations and less likely routes. At this stage page content is not defined in detail. What you are ensuring is that the primary routes that will create customer value, and serve your business needs, are properly thought through and outlined at this stage.

***6. Navigation***
Having mapped out key customer journeys, and iterated the content model and site map accordingly, you are now able to define the navigation that will best support the user in achieving his or her goals. At this stage you should define generic navigation, and navigation rules, as opposed to specific in-page navigation.

***7. Page content***
Now you can really begin to look at every page in detail and define what content, navigation and functionality will be on each. Do this by starting with simple flip charts and a group brainstorm to capture ideas for each page. Then create ‘paper prototypes’ in PowerPoint and use these as a tool for iteration.

***8. Page templates***
As you become clearer on what content and functionality will be required across a range of pages you are able to begin defining templates as you can see common content and functions emerging. You should then create a set of templates to deliver all pages in the site. Seek to minimise the number of templates without compromising what you are trying to achieve at a specific page level. By the end of this process you have a set of templates and are also in a position to drill down to the detailed data elements of the content model.

***9. Page design***
Only now is a ‘look and feel’ applied to the templates and specific pages. Effectively the skeleton you have developed is now being ‘skinned’ with the brand in question.

Although it may be only at the last step that *graphic* design begins, you should see this whole process as being about interactive design. It is interactive design that is needed if you are to successfully deliver the kinds of sites I talk about in the second group earlier.

What do you think?

Ashley