Your business is relying more heavily on technology than it ever has, and it is likely to continue in that direction. But in order for your technology to work for your business and make it successful, there must be at least some degree of usefulness to your technology. That may sound like a no-brainer at first, considering that it is the entire reason your business has adopted technology. However, a surprising number of enterprises fail to adhere to usability and user design principles. Usability, as it suggests, is the field of studying a document’s usefulness to the user. How easy is the website to navigate? Is there enough white space? Is information structured logically? Are elements easy to find? These are just some of the questions a usability test might attempt to answer.

Schedule a Usability Test

If you want your organization to succeed, and you want to improve the quality of your information, consider scheduling a usability test with participants that will offer insight into your publications or information systems. The results of the test should help you determine the areas of your information and design that need to be improved. It can help establish what works and what doesn’t work. Web usability testing is the most common type of usability test, that is usability testing of a website. Any type of document or information system can be put to the test, however, internal or external. A consultant that is familiar with usability testing can test for these issues.

The Era of Responsive Design

User design has become a major development over the years in websites, applications and other information systems. The idea is to make information as easy and intuitive to understand and access as possible. Two terms have developed in this field: User interaction (UI) and User Experience (UX). UI refers to the usefulness of an application or site’s functionality as it relates to the user, and user experience refers to the form or design aspects that help the user locate information or appreciate the visual quality of the content. Usability testing can help determine if your UI/UX should be improved and how.

Eye Tracking

Eye tracking, believe it or not, has been employed as a way of studying usability for decades. Google uses eye tracking to study the interaction between a user and their behavior on a webpage to determine the best way to serve ads to users online. Eye tracking works by providing a heatmap that can visually display user behavior, such as where their eyes spent the most time observing elements on a page. This data is important for organizations to understand where their users are going on their websites or other documents and how they are interacting with them. Most of the content in the right-hand column of many pages, for example, is often unnoticed or less noticed than content on the left, or at the very top of the page. Users spend very little time attempting to locate data online. On mobile devices, the time frame is even shorter. You must catch the user’s attention immediately, literally. 

Information Context and Logic

Information should have context and proper logic if anyone is ever expected to try to understand it. Usability testing can help make sure that information is not only relevant and useful, but that its context and logic follow guidelines on how content should be created and implemented.

The information itself has to be of good quality to start with. Bad information tends to be ignored, especially in today’s culture of fast-paced computer-based interactions. The metrics for usability should not stop at the screen. In other words, it’s not all just about design. Design must be handled appropriately, but information quality, context and logic are just as important because that is the treasure inside the packaging that the user expects to acquire.

Information must follow logical order in terms of navigation, themes, key ideas, narration, order of operations, etc. These elements are extremely important to users who have expectations of how information should be presented to them. Their assumptions should guide your inspiration for method and mode of delivery.

Maintain Reputation and Trust

A part of usability that is rarely discussed is trust and reputation. These are important factors as digital technology becomes involved in nearly all facets of life today. Now, Google, the largest search engine and search enterprise, rewards websites with better search rank if they have a Secure Sockets Layer (SSL) certification. That shows you how important this has become. The Internet is threatened by criminals and others who are making legitimate business difficult with their scams.

Getting a SSL certificate is one way to maintain your security, reliability and reputation. It also will build some trust. Using sub-domains rather than an actual primary domain for your company is another reason users will not trust your business. Your business should have its own domain. Company information like addresses, phone numbers, staff names, company biographies and author biographies also help reinforce trust.

Other Elements for Usability

Information architecture is important for usability. One important element is page outline and mechanics. Users like to see information laid out on the page very organized and clear, so they can index the information for what they need and ignore what they don’t (immediately) need. Breaking content up into clear titles/subtitles, callout boxes, bulleted or numbered lists and other page design elements will improve the quality of your information and if it is hosted on a public website, it will even rank higher in Google and other search services.

Social media is also become part of the usability process. Is content easy to share online?

Also, examine the content’s links and other elements for consistency and clarity. Approach each element with a cautious editor’s eye to make sure that the elements are working as much to the user’s advantage as possible.

Leading enterprises strive to acheeve higher levels of customer engagement through online channels, and this means they must easily, quickly and cost effectively provide fresh, personal, relevant content anytime, anywhere, on any device, through a consistent and dynamic user experience. 

Traditional web content management system (CMS) solutions are no longer sufficient, and a richer and broader range of capabilities that enable web experience management - managing and optimizing the site visitor experience across the web, mobile apps, social networks and more - must now be leveraged in this new era of engagement.

The Need for Web Experience Management

Over the last few years, the Internet has undergone a tremendous amount of fundamental change in its landscape - socia1, personal and mobile.

