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.