(This is an extended version of an email I wrote to one of the local tech mailing lists here in New York, in response to a developer's question. It seemed generally useful enough that I'm reposting it here.)
A very common design problem in web services project these days is the issue of user search. Most web services now involve pools of data that are far too large to be entirely "browseable", even if we're only talking about finding another user on the service. Very quickly you start to see a specification develop of increasing complexity, involving boolean ("AND/OR") concepts, keywords, and all kinds of other demands targeted at extremely precise results tailored very exactly to the knowledge domain or data set. What's the best way to go about building this user experience?
Your answer here has to depend a lot on who your end user is, and how regularly they use the system to make queries. If you are targeting engineers, or maybe salespeople who will be trained to use the site and use it every day, your interface can be relatively complex and look a lot like the "query builder" type systems we've been discussing. If it's general end users, many of whom will only use it once or twice, you're going to have to figure out how to simplify things so enormously that they really don't even know that they're "building a query."
There's an O'Reilly book entitled "Ambient Findability: What We Find Changes Who We Become
Also, my experience has been that clients generally have very complex mental models of their own knowledge domain, and tend to ask for the search system they would want to use, which is often terrible for their customer or end users, because those users have little idea of what their systems of categorization look like. A pretty good example of this is your average real estate broker's web site: it has a complex, parametric query that is probably very familiar to an experience broker, but can be extremely frustrating for a "normal" end user.
(A lot of this pattern is also linked to the tendency of both parties to think in terms of "corner cases" when designing the query interface, rather than "typical cases." The point is not to create the most precise possible search form for a search where you already know your target.)
If you are targeting end-users, I'd recommend multiple rounds of use testing both before and during the dev process. Try something like card sorting to test categorization/tagging and also try showing them some mock-ups and asking them how they'd try to do a typical search (both ones you suggest and ones they think up.) And once you have some working prototypes, try using software like Silverback to record and document use tests.
It's a lot better to have a search system that your expert users (primarily you and the client) think is way too simple than have one that your target users think is way too complex. (And the simpler one is usually cheaper to build.)
I'm going to put up a post on iteration soon, but for now, here's the heart of the answer from a practical standpoint: Build the simplest possible search interface to start with, test it with real users, then go back and add controls or features if you find they are absolutely necessary. Don't test it with the client (at least not for purposes of figuring out if it's a good design) -- the client is most likely not your end user because they know the domain so much better than a regular person. (That's why they're in that business, after all.) It's much easier to add a feature or two than to remove features you've already built and offered to end users. And it's much easier to figure out what needs to be added during user testing then figure out what needs to be removed.
Leave a comment