1. Social - The Web is becoming increasingly more social and much less anonymous. The power of sharing can enhance or destroy brands in seconds.

2. Personal - While the Internet is continuously expanding in terms of ubiquity, at the same time it's becoming much more local and much more personal in terms of user experience.

3. Mobile The growth of mobile access to the Internet is rapidly expanding to the point where access from tablets and phones will soon exceed that from desktops and laptops.

The very way we communicate with customers is changing, and when fundamental change like this occurs, those who recognize the change and move quickly to adapt will benefit the most.

A New Era of Engagement

Each of these trends reinforces the others and fuels further adoption and innovation. It is these technologies, the behaviors and capabilities they foster that have brought us to a new era which Forrester calls the "era of engagement."

Driving these trends are people - our friends, leads, customers, critics, and fans. This is our audience and the other half of the conversation, and in today's age of engagement, they want to participate and expect us to engage them on their terms, on their schedule, in the context of their location, in their language and optimized for their device. To effectively tackle this challenge of serving a mass audience with limited resources, enterprises require strategy and effective tools to help get the job done.

Web experience management (WEM) provides us with the tools to take on this otherwise daunting task. The capabilities of WEM allow you to create, manage and deliver dynamic targeted and consistent content across various online channels including your website, social media, marketing campaign sites, mobile applications, etc. It takes a lot more than a traditional Web CMS to meet these new demands.

Key Principles of Web Experience Management

To effectively implement WEM, enterprises must start with their business strategy and goals which should drive their messaging and engagement strategy and which in turn should drive their content strategy. In other words, the strengths, weaknesses, threats and opportunities that businesses face should be considered first and foremost. 

Too often organizations fail to do this by jumping straight into a technology selection without due consideration of the business drivers. Around this foundation, we wrap the fundamentals of basic Web content management. It is important to remember that content is still king. Business users and marketers need easy to use, yet powerful, content authoring and publishing capabilities.

They need rich content models that allow them to create engaging visitor experiences, to easily create new content assets, to quickly find and re-purpose existing content, and to preview content and the site visitor experience for all online channels.

Upon this foundation, an effective WEM solution provides a comprehensive collection of capabilities that allow organizations to create, manage and deliver dynamic, targeted and consistent content and visitor experiences across multiple touch points -corporate website, dedicated marketing campaign sites, mobile applications, social media sites, etc.

While WEM requirements are going to vary from organization to organization, some of the most critical features needed by essentially all enterprises include content targeting and personalization, mobile device support, faceted search and navigation, multi-channel publishing, integrated Web analytics, and campaign management.

Web usability is an approach to make a web site easy to use for a user, without the requirement that any specialized training is undertaken or any special manual is read. Users should be able to intuitively determine the actions they need or can perform on the web page s, e.g., press a button to perform some action.

Some broad goals of usability could be: present the information to the user in a clear and concise way, give the correct choices to the users in an obvious way, remove any ambiguity regarding the consequences of an action (e.g. clicking on delete/remove/purchase), place important items in an appropriate area on a web page or a web application.

When you designed your web site, you want to promote it everywhere with big bold letters saying, "Hello everybody! Come and look at my web site! It is just great!" When you submit your web site to forums for web site reviews, you may write, "What do you think of my web site?"

This is the big mistake to ask someone to look at your web site. There is never a single answer. To understand if your web site meets its usability requirements, ask people to try it out. They should be able to answer the following questions: what is the purpose of this web site? what can I do here? what needs does it fulfill?

The 5 seconds test tool is one way to explore immediate impressions of the web site users. You can experiment by asking them what the site is about, to see if the site’s purpose is communicated clearly.

The biggest mistake is to believe that web site appearance matters the most. How it looks is only one part of the process. How it performs is another. What it can give back to site visitors and how effectively it conveys that information will matter even more.

Writing content for web users is an important task. The main goal of this task is the ease with which the web site content is read and understood by your users. When your content is highly readable, your audience is able to quickly digest the information you share with them.

Keep the web site content as concise as possible. Users have very short attention spans and they are not going to read articles thoroughly and in their entirety. So, get to the point as quickly as possible. Place your most important content high on the page. Think of a newspaper: the top story is always prominently displayed above the fold. Use headings to break up long text. Use bulleted lists where possible. 

Format the text in such a way that it is easy to read it and just to scan a web page.Keep colors and typefaces consistent. Visitors should never click on an internal link in your site and wonder if they've left your web site. Choose your colors and fonts carefully and use them consistently throughout the site.

Keep page layout consistent. Use a Web site template to enforce a uniform page structure. Visitors should be able to predict the location of important page elements after visiting just one page in your site. 

Design a clear and simple navigation system. a good navigation system should answer three questions: Where am I? Where have I been? Where can I go? 

