Improving User Adoption

Many organizations that deployed a content management system have gone through phases of deployment, development and upgrades without leveraging common practices around information architecture and usability. 

In some cases, a well-intentioned IT department holds user requirements sessions, only to implement the technical features without truly understanding core principles of usability. In other situations, a particular process will be enabled and user tested with good design principles but employing the “build it and they will come” deployment plan. 

In other words, let users just start using the system. In rare cases, organizations do get those elements right but then after the deployment is completed, there is no organizational design to maintain the system, continue to train users, and update design and functionality as user needs change.

The reasons for a lack of user acceptance break down into numerous categories ranging from lack of user involvement in the development process to inadequate content.

For these reasons, many users of content management systems are frustrated and long for a well-designed, maintained, highly functional system with well-organized information and search that gives them what they need when they need it. They blame the technology rather than the way that technology has been configured and managed.

The challenge is that everyone wants everything to be user friendly and intuitive. Users want tools that help them do their jobs without requiring that they jump through hoops to upload and access information. If the system is awkward and poorly designed, users do not want to spend the time to learn how to get the most from the system. However, even when the tools are sophisticated and well designed, fluency is still necessary to leverage them effectively.

When adoption is poor, it is difficult for an organization to get the majority of users needed to achieve the good collaboration, where the knowledge is producing real value and triggering successful cycles of participation and contribution. So moving to a new platform, rather than solving core issues, seems to be the preferred approach that many organizations take, though that will lead to a recurrence of the core challenges. It is best to get to the root of the problems and address them.

Even with a perfectly configured system and design that is user tested, validated, refined, tested some more and validated again, there is no guarantee that the system will be adopted and embraced. Taking an intentional approach to the system requirements and design will go a long way toward increasing the likelihood of user adoption. User adoption requires a thoughtful, intentional approach to a number of areas.

Here are some ways to maximize the chances for success of user adoption.

In many cases, users don’t have a voice in the design decisions and are not sufficiently kept in the loop through ongoing communications from leadership. Involve users in the development process. Socialization should be part of a project from the beginning and continue throughout the life of the project.

Perform user acceptance testing. It is very important to give users a chance to test the system before asking them to use it.

Create realistic expectations for how intuitive the system can be. No matter how user friendly the system is, it may never be completely intuitive to all. The nature of work processes and the information to support those processes can be complex. 

The nature of the task might require understanding terminology that is not part of everyone’s vocabulary. If the job itself requires training and skill development, the information may also require a degree of socialization. Some systems can be very complex.

Allow users time to develop a mental model. When learning to use an application of any sort, users need time to grasp the big picture and become fluent in the details. This means that it would be better to show users the details over time as opposed to in a one-shot training. Doing that at the scale of any enterprise requires planning and development of just-in-time learning that people can move through to get the big picture and can access in the context of their work processes. 

Provide users with the consistency they need. A consistent taxonomy and information architecture will help improve usability in the first place but also increase the learnability of the system. Once users learn about one part of an information structure, they can more quickly understand and internalize other areas if the same terminology is used.

Update functionality often enough to keep up with changes in user requirements. No information environment is static, so ongoing feedback that drives new functionality and capabilities is required. It is important to keep users updated on features in each new release. 

Without updates to functionality, continued testing and adjustments, the delta between what users need and what the application provides will get larger and lead to greater dissatisfaction.

Provide high-quality content. A system deployment should begin with value for the user. That means populating repositories with curated, tagged quality content that they will find valuable. Too often there is a “lift-and-load” migration in which poorly organized content filled with redundant, outdated and trivial content is presented to the user in a new environment. No matter how good the design is, the content will not be viable if it does not meet the users’ work requirements, and it will not be accessible if it is not tagged and organized.

User acceptance of a system will be improved when the right information is available for the tasks and the right processes are reflected in the application.

Offer users an easy way to contribute content. Another barrier to acceptance is a difficult process for uploading content. Too many metadata fields, long lists of choices or fields that don’t apply to the content will keep people from content uploading. The process for uploading content should be as painless as possible. Frequently the best answer is machine-assisted tagging where an auto-classifier tuned to the content and taxonomies appropriate for the process presents the user with suggested values, and the user either accepts them or selects a different value.

Establish a robust governance process. A content management system lives in an ecosystem that is continually changing. There are multiple upstream and downstream processes, and resources need to be allocated with a view to the larger picture of the information environment. 

