Every retailer seems to have a different idea of what “shipped” means. When they say they’ve shipped an order, the real status might be:
– The box has been packed, but there’s no tracking number and it hasn’t left the warehouse.
– The box has been packed and it has a tracking number, but it hasn’t left the warehouse.
– The box has been packed, it has a tracking number, and the shipping company has picked it up, but the tracking info doesn’t show it’s in transit.
The list goes on and on, but the point is the same no matter how many different variations we come up with. For customers, there is only one relevant definition of “shipped”: the package has left the retailer’s warehouse and is physically en route to the customer’s home or office, as confirmed by the tracking information. A tracking status that says “Billing information received” doesn’t cut it.
When something has been shipped, people expect to be able to view when it was picked up and when it’s going to arrive. This, of course, is the purpose of tracking numbers and the like. Retailers seem overly anxious to call packages “shipped” before the point that customers can verify the items are en route. It’s too bad there’s such a disconnect here, since closing the gap would reduce the number of questions that retailers get about shipping status, e.g. why a tracking number has been assigned but UPS or FedEx says the package was never picked up.
Filed under: User Experience | Closed
While exploring part of Chicago’s underground Pedway system, I saw a sign pointing to a building that I didn’t think you could reach from underground. I followed the first sign and then a few additional ones until I reached an escalator to the building. However, the escalator was blocked off, and a small sign explained that the entrance was only available during business hours. At this point, my sense of discovery quickly gave way to disappointment.
Remedying this type of problem is really easy. If a sign directs people to a location that’s only open at certain times, the signage itself should disclose that limitation. I’m not talking about cramming the hours of operation into every navigational sign. Rather, you might create a special icon, write something like “Weekdays only”, or point people towards a more detailed resource, e.g. “See directory in concourse area for hours”. In reality, all you’re doing is setting proper expectations for what comes next in the journey. Do this well, and people will be much happier — even if what they’re looking for happens to be closed at that time.
Filed under: User Experience | Closed
Redundant controls
Although user skills can vary widely, virtually everybody that browses the web will be familiar with the Back button, scroll bar, and other basic controls. So, why do so many sites still insist on presenting alternate sets of controls that do the same thing? Providing another way to accomplish a task that the user already has a solution for will lead to wasted screen real estate at best, and confusion at worst.
In particular, I’m talking about the “Back to top” buttons that I’ve been seeing on a lot of websites lately. Do these really serve a purpose? Doesn’t the scroll bar do the same thing? I consider myself a fairly savvy web user, and I almost never click on “Back to top”. Sure, you might argue that the button is there for people who don’t understand the scroll bar. But if that were the case, they’d never reach the bottom of the page anyway.
So, when you’re thinking about adding this type of feature to your website, consider whether you really want to duplicate something that the web browser already does. Sometimes, these features can be useful, like the large “Close” button that appears in a product detail pop-up. But in most cases, there’s no need to provide redundant ways of doing the same thing. By leaving out these extra controls, you’ll reduce confusion and preserve more space for the actual content that your site is focused on.
Filed under: Design, User Experience | Closed
Predicting loyalty
Which type of customer is more likely to remain loyal in the long run: the person who orders the same product every time, or the one who likes to experiment and try something new? I would probably guess that the first group is more loyal, but I wonder if they’re more likely to go elsewhere whenever there’s a slight difference in quality or service delivery. Maybe the risk-takers actually have more realistic expectations of how a relationship evolves over time.
Filed under: User Experience | Closed
Response patterns
Lately, it seems like all the customer service departments I encounter are grouping their responses into two categories:
“No one has ever had a problem with that before” (so it must be your fault, not ours)
-or-
“This is affecting thousands of our customers” (it’s nothing personal, but there’s nothing we can do about it)
While each of these response patterns might seem logical to the customer service rep, they just serve to annoy the person on the other end. Attempting to downplay the importance of the customer’s problem usually means you’re not even listening in the first place. Issues rarely fit into neat little boxes, and trying to force them in there just makes you sound like an uncaring drone.
The next time you’re helping a customer with a problem, be careful not to fall into these response traps. Listen and respond in your own voice, and you’ll help people get to the source of the problem faster.
Filed under: User Experience | Closed
Most hardware and software products are designed to be used for a relatively long period of time, typically one year or more. During that time, the user will grow accustomed to how to operate the product, and the product has the opportunity to collect quite a bit of data about how its owner uses it. With this in mind, it’s surprising that so few products actually take advantage of this wealth of usage data.
Specifically, I’m interested in how products can look at historical usage patterns to help prevent errors. For example, if you always set your alarm clock for either 6 am or 10 am, shouldn’t the clock remember this and show a warning if you set it to 6 pm by mistake? Or, if you always bill a particular client at one hourly rate, shouldn’t your accounting software let you know if you suddenly try to charge them a different one?
I’m not talking about sophisticated artificial intelligence here. Rather, I’m just pointing out that a simple heuristic based on user behavior over time can be employed to prevent costly errors. Simply keep a log of how a customer uses the product, and then warn them whenever their current behavior varies significantly from their historical levels. I’ve yet to see this implemented in any piece of hardware or software, but hopefully somebody will give it a try. Until then, I’ll be lamenting how even the best-designed products learn so little from our ongoing interactions with them.
Filed under: Design, User Experience | Closed
Push versus pull
Many non-profits will sell your contact information to other non-profits without your consent. However, these organizations rarely advertise any type of discount for patronizing the other organizations in their peer group. I find it ironic that they’re willing to blindly spam their members, but won’t provide any incentive for those who actually want to get involved in multiple organizations.
Filed under: User Experience | Closed
The best features
…are the ones that people take for granted. Customers use them to complete their tasks quietly and efficiently, and never think twice about just how useful those features actually are. But when there’s a bug or glitch with that functionality, you’d be amazed at how many people speak up. This isn’t a complaint on my part; rather, I’m just making an observation about the dynamics that surround the most essential — and often unglamorous — parts of a product.
Filed under: User Experience | Closed
Practice what you preach
I’ve always found it strange that some professionals don’t follow the same advice that they give their clients. For example:
– Doctors that smoke or drink heavily
– Car salesmen that drive a different brand of car
– Web designers that have terrible websites
This sort of behavior erodes your credibility almost instantly. Why should people trust you if you don’t even follow your own recommendations?
Filed under: User Experience | Closed
Choosing the right range
In the summer months, it never seems to get as cool as the daily low in the weather forecast would suggest. Those 65 degree nights always end up hotter and muggier than I expect. Thinking about this a bit, the reason is fairly obvious: the day’s lowest temperature usually occurs in the early morning hours when virtually nobody is awake, let alone outside to experience it.
With that in mind, the whole concept of the day’s high and low temperature is somewhat flawed. Wouldn’t it make more sense to report the ranges for when most people are actually awake? Focusing on the highs and lows for the period of say 6 am to midnight should cover most of the population, and would be a lot more useful for helping us decide how to dress on a given day. The forecast can still provide the overnight low for those who are curious, but without the emphasis that it receives today.
More generally, the problem here is that you’re starting with a wealth of data, and the easy choice is just to report the full extent of that data set. In the weather example, this means temperatures across the full 24-hour period. However, it turns out that a subset of the range is what most people care about. For this audience, generating summary data based on the full scope of the variations can easily be misleading. So, the next time someone asks you to summarize a set of data — whether it’s daily temperatures, sales numbers, or airline delays — be sure that the range you’re studying is what the audience actually cares about most.
Filed under: User Experience | Closed
You must be logged in to post a comment.