Creative Brief

This rang a bell:

The [perfume] executive told me, “Basically it’s ‘We want something for women.’ O.K., which women? ‘Women! All women! It should make them feel more feminine, but strong, and competent, but not too much, and it should work well in Europe and the U.S. and especially in the Asian market, and it should be new but it should be classic, and young women should love it, but older women should love it, too.’ If it’s a French house, the brief will also say, ‘And it should be a great and uncompromised work of art,’ and if it’s an American brief it will say, ‘And it should smell like that Armani thing two years ago that did four million dollars in the first two months in Europe but also like the Givenchy that sold so well in China.’”

I’ve been thinking a lot about niche product design lately — mostly because of a particular project I’m working on which I can’t talk about except to say that the target market they’re going after is nearly as broad as what the parfumier is complaining about here. So we keep running into features that are a necessity for one type of user, but which are irrelevant or even actively interfere with another type of user. So we keep finding ourselves having to make decisions about which users’ needs should override the others at any given point.

This happens in all products, to some extent; whether you realize it or not, every feature you add makes the product more useful for some people, but less useful for others.

If a feature is simply irrelevant to some users, that’s a minor usability cost for them because it’s just menu clutter. More costly are the features that are useful for two separate sets of users, each of which would want the feature to work in different and conflicting ways.

(I can tell right now I’m going to have to come back and rewrite this with examples after Mystery Project X comes out from under wraps… just to keep this from getting too abstract, take word processing. Some users are writing books so want font controls, layout controls, automated tables of contents, etc. Some users are writing software or building web pages, so need syntax highlighting, auto-indents, code completion… Both sets of users are writing text, so in theory you could try to write one text editor that fits both sets of needs. But you’d wind up with an incredibly cluttered, unwieldy product that wouldn’t serve anybody’s needs very well. That’s an extreme example, but you get my point. (And it’s not completely unrealistic, either, he said, pointing grimly towards Microsoft Word’s “Save as HTML” feature.)

So. There are two ways you can try to go with that decision-making. First, you always choose to enhance one particular group’s experience at the expense of the others, and wind up with a highly focused niche product. Or, you try to please some sufficiently large subset of “everybody”, accept a certain amount of clutter, try to avoid adding things that actively interfere with too many peoples’ experience, and aim for a generalist product that isn’t perfect for anybody, but is good enough for most of them.

There’s not a lot of middle ground; most products slide pretty far towards one end or the other. There are economic reasons for this (search for “free, cheap, and dear” here) but just as important is that the more specific and targeted your features are, the more they tend to get in the way of people who don’t happen to want those particular features. Products that wind up in the middle of that range are usually there because of muddy thinking or feature creep, not because anybody planned them to wind up that way.

I’ve been wondering — here’s the point, at last — whether web applications are an opportunity to bridge that gap on purpose, though.

A shrinkwrapped application has to be what it is when you put it in the box; you can only put one perfume in each bottle. But online software can be customized for different sets of users; instead of having two conflicting interfaces for a similar feature, have two separate interfaces. Reuse the same back-end code when you can, branch when you need to. It then becomes less a matter of targeting one set of users, than of targeting several distinct sets of users with what appear to be distinct products.

This is nothing new from a developer’s point of view, of course: every shared library or reusable widget is an example of this kind of thinking. But I haven’t seen it applied to whole applications yet; not in any coherent way, at least. (The closest example I can think of is the Microsoft’s horribly misguided attempt to reduce menu clutter by hiding items you don’t use very often: great in theory, but in practice leads to a lot of “where the hell did that thing go?” And that only addresses the too-many-features problem, not the conflicting-features problem.) More to the point, I haven’t been able to sell the owners of Mystery Product X on the idea.