...back to skills / 1 2 3 4 5 6 7 8 9  / home
4. application design

A web application - a web-based piece of software that collects, works on, and delivers information - is what makes a business-driven, goal-delivering website different to a collection of static pages.

It stores information in a database rather than as static text in HTML files, and web pages are assembled by the application in between rather than being stored as complete pages.

Redpump's method is to write use cases that detail the customer journeys into, around, and out of the site - and integrate them into a conceptual model of database, application, and frontend website. A very large website will contain some 60 use cases; a simple one about 1-5. Use cases are an ideal base for creating the information architecture.

A single use case specifies the inputs and outputs of a single goal (such as 'sign up as a subscriber'.) It includes one diagram of how actor and actions interact to produce the main result wanted, plus a list of supporting info that adds detail. A set of use cases describe the totality of what the site needs to do, and makes the process of creating the site far faster and more purposeful. It's all about answering three basic questions: What happens? Then what happens? And lastly, What else happens? That list is built from this template:

Iteration
Facade, filled, or focussed? The stage of completion the use case has reached.
Summary
In one or two sentences, describe the interaction between user and system that happens in this case.
Basic course of events
Describe the steps that the actors and the system go through to accomplish the goal of this use case (the actor always takes the first step, and then the system responds). This goes back and forth until the goal has been accomplished and value provided to the actor. Include URLs of the pages the user would see on his quest where necessary.
Alternative paths
If the basic course of events is the path most travelled, these are the paths less travelled. Listing these separately from the basic course of events lets us avoid using 'codey' stuff like IF-THEN-ELSE in use cases.
Exception paths
Unlike alternative paths, exception paths are the paths travelled when the user does something 'wrong' according to the system's context. I.e. the sort of things that'd normally throw a 404.
Extension points
An extend relationship shows an association between use cases. It's best to avoid these since they lead to the dreaded hierarchies which use cases try to defeat. If there's anything in here, it's a clue to try and do the use case a different way.
Triggers
These are the entry criteria for the use case - a list of the conditions you expect to be true when the actor enters this use case, such as the completion of another use case.
Assumptions
Things we expect to be true in the outside world when the actor enters this use case, such as knowing how to click on links.
Preconditions
Things that must have happened in order for the actor to enter this use case. Different from triggers triggers refer to conditions within the system that drive the actor's interaction along, whereas preconditions simply create the opportunity for the actor to enter this use case. They're part of the 'contract' between this use case and the outside world, and are outside the scope of the system being built - for example, the actor must be a human.
Postconditions
Postconditions are also part of the contract between this use case and the outside world. They're the result of a user's successful interactions with the system, such as a project being completed or team members being introduced to each other.
Related business rules
These are the business conditions (not system rules) that give rise to the need for the system, such as people needing to work in a team. They provide background for the coder, letting him fit his work into the broader context.
Author
Whoever's responsible for writing and maintaining the use case.
Date/edit history
A list of updates and revisions with dates.

From a set of use cases it's possible to design the web application - all the 'moving parts' of the site and how they fit together. It means working out how information is gathered (a signup form) how it gets filed away (database reqs) what happens to it (business rules) and how it's used by the customer (saving his profile.) I use XHTML/CSS web page mockups, hyperlinked together, so the user experience and content strategy are incorporated early.

Use cases are hard, but ten days spent on them may save a hundred days of execution time. Next user experience.