The system owners and sponsors must make decisions in that context as well as within the context of the system environment. Therefore, they should have a seat at the table in the enterprise information governance decisions and the institution of controls, standards and compliance processes all the way down to the level of content repositories. If sites and content do not have ownership, they will quickly become outdated. If policy decisions are made without compliance mechanisms, they will not be implemented.

Users don’t hate content management systems. They hate poorly designed applications. In reality what they don’t like is the lack of functionality, the poorly constructed taxonomies, confusing navigation, endless fields to fill out and poor-quality content. With the correct approach to design and deployment and with adequate training and ongoing updates, people like and in many cases like a content management system. It helps them do their jobs, makes tasks easier to accomplish, improves efficiency and lets workers redirect their efforts to the more challenging and fulfilling parts of their jobs.

Successful Change Management in Content and Knowledge Management

It is getting more unlikely to find paper documents in filing cabinets or electronic documents in shared network drives. Filing cabinets and shared network drives have been replaced by content management systems, knowledge base application, and collaboration tools in majority of organizations.

At a certain point, it's inevitable that organizations have to make adjustments to keep up with the times. users must constantly adapt to the tools of an evolving world. After all, if customers are using advanced technology, it makes sense that companies should be interacting with them using tools that are up to date as well.

If technology adoption is to have an effect on an organization, users' commitment becomes a required element. But getting that kind of cooperation is not always a simple task. Users might not immediately take to the new processes without some resistance.

Though it's counter-intuitive that anyone would resist technology designed to make their job easier, the resistance is unavoidable element of content and knowledge management initiatives. Organizations should anticipate a number of challenges and do their best to ease their users's resistance through the transition and change management.

Drawing from our 16 years of experience successfully managing user adoption and change management in content and knowledge management initiatives, these are our guidelines for organizations to overcome challenges in these areas.

1. Communicate the Goals

There may be myriad practical reasons for why the change in how your organization manages its content needs to be put in place. Before proposing any major change, establish clear reasons for why the change is being proposed, and how it is going to enhance users' experience.

For users to understand how technology is going to help them, they need to understand what their future will look like with this technology in place. What it amounts to is if you can't articulate the benefits of making the change, you have no business of making this change.

It is very important to create a consistent narrative that instills confidence in users as well as the language you use to deliver this narrative to users. Avoid using the term "change management". The reason is that employees hear "change management" as "Whatever you have done until now is wrong, and now we are going to put you on the right track." That is not a good message.

You may want to use the term "cause management" which attributes any need for adjustment within a company to a cause. Under this approach, organizations would make an effort to craft a story that communicates the idea that this is the outcome that will best benefit the company.

Highlighting what is not going to be changing can be a source of encouragement for users. This way you are introducing a consistency while asking users to evolve.

2. Fear of Change is not Necessarily Fear of Technology

Technology itself is not usually the reason that employees are resistant to change. People are becoming less resistant to using technology. Problems begin to surface when employees are not given enough notice about what technology they are expected to use.

Even before it's been decided which technology organizations have settled on, organizations should give their employees an outline of the problems they are trying to fix. This would give them the opportunity to provide input and make suggestions about what types of processes they would like to see streamlined and how they envision their ideal work environment. Though organizations might not always have the budget for what the employees have in mind, they will at least be involving them and making them feel as though they are part of the equation from the outset.

Also important is that workers are given the time to develop the kinds of skills necessary to make full use of technology. It takes employees some conditioning to see how new technology and procedures can be of aid to them. If you can be proactive about teaching people these new skills and how to use the technology in small segments, this definitely can accelerate the change.

3. New Technology Can Bruise the Ego

All employees are proud of their work. They like to feel as though they possess an innate talent, and that there's a reason they're doing what they've chosen to dedicate so much of their time to. Regardless of age or experience level, there are certain natural emotions that might come into play when companies are proposing changes. If employees are led to believe that so much of what they spent a great deal of time mastering can be transferred to anyone with an ease, they might resent it on an emotional level that they might not even share.

Thus, it would be a good idea to communicate how the technology is going to help them work together and be more connected.

4. Technology is not Only for Managers

It goes without saying that technology should never force people to do more work than they are already doing. If you force people to use a system that is making their jobs worse, they' are going to do everything they can to avoid it.

Employees should never feel as though technology is being deployed solely for the benefit of the managers. Granted, content management system provides managers with more visibility into work processes, but the central message managers should be sending is that the technology is there to help employees do their jobs better.

It is helpful to illustrate that higher management is using the technology as well, for the sake of driving home the idea that the technology is being universally adopted by the organization.

