Extra! Extra!

I just returned from the Information Architecture Summit in Las Vegas, where I gained some new insights. This was a great conference, featuring many informative sessions on topics such as “Usability Challenges of Web 2.0,” “Best Practices for Form Design,” “Maximum Value IA,” and “Mobile Information Architecture.” In addition to the conference sessions, the Summit was a great opportunity to share ideas among peers and exchange techniques and advice.

But one of the more interesting lessons, for me, was from the casinos.

First of all, I should explain that I don’t really gamble. I have no moral objection to gambling, but I do have a pretty thorough understanding of probability, and I’m aware of the fact that casinos make a lot of money. It must come from somewhere.

This means that if I walk through a casino, I can just observe. Casinos are designed around the user experience, with no clocks, hard-to-find exits, and an ambience that I’m sure has been carefully calculated.

On my way to check in for the Summit, I passed through the hotel casino. (Strangely enough, at many hotels going through the casino is the easiest way to enter.) Walking through the casino, I felt something was amiss, but I couldn’t quite put my finger on it. Something just didn’t seem right. As I was leaving through the casino at the end of the day, I got the same odd feeling.

The next day, I happened to arrive at the hotel venue a bit early and had a bit of spare time.

I do have one exception to my lack of interest in gambling. If I am in a casino and have extra time and a lot of loose change in my pocket, I will pull out my change, find slot machines of the correct denominations, and donate my pocket change to the cause of casino profits. I consider the money gone as soon as I pull it from my pocket. In most cases, I am right.

On this particular day, I started looking for slot machines of the right denominations to make my contribution. I discovered that I couldn’t find any that actually accepted coins. The coin slots and been covered and the only way to play was by inserting bills, or some sort of card representing money won. On my way out in the evening, I asked one of the helpful casino people where I might find real slots that took real coins. They said to try to smaller casinos not in a hotel.

Then I realized what was missing! The sound of money. Because the slot machines didn’t accept coins, they didn’t pay out coins either. They just added to total “credits” on the machine. To cash out, you got a card representing your winnings and took it to a window. This meant that walking through the casino, there was no longer the random, “ching-ching-ching-ching” of coins crashing into the trays on the front of the machines. In fact, the noise in the casino was pretty much random crowd murmur, with a periodic outburst from someone when they won.

This seemed odd. Didn’t the casinos realize that hearing someone else getting a large number of coins was bound to be encouraging others to gamble? The sound of money. How could it not attract people? I puzzled over this for some time.

So, I observed a bit more. By not needing to reach into the payout tray, grab a coin and put it in the slot, the gambler could give the machine a spin every 2 or 3 seconds easily. The old method using coins probably meant a spin every 4 to 5 seconds. This meant that slot players could play more quickly.

Still, I couldn’t help but wonder if this more rapid rate of play made up for the loss of the influence from the crashing coins.

Then I remembered that everything about a casino is deliberate. This implied that research must have been done to determine which factor lead to the greater profits, and rapid play won. If “coinless” slot machines had decreased profits, they would never have been adopted.

So the real lesson is that even if we determine which option or design gives the better user experience, we should always keep business goals in mind, and test against those goals (not just raw user experience) when determining which option or design should be implemented.

According to story in Reuters, “wiki” has now been proclaimed a real word by the Oxford English Dictionary.

I find this somewhat troubling. I have been treating “wiki” as a real word for many years. I find it used in news and magazine articles constantly. Anyone who works in any web-related field certainly understands its meaning. And all this time we have been using an unofficial word.

So it has been a long journey for this collection of four letters to become a real word, but it has been worth the wait. When someone says “wiki,” there is a strong shared meaning. Others either know the word or do not, but do not mistake if for something else.

There is a bit of power in inventing a term for something new, rather than just pulling together terms already in existence (I know, I know. “Wiki” is a derivative of “wikiwiki.” But being a derivative, it is new.) A wiki could also have simply been called “an open page” or “collaborative web” or some other combination of existing words. If that had been the case, imagine the chaos that might have insued as various companies and factions tried to include their own sites under such an umbrella term.

If someone says “wiki” we generally agree on what that means.

This is in sharp constrast to other ideas which have been expressed in terminology that is just a recombination of existing words. Take “user experience designer” for example. I know exactly what it means, and you probably do, also. But if you get eight web folks in a room and ask, you will get at least nine opinions about the exact meaning.

