• The Importance of Mentor - Joe Says: “I say if you want to do something with your life and are willing to make a life-changing and risky change in your life to pursue that goal, then stop being such a chicken and go for it.” Agreed. Great post Joe.

• SOA and the ROI - If you sell SOA without ties to MDM, Portals or Process Improvement initiatives, you’re just selling a technology with the ability for reuse, but no framework to foster reuse.

• Periodic Table of Visualization Methods - Just about every conceivable way to visualize information is on this table, with examples. A great resource to keep around for a visual learner such as I.

Here’s an email I received just now from Koss:

Hot Off The Presses!
Be the first to experience the new UR21 Koss Stereophone. Lightweight with deep bass.
Order before 8/31/05 and receive free shipping.

To take advantage of this offer:
1. Click on the link below.
2. Add UR21 to your cart.
3. Enter coupon code 081605 at checkout.

Offer expires August 31, 2005.
This offer valid in U.S. only. Not valid with other offers.

——————————————————-
http://www.koss.com/koss/kossweb.nsf/04ProductDetailCall?ReadForm&Home+Stereophones%5EUR21

Heck yeah, I want to be one of the first to experience the new UR21 Koss Stereophone. Here’s what I got when I clicked on the link:

Looks like Koss has an amazing email promotion system. It so good, in fact, that it sends emails even before products are added to the website. Ouch…

What do you think are the chances of a typical user trying this link again and again until it works? Slim to none? I’d be willing to bet that conversion hurts for this, even if they do send another email.

And I’m not just picking on Koss here. I like their stuff, or I wouldn’t ask for emails from them. The point is that, for many companies, email referrals represent a large segment of traffic to a site. Mistakes like these can be expensive, and the broken link isn’t even the biggest problem. I think the biggest issue here is that Koss doesn’t have a branded 404 page to keep me on the site.

Here’s what I mean:

A friendly message, a link back to the home page and even some product recommendations are what make this an ideal 404 page for Amazon. It’s called defensive design. And it works.

Defensive Design, 404 Pages, User Experience, Koss, Amazon

This morning, I started working on a couple of posts that will pit the search experience of two competing sites against each other. I plan to finish and publish these in the next few days, but I’d like to get the comment-mill going in the meantime. The question is:

What are the things that make for your ideal search experience?

If you can, please comment on this post and list a few things you think ypur ideal search needs to have. It doesn’t need to be comprehensive, just a few ideas off the top of your head. Also, feel free to link to a site or sites that you think do search well. Finally, since I’d love to get as many comments as possible, feel free send this post around to friends, family, search experts, etc so they can comment as well. I’d love to get a long list of the things people are looking for in their search experience.

Here are some of mine to start things off:

1. Ubiquitous (or uniform) search box
2. Results easy to identify, even on a crowded page
3. Ability to refine or start over

This is by no means complete. So what do you think?

SEO, user experience, search, usability

Let me ask you a question: What do you expect from a double-click of your left mouse button? (One-button mouse users and Mighty Mouse devotees are excluded from answering)

Your answer is probably “It depends on where I am and what I’m doing,” right? A double-click on your desktop or in explorer will open a file. In quick-launch it will restore a minimized application. Many other applications perform functions that are designed along the context of the application.

And that’s a valid answer, so let me refine the question: In an interactive map application, what do you expect from a double-click on a point on the map?

Since this isn’t a chat room, I’ll just have to answer for myself: (If you have a take, feel free to throw in a comment) When I double-click on a point on a map, I want the application to center and zoom. I used to think that I was the only one that felt that way because Google Maps (Pictured below) doesn’t do that. It simply centers the map, then I have to click on the zoom-bar to get more detail.

Once I used MSN Virtual Earth, though, I realized I was not alone in expecting the double-click to center and zoom because it does actually that.

My point is not that I prefer Virtual Earth over Google Maps. (I’m not ready to make that call yet because I’ve been using Google Maps since day 1 and I’m trying VE alongside it for comparison.) I’m also not suggesting that my expectation is the one that Google should have yielded to.

