The first question you’re probably thinking of is, “so, when do we get to do wireframes?”

The world isn’t only wireframes, little grasshopper.

What we are going to talk about is use cases. I write a lot of high level use cases in responding not only to request for proposals, but also for determining user needs when constructing the wireframes. Whether I do wireframes first or use cases first really depends on my mood of the day, what kind of project it is, and how complex the project is. In other words, it depends.

Sometimes I do the wireframe first to determine what the detailed use case is, or to spot any branches or scenarios I might miss. However, wireframes are time consuming (and I do them because I don’t like doing Photoshop mockups even more), and I think in bulleted lists, which is how I usually do use cases.

What’s A Use Case?

A use case is a set of five requirements for a task or set of tasks:

• A description of interactions between the user (normally referred to as the actor)
• The system the user is interacting with
• The scope of the interaction
• Dependencies associated with the interaction
• The goal

The use case covers branches, error messages and edge conditions; the main reason for use cases is they are used as a communication tool with developers so they know exactly what’s going on with the system, and how the system should react. The use case will also list dependencies like “user must be signed in.”

When you describe a use case, use active tone i.e. Register as a user, Pay for merchandise, Read mail are typical examples of how I would describe a task the user would take, and I may describe every interaction that user would make in completing that task.

Paying for merchandise may include error messages like:

• Invalid credit card
• Address doesn’t match credit card
• Name doesn’t match credit card
• Expiration date isn’t valid

A good detailed use case will cover every interaction and what to present to the user.

Why Use Cases?

Use cases are tied to personas in that they should describe what the system has to do and how it meets the needs of the target audience. Use cases also ferret out new needs and opportunities that may expand or control the scope of the application.

Detailed use cases are also used as a communication tool with developers: if the team is close knit, information architects and developers discuss the use cases and do a walkthrough so the interactions can be discussed in context with the rest of the website or application. Sometimes, the use case discovers technology barriers that require rethinking the use case or changing the use case to meet system requirements.

As much as we would like to think it’s the case, we can’t design in a black box: something always works not the way as we thought it was going to.

Use cases don’t talk about specific technologies, but they do talk about what the interactions have to do, so technology needs are a very important component of describing the requirements and scope of a use case.

Well documented use cases translate to excellent test plans because they cover every interaction, and are also useful for writing unit tests, which is what developers use to test their code before it’s complete. Good documentation and communication leads to less misunderstandings of what needs to be built.

Use cases that are well written are very effective tools for considering every situation the user or actor may run into, and limit development time because more communication means less question about what has to be built, and what quality assurance will find upon testing the website or application.

Should You Write A High Level or Detailed Use Case?

That depends.

Sometimes.

Not Always.

If the system you developing for is a platform and has a bunch of functionality already defined, listing out the high level use cases may be sufficient. Where I work at, we do a lot of SharePoint implementations, so we use high level use cases to make sure we’ve covered all the needed content in a website. SharePoint (as with a lot of software platforms) has a lot of functionality out of the box, so describing a use case at a high level is usually enough to get the developer started in development and figure what tool or component to use to satisfy the use case.

Detailed use cases are very useful if there’s a lot of custom development that needs to be done, because the last thing you want to leave to software developers is for them to determine the user experience. Detailed use cases also expose flaws the design patterns or technology that may require workarounds or alternate solutions.

What Tools Should I Use To Create Use Cases?

I know there’s a lot of people out there that spend a ton of time creating use cases using Unified Modeling Language — all the power to them — but the tool I use most often is Microsoft Word.

I hate stick figures. I dislike stick figures. I hate stick figures.

I’ve thought about using or creating another tool using PHP and web-based applications, because use cases are fairly repeatable, but I’m just lazy. I write my use cases out in bulleted or detailed form, depending on my needs, and one of the best books I’ve purchased for serious analysts is Writing Effective Use Cases (Agile Software Development Series). Seriously, Allstair Cockburn is a god in my eyes, because he hasn’t sold himself to the devil like Jacob Nielsen or Jesse James Garrett, and he’s provided a useful publication to boot.

Look at your organization and decide what kind of tool is best for communicating to your developers: some of them work best with wireframes, others with written documentation, even more with a white board and sticky notes. A few that I’ve worked at loved HTML click throughs or Azure mockups, because the use cases could be walked through from a user perspective. Most imporantly, if it’s agile and prevents rework, you’re doing the right thing.

Other Resources

• A List Apart’s article on use cases
• Rizwan has an effective, if organized, list of tips on writing use cases.
• This is a great post on Use Cases for User Assistance Writers.