Application design
A web application - browsable software that collects, works on, and delivers information - is what makes a business-driven, goal-delivering website different to a collection of static pages. And it's the core of any scaleable marketing campaign or customer relationship management programme.
A web application stores information in a database rather than as static text in HTML files. The pages a customer sees are assembled by the application as needed, based on what it knows about the customer (fresh lead? Hot prospect? Known customer?) rather than stored as complete pages. Capturing the business functionality and customer journeys into and around your customer's interaction with you is the basis of application design; it's a conceptual model of database, application, frontend website, and surrounding campaigns and programmes across media.
Capturing business functionality is best done with use cases. 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 (the 'ideal case'), plus a list of exceptions (the 'non-ideal cases') where the optimal outcome doesn't happen (and how it's dealt with). A set of use cases describes the totality of what the site does. (A very large website will contain some 60 use cases; a simple one about 1-5. Use cases are also an ideal method for planning the information architecture.)
It's all about answering three basic questions: What happens? What happens next? And what else happens? Here's a useful template when writing a use case:
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.
Ideal 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 ideal course of events is the path most travelled, these are the paths less travelled. Listing these separately from the ideal 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 - 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 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.
It's also best to include summary data:
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 - without coding. 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.