Snow tires and mobile phones

My car needed new snow tires this season. Like most instances of choice, the available information is limited and comes from sources that might or might not be reliable. 

For instance:

• I choose where to purchase tires. Are the differences among tire retailers significant to me? 
• I speak to a sales rep in the store. Do the sales rep's interests in this transaction complement my own, or are they in conflict?
• The sales rep may well show me some actual tires. There are only two or three characteristics of tires visible to me: brand name, tread pattern, and (since they're snow tires) whether they have metal studs. Do tire brands really differ? Are tread patterns significant at all? (My guess is no, since they seem to vary almost infinitely. If there was a "right answer" it seems like it would have begun to emerge over the past century or so that automobiles have needed tires.)
• I could ask people I know about their experiences with local retailers and different brands of tires. Do the anecdotes I gather represent valid data?
• I could look up comparison tests and reviews. These will compare only some of the available tires and only some of the conditions I'll experience (although hopefully fairly representative conditions). Do the tests and comparisons, based as they are on particular methods and contexts, deliver usable information? 

This is a pretty typical purchasing situation: I'm making what amount to a series of guesses because it would take too much time and attention to amass valid, reliable information to support my decision. In other words, I'm not about to fully apply the scientific method to choosing a set of tires. 

What I do is trust some things. I trust that a tire retailer is probably good enough as long as I haven't heard anything very negative about it. I trust that most tire brands and specific snow are functionally equivalent, within reason. I even trust that generally, the more expensive tires might be better in some respects (this is almost certainly the least reliable of these assumptions). 

What I'm trusting is the vast set of systems (a "megasystem") in which snow tires are made available. An egregiously dishonest sales rep would be fired, right? A disreputable retailer would go out of business, right? Tires have to meet some baseline standards, right? A manufacturer would try to build quality, reliable products, right? 

What I'm really trusting — and this is a lot to read into snow tires, I know — is the effectiveness of measurement and feedback loops in our civilization. We believe that competition among retailers, manufacturers, distributers et al, will somehow improve the end results. This can only work if outcomes (sales, durability, defects, prices) are measured and communicated.

The feedback loops of "the market", by which I mean the aggregate outcomes and communication of (in this case) everybody buying and using snow tires, are very slow, and they're unbalanced. Price is immediately clear. But it might take three years to discover a real difference in durability, and a particular advantage one tire might have on, say, black ice might become evident to only a few users. And they might not even be aware of it.

Additional non-market feedback loops augment inherently faulty price information; the comparison tests and standards I mentioned earlier. In those cases I'm once again trusting; in this case that the tests and standards will be based on issues important to me. In the case of snow tires, that's probably true; snow-tire use cases are well understood.

Despite the numerous possibilities for problems, the snow tire system functions well enough, I think. I ended up choosing the retailer by location, the sales rep by default, and the tires by a combination of factors both vague (I had at least heard of the maker) and concrete (price). The tires are good enough. And I still doubt the significance of tread patterns.

The megasystem providing mobile phones to users doesn't appear all that different from the megasystem providing snow tires to drivers. You'd think mobile-phone use cases were pretty well known by now too. I think the core use cases for mobile-phone users are understood, true. But the use cases considered important by manufacturers (with the probable exception of Apple) don't just concern users; they concern carriers. Companies like AT&T, Verizon, Orange, and the rest deliver laundry lists of requirements to manufacturers. Long laundry lists. 

Carriers' requirements and users' use cases are often complementary, but not always. Sometimes the interests of a carrier are in direct conflict with users. A small example is apparent whenever a user opens the web browser on a Nokia Symbian phone, and looks at their bookmarks. The top of the list is often home to a handful of bookmarks that can't be moved or deleted. They point to sites like the carrier's online store, the carrier's information, the carrier's brand, the carrier's advertising. The bookmarks are there because the carrier listed such a requirement, and the manufacturer complied. The outcome for the user is a product that's a little bit harder to use because they can't change those "privileged" bookmarks. 

Mobile phones are full of tiny little compromises like this, where a conflict between the interests of carriers and the interests of users was resolved in favor of the carrier. There's a less specific outcome too; the carriers' laundry list of requirements feeds into another list-based system of questionable value: product reviews and comparisons. A comparison test of mobile phones consists of some specific aspects you identify (a feature list), some way to measure or assess each one and a judgement made within the time available (which is never very much). The way to "win" such a comparison is by having a longer feature list or aiming at very specific measurable differences such as numerically more [memory, pixels], faster [processor, connection], bigger [screen], and so on. That and having very obvious differences that are easy to recognize right away. 

The thing is, when you live with a mobile phone for at least a couple of months, depending on it as your only (or primary) phone, what you learn is almost always quite different from what a feature comparison test suggests. Human judgement is made up of lots of implicit and vague impressions. While a larger display wins the comparison, after six weeks you realize you don't really like carrying a device that size and wish it were smaller. Or there's something about the corners that bother you because they're uncomfortable to hold. Or you don't care about the super-fast connection as much as you thought because whenever you use it you realize you have to plug in your charger in the middle of the day.

It seems like this would present an intractable problem: the feedback loops of the megasystems have inherent flaws that reward short-term values like price and features, and give priority to entities like mobile carriers rather than mobile users. And yet the problem is frequently solved. Apple, for one, apparently does not prioritize carriers' short-term interests nor engage in feature-list design. 

It would seem there's an additional layer of complexity in megasystems, but it's not immediately visible to all participants. 

---------

Note: It's quite feasible, of course, that tire manufacturers do consider retailers their customers; I have no inside knowledge of the tire megasystem.

Fine Print

Through pure coincidence, I read in the same morning this review of Ellen Shulz' new book Retirement Heist and this story (part one) about Ken's response to a toner scam. I noticed that the toner scam article says this (emphasis added):

how can it be fraudulent if the invoice says right on it “Thank you for your business. This is not a statement for services rendered but for preventative maintenance”?

Simple: fraud law doesn’t work like that.

I noticed as well that Shulz explains, in part, how corporations were able to unilaterally alter what everyone considered contractual obligations this way:

Union employees had physical legal contracts that had been collectively bargained that said, "We promise you lifetime coverage." So the employers claimed, "We didn't mean your lifetime, we meant the life of the contract," and it worked.

This is pretty interesting. Legal fine print sometimes acts as an effective tool for deception, changing what appears to be the spirit of a written agreement, and sometimes the spirit of the agreement takes precedence.

This is not, of course, very surprising; it's deeply embedded in our collective understanding that "fine print" can and does deceive. The legal profession maintains itself in large part because of this; lawyers are versed in very specialized language and procedure that we all agree is obscure, counterintuitive, and often intended to deceive. 

I'll assume that the fine print in the toner scam example was also written by lawyers (this is arguable, but that's what for the sake of argument means). Both of these "agreements" are relatively unilateral. The cases have other similarlties.

