Dealing With Goldilocks December 19, 2008
Posted by Chuck Musciano in Leadership.Tags: Automobiles, Customer Service, Interfaces
add a comment
Recently, my wife’s car wouldn’t start. Drawing on my deep technical acumen, I jump-started the car and took it to a local repair shop. They agreed with my diagnosis of a bad battery, but to be sure, they wanted to test my battery with their special equipment. This would ensure that the battery was the culprit, keeping me from wasting my money when the problem might lie elsewhere. They would even provide me with the diagnostic printout showing the exact problem.
I hate getting car repairs, and this kind of customer service was pleasantly unexpected. After a little while, the technician returned with the promised printout. Along with the date and time, the printout provided this complete technical analysis of my battery:
REPLACE BATTERY
Wow! With this kind of detailed analysis, it was clear that my $130 would be well-spent.
Where were the voltages and amps? Where was the graphical display of the cells in the battery, with one or two in red? Where was some sort of chart, showing how quickly the battery would charge and then die? Where was the link to the online version of the report that I could view years from now? How about a special code I could text to a server, or a Twitter stream for my car?
Clearly, my expectations of the diagnostic report were very different from what the vendor provided. And in the mechanic’s defense, many customers need only see that printed confirmation to verify their battery suspicions. Volts and amps don’t mean much to most people.
Every customer is Goldilocks: they don’t it want it too hot, or too cold. They want it just right. As technology designers, we struggle constantly to anticipate “just right” and deliver it quickly and reliably. But we rarely get it right, because every user has a different definition of “just right.”
What to do? Personalization may be the answer, but can be cumbersome and very expensive to implement. Presenting progressively detailed data can help, allowing users to dig in deeper as their interests dictate. Even offering a few versions of a report or interface (beginner, experienced, and expert) can mitigate a lot of user complaints.
Although it is difficult, we cannot give up on finding the sweet spot for our users. Because if we do, we may find that one day our boss shows up with a diagnostic report of their own:
REPLACE CIO
.
Truth In Business Cards December 3, 2008
Posted by Chuck Musciano in Random Musings.Tags: Business Cards, Interfaces
2 comments
I get handed a lot of business cards. Some get keyed into my address book; most do not. All get thrown away. And many suffer from the same problem: unnecessary labels.
Why do people have business cards that needlessly prefix their phone number with the label “Telephone?” Is that really necessary? Is there anyone, anywhere in the world that does not recognize a lengthy string of digits as some sort of telephone number? Do you really need to take up precious space on the card to clarify that number? Do you think a lot of people mistake a phone number for some odd post office box or extended zip code? Me neither. Yet, there it is.
Some would argue that cards with multiple numbers need to clarify which number is which. I agree. But let’s agree that your main number doesn’t need further elucidation. For your cell phone, a simple “C” would suffice. And honestly, why are you putting a fax number on your card? When is the last time you faxed something to anyone without first calling to confirm that you were going to do it? For the two faxes you send each year, call their main number, ask for the fax number, and you’re good to go.
Even worse are those cards that label your email address as “Email” or (the worst) “Email Address.” Let’s face it, if a person doesn’t realize that the odd string of characters with an “@” in the middle is an email address, the odds of them successfully knowing how to use that address are pretty slim. Let’s give everyone the benefit of the doubt and assume that we can all successfully find the email address on a business card.
Finally, drop the separate listing of your company’s web site. It’s only there because someone in marketing thought this would be a great way to drive traffic to the site. If your email address is correct, I already know what your company URL should be. If I can’t figure out that prefixing “www.” to your email domain name does the trick, I’ve got bigger problems. And if your company web site isn’t the same as your email domain, your company has bigger problems than both of us.
[tweetmeme source=”EffectiveCIO” alias=”http://j.mp/cio162″ only_single=false]
Another Web Irritant November 21, 2008
Posted by Chuck Musciano in Technology.Tags: Interfaces, Irritants, Software
2 comments
I understand that advertising helps keep vast swaths of the web free. I respect a site’s right to sell ads; I just wish they would respect my intelligence.
The latest affront to my self-esteem comes along with interstitial ads, those full-page popups that appear for a fixed period of time before letting you see the real content you were seeking. I don’t mind the ads; that’s part of life, and that’s why Firefox has all those clever ad-blocking plug-ins.
I do mind the inane message that accompanies the ad, the one that says something to the effect of “Please wait while your page is loading…” While my page is loading? Come on!
I suppose there are some folks who may think that web pages are handcrafted as you request them, with teams of web artisans standing by to put all that content together in the fifteen seconds that the ad stays on your screen. For those folks, it may seem like a courtesy to provide something to look at, instead of a blank screen and an hour-glass cursor.
If only they knew the exact opposite: your page starts rendering after the ad goes away, and the twenty-something web designer who put that “Please wait” message on your screen got a snarky chuckle over getting away with such a blatant, insulting lie. It’s as if a full page ad in a print magazine had a tag line at the bottom: “Please wait for fifteen seconds while we print the next page.”
How about a little truth in advertising? I’d much prefer a message like “Please, please take a moment to look at this ad. We’re running out of VC funding, and unless we get some positive cash-flow out of our ad-based revenue model, I’ll be looking for my fifth job in three years.” If I see that message on my screen, I’ll not only read the ad, I’ll click through just for good measure!
Lazy Developers November 17, 2008
Posted by Chuck Musciano in Technology.Tags: Interfaces, Irritants, Software, Users
add a comment
You see it all the time on web forms: the little bit of “advice” next to entry fields for phone numbers and credit cards: “No dashes or spaces.” This drives me crazy!
Let’s understand this: the developer is asking you, the unfortunate user, to make sure you enter data correctly to match what he needs. Because… it’s so hard for computers to get rid of characters that aren’t numbers? No. Because the developer is too lazy to write the code to get rid of the unwanted characters you may type.
Ever type in a phone number with dashes, only to be dinged with an error popup chastising you to not type the dashes? Ever put spaces in a credit card number only to be similarly admonished? If so, you have been the victim of a lazy developer, one who deserves to have their keyboard seized and their pocket protector revoked. That’s shameful coding, and it should be punished.
In case you were wondering, it is trivially simple to automatically remove non-numeric stuff from numeric fields. Actually, it’s trivially simple to configure the field to keep you from typing them in the first place. It actually takes a lot more work to check for the errant characters and pop up a window to irritate you that it does to fix the $%&^# field in the first place! Bad developers will spend more time writing bad code that irritates the user than they will writing good code that makes life easier for the user. Go figure.
All software development is about the end user experience. Period. The user experience should be natural, easy, forgiving, and rewarding. It should not be filled with pedantic errors and foolish activities better left to the machine. Developers who develop anything less should be ashamed, and user should complain vociferously when they are forced to use such systems. Stand up and demand better!
These Eyes… February 16, 2008
Posted by Chuck Musciano in Technology.Tags: History, Interfaces
add a comment
I am a huge fan of mobile devices. I was one of the first people to use a Casio Zoomer back in 1992 and moved on to Palm devices in 1998. I recently made the Great Conversion to a Blackjack smartphone and upgraded to a Blackjack II last November.
I love seeing what new things you can do on these devices, and am always willing to try new tools and applications on my phone. But there is a limit. Some things were not meant to be done on a phone.
The fundamental problem with phones is that the display can only convey so much information. As tools get more and more sophisticated, it seems that the designers are trying to display more and more information on the display. Microsoft seems intent on running the entire Office suite on my smartphone, and phone browsers struggle to handle the complex content of full web pages.
I finally realized why this is happening. The people designing and building these tools have 25-year-old eyes. Many of the people using these tools have eyes that are… much older. Tiny little sharp letters and itty-bitty icons work great for young users. They are completely wasted on us more mature technophiles.
Have you ever tried to use Mobile Excel? Somehow, being able to see five or six cells of a spreadsheet at once leaves a bit to be desired from a usability perspective. Even as tools get more sophisticated in their rendering capabilities (the latest crop of zooming browsers is very cool), there is still only so much you can see at once on the screen. Even when I zoom out until I can just barely read the text on the screen, I still find myself panning back and forth just to read a single text flow in a document. Attempts to reflow the document often break the layout and make the document difficult to understand.
This is all the result of what I call “Mount Everest development.” Many tools are ported to mobile platforms just “because it is there.” It may be clever and a testimony to someone’s development skills, but it is ultimately useless.
When IBM PCs first became popular, one of the most important things you could buy was an Irma board. It added the coax connector and software that let your PC emulate a 3270 terminal. Migrating a 3270 mainframe display onto this new platform was useful, but hardly scratched the surface of what the device could really do.
The real breakthrough on these devices occurs when clever ways to exploit the form-factor emerge. Instead of dragging the tools of the past onto the platforms of the future, we need to figure out how to use these platforms in ways we never previously imagined.
The Effective CIO 