Scott Rippon [HREF1], User Interface Designer, Information Technology Services (ITS) [HREF2], Monash University [HREF3], Victoria, 3800.
Scott.Rippon@its.monash.edu.au
Documentation on the best practice process our team uses in designing/redesigning the information architecture of websites, the output from the different steps, and the issues we commonly face which make us deviate from best practice.
One of the tasks of the Web Resources and Development (WRD) team within the Information Technology Services (ITS) division at Monash University is the development of artefacts to assist in the development/redesign of the information architecture for Monash University web sites. The goal of the poster and this accompanying paper is to document the best practice process our team uses, the artefacts produced at each stage in the process, and the issues we commonly face in trying to promote best practice.
| Step | Step title | Description | Output |
|---|---|---|---|
| 1 | Identify the business goals and target audience groups for the site. | The business goals for a site help determine the type of content, resources or features provided to users. They also drive content/feature prioritisation. It is also important to understand who the site is being developed for. At Monash, we have a reasonably good understanding of our key target audiences, as they tend to be similar for most sites. The site structure, navigation systems, and content provided will all vary depending on the goals and audience groups for a site. |
Documentation of the business goals and audience groups for a Monash University web site. |
| 2 | Conduct a content inventory. | We advise clients to perform a content inventory. A content inventory details the content that presently exists on (or, in the case of new sites, is planned for) the site. The process helps identify:
|
A content inventory (generally a spreadsheet containing details of content and content groups on or planned for the site). |
| 3 | Undertake user modelling. | The users' understanding of the structure of the content is modelled using a method called "open card sorting". Users sort cards representing the content on the site into group of content that they believe are related. They are then asked to label the resulting groups. | Report detailing findings and recommendations from the card sorting exercise. |
| 4 | Create a sitemap and wireframes to reflect proposed structure/classification scheme. | Using the output of the previous steps a sitemap diagram is developed to show content classification and structure. Wrireframes — page schematics — are developed for key pages. They help communicate key aspects of the information architecture to clients. |
Content sitemap diagram. Wireframes of key pages within the site. |
| 5 | Test the proposed site structure/classification scheme. | Either a closed card sorting exercise, or a simple usability test is conducted to test the proposed site structure and navigation labels. In a closed card sort users sort cards representing the content on the site into predefined groups which are taken from the sitemap. In the simple usability test users are given a number of tasks and asked to interact with a paper based version of the sites navigation. |
Revised sitemap and navigation labels. |
| 6 | Template development. | Template development would normally be carried out by a development team, but in our department, we do design and development work. Using the sitemap and wireframes a set of templates is created. These are subject to a quality assurance process before being moved to a staging server where clients can migrate content and build the new site. |
Web templates. |
| 7 | User testing. | Once the site has been developed, final usability testing can be conducted. In this testing users are given a number of tasks and are asked to interact with the live site. This allows us to evaluate the effectiveness of the layout of key pages, the sites' navigation system, content classification and structure. |
Report detailing findings and recommendations from the user testing. |
| Step | Step title | Issues |
|---|---|---|
| 1 | Identify the business goals and target audience groups for the site. | Often the term "business goals" is not understood by clients. This happens for several reasons. First, we sometimes deal with administrative staff or web developers who are charged with looking after a business unit's websites. Often they are not familiar with the term. Other times, because they have little interaction with their management on issues of policy or strategy, they are simply unaware of the goals for the site. A key obstacle in identifying business goals is inadequate senior stakeholder engagement. This may occur because the web is still not seen to be a strategic business tool. It may be considered "too technical", or so simple "my 15 year old could do that". Often, we find that stakeholders become interested late in the development process. On doing so they begin to realise how a web development project will impact on them and other projects within their business unit. |
| 2 | Conduct a content inventory. | Performing a content inventory for a large site can be time consuming. Many clients and stakeholders have never done this and fail to see the need to do so. While we have attempted to address this through education and training, it is difficult to get the message across in a large organisation where a wide range of people are involved in decisions regarding web site development projects. Our team is not resourced to conduct detailed content inventories on behalf of clients, so when the client is unable to do so, we do a very high level audit and use that to assist in designing the sites' architecture. |
| 3 | Undertake user modelling. | For most small sites, user modelling is not performed, due to lack of resources and the urgency in getting the site created or redesigned. In these cases we rely on our team's knowledge which is based on research conducted on larger projects. |
| 4 | Create a sitemap and wireframes to reflect proposed structure/classification scheme. | On most small projects, the sitemaps we develop are based on our own high level content audit, and sketchy business goals. Given that most of these types of sites tend to be poorly-organised, we are still able to make significant improvements. |
| 5 | Test the proposed site structure/classification scheme. | Again, lack of resourcing often sees this step being skipped on smaller projects. However, we have developed a simple form of user testing which has become increasingly popular in the past 12 months. The method is relatively simple, quick and therefore cost-effective. We encourage the participation of the client in this method, and many clients are keen to get a first-hand sense of the success of the proposed architecture. |
| 6 | Template development. | Sometimes developers modify the site architecture to the detriment of their site. This may be done intentionally – through a need to stamp their own mark on the design – or unintentionally – through lack of experience or expertise. |
| 7 | User testing. | Lack of adequate resourcing often sees this step skipped on smaller projects. On larger projects there may be several rounds of testing and iterations of the design. |
Alexander, D. (2004), Preparing web content for migration, viewed 4 April 2005, [HREF4].
Garrett, J. (2002), The Elements of User Experience: User-Centered Design for the Web, New Riders Press, New York.
Kuniavsky, M. (2003), Observing the User Experience: A Practitioner's Guide to User Research, Morgan Kaufmann, San Francisco.
Lamantia, J. (2003), Analyzing Card Sort Results with a Spreadsheet Template, viewed 13 April 2005, [HREF5].
Maurer, D., Warfel, T. (2004), Card sorting: a definitive guide, viewed 4 April 2005, [HREF6].
Rosenfeld, L., Morville, P. (2002), Information Architecture for the World Wide Web: Designing Large-Scale Web Site, O'Reilly, Sebastopol.
Rubin, J. (1994), Handbook of usability testing: How to plan, design, and conduct effective tests, John Wiley & Sons, Inc., New York.
Snyder, C. (2003), Paper Prototyping : The Fast and Easy Way to Design and Refine User Interfaces, Morgan Kaufmann Publishers, San Francisco.
Scott Rippon, © 2005. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.