5. Deploy Gradually

When it comes to deploying the systems that employees are going to be using regularly over an extended period of time, it is a good idea to steer clear of an abrupt implementation in favor of a more gradual one.

Use Pilot Periods. During these periods, a small subset of the company is selected to test the technology and share its experiences with the others. Keeping employees updated via email, meetings, or through other internal communication channels can be helpful, as it also lets people know what to expect. Likewise, getting user testimonials and videos in which those who have piloted the product attest to its benefits could prove useful.

However, it's important to be all-inclusive when deciding who is going to be participating in such trial periods. While it might be tempting to recruit the most enthusiastic and vocal representatives of a company to test the materials, it might be a better idea to go for a mix to act as testers. Use a subset of users that will represent those who are ultimately going to be expected to use the new technology. Of course, asking volunteers to step forward is advised, but testers should also be drawn from a segment of those who are not as keen on trying it.

Including people who are not technology experts is a good idea, because it helps drive home the point that anyone can use the solution effectively. It also reinforces the idea that there will be support and training opportunities available.

If the right group of people is selected for the pilot program, they can generate excitement about the system and show how the program has helped them do their jobs.

One small factor to keep in mind about the pilot period, however, is the capacity of the system. Since the entire program will eventually be inhabited by more users, the experience that the small subset reports might differ from the one that is waiting further down the line. For example, a system that works fine when you have ten users on it may not work as quickly when there are 200,000 users connected to it. You need to be able to account for things like that.

6. Maintain the Change

Change management is not as simple as preparing employees for the transition that is about to be introduced. It has just as much to do with ensuring that employees don't revert to outdated and inefficient methods as it does with ensuring that people begin to use it. Managing resistance is a process, not a series of events.

Because it's a process, managers should be very careful to communicate the fact that the improvements might not come all at once, but rather in small increments. Incentives can also act as fruitful aids in encouraging adoption. For this very reason, gamification applications have been gaining popularity because they allow employees to compete against one another and display to the rest of the company how well they have done by showing off their achievements.

It is important to build employees confidence and a positive environment. Set specific event days to encourage the use of the new technology. Typically held once a month, these are known as blitz days. The idea is to set aside a time period during which everybody is forced to use the technology in a fun environment. At the end of the day, the users share those results. The goal is to say that if this can be done on one particular day, why can't it be done every day? Over time, the benefits of these events could be substantial.

Change is ongoing. As time goes on, the window for change for technology is becoming much narrower than it used to be, with updates occurring far more frequently. For some people, it might seem that just as they are getting used to one change, another one is on the way. Organizations need to create an infrastructure that better supports that.

Characteristics for Driving Change

• Be outwardly focused - avoid being locked into one area of the company. Look for ways to make an impact across organizations.
• Be Persuasive - be clever and persuasive enough to gain the support of users.
• Be Persistent - do not give up. Constantly work through the channels of the organization to ensure that new systems and processes are factored into organizations' way of work.

What is Usability?

Usability is the ease of use of a system or a web site. It is a quality attribute that assesses how easy user interfaces are to use. If users either find a system difficult to use or find problems with it, then user adoption of this system is going to be extremely difficult.

Usability is a quality attribute that assesses how easy user interfaces are to use. The word "usability" also refers to methods for improving ease-of-use during the design process.

Usability is defined by 5 quality components:

• Learnability: how easy is it for users to accomplish basic tasks the first time they encounter the design?
• Efficiency: once users have learned the design, how quickly can they perform tasks?
• Memorability: when users return to the design after a period of not using it, how easily can they reestablish proficiency?
Errors: how many errors do users make, how severe are these errors, and how easily can they recover from the errors?
• Satisfaction: how pleasant is it to use the design?

There are many other important quality attributes. A key one is utility, which refers to the design's functionality: does it do what users need?

Usability and utility are equally important and together determine whether something is useful: It matters little that something is easy if it is not what you want. It is also no good if the system can hypothetically do what you want, but you can't make it happen because the user interface is too difficult. To study a design's utility, you can use the same user research methods that improve usability.

Definition: Utility = whether it provides the features you need.

Definition: Usability = how easy and pleasant these features are to use.

Definition: Useful = usability + utility.

Why Usability is Important?

On the web, usability is a necessary condition for survival. If a website is difficult to use, people leave. If the home page fails to clearly state what a company offers and what users can do on the site, people leave. If users get lost on a web site, they leave. If a web site's information is hard to read or doesn't answer users' key questions, they leave. Did you note a pattern here? There is no such thing as a user reading a web site manual or otherwise spending much time trying to figure out an interface. There are plenty of other web sites available, leaving is the first line of defense when users encounter a difficulty.

