Communicating Effectively with Users - Part One

Published in Web Development on Thursday, June 2nd, 2005

What exactly do I mean with the title of this article? Well, in part one I'm thinking about the messages that we provide as feedback to the users of our websites. Be they error messages, help messages or whatever, there is a need to ask "am I communicating effectively with this message?"

"Ach, I've heard this before"

I know that this is a tired topic, it's been written about on blogs before and even books have been published about the subject.

However, in a sense this is a little like how we have to keep hammering home the idea of proper semantic markup, because the abuse just keeps happening. I find examples of poor, ineffective communication on the web every day and I can't help but wonder if people ever stop and ask themselves "is this what I want to say here?".

"No time, no budget"

This argument manifests itself time and again as an excuse and lets face it, for some websites out there it is a valid reason for the lack of some level of contingency design. So for those of you who don't get the time or money to build very effective contingency design into a site, I understand. However, examples like that provided below could be avoided if we simply took a few more seconds when developing some facets of our websites. So while this argument is valid, it is so only to a degree.

Lets look at an example

The following image contains an example of what I am talking about. I grabbed it from a site that belongs to a company that, ironically, has helped me to communicate more effectively.

Problem #1

By examining the image, you can see that I tried a search and it did not return any results. Rather then use some friendly message and perhaps using a style "error page suggestion" feature to help me on my way, this site simply says "Error: No matches were found". Oh really, in what way is this an error, anyway?

This is where I would suggest that someone have a look at this and ask:

"Is this what I want to say here? Does this convey the problem or message clearly and help the user on their way?"


The fact is, I searched, and no matches were found. Matches? How about products? I searched for a product, not a matching term in your database. Users shouldn't have to figure out what a message means. If they do a product search and no products were found, simply tell them that no products were found!

[h4]Lets try that again[/h4]

I would suggest something more along the lines of "We're sorry, but we did not find any products that matched your enquiry." After that they could offer up a contact form or perhaps some suggestions for other products.

Problem #2

This is a bit of a pet peeve of mine, and has to do with the live help box shown in the left of the image above. This feature has become very popular, but let me ask you:

  1. How many times have you actually seen this feature working on a site?
  2. How many times do websites post a schedule indicating when the live chat will be open?

1. Companies should not use the live chat if they don't have the staff to support it and 2. Give me a day and time and I'll return and use it, leave me guessing and I'll give up after the third try back, and I'm a patient person.


In this example, users are given a cryptical and not too helpful message, and then they are left somewhat hanging to dry with the unattended live chat (granted a user could log in and leave a message). This website would benefit from better communication:

  1. Give a clear search result message: "We're sorry, but no search results were found for your search: Search terms here".
  2. Use consistent terminology: A user is searching for products, not matches.
  3. Let a user know when a feature will be available: "Our chat is online from 9am-5pm GMT, M-F".

These are very simple things that need not add much to development time once a developer gets in the habit of thinking a little harder about who will be reading the messages a website provides.

Comments and Feedback

Perhaps a beaten topic, but is the problem still rampant? Indeed.

I never really payed much attention, but I don't think I've ever seen "Live Support Now Open" or similar... maybe it's because I'm on the 'wrong' side of the planet :?|

In your example, there is a third problem:
Asking your customers to search by numerical ID is EVIL!.

Sorry 'bout that, I have to put up with a numerical search in the learning management system at the Uni I work for. There are other options, but the fact that this is the default is just wrong. AHA! (literal brainstorm moment!) I'll make a greasemonkey script to switch to title search automatically.. /me makes script.

Awesome! Thankyou Mike, you just sparked my mind onto the concept of fixing my own problems :D

Oh o.. I've gone off topic AND ranted..

Hey Andrew... A good point, for users outside of the North American business hours, the chat sure can be frustrating. Having the timetable there would be an advantage.

Numerical ID search can also be frustrating - a good point. In this case, perhaps while validating the user input they could check to ensure that it is numeric and, if it isn't, point them to a text search....

Feel free to rant anytime ;-)

You can go back to the old saying, Would your computer illiterate mother be able to use it. If not, why not?

I think another problem some people must face is forgetting the fact that not everyone that uses the internet speaks english as their first language. I can only assume how hard some site must be to use for a person still learning english.

The reality is that live help rarely works even for those of us on North American time. Even if a company runs on a 9-5 schedule, that often means Eastern Time. Ok, if I need support for something at work, horrible if I need support for something at home. (I'm in the central time zone.)

Nevermind the fact that live help is almost never staffed.

Seems to me, especially with the internet, that people are in such a hurry to get sites up and running that they don't spend enough time thinking on how users perceive that information. Like e-mail, errors and typos are considered the norm and people jsut accept that as a fact. If we took a little more time to think through how and what we communicate, a lot of the issues you bring up would be greatly reduced.

Nice points.
The "no time, no money argument" is such a weak cop out. As you say it doesnt take much time to add this kind of contingency, but for a shopping search to return an error is ludicrous.

If I received this error I would lose total confidence in company x as a supplier and they in turn have lost my business now and in the future.

Not the time or money to worry about lost sales for a client? It's just lazy.

Home » Blog » Web Development

Check out the blog categories for older content

The latest from my personal website,

SiteUptime Web Site Monitoring Service

Sitepoint's web devlopment books have helped me out on many occasions both for finding a quick solution to a problem but also to level out my knowlegde in weaker areas (JavaScript, I'm looking at you!). I am recommending the following titles from my bookshelf:

The Principles Of Successful Freelancing

I started freelancing by diving in head first and getting on with it. Many years and a lot of experience later I was still able to take away some gems from this book, and there are plenty I wish I had thought of beforehand. If you are new to freelancing and have a lot of questions (or maybe don't know what questions to ask!) do yourself a favor and at least check out the sample chapters.

The Art & Science Of JavaScript

The author line-up for this book says it all. 7 excellent developers show you how to get your JavaScript coding up to speed with 7 chapters of great theory, code and examples. Metaprogramming with JavaScript (chapter 5 from Dan Webb) really helped me iron out some things I was missing about JavaScript. That said each chapter really helped me to develop my JavaScript skills beyond simple Ajax calls and html insertion with libs like JQuery.

The PHP Anthology: 101 Essential Tips, Tricks & Hacks

Like the other books listed here, this provides a great reference for the PHP developer looking to have the right answers from the right people at their fingertips. I tend to pull this off the shelf when I need to delve into new territory and usually find a workable solution to keep development moving. This only needs to happen once and you recoup the price of the book in time saved from having to develop the solution or find the right pattern for getting the job done..