In part one, Michael Swanson discussed several ways of using Use Cases to maintain programmatic and data organization, among other topics. In part two, he discusses Use Cases and their application to website design, specifically as it concerns the backend interface, maintenance, and interaction with customers. Introduction

In the previous article on Use Case design I discussed how to use Use Cases to suggest good visual layout and page hierarchy as well as programmatic and data organization. This article will focus more specifically on examples and specific tasks in website design that Use Cases make easier and more organized. These tasks will include: improving backend interface, helping a programmer or designer actually interact personally with customers, designing a site to specifically match a customer's needs, and finally helping with building a website that is easily maintained and expanded to meet the future needs of a client.

Backend Interface

Every dynamic website has a backend interface that is at least as complicated as the front-end, if not significantly more complicated. This interface is often shortchanged in terms of design for ease of use. At the same time, this interface often receives as much use by as varied a user group as the front end. The users at a client whose jobs it will be to update the content of a website will become intimately familiar with this interface. Therefore, it is important to keep Use Case design concepts in mind for this interface as well.

When designing this interface, it may be useful to go somewhat beyond simple Use Cases to make sure the interface is both easy to use and simple. Getting input from actual end users, especially if they have a previous website that they are used to working with, can be priceless. Making a switch from an old website to a new one can be difficult. If you, as a programmer or designer, find out exactly what about the old website backend users found good and what they found bad, you can make the switch easier.

Specifically, this can take the shape of something like the following. When you complete original specifications and Use Cases for a website, split them into backend specs and frontend specs. Then, set up a meeting between yourself and the actual employees of your customer who will be working day-to-day with the website backend. At this meeting, take them through your backend Use Cases step-by-step, explaining each Use Case as thoroughly as possible.

Find out any questions or comments the users might have at this point. It is important to do this objectively. What a programmer might think of as a really neat interface trick or something that is very slick and streamlined, may in fact confuse the end users for whom you are writing the software. Therefore, make sure that you take all of the suggestions from this user group seriously, as they usually have a good understanding of how they want a website to work and what sorts of interface standards work well for them.

About the Author

Use Case Design for Websites, Part 2