The first law of e-commerce is that if users cannot find the product, they cannot buy it either.

For intranets, content management systems, web portals usability is a matter of employee efficiency and productivity. Time users waste being lost on your intranet or pondering difficult instructions is money you waste by paying them to be at work without getting work done.

Current best practices call for spending about 10% of a design project's budget on usability. For internal design projects, think of doubling usability as cutting training budgets in half and doubling the number of transactions employees perform per hour. For external designs, think of doubling sales, doubling the number of registered users or customer leads, or doubling whatever other desired goal motivated your design project.

How to Improve Usability

There are many methods for studying usability, but the most basic and useful method is user testing, which has 3 components:

1. Get hold of some representative users, such as customers for a web site or employees for an intranet (in the latter case, they should work outside your department).

2. Ask the users to perform representative tasks with the design.

3. Observe what the users do, where they succeed, and where they have difficulties with the user interface. Do not talk and let the users do the talking.

It is important to test users individually and let them solve any problems on their own. If you help them or direct their attention to any particular part of the screen, you have contaminated the test results.

To identify a design's most important usability problems, testing 5 users is typically enough. Rather than run a big, expensive study, it is a better use of resources to run many small tests and revise the design between each one so you can fix the usability flaws as you identify them. Iterative design is the best way to increase the quality of user experience. The more versions and interface ideas you test with users, the better.

User testing is different from focus groups, which are a poor way of evaluating design usability. Focus groups have a place in market research, but to evaluate interaction designs you must closely observe individual users as they perform tasks with the user interface. Listening to what people say is misleading: you have to watch what they actually do.

When to Work on Usability

Usability plays a role in each stage of the design process. Therefore there is a need

for multiple studies.

Follow these steps:

Before starting the new design, test the old design to identify the good parts that you should keep or emphasize, and the bad parts that give users trouble. Unless you are working on an intranet, test your competitors' designs to get data on a range of alternative interfaces that have similar features to your own.

Conduct a field study to see how users behave in their natural environment. Make paper prototypes of one or more new design ideas and test them. The less time you invest in these design ideas the better, because you will need to change them all based on the test results.

Refine the design ideas that test best through multiple iterations, gradually moving from low-fidelity prototyping to high-fidelity representations that run on the computer. Test each iteration.

Inspect the design relative to established usability guidelines, whether from your own earlier studies or published research.

Once you decide on and implement the final design, test it again. Subtle usability problems always creep in during implementation.

Don't defer user testing until you have a fully implemented design. If you do, it will be impossible to fix the vast majority of the critical usability problems that the test uncovers. Many of these problems are likely to be structural, and fixing them would require major re-architecting.

The only way to a high-quality user experience is to start user testing early in the design process and to keep testing every step of the way.

Where to Test

It is best to test users in their own work environment, i.e. at their office. This will make them more comfortable. Also, users are used to their own computers. Be present with them while they use the design and just observe and make notes.

Misconceptions About Usability

Misconceptions about usability's expense, the time it involves, and its creative impact prevent companies from getting crucial user data, as does the erroneous belief that existing customer-feedback methods are a valid driver for interface design. Most companies still don't employ systematic usability methods to drive their design. The resulting widespread ignorance about usability has given rise to several misconceptions.

Misconception - Usability Is Expensive

Usual usability projects are not expensive. You can run user tests in a spare conference room or better yet in participants' offices. The methods are flexible and scale up or down according to circumstances. On average, best practices call for spending 10% of a design budget on usability. That is an inexpensive way to ensure that you spend the remaining 90% correctly, rather than blow your budget on an unworkable design.

Misconception - Usability Engineering Will Delay My Launch Date

Usability need not be on the grand scale. The simplest user testing method would take around 3 days but even faster tests are possible.

One of the main benefits of letting user research drive design is that you don't have to spend time on features that users don't need. Early studies will show you where to focus your resources so that you can launch on time.

Finally, usability can save time by helping you quickly settle arguments in the development team. Most projects waste countless staff hours as highly paid people sit in meetings and argue over what users might want or what they might do under various circumstances. Instead of debating, find out. It is faster, particularly because running a study requires only one team member's time.

Misconception - Usability Kills Creativity

