I read an article this morning on TechCrunch by the co-founder of a mobile app company (they make “Bump”, which shares contacts or other data through phones’ NFC chips). He was talking about the difference in understanding of technology between the creators of that technology verses their target market. It’s not a bad article, although the points are reasonably well rehearsed. But I think he’s misunderstood the problem slightly.
According to David Lieb, the article's author, for the mass market, things should be very, very simple, at the expense of features. Bump’s creators apparently discovered this idea and helpfully named it for us, “cognitive simplicity”, although I doubt the notion will be a surprise to many. The other side of the coin is “cognitive overhead”, a more widely used term for the brain power necessary for the uninitiated to understand a point or operate a tool. With delightful irony, a number of the comments below the article (as well as complaining about the rehashing of well-known ideas) pointed out the “cognitive overhead” of giving jargon names to straightforward concepts.
The article implies that technology producers often simply do not understand that non-techy users could struggle to comprehend how something they’ve designed operates. This is almost certainly correct in some cases: it’s easy to overlook the learning curve of an item you’ve been intimately familiar with since its inception. By and large though, I think it’s a problem of scale rather than intent – it’s actually quite hard to make something simple without losing the essence of the product or what differentiates it from its competition. And this is where people fall down – it’s a much bigger job than people often think and it’s compounded by the fact that you can stop at any point and still have a perfectly functional product.
And one of the difficulties is going too far. Albert Einstein said that things should be made as simple as possible, but no simpler. Several article commentators who use Bump complained about vanishing features in the latest version, presumably removed to increase simplicity. It’s obviously going to annoy a certain proportion of your users if you take functions away and perhaps the trade-off here is the right one, but it makes it clear that it is a balancing act.
In my opinion, a neglected counterpart to having an easily understandable product is having an easily describable product, or at least making an effort to describe it. Distressingly common is the inability of software companies (and to some extent providers of other forms of technology) to properly explain something they want to sell to me (or sometimes give to me, for which I can’t be quite so belligerent). This goes all the way from small open source projects to massive product suites from big companies. In the latter case, it’s usually because they have a marketing department who feel it’s their duty to talk up the product without worrying too much about whether it will actually fit the needs of potential customers. Examples can be found in the whole gamut between.
I don’t want to know how I’ll feel using your gadget. I don’t care (initially, at least) whether it’s been designed with solid engineering principles or by throwing a bag of C++ keywords in the air and seeing how they land. I especially don’t want to be greeted with a list of the minor functionality tweeks between versions 2.4.2.17 and 2.4.2.18, which seems particularly common in open source product pages. I want to know what it does. I think that should be more obvious than it would appear to be.
So I’d like to make a plea for simplicity myself, in the sales pitch: if the first page an interested visitor will see on your product’s website or information brochure does not contain a brief, clear description of what the program / gadget / vegetable can be used for (and I don’t mean, “Use the Big Bright Green Pleasure Machine and it will make your TCO lower / your life better / your partner sexier”, unless one of these purposes is its sole function) then your marketing is rubbish.
