Website redesign – a case study

Download ‘printer-friendly’ PDF version (File size: 126 KB)


This document describes the redesign process for the Information & Design website.

The process we followed is not the only way to undertake such a redesign. For example,
it is perfectly feasible to conduct a redesign without consultation and without usability
testing. However, following a structured approach improves the probability that the new
version will serve the requirements of the business and the needs of the users.

This paper was written by Gerry Gaffney and Philipp Pagendarm. Thanks are also due
to Peter Grierson and Su Dharmapala, who were also involved at various stages
of the design process.

Background

The website in mid-2000

The Information & Design website was first launched in 1998. Since then, one major
structural change had been made.

By 2001, several factors indicated that a significant redesign was needed.

  • The site has seen a growth in content (from half-a-dozen pages to over
    one hundred)
  • Some material was no longer relevant and needed to be retired or demoted
  • The busiest part of the site (usability materials and resources)
    was relatively ‘buried’
  • There was so much information in the busiest area of the site that
    it was necessary to scroll the equivalent of two pages just to read the secondary navigational elements
  • Because plain HTML was used, many pages had to be updated whenever a new
    page was added. This was laborious and error-prone
  • The company had changed significantly since the site’s inception, and there
    was a requirement for the site to be more effective as a vehicle for Information & Design, while continuing to be a resource for the usability community.

The Analysis Stage

Analysis consists of gaining a sufficient understanding of:

  • Business requirements
  • User needs
  • Constraints (such as platform, budget and time)
  • Current content.

User and Business Requirements

Because of the nature of our relationship with our audience, we had a large amount
of information from our existing users. Most of this feedback tended to be positive,
and to relate the availability of the free resources on our site. Clearly, it would be
important for us to continue to maintain those resources. We had conflicting feedback
on the visual aspect of the design. Some users strongly supported the simple nature
of the site design, while others commented that it was ‘bland’ or lacking colour.

The amount of user needs analysis conducted was significantly less than we would
typically recommend for most clients (who may not have a strong day-to-day
relationship via the web with their customers).

While we felt we understood the business requirements, these had never been articulated.

We conducted two internal workshops to consider the issues and requirements,
and to develop design goals and scenarios. The workshops took less than a day
in total – this represents excellent value in terms of return on effort, because
the outputs of these workshops ifnormed the subsequent design activity. Refer to the
‘Website Requirements’ document in the accompanying zip file. (File size: 433 KB).

Constraints

In our case, our primary constraint was budget and resourcing. We did not
employ additional resources for the redesign, so work was done when the pressure
f other immediate project activity was low. Technology constraints did not present
any difficulty, as our hosting service provided all the features we required.

Current content (content audit)

It is important when conducting a redesign to ensure that all current content is
identified, and an appropriate action is taken for each piece of content.

This is a tedious job, but one which, if neglected, can cause much difficulty
in terms of problems with the redesigned site (especially in terms of broken links
and missing content).

We automated part of this task by using the command line to get a text list of
every element on the current site, and using that as the basis of a simple spreadsheet
(as shown here).

Content Audit Extract

See the ‘Content Audit Extract’ spreadsheet in the accompanying
files for a more detailed extract.

For each item in the spreadsheet, we noted its name, location, type, nature
(for example, graphic, document, form), size, owner, users, date created (or last
updated), and incoming links. This allowed us to decide which items would be deleted,
transferred to the new site, or treated in some way and then transferred to the new site.

It can be hard to decide what information will be required – erring on the side
of caution is sensible. You can easily discard excess information about any item; it
is more time-consuming to revisit items in order to gather information you failed to
get on the first pass.

(During the design stage, we specified the location of each item in the redesigned
site structure.)

The Design Stage

Once sufficient analysis and information gathering has been conducted, it is appropriate to move into a stage of active design.

The usual process is to use personas (user profiles), scenarios and specified requirements to conduct one or more participatory design workshops. This is the opportunity to get buy-in from various business stakeholders, to elicit specific user input, and to get initial design ideas. On client projects, this activity often brings into the open issues and requirements which have not yet been adequately tackled.

Reviewing the requirements enabled us to identify the total amount of content required, and we undertook affinity diagramming exercises to group this information in meaningful ways. ‘The Content Cards Extract’ document in the accompanying files shows some of the content. We printed this on cards and sorted the information into groups in order to come up with a structure for the new site.

Note that we did not have a card for every item in the site. For example, individual graphics were known to be attached to specific documents, so identifying the location of the document also implied the location of the graphic.

We held several informal design sessions. We made a decision to maintain, where practical, the same simple navigational structure already in use, but to break it down into smaller and more modular elements – this would improve the user experience and make the site easier to maintain.

Partial view of the Site Structure

The structure was documented, and each element given a number. This was documented in a ‘Site Structure And Templates’ document (contained in the accompanying files).

Evaluation can take place at various stages of the design process. For a large site, initial evaluations can and should be conducted early – even before a working prototype is available.

Since our site is relatively small, with homogenous pages, we conducted a usability test using a working prototype of part of the site.

Prototype

The Evaluation Stage

We tested using several scenarios, including the scenarios that had been developed during the analysis stage – this is good practice as it allows you to confirm whether the design is meeting the original requirements.

See the Usability Test Plan for more detail on the usability testing, and the Usability Test Report for the results. Both these documents are in the accompanying files.

Philipp administering a usability test session

The usability test revealed several issues – most of which were relatively easy to address. We made several minor changes to the design as a result of the testing.

The Technical Design Stage

Now that we had a site whose operation was satisfactory from a user perspective, we needed to implement the site, and to document it for maintenance purposes.

We used Microsoft Active Server Pages (.asp) and JavaScript. We also Cascading Style Sheets (CSS). The earlier version of the site had used relatively primitive CSS.

Navigation was implemented using dynamic navigation. The navigational structure is saved in a file in the root directory. This allows for relatively easy global changes, and has proved enormously more efficient than our previous HTML version.

Several issues arose during this stage. For example, how would we manage the fact that we were switching from HTML to ASP as our file extension? We did not want to use the ‘redirect’ facility as this has usability issues. Nor did we want to maintain a family of redundant pages. We eventually settled for an error page (for ’404′ errors) with links to the Home and other commonly-used pages.

Having tested that the design worked, we migrated all content to the new structure, and launched the site in May 2003. We chose a launch date in a holiday (Easter) period so that fewer visitors would be affected by any teething problems (in fact there were no problems).

Over the subsequent several weeks, some problems did emerge – particularly in the differences between CSS-handling between browsers. However, we felt that our reasons for choosing CSS were still relevant, and did not back away from this position.

We documented the steps required to add, delete or change the site content and structure, so that it can be handled by any appropriate person in the future.

Conclusion

We retained the original vision for our site, while improving its operation and appearance, and meeting most of our original goals. We should conduct further usability testing to validate the changes made. However, given that we were satisfied with the results of the testing, and have made minor changes to address these changes, we had a degree of confidence that the new site represents an improvement, from a usability perspective, on the previous version.

The cost of conducting the usability activities described in this document were minimal, resulted in useful changes to the site, and provided a degree of confidence that our new design was ready for launch.

The techniques we used were simple and, if conducted carefully, should result in quality benefits for any organization.

The new site