Galaxy Consulting
  • Home
  • About Us
    • Our Process
    • Meet Us at Industry Events
  • Services
    • Business Analysis and Usability
    • Content and Knowledge Management
    • Records Management
    • Information Architecture
    • Enterprise Search
    • Taxonomy and Metadata Development and Management
    • Document Control
    • Information Governance
  • Solutions
    • Information Overload
    • Compliance
    • E-Discovery
    • Internal and External Websites
    • Enterprise Search
    • Collaboration and New Employees’ Onboarding
    • Customer Service
    • Manual Processes
    • Vulnerability of Sensitive Information
  • Portfolio
    • Our Brochure
    • Our Clients
    • Case Studies
    • Presentations
    • Press Releases >
      • Galaxy Consulting Receives 2016 Best of Redwood City Award
      • Galaxy Consulting Receives 2015 Best of Redwood City Award
    • Videos
  • Testimonials
  • Blog
  • Free Consultation
  • Contact Us
  • Terms of Use/Privacy Policy

Successful Change Management in Content and Knowledge Management

7/23/2016

0 Comments

 
Picture
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.

0 Comments

What is Usability?

6/26/2012

0 Comments

 
Picture
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. 

0 Comments

User Acceptance Testing

6/21/2012

0 Comments

 
Picture
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.

0 Comments

User Study

5/31/2012

0 Comments

 
Picture
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. 

0 Comments

User Adoption Strategies

1/23/2012

0 Comments

 
Picture
Here is the situation. Your documents are stored on your network drive 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. 

0 Comments

Analysis Tools Used in User-Centered Design

12/14/2011

0 Comments

 
Picture
There are few tools that are used in user centered design. They are persona, scenarios, and essential use cases.

Persona

During the UCD process, a persona of the user's need may be created. It is a fictional character with all the characteristics of the user. Personas are created after the field research process, which typically consists of members of the primary stakeholder (user) group being observed on their behaviour, and additionaly answering questionnaires or participating in interviews, or a mixture of both.

After results are gathered from the field research, they are used to create personas of the primary stakeholder group. Often, there may be several personas concerning the same group of individuals, since it is almost impossible to apply all the characteristics of the stakeholder group onto one character. The character depicts the a "typical" stakeholder, not an "average" individual in the primary stakeholder group, and is referred to throughout the entire design process.

There are also what's called a secondary persona, where the character is not a member of the primary stakeholder group and is not the main target of the design, but their needs should be met and problems solved if possible. They exist to help account for further possible problems and difficulties that may occur even though the primary stakeholder group is satisfied with their solution.

There is also an anti-persona, which is the character which the design process is not made for. Personas usually include a name and picture, demographics, roles and responsibilities, goals and tasks, motivations and needs, environment and context, and a quote that can represent the character's personality.

Personas are useful in the sense that they create a common shared understanding of the user group for which the design process is built around. Also, they help to prioritize the design considerations by providing a context of what the user needs and what functions are simply nice to add and have. They can also provide a human face and existence to a diversified and scattered user group, and can also create some empathy and add emotions when referring to the users.

However, since personas are a generalized perception of the primary stakeholder group from collected data, the characteristics may be too broad and typical, or too much of an "average joe". Sometimes, personas can have stereotypical properties also. Overall, personas are a useful tool that can be used since designers in the design process can have an actual person to make design measure around other than referring to a set of data or a wide range of individuals.

Scenario

A scenario created in the UCD process is a fictional story about the "daily life of" or a sequence of events with the primary stakeholder group as the main character. Typically, a persona that was created earlier is used as the main character of this story. The story should be specific of the events happening that relate to the problems of the primary stakeholder group, and normally the main research questions the design process is built upon.

These may turn out to be a simple story about the daily life of an individual, but small details from the events should imply details about the users, and may include emotional or physical characteristics. There can be the "best case scenario", where everything works out best for the main character, the "worst case scenario", where the main character experiences everything going wrong around him or her, and an "average case scenario", which is the typical life of the individual, where nothing really special or really depressing occurs, and the day just moves on.

Scenarios create a social context to which the personas exist in, and also create an actual physical world, instead of imagining a character with internal characteristics from gathered data an nothing else; there is more action involved in the persona's existence. A scenario is also more easily understood by people, since it is in the form of a story, and is easier to follow.

Picture
Use case

In short, a use case describes the interaction between an individual and the rest of the world. Each use case describes an event that may occur for a short period of time in real life, but may consist of intricate details and interactions between the actor and the world.

It is represented as a series of simple steps for the character to achieve his or her goal, in the form of a cause-and effect scheme. A use case should:
  • Describe what the system shall do for the actor to achieve a particular goal. 
  • Include no implementation-specific language. 
  • Be at the appropriate level of detail. 
  • Not include detail regarding user interfaces and screens. This is done in user-interface design, which references the use case and its business rules.
Use cases are useful because they help identify useful levels of design work. They allow the designers to see the actual low level processes that are involved for a certain problem, which makes the problem easier to handle, since certain minor steps and details the user makes are exposed. They also convey useful and important tasks where the designer can see which one are of higher importance than others.

Tomorrow: tools of information architecture.

0 Comments

User-Centered Design

12/13/2011

0 Comments

 
Picture
User-centered design (UCD) is a design philosophy and a process in which the needs, wants, and limitations of end users of a product are given attention at each stage of the design process. 

User-centered design can be characterized as a multi-stage problem solving process that not only requires designers to analyze and foresee how users are likely to use a product, but also to test the validity of their assumptions with regards to user behaviour in real world tests with actual users. 

Such testing is necessary as it is often very difficult for the designers of a product to understand intuitively what a user of their design experiences, and what each user's learning curve may look like. The main difference from other product design philosophies is that user-centered design tries to optimize the product around how users can, want, or need to use the product, rather than forcing the users to change their behavior to accommodate the product. 

