The previous example of a skills database brings up another principle of sustainable KM: design for the people, not for the data. We often get so caught up in what we are trying to capture, that we forget who we are capturing it from and who will use it.
I was recently filling out a form online that asked where I got my college education. What's more, it insisted on trying to guess my answer. I couldn't simply enter the name of the university; it insisted it had a complete list of all possible answers. As you might suspect, it was neither complete nor easy.
Why did it do this? Because whoever wrote the program wanted to make sure the data was valid -- that there was no ambiguity between University of New Hampshire and University of NH, for example. People have no problem understanding this sort of variation. Unfortunately, computers do.
As a result, the designer decided I, the user, was the one who would have to solve the problem. I was forced to scroll half way through an extraordinarily long list of names to discover that -- for the sake of the computer -- my alma mater was classified as NH - University of, Durham.
This is a case of simple annoyance. But this type of thinking, when dealing with large volumes of data and more complicated concepts, becomes debilitating.
Going back to our example of a skills database, these applications often assume a preset list of skills, organized hierarchically into job categories (such as administration, information technology, management, marketing, communications, etc.) More often than not, the UI reproduces the computer's way of seeing the information, forcing the user (the person whose information it seeks to elicit) to click blindly through hierarchies looking for something that resembles their skills. What's worse, the preset list is often defined by management, so it not only is incomplete, it lists only what management wants to see, rather than skills the person entering might choose to identify.
The results are predictable. Entering information in such a system is frustrating and annoying. People will avoid it or enter as little as possible to get done quickly. Where presets do not match actual skills (or can't be found easily within the hierarchies), people will deliberately choose incorrect or approximate answers.
This is before we get to any of the psychological issues of what information (true or false) people will enter based on the implicit messages the preset items and hierarchies are telling them about the importance of specific skills.
The consequence is that those responsible now have to budget time and money for training on how to fill out the form as well as prompting people to maintain their data!
A disconnect between the interface and the users' perspective results in frustration, misuse, mistakes, invalid entries, and avoidance. This concept is well understood in the field of usability and UI design. Unfortunately, it is not applied frequently enough to internal systems design and KM. The result is (unsustainable) systems that often cost more to maintain than to create.
[Continued in Part 3]
2 comments:
the 'preset list of skills' problem is something I'm struggling with at the moment. Staff have said that knowing about their colleagues skills and experience is one of the biggest barriers to knowledge sharing. Adding this information to the intranet people directory has been proposed but we've put this off because we don't think a pre-set list will work for inputers. The alternatives of free-text doesn't seem to solve the problems for people searching for other people. We need a more sophisticated middle ground.
Avoid free text. I strongly recommend using a folksonomy (i.e. freely defined tags ala del.icio.us or Flickr). It has the benefits of free text for the person entering, but with meaning and browsability. for reuse/search/filtering/etc. We had very good success with it at HP.
Post a Comment