in General Coding

Bagging grocerices and software feature bloat

So I’m standing in the checkout line at Whole Foods at Union Square in New York City, where they’ve basically got long lines from open until close, and then I finally get to the always-friendly cashier, who rings up my groceries, and then proceeds to bag them. Having lived much of my life in Europe, it’s always struck me as unfortunate that, in most U.S. supermarkets, cashiers or someone assisting them, will provide grocery bags and bag your groceries for you, while in Europe (at least in Stockholm, Berlin, and Brussels), you will almost certainly have to bag your own groceries, as well as either bring your own bag, or pay extra for supermarkets bags.

I think the reasons for this difference is likely tied to all kinds of cultural, sociological, and market factors, but, ultimately, I think customers are done a disservice by being provided this extra “free” service. Aside from coming home to discover that your canned preserves were placed on top of your bananas, having cashiers do the bagging actually slows down lines, which means more cashiers or assistants need to be hired, which means more overhead. And then, of course, there is the environmental side to the equation, by requiring customers to bag their own groceries and charging them for supermarket bags, you encourage that they bring their own bags (this is very common in Stockholm.) I usually bring my own bag when I go to Whole Foods, and even at this generally progressive establishment, I often get a confused look by the cashiers who often are not quite sure what to do with this alien variable that has been inserted into their process.

In the world of user experience design, I would call the cashier-bags-groceries feature an example of feature bloat. One of the more notoriously feature-bloated applications is MS Word. While users of this app may not be familiar with this term, they have almost certainly experienced its detriments, which basically takes the form of wading through all kinds of features you either never use or don’t really understand (when did you last do a mail merge?) to get to the 10% or so of the features that you use all the time.

The origin of feature bloat are slightly less complex than the cashiers doing the bagging in supermarkets, but may be driven by similar forces. They mostly have to do with justifying a new version of the application every few years. Just like software marketers need new exciting-sounding features that they can splash across their ads, supermarkets need to sell convenience, which often can take the shape of giving customers things they never really asked for but which it is expected will help selling the product. And this really is at the core of the issue giving users stuff they never really explicitly asked for (Do you really think a customer in a supermarket just one day refused to bag their own groceries, and so supermarket owners were forced to start bagging them? Ok, I jest, but you get my point.)

In the world of software development, every design decision implies some form of trade-off; you get one thing, you are likely giving up something else. By giving users features they haven’t explicitly asked for, they may need to either cut corners elsewhere or completely forego features that may be more important to them. In MS Word, most users just want to write whatever they need to write and print it or email it or whatever and be done with it; in supermarkets, customers just want to get their groceries and get out of there. Aware of this issue, Microsoft has in recent versions begun to for the first time reduce the number of features in MS Word; some U.S. supermarkets have actually also begun to (inadvertently?) also address the issue by having self-serve checkouts (there is one at the Kmart at Astor Place in NYC), which require customers to bag their own groceries, but is also churning up a host of new user experience issues relating to the touch screens and other devices used when doing a self-serve checkout, but I’ll save that for another posting.