Third-Party Perils

A lot of client sites that I evaluate have tagging problems that aren't really of their own making. We have clients "tag" their sites for analytics purposes to send data back to our mothership, which is then returned to the client as reports. As you undoubtedly know, it's been getting commonplace to "farm out" a certain part of a site to third-party suppliers. Many clients, for example, now out-source their employment pages, with just enough matching page elements to make the visitor think they're still somewhere in the same site. Same thing with newsletters and emails - other people handle it for you. The problem is that those sites usually aren't tagged, so you can't track them. No tracking, no evaluation. Again, small sites aren't deeply affected, but bigger ones are. If you can, work it out with your vendor to let you tag their pages, or have them tag the pages. It's not a new request for most of them. Don't ignore such vital functions as recruitment and marketing contacts.

Old Houses and Portals

I live in an older home (1920s) in a historic neighborhood. It's not a particularly wealthy neighborhood. Most historic ones aren't. Money flees its breeding ground. But the neighborhood is comfortable and reasonably vibrant. I always wondered why I loved older homes, and finally one of my gurus, Stewart Brand, might have explained it in his book How Buildings Learn: What Happens After They're Built. He says that older buildings exude what we call "charm" or "character" because they've been altered over time to suit both changing infrastructure needs (the arrival of central heating, air conditioning, indoor plumbing, electricity) and the changing life needs of its occupants (bigger kitchens, more light, more entertainment at home). They grow, morph, and gradually conform more closely to actual human life, like an old pair of jeans. New homes are raw despite their efforts to "design for life". Brand points out that buildings can't be designed up-front for our lifestyles, because no designer can get it right the first time. That's why a home needs so much time to find its proper shape.

What's the lesson for Web designers? Alas, probably not much, despite my most earnest desires to bring the analogy across. The missing element is time. Websites don't give you time. Portals were supposed to let users modify their views quickly, compressing the decades of home conformity into minutes online. Never worked. The vast majority of visitors never knew about customization or took the time to mess with it. Personalization works to an extent, but not completely. Web users are now used to their comfortable sites changing regularly, and although they may not approve, they rarely boycott on that basis.

That said, for years I've been fascinated with the idea of a personalization engine that would track Web user behavior and subtly shift the interface to suit. I've never bothered to fully flesh out the concept, but in general it would work much like Microsoft's failed personalization functionality in Office, the one that gave you chevrons instead of full menus. It was a good idea, but possibly the wrong place to use it. Office users are almost all repeat visitors. Website visitors aren't. Amazon does a good job with personalization, but I'd extend it from "you might also like this stuff" to actually shifting controls and navigational paths. A pipe dream, certainly, but given a huge pile of cash something I'd be interested in researching.

Reading TeaLeaf

Sorry to have been away so long. Complications of various kinds. But now I'm back, and with tea.

Have you seen TeaLeaf? It's a snazzy app that sits athwart your Web traffic, sniffing and recording every user's session. A bit disconcerting, that. But its benefits are undeniable. It stores thirty days (or more, at your discretion) of user transactions, at the user level. It aggregates them too. I've long been a proponent of continual usability checking. Our profession seems to put all its emphasis on initial design and testing, while utterly neglecting Web analytics and other red-flag functionality that can signal usability leaks. Traditional Web analytics is good, but it isn't always granular, meaning that its results are en masse, not at the level of the individual user. It's great for marketing departments, but not as good for usability concerns. TeaLeaf shows the actual user transactions - where people go, what they click, what choices they make, and whether their conversions are successful.

For example, you can lose users at any turn in the road, but especially during checkout. Many visitors drop off when money becomes an issue, and understandably so, since they had no intention of paying anyway; they're just here for the experience, or the knowledge. But others experience technical problems or usability pitfalls. TeaLeaf generates a report on who converted and who didn't, and then you can track out why the failures happened, following every user's trail.

Scott Adams and the Demise of Common Sense

