You have decided to implement a content management or a document control system. This system that you are planning to deploy is for users. Everything you create is for users. If your system meets your users' requirements, they will use it. If your system does not meet your users' requirements, they are not going to use it.
They are the ultimate designers. Design a system that confuses users and they will go somewhere else. Build the system that frustrates users and they will not use it. No matter what you do, they will find all possible excuses of why they cannot and should not use your system. Users adoption is going to be very difficult, almost impossible if you deploy a system which is not based on your users' requirements.
But who are your users? Why are they looking for information? What information are they looking for? How are they looking for information? How would they like to search for information? How would like to author this information? How would they like to use your system? and similar questions - these questions you should ask your users before you deploy any system. You ask these and similar questions during user study which should be done at the beginning of your project. This is the subject of my today's post.
How do you study users and their requirements? There are few methods: surveys, focus groups, interviews, user testing. Select broad spectrum of users across the entire organization. Include major stakeholders, department or unit managers, major authors and consumers of information.
This research tool provides an opportunity to gather input from a large number of people. They can be used to gather qualitative or quantitative data. You can send them by email or you can use free survey tools like Survey Monkey. When creating a survey, you will need to limit the number of questions if you want a reasonable response rate. If you have too many questions in your survey, users may not return the survey to you. You may also have to guarantee anonymity and offer an incentive.
Since there is little opportunity for the follow-up questions or dialogue, surveys do not allow you to gather rich data about users' information seeking behavior. The survey results can provide you with a powerful political tool. For example, if 90% of users say that they have a problem searching for documents and are frustrated, than this could be used as a compelling reason to improve the search by having a better system or improving existing system.
When conducting focus groups, you gather groups of people who would be users of your system. You might ask them questions about what features they would like to see in your system, demonstrate a prototype of a system, and then ask users' perception of the system and their recommendations for improvement.
Focus groups are great for generating ideas about possible content and functions for the system. By getting several people from your target audience together and facilitating a brainstorming session, you can quickly find yourself with list of suggestions.
They could be used to prove that a particular approach does or does not work.
Face-to-face sessions involving one user at a time are a central part of users' study. You typically would begin with questions. Some of the questions you might ask are:
- What do you do in your current role?
- What information do you need to do your job?
- How do you search for this information?
- What information is most difficult to find?
- What do you do when you cannot find something?
- Do you create documents that are used by other people or departments?
- What do you know about life-cycle of your documents?
- What happens after you create them?
- If you could select few features in the upcoming content management system, what would they be?
In determining what questions to ask and especially how to determine what features users would like in the system, it is important to remember that users are not content managers or information architects. They do not have the understanding or vocabulary to have a technical dialog about the system or its architecture. So, you need to be prepared to interpret what they might tell in general to specific system features that you already know about and then provide this information to them in your response.
In basic user testing, you ask a user to do a task, for example to find information in the current situation. You can ask the user to browse or to search. Allowing about three minutes per task, ask the user to talk out loud while he is navigating. Take good notes and make sure you capture what he said and where he goes. You may want to count clicks and time each session. Include a range of audience types. It is particularly important to include people who are technically minded (for example engineers) and who are not (for example marketing) as they will demonstrate different behavior.
User study is iterative process, so you may have to repeat the same method few times. But whatever you do, do not underestimate the value of user study. If you would like to have the user adoption in the end, conduct the user study in the beginning.