For one thing, the victims and employees don't have full awareness of what's being done to them. The contractual verbiage associated with employment is intentionally obtuse, and employees' "choice" is not to accept it or not; it's "have a job or not". Employment agreements don't differ much, and the obtuse legal framework they all operate within is the same. Employees don't typically notice what's being done to them. In the scam case, similarly, victims don't notice what's being done to them.

The intention is the same in both cases: bluntly, it's theft. 

The difference lies in the perpetrators, and in the outcome. Characterize someone as a "scammer" and you've made a presumption about what the outcome should be. Scamming is obviously bad and should be prohibited, punished, stopped, not allowed, and so on. But characterize someone as a "businessman" and your presumptions are (probably) quite different. 

Laws in these cases are fairly different based largely on who you are. 

Now start substituting labels. For "businessman" and "scammer", what if you substitute "white man" and "black man"? "Man" and "woman"? "Straight" and "gay"? "Muslim" and "Christian"?

We give a lot of lip service to the idea that "we're a nation governed by law, not by men". Some people whistle past graveyards, too. 

Crayons

I was invited this morning to a review of a corporate intranet homepage. The original design is an extremely busy, confusing piece of work that's full of conflicting, nonparallel lists, lacks coherence and hierarchy, and is the sort of page you can puzzle over for long minutes before concluding there's just no way you're going to find what you're looking for. In other words, it badly needs some design work. 