Scott Adams, the creator of Dilbert, has announced on his blog that he'll be blogging less often. It seems that his original common sensical expectations about how the blog would turn out aren't coming out well at all.

They original expectations included:

1. Advertising dollars
2. Compiling the best posts into a book.
3. Growing the audience for Dilbert
4. Artistic satisfaction.

Of these, only number 4 has worked out. RSS has made visitors go around the ads, the book hasn’t done all that well, and the audience for Dilbert hasn’t been correlated at all with the growth of the blog. As the blog has exploded, the benefits to him haven’t. So he’s talking about blogging less often. It’s a great illustration of how common sense is a lousy predictor of future events. Viva testing and statistics.

Give Me Your Huddled Masses...

When I do usability work, it's astonishing how often a client won't give me access to their user base. They're so used to protecting that base that they can't immediately swing their thinking around to working with that base, rather than just wining and dining them. Sales personnel are the most protective, in my experience. They seem to live in terror that somebody will screw up the precarious relationship they have with their customers. Even when I get to customers, I'm usually given only a small number of very carefully selected and primed representatives, and sometimes not the right people within the customer organizations.

The excuses are legion - customers are too busy, they're too far away, the right people aren't available. But perhaps the most ironic is the excuse that I'll raise customer expectations by letting them think that their wishes will become features in the next release, and if they aren't then the customers will get crabby and disappointed. A lot of salespeople leave me with the impression that their customers are generally vocal and upset about something, interspersed with short interludes of grumpy acceptance. The salesperson doesn't want that sleeping dog disturbed by the slightest zephyr.

But what they can't seem to get straight is that I'm not after user wishes; I'm after user processes. I'm not going to talk much about desires, but about business. I'm trying to understand how customers operate. They'll tell me their desires, of course, but I'm always careful to be noncommittal, with comments like "I'll see what I can do about that in the design, but it may have to be in version two".

Letting users into the planning and design stages is good business, and establishes a level of trust that can't be won any other way. Now if I can just make clients see that...

Another Hideous Example

Perhaps the most fun entries to write are about awful sites, and here's a real winner, courtesy of BoingBoing. The site is by the British government, and it's trying to discourage knife violence. But the site has two major failings: it's all in Flash, and it has enough stupid lawyerly language to discourage a Supreme Court justice from reading the site. The BoingBoing article is here. The awful site is here.

Microsoft Is After Your Brain

New Scientist is reporting a Microsoft patent application for monitoring a test subject with an EEG during usability testing, so that testers can see how people really react, instead of relying on second-hand information like behaviors or think-aloud protocols. Apparently Microsoft believes it has a way to separate out the dozens of noisy signals from the ones they believe relate to user responses. Are all the rest of us out of work now?

Where are the UCD'ers for the Military?

An article in Slate points out that Iraqi jihadists are every bit as clever about creating IEDs as the Viet Cong ever were, but with vastly updated technological help. To counter the problem, the military has come up with seemingly workable ideas, such as a drone lead vehicle in a convoy that could be driven from the back, but which makes the virtual drivers carsick, door armor so heavy it can't be moved, and images so detailed that the human eye despairs of picking out field from background. The article says quite plainly

The enemy's simple technology suits human limits; our complex technology defies them. Our crazy menu of jammers confused our troops, making them think they were jamming the right frequencies when they weren't. Our tutorials in wave propagation flummoxed them. When the $800,000 IED neutralizer flunked real-world tests, the company that built it blamed operator error, denying that the machine was "a failure in any way." But if humans can't operate your machine, your machine is a failure.

If UCD'ers are getting so commonly accepted, why isn't the military letting us design and test their wonderful ideas? Most of our best people could tell them outright that these ideas won't work, because they've been tried elsewhere.

Vocal Joystick

Researchers at the University of Washington have built a "joystick" that works entirely with basic vocal sounds. Vowel sounds move the cursor in various directions, while consonants like "k" and "ch" simulate clicks and releasing the mouse button. Saying the sounds louder moves the cursor faster.

