"Search for X" Considered Harmful

Many of use employ Use Cases as a tool to help design software we write. Maybe we want to be hip with the techniques the cool kids use, or our bosses tell us we have to start using "that RUP thing," or we just like drawing the stick figures.

Regardless, use cases are a good thing. User-focused, goal-oriented. Good stuff. I have one pet peeve, though.

"Search for X" is not a use case.

Your system should probably not have a "search for widgets" use case. Unless you have people who show up at the office, pull up to their desk, search for something and upon finding it throw up their hands and say "I'm done for the day," searching is not a primary use case.

Certainly, your users will need to navigate to the correct spot in the application. They might need to find things, too. Say, the correct invoice to post or the correct account for an expense report. But the searching is secondary. Searching is part of getting something done, not the thing to get done.

The "search for X" use case is a use case only a geek could love. "But you have to search" says the nerd. Another developer will argue, "we have to know exactly what they want to search for...to write the SQL." While this is all true, it almost entirely ignores the point of a use case: to be focused on something of benefit to a user. Us getting our joins straight isn't of direct benefit to the user.

Applications with "search for widget" use cases are easy to spot. They have big, obtrusive search functions. Every table in the database is represented in the window, often with multiple options per field. "Starting with X." "Contains X." "Ends with X." "Between X and Y." Almost invariably, if you do some user testing, no one uses every field or option in the application. Most people search for one thing, one way, and ignore the small forest of fields and menus sprouting from the screen.

Choose use cases carefully. Think about whether you need the search function to be central in the application -- should it be visible at all? Could you accomplish the same tasks by displaying a cleverly crafted list of stuff, mostly eliminating the need for most users to search for things? Search functions are often a manifestation of the underlying data storage. As yourself whether your search function is a necessary part of the system, or whether you are exposing too much of the relational model to avoid collecting more detailed requirements.