My point is that, sometimes, two sets of usability tests on the same application can sometimes yield drastically different results and lead to different conclusions. I know that Google and Microsoft extensively UT their software. The irony of it is that, in the world of User Experience, there are no answers that meet the needs of 100% of your users (There must be someone out there that honestly expects for a double-click on a map to show him his house), so we seek to find answers that satisfy either a majority or 70-80%. Such is our world.

And in this case, Microsoft and Google appear to have each drawn from a different 80%.

Google Maps, MSN Virtual Earth, User Experience

I was speaking with a friend yesterday about an intranet application that has been something of a headache to us. Neither of us built this application, but we reviewed both the UI and the technical design because all web work must be reviewed by our team before development can begin. During the process of our design review (which, due to the lack of preparation by the development team, ended up as a design brainstorming session), we suggested that they try three different approaches at the UI for review by the customer. They agreed. I found out a week later that their manager overruled us and told them to go with option 1. Option 1 was my least favorite, but just so happened to be the original idea the team had as well as the most flashy (in a developers eyes, mind you). So off they went and abandoned the design review.

In the last few weeks, my friend, who has been code-reviewing work by this development team, discovered some flaws in the implementation of this intranet application (which ultimately feeds form data on a public website). He wisely used this as an opportunity to revisit the design (technical and non-technical) issues with this application. During the course of these conversations, my friend was speaking to one of our customers, who just so happens to be trying this application out in development. My friend asked how it was going and the customer responded with:

“I’m getting used to it.”

If you are a person passionate about creating the best possible User Experience for your organization, those words should make you ill. Ask yourself honestly, does that phrase speak well of a design to you? When you hear the phrase, “I’m getting used to it,” don’t you think it applies more to:

Having to wear a suit to work every day;
A new toupee;
A persistent rash;

rather than an admin tool that is supposed to aid in the automation of a manual process?
I can’t say enough about how much it bothers me that most of us in the IT world don’t see the difference between “This is so easy to use, it’s like second nature” and “I’m getting used to it.” And that’s why I think that phrase is a death knell for an application and a virtual guarantee that one of two things will happen:

1) Drastic enhancements will be requested 1 minute after the application is deployed.
2) The application will be abandoned and old, familiar, manual processes will resume.

It seems to me that “I hate this, it doesn’t work for me” is a better thing to hear because your manager will see the benefit of doing some UT and a redesign. In this case, the busy, over-worked IT world sees an “I’m getting used to it” as close enough to the bull’s-eye to move on. But then again, maybe I’m just trying to create broad observations from one incident. Thoughts anyone? Maybe you can back me up or tell me I’m wrong…

Usability, User Testing, User Experience, UI, Design

I’m not usually the kind of person that stops to fill out online surveys. Most of the time, I find myself hassled by the unethical way most survey sites offer free drawings in exchange for the right to spam me and sell my email address to the highest bidder. On occasion, though, I break my own rules and do complete surveys. In this case, I got exactly what I expected… something to write about.

This survey, which was conducted by PollingPoint.com, was a simple, straightforward survey. It consisted of three pages of questions about entertainment, politics, religion, etc. It was easy, and it took me two minutes. Once the survey was complete, Polling Point asked for my contact information so that they could send me more poll invitations. Here’s the screen:

On the surface, this page is pretty straightforward. However, I have a couple of problems with it. Keep in mind that I try to approach every screen I see like a casual browser, not the developer and frequent web user that I am:

1. What do the asterisks (*) next to the name and email fields mean? I suppose they could mean that those three fields are required, but they aren’t; I can navigate away from this page without filling out anything. But even if they were required, the only web convention for denoting required fields they seem follow is the presence of the asterisk. What they didn’t do was make the asterisk red, place it before the field and place a note at the top of the page communicating as much. But since none of the information on this page is required, I can only assume that the asterisks mean that I should fill out those three fields if I’m going to fill out anything. This is probably not the best way to communicate that information. Even still, since there is nothing on the page to map the asterisks to their purpose, I’m only making an assumption and I could be totally off.

2. I need to be reassured that you’re not going to pimp out my information before I fill out the form. This is nit-picky, I know, but it makes a difference in conversion. Most people are going to miss that note because it’s jammed between the form and the navigation buttons. In addition, the first sentence can be emphasized a bit more. That’s the reassurance the user wants to hear.