Existing joysticks for the disabled require a stick in the mouth, which is tiring and interferes with speech, or head or eye tracking, which is hard to do properly. The inventors say that they elected not to use full voice recognition because it was far less efficient. That makes sense to me - syllables are much shorter and universal than whole words or phrases, and they can't be misinterpreted as easily.

Another Example of Lousy Design

This curtain control is said to be an example of truly bad design. As the cutline says:

There is no natural mapping between the buttons and their functions. I went through quite a bit of trial & error before figuring it out. And the problem is that even once you figure it out, it's not very logical.

But one commentator responded that

From the printing around the buttons,. it looks pretty clear... The right column is for the solid curtains and the left column for the sheer curtains. The top button in either column opens the curtains, the middle button stops them while opening or closing, and the bottom button closes them.

This seems reasonable only after you've studied the panel for a while. In low light, in poor position, or if an old person is looking at it, the design is still bad, in my opinion. Most Americans, at least, tend to think of controls being arranged in vertical clusters, not columns. Maybe they could use some icons to improve effectiveness, or have two controls. Even better is to just use the old-style rods that you pull to open or close drapes. One big plus to the rod approach is that the visually impaired can figure it out, while the electric control doesn't even have a braille equivalent for its labels. Why overcomplicate things?

Ice Cream by the Blues

Here's an ice cream machine that dispenses an amount based on how unhappy the customer is perceived to be. The vending machine does a voice analysis to determine your level of the blues. Some days I'd qualify for a whole week's worth of ice cream production.

What Have I Forgotten?

I'm teaching a graduate course in HCI, and I've learned one thing so far - how awfully much I've forgotten already. We're getting into patterns and pattern languages, and I'm alarmed to say that although I have a vague recollection of this subject, I haven't been able to use them in the field much, so they've receded into my mental archives. The same is true of other things. Names for rarely-used prototype techniques. Details about the types of conceptual models. The difference between categorization and classification. I know this kind of forgetting happens, but it's not supposed to happen to me.

Still, teaching these courses keeps the information fresher, and that's comforting to me. It's one reason why I keep teaching, even though sometimes the cognitive loading of work, home, and two or three simultaneous classes can get stressful.

Why Am I Not a Programmer?

I was recently in a meeting where I was enumerating what I did well and what I didn't. Although I have a lot of skills, there are some things I just don't do well. In user experience terms, those are primarily programming and graphical design. I can do both, but haltingly, and others do them much better, so I have a tendency to avoid them. At least with graphical design I tend to compare my meager skills to those I see on display on the finest pages, so perhaps my bar there is unreasonably high. I've never had much coursework in graphical design, at least in the past two decades, so I have little basis for comparison.

I have taken courses recently in programming, though, so I think I'm more realistic there. Java drove me crazy. I'd be looking for a method in the documentation so I could find its arguments, and to my annoyance I'd have to trace it up the tree several classes, because it was inherited a dozen times. The classes weren't hard, just tedious, frustrating, and boring. I've had the same problem in other programming classes. I was probably the only English major in history to sign up for assembly language programming class. It went OK, but I didn't feel any affinity for the subject. No spark. No gift. I concluded I would never be much good at it, and that was that.

But after my meeting, I started to reconsider my position, especially after I talked with a programmer and looked up some "how to think like a programmer" pages. To my amazement, it appears programmers don't like to code much more than I do. It's just that to solve their problems, which they love to do, they have to code.

It reminds me of my mathophobic days. Although I teach statistics now, I was once afflicted with math anxiety. That cracked away after I abruptly realized what math is. It's a modeling language, with enormous lossless compression. You can model reality with it, sort of. Once you learn the language, the rest is just fiddling with it until any given equation makes sense. Even mathematicians diddle and doodle. There are no born mathematicians, only those who have messed around with it for a long time until it's easy for them to manipulate the linguistic symbols. There may be a math aptitude, but no math gene. I could do it too.