This same lack of common meaning is true of much of the vocabulary we have been forced to establish as the web has evolved to prominence. Remember “webmaster?” Luckily, that has fallen from common usage, because it was so vague as to be almost meaningless. And “web page” is becoming increasingly inaccurate, since what you are seeing in your browser is likely a set of templates used to display a collection of content objects and applications. The term “web page” is a just holdover from thinking about the web by relating it the more familiar idea of a book or magazine page.

But, I have hope. We eventually stopped using the term “horseless carriage” in favor of terms such as “automobile,” “car,” and “taxi.” And no one says “picture show” any more unless they are a Rocky Horror fan. I think new terminology will evolve to replace some of the interim descriptions we’ve been using, and it can’t be soon enough for me. Let the names begin!

Jakob Nielsen’s latest Alertbox column discusses “12 High-Profit Redesign Priorities.” He mentions tactics he believes have a high return on investment.

Looking over the list, I have to agree, in general, that these are all really good ideas.

I do, however, worry a bit about such lists. Lists from experts are sometimes prone to misuse. Managers may blindly use the list as their roadmap for planning upcoming web projects, trying to do everything on the list without determining the relevance to their site. For example, “Catering to Seniors” might not make much sense if you sell skateboards. (Apologies to any skateboarders out there with several decades behind you.) Each site is different, and priorities for change should be based on business objectives, the focus of the site, and the intended audiences.

I would also like to have the ROI for these actions explained in a little more detail. Or at least the mention of a good method for calculating the return on each suggested change, along with maybe a benchmark. It has been my experience that CFO’s won’t simply accept an assertion of positive ROI when making decisions on project funding. Instead, they want to see the calculations, or at least the projections of return.

The list contains good ideas and probably bears evaluation against your current sites for a bit of guidance in setting priorities, but like many useful tools (such as hammers, bulldozers, etc.), incorrect use can have a negative impact.

Dear Yahoo!

Thank you for refreshing MyYahoo! with a new Ajaxy UI. Your UI team deserves cheers for this polished experience. However, following the trend of your Mail beta, the browser-side experience is unnecessarily clunky and slow. Despite the fact that I’m packing Pentium and a high speed connection, I feel like I’m back in 68040 land on 28.8k surfing a FirstClass BBS. I will be more than happy to download a plugin to speed things up if you make one available.

Safe Credit Union’s web site wins praise in Friday’s netbanker report. There, Jim Bruene compliments Safe Credit Union’s Clever Homepage Comparison tool, citing it as “one of the best rate comparison tactics we’ve ever seen.”

Kudos to the Extractable team who made the Safe CU rate comparison tool and web site come to life!

Here at Extractable, we are embarking on a bit of work on our own web site. (I’ll skip the details for now.) We, of course, began with the process of ensuring clarity of business goals and identifying the business value of the site.

This essentially means forming something like a complex “problem” statement. We determine what are the desired outcomes before we start exploring possibilities and defining solutions. We held a meeting of all stakeholders to begin to gather this information.

Do you have any idea how difficult it is to sit in a room of people who spend their lives proposing solutions and ask that they state only the desired outcomes? Every idea about what should happen was accompanied by a method for making it happen. It was a very fun meeting.

It was a bit like conducting an orchestra made up of fellow conductors. The phrase “everybody’s an expert” was literally true.

Of course, since we all were speaking the same language, much progress was made quickly. But to me, one very interesting side effect of the meeting was getting an amplified example of one of the major traps of web strategy: getting to the solution before fully stating the goals of the site.

There is a very strong desire to quickly get to the solution phase. Having a defined solution is much more comfortable than not having one. The issue is that defining a solution too quickly can miss the mark by not allowing time to explore all possible outcomes and really get important details about the goals of the site.

For example, the obvious goal of many business web sites is to make money. That would seem to be a fine goal to achieve, so let’s get to the design, right?

Not so fast. There are different ways to make money. Designing an e-commerce site to increase sheer sales volume is different from designing one to increase margins on existing sales. And both are different from designing a site to grab market share to create future profits. Design of a site involves hundreds of small decisions, and a number of large ones. Understanding exactly the desired outcomes helps to keep all those decisions in alignment.

I guess the key point is to be willing to spend the necessary time and effort in exploring outcomes before defining solutions. It’s an obvious idea, but one that is very important. A full understanding of business goals is crucial to designing a successful site.

By the way, we were able to define our desired outcomes in detail and are progressing nicely on this internal project. We can’t wait to share the results.