But alas, I am not interested in receiving invitations to complete surveys, and since nothing appears to be required, I click the “Next Page” button. Here is the result:

Two thoughts on this page:

1. Never, ever keep a user from navigating away from a page with NO required information. To a casual user, no good can come of this and only confusion will result. “Why am I seeing the same page again, and with lots of red text?” they will ask as close their browser. I should never see red on a page where nothing is wrong and nothing is required. A better solution would be to allow me an opportunity to change my mind and return to this form on a future page.

2. “You may continue to skip entry of this information.” That’s exactly what I was trying to do, isn’t it? So what do I do now? If I click “Next Page” again, will it give me the same message or let me go? This message, which is unclear and grammatically incorrect, isn’t really helping me and I don’t even know exactly what to do until I click “Next Page” again and it actually works. This is not a difficult fix, but changing the text to read “Click ‘Next Page’ to skip entry of this information” can make a big difference.

After clearing the land mines, I am presented with the last form, which, aside from trying to get me to enter a drawing for an iPod mini, actually employs a good method for increasing conversion:

The box to the right, which gives me an opportunity to go back and complete the last form, is the right way to go about this process. Unfortunately, I’ve already gotten a bad taste from being unable to leave the form behind and I won’t be changing my mind this time.

The point of bringing up PollingPoint.com is to illustrate that there is more to a satisfying user experience than slick and simple interfaces. PollingPoint had those, to be sure. But a user will quickly forget about the look of something if they’re having trouble completing a task.

I think it’s time I get back to the “Design for Context” series now, so I’ll return in my next post with “Ideas vs. Implementation” as promised.

I want to make sure that, from time to time, I’m giving praise to sites, apps and everyday things that bring happiness to the user locked within me. So that I can never be accused of only seeing the negative, here’s one right now…

I was downloading a trial version of AppRocket by CandyLabs this morning, when I was presented with the following on the post-download page:

Some things I like about this page:

1. No attempts to make be buy the full version of the software before I even try the trial. CandyLabs knows that I’d like to try out the application before buying, so they don’t bother to try the instant upgrade routine. You’d think that would be common sense, but it’s not in this crazy, mixed-up world. Several years ago, I walked into a Bally Total Fitness with the intention of going through a two-week trial. Rather than getting that trial card right away and being left alone for two weeks, I was pitched by a sales guy who told me they’d discount those two weeks off of a three year membership if I signed up that very day. I hadn’t even seen the inside of the club yet!

2. No ads. CandyLabs has no interest in keeping me on the site at this point, and that’s a good thing. They want to send me skipping off like a kid with a new baseball glove, and I appreciate that. It gives me a positive impression of their business and gears me up to test drive the software.

3. An important message on the page that’s actually important. Notice from the image that there isn’t much CandyLabs feels the need to say after I’ve requested the trial download. Here’s the text in question:

I can’t say enough about how useful and friendly this message is. The .NET Framework is in my blood, so you can bet I’ve already got it installed. But I can also put myself in the shoes of someone who has never even heard of the Framework. I can bet that said individual would find the idea of installing one piece of software and suddenly being asked to install another along with it both annoying and a bit scary. CandyLabs sees this and, not only helps out those customers with friendly, accessible language, but they probably saved a few aborted installs and, therefore, sales.

This is the kind of consideration for customers that I love to see. In addition, CandyLabs gets marketing out of the way and lets the software speak for itself. As long as they never hire marketing reps from Bally Total Fitness, I think they’re on the right track.

Here is an interesting site: http://www.dontclick.it/

The goal seems to be to educate us commoners on how ingrained clicking is to our navigation of the web. They do so by promoting and forcing navigation through “gestures” and by removing all click functionality from the site. For example, when I move my mouse over a link, the link is immediately activated.

I said it’s interesting, but I hate this site. Here’s why:

1. I’ll give them that clicking is an ingrained behavior, but why does it need to change? If I change the way that web navigation works, doesn’t that run contrary to all other user interfaces (i.e. Windows XP) that rely on click events? I see this like arguing that a steering wheel is a bad control mechanism for a car and we all need to start using joysticks when we drive.