Maybe programming is like that and I'm being too critical with myself. I have yet to meet anyone who enjoyed programming courses and having to memorize languages, any more than I've met mathematicians who liked algebra classes. The essence of math is modeling; the essence of programming is problem-solving. Indeed, a lot of programmer-pundits say that formal college training in programming is counterproductive, because it confuses syntax with thinking. Many advocate starting programming careers by learning calculus, linear algebra, or even physics, just to get into the swing of thinking through complicated problems. Maybe I don't want to earn my living inside a compiler, but maybe too I'm too hard on myself when I sneer at my programming skills. Maybe I'm not much worse than anybody else.

Boeing Turns to Psychology to Design 787

The September issue of Air and Space Magazine has an article about how Boeing designed the interior of the new 787 using psychologists, focus groups, and other user-centered design techniques. They hired renowned marketing expert Clotaire Rapaille to help. Apparently together they did a load of research about how fliers like to see aircraft interiors. And they're not publishing what they learned, either. Usability as trade secret.

New Data Visualizations

One of my enduring interests is data visualization. It hits so many user experience hot buttons: cognition, potential for confusion, Gestalt principles, and so forth. Research in the past few years seems to have slowed considerably in this area, perhaps because much of the breakthrough work has already been done. We're not seeing new methods of visualization now, but refinements of old ones. Fisheye views (PDF) have been around for a very long time now. So have heat maps, tree maps, network maps, and so on. They're just getting new treatments and makeovers. If you want to see how a lot of them have been retooled with modern computing power and pretty colors, check out this article in the online zine Smashing.

Most of the applications are intriguing and professionally done, but I'm not seeing anything that makes me sit forward in my chair. Many old standbys have been dusted off, like the radar chart, but everything here has been done elsewhere. I don't suppose there are many more visualization methods to be discovered. But the flip side of this is that these techniques are getting more common and less expensive, and therefore more accessible to us. I've wanted to do tree maps forever, but no client has ever warmed to the idea. If you want to see how the principle can be applied well, if a bit understated, look at the daily stock market data here.

Control is Everything

Scott Adams got me thinking. In his blog entry for August 17, he mentions that one of our strongest needs it to feel like we're in control. He used an old example: A genie offers you two choices. In the first choice, "You can eat at the finest restaurants in the world for free, twice a week. The only catch is that the genie picks the day, when you are not already booked, and he picks the specific restaurant." In the second choice, "You can eat at “good” restaurants, again for free, twice a week. But this time you can schedule it whenever you want, up to two places per week, and pick whatever “good” restaurant you want."

He goes on to develop the theme that the first choice probably wouldn't make many people happy, because they would eventually feel the keen sense of loss of control. The second choice, while gastronomically less appealing, is probably a better one for most of us.

It reminded me that one thing users dearly love is control, or at least the illusion of it. This is something that subconsciously irks me about lots of software and websites, I think. It's why I'm irritated with Flash so often. It just takes off and does things without asking me. The same thing annoys me about flashing ads, shifting menus, and other things that don't help me do things, but invade my locus of control. We humans don't seem to resent losing control if we don't expect it. We accept that the good guy may die at the end of the movie, but we'll shriek in fury if we can't change the channel to another movie. And we accept a loss of control when it benefits us. My car's engine does hundreds of things that I don't need to approve as they're happening. But there are some places where humans just won't accept interference. I wouldn't pay less for a car if it decided by itself when it would start. The same thing is true for software and websites, I think.

Decluttering

A group of scientists at MIT headed by Ruth Rosenholtz, a long-time researcher into vision and technology, has developed a prototype application in MATLAB that determines the amount of clutter on-screen (Link). The HCI profession has long needed something that could separate figure from ground reliably. The program is only in prototype, but apparently it's rather promising.

The problem of figuring out what's vital few from trivial many isn't trivial itself. Nuclear facility control rooms are a case in point. Rows of lights can go from being background hum to suddenly becoming extremely important. How much do you expose to an operator, or to a website user? Hicks Law was an early attempt at measuring how much stuff was too much, but the sophistication of control schemes today needs a better way of knowing when you've overstuffed the interface.