The navigation system should be in the same place on every page and have the same format. Visitors will get confused and frustrated if links appear and disappear unpredictably. Don't make your visitors guess where a link is going to take them. Visitors should be able to anticipate a link's destination by reading the text in the link or on the navigation button. Users don't have time or patience to guess.

Large or complex sites should always have a text-based site map in addition to text links. Every page should contain a text link to the site map. Lost visitors will use it to find their way, while search engines spiders will have reliable access to all your pages.

Include a home page link inside your main navigation system. Visitors may enter your site via an internal page, but hopefully they will want to head for the home page. Link the site logo to the home page. Most sites include their logo somewhere at the top of every page - generally in the top, left-hand corner. Visitors expect this logo to be a link to your site's home page. They'll often go there before looking for the home link in the navigation system.

Include a site search box. A robust site search feature helps visitors quickly locate the information they want. Make the search box prominent and be sure that it searches all of your site, and only your site.

Check your page display at in a number of different screen resolutions to make sure that your most important content is visible when the page loads.

Include a form for users' feedback on your site.

A good brand creates or reinforces a user's impression of the site. When your site is strongly branded, that means that visitors will think of you first when they go shopping for your product or service.

Conduct usability testing. Usability testing helps you to replicate the experience of the average web site user and correct problems before real users find them.

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. 

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.

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. 

In my last post on business analysis, I described user stories and gave a comparison between user stories and use cases. In my today's post, I am going to describe use cases.

A use case (a case in the use of a system) is a list of steps, typically defining interactions between a role known as an "actor" and a system to achieve a goal. The actor can be a human or an external system.

There is no standard way to write a use case, and different formats work well in different cases. There are few templates to use for a use case.

Simple Use Case

Title: goal the use case is trying to achieve
Main Success Scenario: numbered list of steps
Step: a simple statement of the interaction between the actor and a system
Extensions: separately numbered lists, one per Extension
Extension: a condition that results in different interactions from the main success scenario. An extension from main step 3 is numbered 3a, an extension from main step 4 is numbered 4a, etc.

Complete Use Case

Title: an active-verb goal phrase that names the goal of the primary actor
Primary
Actor
Goal in Context
Scope
Level
Stakeholders and Interests
Precondition
Minimal Guarantees
Success
Guarantees
Trigger
Main Success Scenario
Extensions
Technology and Data Variations List
Related Information

Casual Use Case

Title: goal
Primary Actor
Scope
Level
Story: the body of the use case is simply a paragraph or two of text, informally describing what happens

Example of a Simple Use Case

Use Case Name: Place Order

Actors: Shopper, Fulfillment System, Billing System

Use Case Description: after the user selected items to purchase, user orders the items. The user will provide the payment and shipping information. The system will respond with confirmation of the order and a tracking number that the user can use to check on order status in future. The system will also provide the user with an estimated delivery date for the order which will include all selected items. The user may already have an account with the company with billing and shipping information.

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but don't to be human. An actor might be a person, a company or organization, a computer program, or a computer system — hardware, software, or both. The term "actors" are frequently interchanged with the term "users".

Actors are always stakeholders, but many stakeholders are not actors, since they never interact directly with the system, even though they have the right to care how the system behaves. For example, the owners of the system, the company's board of directors, and regulatory bodies such as the Internal Revenue Service and the Department of Insurance could all be stakeholders but are unlikely to be actors.

Similarly, a person using a system may be represented as different actors because he is playing different roles. For example, user "Joe" could be playing the role of a Customer when using an Automated Teller Machine to withdraw cash from his own account, or playing the role of a Bank Teller when using the system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. If actor is "sales rep for the customer" or "clerk for the marketing department" to capture that the user of the system is acting for someone else. This tells the project that the user interface and security clearances should be designed for the sales rep and clerk, but that the customer and marketing department are the roles concerned about the results.

A stakeholder may play both an active and an inactive role. For example, a Consumer is both a "mass-market purchaser" (not interacting with the system) and a User (an actor, actively interacting with the purchased product). In turn, a User is both a "normal operator" (an actor using the system for its intended purpose) and a "functional beneficiary" (a stakeholder who benefits from the use of the system). For example, when user "Joe" withdraws cash from his account, he is operating the Automated Teller Machine and obtaining a result on his own behalf.

Look for actors among the stakeholders of a system, the primary and supporting (secondary) actors of a use case, the system under design, and finally among the "internal actors", namely the components of the system under design.

The relationships between all the use cases and actors are represented in a Use Case Diagram.

A use case diagram is a graphical representation of a user's interaction with the system and depicting the specifications of a use case. A use case diagram can portray the different types of users of a system and the various ways that they interact with the system. This diagram is typically used in conjunction with the textual use case and is often accompanied by other types of diagrams as well.