The site is immense, but there were only a couple of mockups. Worse, they seemed to have exactly the same content, just slightly tweaked to make the graphics look boxier and a different shade of blue. I asked about use cases and IA charts, and was told no, that's not part of this "design initiative". The content will not change one bit, nor will its organization. It just might sit in a different color box. 

How is it that this kind of crayon-coloring is called "design", while a serious effort to make a huge repository of information comprehensible, navigable, and useful is called..."design"? Sigh.

Designing the Audience

One of the things designers do is learn about the audience for whatever it is they're designing. But there's design, and then there's design, if you know what I mean. At another level, by another set of people — also designers, although they might not think to call themselves that — are designing the audience and their milieu in order to fit products, or potential products.

For example, think about a huge audience, dead center in the sights of marketers around the world: teenagers. How did that come to be? The marketers just recognized teenagers and focused on that category? No, "teenager" is a created category. Somebody designed the idea of teenagers.

The Oxford English Dictionary is the best source I know of for etymology, and points out that the word teenager seems to have entered common usage in the 1940s. Before you have the word for something, it's harder to conceptualize it and harder to "deal with it" easily. You might not even recognize it. Like that story about the Aleutian people having, what was it, 23 different words for "snow", and they're able to recognize all those types because, having words, they have a ready typology into which to fit their observations. 

If you're a designer, or a marketer, or for that matter a publisher, once you have the word for a category of people you can start to aim at that category, and easily explain to your colleagues what you're trying to do. Before "teenagers", there were only children and adults. And designs, whether of products or of marketing campaigns, were different. 

Bricklaying and sculpting

Interface design is like building with bricks. It's especially like building with Lego-style bricks, which come in lots of varieties, but all snap together. You use components defined by the platform — buttons, sliders, pointers, and so on — and lay them out in a usable arrangement. Sometimes you begin with a layout grid that suggests or even defines locations where each component can "snap into place". 

The thing about building with Lego bricks is that no matter how impressive the thing you build, it's hard to think of it as anything more than a "clever assembly of Lego bricks". Interface design can be a bit like that too; if all you do is use standard components, it can feel (at least to you) like an "assembly" more than a new thing in itself. With interface design this impression is probably more common for the designer than for users.

Interface is also like sculpting. It's especially like sculpting with clay, using a method in which you add new clay as you proceed. You have a goal — usually a set of goals, in fact — and create controls, visual cues that inform users about what the controls are and how they're used, and combine them into a whole that (hopefully) is useful and attractive. 

There can be drawbacks to sculpting, too. Sculpting gives you an infinity of possibilities, out of which only a very few, or one, really works well. You're creating not just the end product, but all the component parts as well — the "bricks", so to speak. 

When you're designing a production interface you need a mix of bricklaying and sculpting. Preexisting components are helpful things; they save time in both design and implementation, they reduce bugs (because they've already been tested individually and in combination), and they're easy for users to recognize and use. But most software design projects need things that don't exist as system components, so you need to do some sculpting as well.

Some platforms have too many available components. Symbian is an example of this; for any given interface object there are likely to be several variations. Such a huge set of components is a result of accumulation; the original set was, I believe, a much smaller and more manageable set. But over time that accumulation also engendered changes in parameters, requirements, and implementation. If the existing list element wasn't quite what was needed, a new one was designed. It needed more or different parameters. Perhaps it depended on different display layouts. Since the first implementation maybe coding practices have changed, or the documentation format is different, or (most commonly) there are simply different people involved. 

The end result can be a mixed bag of "these components work this way, those work that way" and as the complete set of components grows it can become just as much effort to build an interface by "bricklaying" as "sculpting". 

The overall result is that there's no time left in the project for "sculpting." And that's a problem. 

Really effective software design — beautiful, original, usable design — usually takes a combination of "bricklaying" and "sculpting" approaches. Development organizations, which feature project managers, engineering estimates, and many different ways of measuring and quantifying things, naturally favor the bricklaying approach. It's more predictable, for one thing. And the organization (where the interface designer probably works) has a bias toward predictability. 

When the software platform you're working with has accumulated a vast number of components, and those components have over time become inconsistent in many small ways, the sculpture — the beauty — of interface design is lost simply because there's no longer time for it. 

And that's one of the fates that befell Symbian.