HCI of Casinos and Slot Machines

This is the kind of article I love to read. It's about the human factors that go into designing slot machines and casinos. The article says that a slot machine is designed to be loud and visually appealing, especially when it pays off. The three wheels encourage the victim player to think that he's almost won when two of the wheels align, when there's no such thing as "almost". The slots are positioned just within easy walk of the tables, because table players don't like to hear them, yet the spouses of table players may well play the slots while they're waiting. It also talks about casino design in general, arranging that players can't see the outdoors, or even real outdoor lighting. No clocks, either, no way of knowing how long you've been there.

The slots are insidious in that they pay off only sporadically, which is how positive reinforcement works best. They pay off publicly, so everyone around is encouraged to keep playing. And they keep nurturing that "almost there" feeling.

Usability as a Path to Failure? Surely Not.

Todd Wilkins at Adaptive Path has thrown down a gauntlet to usability professionals, claiming that usability is not only overrated, but even injurious and a path to failure. He cites successful artists who didn't worry about "usability" either. He says:

So, why oh why do people in this day age still hold up “usability” as something laudable in product and service design? Praising usability is like giving me a gold star for remembering that I have to put each leg in a *different* place in my pants to put them on. (Admittedly, I *do* give my 2 year old daughter a gold star for this but then she’s 2.) Usability is not a strategy for design success. The efficiency you create in your interface will be copied almost instantaneously by your competitors. Recently, I’m even coming to believe that focusing on usability is actually a path to failure. Usability is too low level, too focused on minutia. It can’t compel people to be interested in interacting with your product or service. It can’t make you compelling or really differentiate you from other organizations. Or put another way, there’s only so far you can get by streamlining the shopping cart on your website.

Ahem.

Rarely do I see a designer get this blatant. They may think this drivel, but they don't usually voice it before a plunge into happy hour. First, usability here might seem synonymous with "make stuff easy to see". We professionals know this is not anywhere close to being true. Second, it entirely overlooks that websites aren't works of art, unless they're private, non-commercial ones. Commercial (e-commerce) sites are for making money, and every visitor who snorts in frustration and leaves is a financial failure, not a failure to make a friend. Visitors don't need to be engaged, or have fun in most cases. They need to transact. They need to do the tasks they arrived to do. Much "design" merely gets in the way of that simple goal, and ought to be cut out like a splinter under the fingernail, because it provides about as much value. A big-time website isn't an opportunity to dance the visitor about. It's to enable him to act.

Of course any successful design will be copied. But then, there are only a few designs in human experience, and they're all copied every day. Graphic designers tend to think that their designs are unique and powerful. Most often the ones that are sold this way are actually glitz with no go, at their core simply reproductions of past designs with a few cosmetic changes. There are only so many ways to arrange elements on a surface.

In my view, websites are not akin to artworks, but more like cars. First you make sure the damned thing drives properly, and then you dress it up. Not the other way around. We tolerate few physical objects in our lives that are as poorly designed as "cool" or "artistic" websites, yet we complain about the physical and work our way around the virtual. This seems asinine to me.

Keeping a Usability Portfolio

When I scan the want ads for people in the design end of usability, I often see language like "Must show portfolio". Huh? Most of us would find that requirement very hard to fulfill, no matter how long we've been in the business. It's not like we're artists in a garret, and our work endures down the centuries. It may last only days or weeks. And it may be buried in the overall design of the site. Further, we may not be the graphical designer, who will get credit for the look of the site. Perhaps more importantly, websites are inherently team affairs, largely produced by committees. After the wrangling is over, any usability person might question where his or her work might be found and pointed out. Add to this the short life spans of many design companies or design departments. Even if the company name sticks around, the personnel turn over rapidly in some places. After we've been gone for a year or so, nobody there remembers us. The lesson here is that when a site goes live, we should take screen shots and put them away on a CD somewhere so that later we can make up "portfolios". Forget, and the opportunity may slip away forever. Put it into your design process.