For example, the user-centered design process can help software designers to fulfill the goal of a product engineered for their users. User requirements are considered right from the beginning and included into the whole product cycle. These requirements are noted and refined through investigative methods including: ethnographic study, contextual inquiry, prototype testing, usability testing and other methods. 

Generative methods may also be used including: card sorting, affinity diagraming and participatory design sessions. In addition, user requirements can be understood by careful analysis of usable products similar to the product being designed. 

UCD answers questions about users and their tasks and goals, then uses the findings to make decisions about development and design. UCD of a web site, for instance, seeks to answer the following questions:
  • Who are the users of the document? 
  • What are the users’ tasks and goals? 
  • What are the users’ experience levels with the document, and documents like it? 
  • What functions do the users need from the document? 
  • What information might the users need, and in what form do they need it? 
  • How do users think the document should work? 

Picture
As examples of UCD viewpoints, the essential elements of UCD of a web site are considerations of visibility, accessibility, legibility and language. 

Visibility 

Visibility helps the user construct a mental model of the document. Models help the user predict the effect(s) of their actions while using the document. Important elements (such as those that aid navigation) should be emphatic. Users should be able to tell from a glance what they can and cannot do with the document. 

Accessibility 

Users should be able to find information quickly and easily throughout the document, regardless of its length. Users should be offered various ways to find information (such as navigational elements, search functions, table of contents, clearly labeled sections, page numbers, color coding, etc). Navigational elements should be consistent with the genre of the document. 

"Chunking" is a useful strategy that involves breaking information into small pieces that can be organized into some type meaningful order or hierarchy. The ability to skim the document allows users to find their piece of information by scanning rather than reading. Bold and italic words are often used. 

Legibility Text should be easy to read: Through analysis of the rhetorical situation, the designer should be able to determine a useful font style. Ornamental fonts and text in all capital letters are hard to read, but italics and bolding can be helpful when used correctly. Large or small body text is also hard to read. (Screen size of 10-12 pixel sans serif and 12-16 pixel serif is recommended.) High figure-ground contrast between text and background increases legibility. Dark text against a light background is most legible. 

Language Depending on the rhetorical situation, certain types of language are needed. Short sentences are helpful, as well as short, well-written texts used in explanations and similar bulk-text situations. Unless the situation calls for it, do not use jargon or technical terms. Many writers will choose to use active voice, verbs (instead of noun strings or nominals), and simple sentence structure. A user-centered design is focused around the rhetorical situation. 

The rhetorical situation shapes the design of an information medium. There are three elements to consider in a rhetorical situation: audience, purpose, and context. 

Audience 

The audience is the people who will be using the document. The designer must consider their age, geographical location, ethnicity, gender, education, etc. 

Purpose The purpose is what the document is targeting to or what problem is the document trying to address. 

Context The context is the circumstances surrounding the situation. The context often answers the question: What situation has prompted the need for this document? Context also includes any social or cultural issues that may surround the situation. 

User-centered design involves simplifying the structure of tasks, making things visible, getting the mapping right, exploiting the powers of constraint, and designing for error. 

Tomorrow, I will talk about analysis tools used in user-centered design.

0 Comments

    Archives

    April 2022
    March 2022
    January 2022
    July 2021
    May 2021
    April 2021
    March 2021
    February 2021
    January 2021
    December 2020
    July 2020
    April 2020
    March 2020
    December 2019
    November 2019
    September 2019
    August 2019
    July 2019
    May 2019
    March 2019
    February 2019
    January 2019
    December 2018
    October 2018
    July 2018
    June 2018
    May 2018
    March 2018
    February 2018
    January 2018
    December 2017
    September 2017
    July 2017
    June 2017
    May 2017
    April 2017
    January 2017
    December 2016
    November 2016
    September 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    September 2015
    July 2015
    June 2015
    May 2015
    April 2015
    March 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    September 2012
    August 2012
    July 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011

    Categories

    All
    Alfresco
    Arena
    Automatic Classification
    Autonomy
    Big Data
    Business Analysis
    Case Studies
    Change Control
    Change Management
    Cloud Content Management
    Cloud Ecm
    Cloud Enterprise Content Management
    Cms
    Collaboration
    Compliance
    Concept Searching
    Confluence
    Content Analysis
    Content Localization
    Content Management
    Content Management Systems
    Content Strategy
    Controlled Vocabulary
    Coveo
    Crisis Management
    Dams
    Data Integrity
    Data Security
    Digital Asset Management
    Digital Asset Management System
    Digital Transformation
    Dita
    Document Control
    Document Control Systems
    Documents Management
    Documentum
    Drupal
    Dublin Core Metadata
    Ecm
    E Discovery
    Engineering Change Process
    Enterprise Content Management
    Enterprise Search
    ERoom
    E-Signature
    Exalead
    Fatwire
    Gamification
    Gmp
    Gxp
    Hadoop
    Information Architecture
    Information Governance
    Information Overload
    Information Technology
    Iso 9001
    IT Systems Validation
    Joomla
    Knowledge Management
    Knowledge Management Applications
    Metadata
    Mobile Devices
    Naming Conventions
    Ontology
    Open Source Cms
    Open Text
    Oracle
    OWL
    Personalization
    RDF
    Records Management
    Risk
    Search Applications
    Self Service
    SEO
    Sharepoint
    Social Media
    Structured Content
    Taxonomy
    Teamsite
    Thesaurus
    Tridion
    Twiki
    Unified Data
    Usability
    User Adoption
    User Centered Design
    Vasont
    Vivisimo
    Web Site Content
    Web Site Design
    Wiki

    RSS Feed

Powered by Create your own unique website with customizable templates.