Design is problem solving under constraints: you must design a system that can actually be built within budget and that works in the real world. Usability adds one more constraint: the system must be relatively easy for people to use. This constraint exists whether or not you include formal usability methods in your design process.

Human short-term memory holds only so many chunks of information. If you require users to remember too much, the design will be error-prone and hard to use because people will forget things when you overload their memory.

Also, if you are designing a web site, it will be one of millions available to users and they'll grant you only so much of their attention before they move on.

These are facts of life. All usability does is to make them explicit so that you can account for them in your design. Usability guidelines tell you how people typically behave with similar designs. User testing tells you how people behave with your proposed design. You can pay attention to this data or ignore it; the real world remains the same regardless.

Knowing real-world facts increases creativity because it offers designers ideas about design improvement and inspires them to focus their energy on real problems.

Misconception - We Don't Need Usability, We Already Listened to Customer Feedback

Market research methods such as focus groups and customer satisfaction surveys are great at researching your positioning or which messages to choose for an advertising campaign. They are not good at deciding user interface questions, in fact, they are often misleading.

When a group of people is sitting around a comfortable table having snacks, they are easily wowed by demos of a web site's fancy features and multimedia design elements. Get those people to sit alone at a computer, and they are likely to leave the same web site in a short time.

Seeing something demo'd and actually having to use it are two very different things.Likewise, what customers say and what customers do rarely line up; listening to customers uses the wrong method to collect the wrong data.

Luckily, the correct usability methods are inexpensive, easy to implement, and will not delay your project. Instead, relying on wrong methods or not doing usability work is much more expensive.

User Acceptance Testing

I have mentioned in my posts that if users either find a system difficult to use or find problems with it, then user adoption of this system is going to be extremely difficult. One of the ways to eliminate potential problems and provide user adoption is user acceptance testing.

User Acceptance Testing (UAT) is a process to obtain confirmation that a system meets mutually agreed upon requirements for the system. Major stakeholders, the project sponsor, and users across an organization provide such confirmation after testing the system. UAT is done using real world scenarios relevant to the users' tasks in the system.

Users of the system perform these tests, which you would derive from the user requirements documents. The UAT acts as a final verification of the required business functions and proper functioning of the system, emulating real-world usage conditions. UAT is one of the final stages of a content management project and often occurs before users accept the system. This type of testing gives users the confidence that the system being deployed for them meets their requirements. This testing also helps to find bugs related to usability of the system.

Prerequisites

Before UAT is conducted the system needs to be fully developed. Various levels of QA testing should already be completed before UAT. Most of the technical bugs should have already been fixed before UAT.

What to Test?

To ensure an effective UAT test cases are created. These Test cases can be created using various use cases identified during the requirements definition stage. The Test cases ensure proper coverage of all the scenarios during testing.

During this type of testing the specific focus is the exact real world usage of the system. The testing is done in an environment that simulates the production environment. The test cases are written using real world scenarios for the system.

How to Test?

Focus is on the functionality and the usability of the system rather than the technical aspects. It is assumed that the system already has undergone QA testing.

UAT typically involves the following:

• UAT planning;
• designing UA test cases;
• selecting a team that would execute the UAT test cases;
• executing test cases;
• documenting the defects found during UAT;
• resolving the issues/bug fixing
• sign Off.

UAT Planning

As always the planning process is the most important of all the steps. This affects the effectiveness of the testing Process. The planning process outlines the UAT Strategy. It also describes the key focus areas, entry and exit criteria.

Designing UAT Test Cases

UAT test cases help the test execution team to test the system. This also helps to ensure that the UAT provides sufficient coverage of all the scenarios. The Use Cases created during the requirements definition stage may be used as input for creating test cases. The input from users can also be used for creating test cases.

Each UAT test case describes in a simple language the precise steps to be taken to test something.

Selecting a Team That Would Execute the UAT Test Cases

The UAT Team is generally a good representation of users across the organization. Be sure to involve major stakeholders and sponsors.

Executing Test Cases

The testing team executes the test cases and may additionally perform random tests relevant to their tasks in the system. Lead the team by executing the test cases with them and guide users as necessary.

Documenting the Defects found During UAT

The team logs their comments and any defects or issues found during testing.

Resolving the Issues/Bug Fixing

Discuss the issues/defects found during testing with your project team and sponsors. The issues are resolved as per the mutual consensus and to the satisfaction of the users. Sometimes you may have to prioritize these issues/bugs. After these issues/bugs were either fixed, allow users to re-test the system. If you decided to prioritize and fix them later, inform your users about it with the estimated date of the fix.