2. From a user experience standpoint, it strikes me as a bad idea to tell a customer that their habits and behaviors are the problem and ask them to change. The key to creating a satisfactory user experience is to recognize that all web use is idiosyncratic and the best we can do is to cater to the 80% of our customers that expect to use our site a certain way. We should never seek to force our customers into a set of behaviors or ways of thinking.

3. I was careful NOT to click, but I accidentally did once after I finished reading something on the site and forgot where I was. After I clicked a link, the entire screen fuzzed as a TV with a bad signal would and I was presented with this message:

“Oops! You accidentally clicked even though there isn’t anything to click.”

I was forced to stare at this screen while a 10 second countdown clicked away before I was returned to the main interface.

While I appreciate the pavlovian attempt to slap the clicks out of me, I shuddered to think about what a casual user would think about such a thing. I can guess that most casual users would shut the browser down before the countdown had clicked off 5 seconds.

4. It’s not practical. If you want to sell me on a different way of navigating a site, do it practically. Put up a pseudo storefront for me to browse products. Show me how easy it would be to add items to my shopping cart. Make me fill out a form so I can see that the “no click” interface makes that simpler. All I got from this site was 5 minutes wasted and something to rant about.

5. It’s gimmicky and silly. But hey, they got my attention…

“Bad design cannot be patched up with labels, instructions manuals, or training courses.” - Donald A. Norman, The Design of Everyday Things

A couple of weeks ago, my wife and I ventured to Home Depot for a couple of items we needed in the midst of renovating our master bathroom. What started as a simple job of laying porcelain tile where once there were carpet pieces and linoleum has turned into a complete repainting of the walls, new tile on the counter, new fixtures, etc. That is a story for another day, though.

Our purchase from Home Depot was a typical case of “Going back after the initial trip to get the things you either forgot or didn’t think you actually needed.” So we didn’t have a large number of items, maybe 4 or 5 things. When I make a trip like that, I tend to use the self checkout that Home Depot offers. It’s a staple of any grocery shopping experience for us, so I usually gravitate there at Home Depot if I’m purchasing a small number of items.

On the evening in question that my wife and I were there buying 4 or 5 items, we encountered the following:

• We waited 2 times for human visual verification of items.
• The system told us 3 times to replace an item in the bags that it felt we had removed when, in fact, we had not removed anything. Human intervention was required to “reset” the system so that we could continue.
• One item would not scan and required the self-checkout employee to take the item back to her station, scan it for us and then bring the item back.

Keep in mind that we had small items no bigger than would be in your basket at a grocery store. Unfortunately, I’ve found this kind of experience to be typical when I’m buying more than two items at the Home Depot. In addition, it wasn’t isolated to us. The couple next to us was encountering similar issues requiring human intervention. That means that, in addition to not being able to checkout without human intervention, we each were required to wait while the employee helped the other couple. It would have actually been faster for each of us to get in a typical line rather than attempting self-checkout even though we were “ideal” users of self-checkout as far as the Home Depot is concerned.

While our self checkout experience on this particular evening wasn’t overly painful in that it still took less than five minutes, it also wasn’t swift like a self-checkout experience at a grocery store tends to be. That, combined with the couple next to us who were obviously “muddling through” their checkout experience, got me thinking about self checkout and design for context.

The difficulties in the self-checkout at Home Depot seem to center around the business rules they used to “calibrate” the system. More so than a typical grocery store, Home depot offers products that vary vastly in size, dimension, weight and price. You can purchase anything from a single nut to a pre-built aluminum shed and you can do so through self-checkout. As a result of this “shopper must be able to purchase any item at self-checkout” business rule, the system is set up to do some funky things that the person buying spray paint and drywall screws sometimes gets frustrated by. Similar to the experience above, I’ve been through the line buying 180-degree caps for my sprinkler heads and had to wait for approval from the warden of the self-checkout that hovers from station to station.