While a use case itself might drill into a lot of detail about every possibility, a use case diagram can help provide a higher-level view of the system. They provide the simplified and graphical representation of what the system must actually do.

Limitations

Limitations of Use cases include:

• Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or non-functional requirements (such as platform, performance, timing, or safety-critical aspects). These are better specified declaratively elsewhere. 
• Use case templates do not automatically ensure clarity. Clarity depends on the skill of the writer(s). 
• Use cases are complex to write and to understand, for both end users and developers. 
• As there are no fully standard definitions of use cases, each project must form its own interpretation. 
• Some use case relationships, such as extensions, are ambiguous in interpretation and can be difficult for stakeholders to understand. 
• In Agile methodology, simpler user stories are preferred to use cases. 
• Use case developers often find it difficult to determine the level of user interface (UI) dependency to incorporate in a use case. While use case theory suggests that UI should not be reflected in use cases, it can be awkward to remove this aspect of design, as it makes the use cases difficult to visualize. In software engineering, this difficulty is resolved by applying requirements traceability, for example with a traceability matrix. 
• Use cases can be over-emphasized. For example, driving system design too literally from use cases, and using use cases to the exclusion of other potentially valuable requirements analysis techniques. 
• Use cases are a starting point for test design, but since each test needs its own success criteria, use cases may need to be modified to provide separate post-conditions for each path.

In my last post on business analysis in content management, I mentioned that methods used in business analysis are: focus groups, documentation analysis, surveys, user task analysis, process mapping, stakeholders interviews, use cases, user stories, personas, storyboards, etc. In my today's post, I am going to describe user story method.

A user story is one or few sentences in the everyday or business language that captures what a user does or needs to do as part of his or her job functions. This is a high level definition of a requirement containing just enough information so that a developer could produce a reasonable estimate of the effort to implement it.

User stories are used with Agile software development methodologies as the basis for defining the functions that a business system must provide. It captures the "who", "what" and "why" of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for a business user as that user's primary way to influence the functionality of the system being developed.

User stories are a quick way of handling users' requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing business requirements.

During the process of collecting users requirements, a business analyst gets together with a users' representative to identify the specific needs of the business and create user stories.

As the customer conceives the user stories, business analyst writes them down on a note card with a name and a description which the customer has formulated. If the business analyst and the user find that the user story is lacking in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory often using the INVEST guidelines.

The INVEST guidelines was created by Bill Wake as the characteristics of a good quality user story: 

User stories generally are not created to be too definite once they have been written down because requirements tend to change during the development period.

User stories generally follow the following template:

As a "role", I want "goal" so that "benefit".
As a "user" I want to "do something" so that "I can accomplish goal".
As a "user" I want "function" so that "value". 

There is also shorter version:

As a "role", I want "goal/benefit"

For example:

"As an estimator, I want to see all items I need to estimate this season so that I can see the volume of my work."
"As a user, I want to search for my customers by their first and last names."
 "As a user closing the application, I want to be prompted to save if I have made any change in my data since the last save."

It is very convenient to write user stories on cards which could later be arranged on a board to facilitate their discussion with a team. These discussions are important for the optimal project planning.

As a central part of many agile development methodologies, user stories define what is to be built in a project. User stories are prioritized by developers to indicate which are most important. User stories then will be broken down in tasks and estimated by developers.

User stories could be written with various details. Sometimes they describe too many functions. Such user stories are called epics. For example:

"As a user, I would like to be able to have documents workflows."

Such user story would be too large for an agile project to complete in one iteration. So, it would have to be split into smaller stories so they could be worked on in iterations. For example

"As a user, I would like to be able to send documents through a workflow to be approved." 
"As a user, I would like to be able to send documents through a workflow to be reviewed."  

Agile projects use a product backlog which includes list of functions in prioritized order for the development. User stories is very convenient and popular way to create product backlog. It is important to remember that user stories are not completed until they are discussed by a project team. Product backlog is not a replacement of the requirements document. User stories could help in creating the requirements document.

Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the user to validate it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered.

Agile methodology favors face-to-face discussion over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:

• Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks. 
• Allowing a developer and a user to discuss requirements throughout the project. 
• Needing very little maintenance. 
• Only being considered at the time of use. 
• Maintaining a close user contact. 
• Allowing projects to be broken into small increments. 
• Being suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process. 
• Making it easier to estimate development effort. 
• Require close customer contact throughout the project so that the most valued parts of the project get implemented. 

Some of the limitations of user stories in agile methodologies:

• They can be difficult to scale to large projects. 
• They are regarded as conversation starters.

While both user stories and use cases serve the purpose to capture specific user requirements, there are major differences between them: