What is Usability and How Does it Relate to Business?

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.

Optimize Web Experience Management

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.

Website Usability

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.

What is Usability?

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

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

Usability is defined by 5 quality components:

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

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

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

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

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

Definition: Useful = usability + utility.

Why Usability is Important?

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

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

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

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

How to Improve Usability

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

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

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

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

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

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

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

When to Work on Usability

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

for multiple studies.

Follow these steps:

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

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

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

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

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

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

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

Where to Test

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

Misconceptions About Usability

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

Misconception - Usability Is Expensive

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

Misconception - Usability Engineering Will Delay My Launch Date

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

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

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

Misconception - Usability Kills Creativity

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

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

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

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

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

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

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

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

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

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

User Acceptance Testing

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

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

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

Prerequisites

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

What to Test?

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

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

How to Test?

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

UAT typically involves the following:

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

UAT Planning

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

Designing UAT Test Cases

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

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

Selecting a Team That Would Execute the UAT Test Cases

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

Executing Test Cases

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

Documenting the Defects found During UAT

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

Resolving the Issues/Bug Fixing

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

Sign Off

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

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

UAT Key Deliverables

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

User Study

You have decided to implement a content management or a document control system. This system that you are planning to deploy is for users. Everything you create is for users. If your system meets your users' requirements, they will use it. If your system does not meet your users' requirements, they are not going to use it.

They are the ultimate designers. Design a system that confuses users and they will go somewhere else. Build the system that frustrates users and they will not use it. No matter what you do, they will find all possible excuses of why they cannot and should not use your system. Users adoption is going to be very difficult, almost impossible if you deploy a system which is not based on your users' requirements.

But who are your users? Why are they looking for information? What information are they looking for? How are they looking for information? How would they like to search for information? How would like to author this information? How would they like to use your system? and similar questions - these questions you should ask your users before you deploy any system. You ask these and similar questions during user study which should be done at the beginning of your project. This is the subject of my today's post.

How do you study users and their requirements? There are few methods: surveys, focus groups, interviews, user testing. Select broad spectrum of users across the entire organization. Include major stakeholders, department or unit managers, major authors and consumers of information.

Surveys

This research tool provides an opportunity to gather input from a large number of people. They can be used to gather qualitative or quantitative data. You can send them by email or you can use free survey tools like Survey Monkey. When creating a survey, you will need to limit the number of questions if you want a reasonable response rate. If you have too many questions in your survey, users may not return the survey to you. You may also have to guarantee anonymity and offer an incentive.

Since there is little opportunity for the follow-up questions or dialogue, surveys do not allow you to gather rich data about users' information seeking behavior. The survey results can provide you with a powerful political tool. For example, if 90% of users say that they have a problem searching for documents and are frustrated, than this could be used as a compelling reason to improve the search by having a better system or improving existing system.

Focus Groups

When conducting focus groups, you gather groups of people who would be users of your system. You might ask them questions about what features they would like to see in your system, demonstrate a prototype of a system, and then ask users' perception of the system and their recommendations for improvement.

Focus groups are great for generating ideas about possible content and functions for the system. By getting several people from your target audience together and facilitating a brainstorming session, you can quickly find yourself with list of suggestions.

They could be used to prove that a particular approach does or does not work.

Interviews

Face-to-face sessions involving one user at a time are a central part of users' study. You typically would begin with questions. Some of the questions you might ask are:

• What do you do in your current role?
• What information do you need to do your job?
• How do you search for this information?
• What information is most difficult to find?
• What do you do when you cannot find something?
• Do you create documents that are used by other people or departments?
• What do you know about life-cycle of your documents?
• What happens after you create them?
• If you could select few features in the upcoming content management system, what would they be?

In determining what questions to ask and especially how to determine what features users would like in the system, it is important to remember that users are not content managers or information architects. They do not have the understanding or vocabulary to have a technical dialog about the system or its architecture. So, you need to be prepared to interpret what they might tell in general to specific system features that you already know about and then provide this information to them in your response.

User Testing

In basic user testing, you ask a user to do a task, for example to find information in the current situation. You can ask the user to browse or to search. Allowing about three minutes per task, ask the user to talk out loud while he is navigating. Take good notes and make sure you capture what he said and where he goes. You may want to count clicks and time each session. Include a range of audience types. It is particularly important to include people who are technically minded (for example engineers) and who are not (for example marketing) as they will demonstrate different behavior.

User study is iterative process, so you may have to repeat the same method few times. But whatever you do, do not underestimate the value of user study. If you would like to have the user adoption in the end, conduct the user study in the beginning.

Business Analysis - Use Cases

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.

Business Analysis, User Stories, and Agile Methodology

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 a short, simple description of a feature told from the perspective of the person who desires the new system capabilities, usually a user or a customer of the system. It 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.

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:

Letter	Meaning	Description
I	Independent	The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N	Negotiable	User stories can always be changed and rewritten.
V	Valuable	A user story must deliver value to the end user.
E	Estimatable	You must always be able to estimate the size of a user story.
S	Sized appropriately or Small	User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T	Testable	The user story or its related description must provide the necessary information to make test possible.

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 the CTO, I want the system to use our existing orders database rather than create a new one so that we don’t have one more database to maintain.

"As a user, I want the site to be available 99.9% of the time I try to access it so that I don’t get frustrated and find another site to use."

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

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

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.

One of the benefits is that they can be written at varying levels of detail. We can write user stories that cover large amounts of functionality. These large user stories are generally known as epics. Here is an example epic from a desktop backup product:

"As a user, I can backup my entire hard drive."

Because an epic is generally too large for an agile team to complete in one iteration, it is split into multiple smaller stories before it is worked on. The epic above could be split into dozens (or possibly hundreds), including these two:

"As a power user, I can specify files or folders to backup based on file size, date created, and date modified."

"As a user, I can indicate folders not to backup so that my backup drive isn’t filled up with things I don’t need saved."

Agile projects use a product backlog which is a prioritized list of the functionality to be developed in a product or service. Although product backlog items can be whatever the team desires, user stories have emerged as the best and most popular form of product backlog item.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of a user story (“As a user, I want…”) is incomplete until the discussions about that story occur. It is often best to think of the written part as a pointer to the real requirement. A user story could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

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:

User Stories	Use Cases
Provide a small-scale and easy-to-use presentation of information. Are generally formulated in the everyday language of the user and contain little detail, thus remaining open to interpretation. They should help the reader understand what the software should accomplish.	Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”.
Can be accompanied by Acceptance Testing procedures for clarification of behavior where stories appear ambiguous.	May be delivered in a stand-alone document.

Business Analysis in Content Management

Content management initiative starts with the analysis of the current situation and coming up with a solution and the strategy for this solution. This process is called business analysis. Business analysis can be defined as the discipline of identifying business needs and determining solutions to business problems.

The usual problem in content management arena is that employees spend a lot of time searching for information, re-creating information and while they are doing it, they are not being efficient and productive, and so the company looses money. Employees also use obsolete documents in their work and so the integrity of work and compliance is at risk.

How is this problem solved? By implementing a content management initiative. The first step of it is business analysis. It involves requirements gathering and development process. During this process you identify the specific needs of the business and then develop and implement the solutions to meet them. This could be for example a new content management system deployment, modification of a current content management system, integrating few content management systems, designing a search solution, etc.

Business analysis techniques are applied to develop an appropriate plan and then put it in to action. One has to take the big picture and break it into smaller parts. Business analysis always focuses upon goals, but in a bi-directional fashion.

Business analysis can be implemented to both set goals, and to achieve them. These goals will cover strategic business practices encompassing IT, business processes, and corporate policies. For example, what support would IT provide to the project and if a CMS is implemented, would IT be able to support it? What vendors should be included in the selection list? What business processes need to be included in the system selection and deployment, and its governance? What corporate policies should be in place? What are legal and compliance policies? and etc.

The Three Phases of Business Analysis

Every time that business analysis techniques are applied, there is a natural three phase progression, which can be explained in this way:

Phase 1 - Why? - This phase is purely about fact finding. Normally, this will involve the formulation of a feasibility study to examine the business case put forward for changes.

Phase 2 - Work - In this phase the business analyst will develop a project or requirements plan, which will need to be agreed with all stakeholders, and then implemented.

Phase 3 - Working? - This is the final phase, where any changes implemented need to be proven as working. Additionally, at this phase the business analyst needs to confirm that all requirements have been met.

Business Analysis Techniques

Depending upon the market sector the enterprise sits within, different business analysis techniques will be applied. Different techniques may also be applied at project level. Some of the most common of these techniques are:

PESTLE - (Political, Economic, Sociological, Technological, Legal and Environmental) - it is a technique which is suitable for evaluating external factors and the effects they have upon the business.

SWOT - (Strengths, Weaknesses, Opportunities and Threats) - it is used to identify possible opportunities and any threats to the business by evaluating its strengths and weaknesses.

MOST - (Mission, Objectives, Strategies and Tactics) - it enables the organization to perform internal analysis and identify the best way to achieve its goals.

CATWOE - (Customers, Actors, Transformation Process, World View, Owner and Environmental Constraints) - it is used to identify the main processes and entities which may be affected by any changes the business makes.

MoSCoW - (Must or Should, Could or Would) - it is used to prioritize both proposed changes and business goals.

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.

As the result of this business analysis, you would have a clear picture of what your company needs and how to achieve this goal.

Based on gathered requirements, the business analyst would produce a document called either "Business Requirements Document for ABC Project" or "Project Requirements Document". This document should outline the background of the problem and the proposed solution. This document usually is being handed to major project sponsors for approval.

If the project is approved, the document becomes "Functional Specification" and handed to IT for the implementation. If the business analyst is a project manager and content manager, he/she would continue working with IT to put the project into action and complete it.

I will continue this subject in my future posts.

Analysis Tools Used in User-Centered Design

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.

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.