Sign Off

Upon successful completion of the UAT and resolution of the issues the team generally indicates the acceptance of the system. Once users "Accept" the system, they indicate that the system meets their requirements.

Users now would feel confident that the system meets their needs and they feel "invested" in the system. There may also be legal or contractual requirements for acceptance of the system.

UAT Key Deliverables

• the test plan - outlines the testing strategy;
• test cases – help the team to effectively test the system;
• the test log – a log of all the test cases executed and the actual results;
• user sign off – this indicates that the users find the system is delivered to their satisfaction.

User Study

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.

Surveys

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.

Focus Groups

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.

Interviews

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.

User Testing

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.

User Adoption Strategies

Here is the situation. Your documents are stored on your network drives and you are contemplating to implement a content management initiative. At the same time you have an apprehension about how your users will adopt to your content management system (CMS).

Well, your apprehension is very much valid. User adoption task is not to be taken lightly. So, what do you do?

Good news is that it is possible to have your users to adopt to your content management systems. What are the strategies do accomplish user adoption? Let's look at them.

1. Point out benefits and usefulness – how it is better than what a user is doing now before you even started working on your deployment. This would create a good start to your project. It would prepare your users that the change is coming. The change is difficult to accept and so the earlier you start preparing for it, the easier it will be for you to implement it.

2. Collect user requirements and create use cases. Select your system and deploy it based on these requirements and use cases. I preach user-centered design. User-centered design is a cornerstone of user adoption. Never underestimate user-centered design. You deploy the system for users, make it they way they need it as much as possible.

3. Provide assurance of training and assistance from the beginning of your project. Let your users have confidence in you from the very beginning that they are not going to be left alone when the system is in place.

4. Make everything very easy and very intuitive.

5. User acceptance testing is paramount to user adoption.

6. Provide training early on.

7. Provide documentation describing in detail how the system works, what are the new procedures, etc.

8. Demonstrate that it is easy and consistent with what the user already knows or already does.

9. Let the user try it in safe, verifiable increments. Do not ask the user to make immediate switch from his accustomed way of work to your new system. Do it gradually.

10. Accept that user adoption is not a single event or decision on the part of a user. It happens in phases, which are affected by the frequency of product use. Use progressive user adoption strategy.

11. A progressive user adoption strategy consciously moves a user to new levels of product acceptance over time, through an orchestrated sequence of exposures to the product’s functionality.

The overall strategy for progressive user adoption starts with the solid foundation of a satisfying user experience of a product’s core functionality, then builds a logical progression from that base by identifying moments of opportunity and appropriate interventions.

12. Consider the following steps.

Identify core functionality. Core functionality is the basic functionality that, if not achieved, will guarantee the user will reject the product.

Make the core functionality bulletproof from a usability perspective. From a product design perspective, initially, the main goal should be to optimize the user experience that touches the core functionality.

The unspoken rule here is this: "Don’t break the core functionality as you add features". Promoting or adding advanced features can also add real or perceived complexity, disrupt compatibility with users’ established routines, and increase a sense of risk. All three of these consequences can stop adoption.

Identify sequences that go from core functions to advanced functions. Identify the next layers of features and functionality that could represent logical steps for users to take over time, once they have increased familiarity with the product.

Construct product interventions to move users to advanced functionality. An important goal of this step is to identify moments of opportunity that indicate readiness on a user’s part to advance to a new level of functionality. You must make it easy for a user to ignore the intervention.

What is of tantamount importance is that the intervention not be overly intrusive, impacting the core functionality. By all means, make it noticeable but don’t force users to change their habitual task flows in order to reject the option or suggestion. Not disrupting the core user experience is a key requirement for those interventions.

I will give you two examples of a progressive adoption strategy.

Banking industry has created online banking and invited us to use it. It was very much optional. Then they said that we can choose between paper statements and electronic statements. And then they said that there will be no more paper statements any longer and that we must go online to see our statements. So, the online banking has now become mandatory.

Similar example can be used in content management. When you have a CMS in place, announce to your users that they can choose where they can store their documents - either on network drives or in your CMS. But point out benefits of your CMS as compared to network drives. In your next step, announce to your users that certain types of documents must now be stored in your CMS. Provide continuous training and one-to-one assistance if necessary.

In the following step, announce to them that you are closing network drives and that all documents must now be stored in your CMS. After they got used to basic documents uploading into your CMS, you can introduce other features of your CMS, like Wikis, blogs, personalized sites, etc.