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

Hi David

An excellent post if I may say so...

In reply:

1. You are absolutely right that, in practice, things are much more fluid and iterative than my process (or any process, for that matter) might suggest.

2. I think your final point ("...a move away from defining processes in too much detail, and instead having a range of tools to call on at particular stages of a project in order to solve particular design problems. I would like to see best practice defined as a process AND a toolbox") is an excellent one.

I entirely agree. I do think that it is important to have a standard process to work to as this provides a framework and a common language. I don't actually think it matters too much whether it is RUP, PRINCE2, DSDM, RAD, PACE, or indeed the process I suggest in my first book. What you should do, however, as you suggest, is use techniques and tools from these, and other approaches, as required. It matters less what you call things (I say 'user requirements', you say 'goals and tasks') but more what tools you have at your disposal. You don't need to know everything about UML or the Rational Unified Process to make good use of 'use case scenarios' ('user journeys' to the more prosaic of us), for example.

3. 'Content model'. Of course now we are going to be victim to the fact that we *do* confuse terminology... ;). I take a fairly data-centric view of 'content model' and have quite a strict understanding of what goes into a content model. This is particularly handy and relevant when it comes to content management and CMSs. It is related to information architecture and navigation etc. (what the user experiences) but not with a fixed relationship.

I go into this a lot more in my second book, coming out soon, but here is an adapted extract which looks at this a little more - at least it might help provoke some further thoughts on how 'content model' relates to 'information architecture' which is your area of expertise...

"The content model is also sometimes referred to as a content taxonomy or content schema. It is at the heart of what is more broadly referred to as information architecture. The content model is the underlying structure of your content so connotations of architecture are indeed apt: the content model is the blueprint and infrastructural skeleton to which is then added the flesh and skin. It is relatively easy to change the decoration of a room, or the clothes that you are wearing, to change outward presentation, but it is much more difficult to change the infrastructure that underpins it.

Think of your content model like a matrix, rather than a hierarchical tree, with different axes that allow you to view your content in different ways. You need to figure out what it is you need to do with your content and then design a unified framework which will serve your purposes. The following are common content axes that go together to build a content model:

# Users. Users can be grouped by numerous attributes: by behavioral characteristics, by name, by client, by permission level, by gender, by age range, by interest group, by job or by geography.

# Products. If you are in the e-commerce field then you are no doubt quite used to product taxonomies and catalogs which structure your product information.

# Topic. Certainly if you are in publishing you will likely need to structure content according to its subject matter.

# Type. This might be the type of content asset in terms of format (video, text, imagery) or other classification (article, news item, case study, press release, white paper and so on)

# Channel. If you are delivering your content across multiple channels then you are going to need a way to retrieve the right content for the right channel. This does not necessarily mean creating different content for each channel which, though sometimes necessary, defeats the objectives of content reuse and repackaging offered by content management. However, in your content model you need to think through how content might need to be tagged in order to then automatically configure it for use through the particular channel.

# Business area. Particularly for business to business sites, you may want to structure your content according to business disciplines, by sector or industry.

# Location. This is particularly important if you are dealing with a multi-lingual or international site where different content, or slightly different versions of content, are required for each location. If your content model does not contain a way of retrieving content by the relevant locations, how can you effectively manage and publish that content?

A content model contains the following elements:

* Content class – for example, with e-consultancy, we have a ‘white papers’ class or a ‘admin users’ class

* Content objects – for example, each white paper record or admin user profile

* Data elements – the actual fields within the white paper record, including both what users see (display data elements) and what the system requires (management data elements).

The content model is at the heart of any content management system. It is the intelligence which the engine needs to drive not just the collation, management and publishing of content to a site but also provides the framework for personalization, community, analytics and reporting. As such it is extremely important to get right. Yet it is very tough to define within the organisation. Why? Because the content model is a distillation of everything that the company is, understands about itself and wants to be. The architecture may be defined by customer segments, by content types, by business units, by country or by product lines as outlined above. Who is to decide? Who can decide what is, effectively, the blueprint for the company now and in the future?

Imagine you are a global financial services organisation which is structured internally by business units, some of which have international branches and some of which do not. You then have financial products most of which must be sold differently in each country because of legislation. Some of them, however, can be sold only to certain types of client, irrespective of which country they are in. Then you have your customers, who you group not by product line but by characteristics that define the way they invest in order to help you cross-sell your products. You can see that there are fairly clear axes here along which to build a content model but you can equally imagine how hard it will be to reach consensus over which elements are required and which are not to create the desired end result.

Defining a content model forces you to go to the very core of your business and draw up and prioritise fault lines that will enable you to deliver the most value. Choosing and integrating a content management system may seem a daunting task but it is far easier, and far less important, than defining a content model, a process which must be fully integrated with overall corporate strategy. Your content model is an important strategic intellectual capital asset, representing the ultimate distillation of business and customer.

***A Site Map is not a Content Model***

Which comes first the content model or the Web page? Do you build up from your content model and end up with a Web page or do you design a Web page that will work for your users and then work out what the content model to support it is? Well, both. Ideally you should create your site focusing on your users’ needs but also have in mind commercial constraints and requirements, one of which is your ability to support a particular content model. As ever, iteration is required and a multi-disciplinary team who can juggle priorities and make the best trade-off decisions.

A site map outlines what the content sections of a Web site are, as seen from a user’s point of view. A site map is hierarchical: it shows what content is in what section or sub-section. As such a site map typically also dictates the site’s navigation. Site maps, as visual representations, are very bad at showing inter-relationships or cross-references. If you have tried to show these you will know you end up with an organogram that has arrows drawn all over it to the point where it is useless.

A site map shows what is on a site and where it is ‘located’ within a navigational structure from a user’s point of view. This is not the same as a content model. For a start a content model does not need to be hierarchical. Parent > Child relationships are needed with navigation but the information axes that make up the content model matrix are not hierarchical. Also, there is no hard-coded relationship between navigation, as a content access method, and the underlying content model whereas there is a very definite correlation between a site map and site navigation.

The e-consultancy content model structures content by twenty-four topics and yet these do not appear in the navigation: they are used for filtering searches and for tracking what subject area a user is interested in across all the content sections of the site. Is it more useful to know that a user looks at particular content sections (white papers, for example) or that she is interested in interactive advertising generally? Either way, the point is that the content model, although often closely related to a site’s navigation and site map, is separate. If you have well structured content according to a well defined content model it is quite easy to change your site structure and re-jig your site map. If all you have is a site map, then restructures are painful."

I'd certainly agree with your analysis Peter. So what do you understand by 'information architecture' which gets used a lot as a term?

To me it is a broader term encompassing all levels. However, perhaps the skills required at the various levels are different? I've known people who go by the job title of 'information architect' who basically do interface design, or others who do site maps, and only a few who go to deeper levels...

Ashley