Just a Thought...

How do you know if your design is any good? Some people will tell you that if the user doesn’t have to think about it and it just works then you’ve got it right. There is a lot of truth to that, but what if what you are doing is going to bend people’s brains in the beginning? It’s particularly an issue if you want to overcome a cultural barrier to free people from the shackles of their backward thinking. Once they get over this cultural barrier and they “get it”, then they can see the limitless possibilities ahead of them. The best way to illustrate what I mean is to use a case study.

Department of State

The U.S. Department of State has a messaging system that has been in place for several decades, and at the time they were very forward thinking. They had a set of Traffic Analysis by Geography and Subject (TAGS) keywords that can be associated with each message. It didn’t stop there, you could associate any word you wanted to with the message and it would be called a Term. Now, the confusion lies in the fact that both TAGS and terms were marked in the message by the heading “TAGS:”. Anyone who has done anything with web 2.0 technologies can immediately recognize that both these TAGS and Terms fit the concept behind tagging. The Department of State has been doing this for years. My company has developed a system to allow all the federal government agencies to find, tag (in the web 2.0 sense), and consume these messages. Ironically, most of our users are outside the Department of State. They don’t have the cultural bias as the Department of State.

Since the beginning of the project, we operated under the assumption that it was going to be primarily for the Department of State, and maybe a few folks from other agencies would be accessing the database. It didn’t turn out that way, and as Guy Kawasaki mentioned in his online presentation “The Art of Innovation” you don’t get uptight because different people are using your application than you anticipated. You work with it. None of our other users don’t have the Department of State background and baggage, so they don’t really get tripped up if you call something a tag or a term.

We made a conscious design decision for this version of the software, and that was we were moving to a more standard web 2.0 model. All our previous discussions on the matter confused things, and if the designers were getting tripped up over where to use TAG, Term, tag, etc., then what about our users? The truth of the matter is, we could view all the tags in the system as plain old web 2.0 tags. It’s just that some of those tags have special meaning to a large portion (but not majority) of our users. So when we implemented the rel-tag microformat, we added a note when a tag was important to the Department of State. This also opens up our system so that we can support other categorization systems for other government agencies.

As we got to a place of testing the system, we wanted to put some extra eyes on the new application. To do that, we put a version on the staging server and asked certain people to look at the preview version and give us our thoughts. I noticed something interesting, the people we have been coordinating with since the beginning have been educated all along and didn’t have any problems whatsoever. The one or two that handle support requests for the existing system had a hard time. In the “bug” reports he unconsciously kept referring to the web 2.0 tags as TAGS, and drawing the separation of TAGS and Terms and wondering why we mixed the two together, etc. We knew there would be some culture shock, but it didn’t take long to explain to him what was going on and he got it.

How to Edumikate Your Users

Educating users should not take too long. In fact, if you can’t do it in a short paragraph or two, you might be stretching things too much for them. We added a bit more explanatory text to help put user’s minds at ease. It was surprising to us that in two specific instances the extra words we used were confusing things rather than simplifying them. Our preview users said it made more sense to label the section where the tags were located “Tags” as opposed to “Tags used in these messages” or “Tags in this message” (depending on whether we were looking at a list or a single message). That’s a no-brainer.

We did find that the “rel-tag” microformat caused a little bit of a headache. We allow the users to narrow down the messages they are looking at by going to a certain geo-political slice, Department of State TAG, and/or a search term. When they clicked on the link to the tag (to go to the rel-tag space) they were expecting all those constraints to apply there as well. We chose not to do that, because we wanted to ensure that all people saw the same messages that are marked with the tag in question, regardless of where they came from. All that required was a little bit of explanation of what people were seeing on those pages, why we were doing it, and some reassurance that we didn’t forget about where they were.

We still know that we will have to help explain to our Department of State users why we made the changes like they are. The important thing is to be very up front about what is going on, what it means to them, and use plain language. You shouldn’t need a doctorate or background in cypher approaches to figure it out. Sometimes you can spread the user education throughout the application. That is one of the more subtle ways of making an application that doesn’t need a user manual. It at least tells the user how something is done. If it is short enough, experienced users will simply gloss over or ignore the instructions. Try not to make the user scroll past the instructions before they can do what they need to do—that will make them mad. If it takes a lot of instruction, you may have the wrong approach or you may need that help on a separate page. Usually you only need to look at it once or twice. I prefer to use the separate pages to educate on why we are doing things the way we are doing them, and what it helps the user do that they couldn’t do before.

To answer the question in the title, you will probably need to educate your users a little bit. Spreading the instruction out so that there is just enough so they know what to do is a good way to make the application self-documenting. They can throw the manual away without worries. When your screen starts looking like an instruction manual and you can’t find the controls, then you probably have the wrong design approach for your users. There is a threshold, but you’ll have to use your gut to find it for your application. Sometimes, it is worth a bit more user education to make a design choice that will help your users do more with what they have.

Technorati Tags: education user design validation