While enabling customers to purchase anything from self-checkout is a noble goal for the Home Depot, ask yourself what you think a self-checkout system should be designed for. Now, I could be wrong about this, self checkout could have been designed for the amusement of the employees that work at the stores where it is used, but I surmise that the intention of self-checkout was designed to accommodate the “in and out” shopper. It’s the Amazon.com 1-Click of the brick and mortar world. It was installed in grocery stores and the Home Depot alike to accommodate one of the two types of shoppers both venues get: the “I need a few things and I want to be on my way” group. One could argue that this also helps the other group, the planners who load up on a weeks worth of groceries or a project’s worth of supplies and aren’t (or shouldn’t be) in any kind of hurry. They don’t have to wait behind a line of 6 people each getting one item while they block the front aisle with large sheets of plywood and 2×4s.

The problem is that the business rules tend to hamper the demographic they should be targeting by setting up just-in-case rules for people buying abnormal items that won’t fit on the weight-sensitive bagging tray or high-priced items that require visual verification. The just-in-case idea is admirable for the Home Depot because they try to accommodate every shopper they have, but it damages the experience of the in-and-out shopper when they are affected by business rules that don’t apply to them.

And thus, this is a problem of failure to design for context. I’m not suggesting that the Home Depot failed to consider their context altogether; the fact that they calibrated their system with so many rules suggests that they did. The problem is that they designed for one context and assumed that the “out-of-the-box” system would work for the other.

Doesn’t that sound a bit like the original query from my first post: “Take a look at widget.com and let’s do it like that?” The moral of this story is that the context of your business and of your customer base is important. There is no such thing as an out of the box solution for either unless it’s your box to begin with.

In my next post, I’ll continue this discussion with a bit about where this kind of context breakdown occurs: ideas vs. implementation.

Have you ever been in a design meeting with a customer and been told something like this:

“We need to add [a cool new feature, content, functionality, etc.] to our site. Take a look at [Amazon, Google, Microsoft, or any other oft-compared-to website.] and let’s do it like that.”

I’m sure you have. If you haven’t, you haven’t been in many design meetings.

Most of us probably get a deer in the headlights reaction to this and simply say “I’ll take a look” or, “That’s an option,” when in reality, that statement should prompt us to direct a barrage of questions back at the customer.

What questions, you ask? Questions about context and usability. More on those in the next few posts…

Here is what is happening when a request like this is made: Your customer wants your site to look like the site in question with the goal being to have their traffic and do their business. There is this nice trend on the web these days towards homogeneity (for a number of reasons) and, while I think that uniformity equals usability to a fault (read: on a site-by-site basis), I do not think the entire web needs to operate in the exact same way.

And I don’t think anyone is saying that out loud. I just think that internal customers for those of us that create and maintain a corporate web or webs are starting to ask for and expect that.

“What works for the goose, works for the gander,” they think and say. But what if the goose is selling pet medication and the gander is peddling over-priced duvet covers?

In all honesty, if I’ve determined that something is very effective on my site because I’ve taken the time to conduct user testing, do I really care if it will work for yours? Conversely, just because you’ve done something on your site that enhances my user experience doesn’t mean that it will work for my site.

Notice one key thing I said in the last paragraph. “I’ve taken the time to conduct user testing.” That is the biggest IF on the web. It’s also the caveat to any evaluation of something working for you in your context. Remember the old logic question that went something like this:

“If all snarps are flarps, and some flarps are clarps, are all snarps clarps?”

Meaning: Some users on my site may use widget.com a little or a lot. But I can pretty safely assume that some don’t, so why would I design aspects of my site to pattern widget.com just because widget.com does it and some of my users are familiar with it.

In addition, what guarantee do I have that widget.com actually did any of their own user testing on this functionality? They could have stolen it from doohickey.net. And who knows if they actually tested it on their site. And so on…

My muddled point is this: I think that we’re in a world where our customers will supplant their own user testing with something that works for another site. The flaw in that reasoning is that we don’t know how they decided that it “works.” They could mean:

• It looks nice.
• It works… for me.
• My son uses this site all the time and raves about this.
• My admin suggested this to me.

Our challenge is to reverse that thinking by asking questions of context and championing user testing for everything we design.

My next couple posts will spend more time expanding on the concept of context. Then I’ll wax a little on user testing. Finally, I’ll look at consequences of our current path and what we can all do to work asking about context and user testing into our daily lives.